What makes agile software development agile?
ieeexplore.ieee.org
ieeexplore.ieee.org
Or less kindly, the sponsors don't know what they want, so we do a lot of hill climbing instead of going directly to our target.
You know where you are, you know where you want to go (what customers are asking for), and you can break the transition into discrete steps. Can sit with the dev team and say in 6 months we want to be roughly here - and then tell them what you want to see in 2 weeks. If they deliver on commitment in 2 weeks, they've done their job, and everything else is on me. If they tell me there's a problem, or point out some stupid mistake I've made - I can take that on board (new stories, new prioritization), and explain to everybody above why there's a delay. Thing that I love most of all, is "we could make this better if". Hands down the things I'm most proud of, are when dev tells me something elegant and wonderful can be produced and I can say yes.
Two places I think agile can go wrong: 1) Used where it shouldn't be. If there is some complex multi-year piece of work, somebody (product or architects) need to understand the vision. Nothing great is made 2 weeks at a time in isolation, and then presented 2 years later. 2) There needs to be slack in the system. To me the shining benefit of agile is that you can meander away from "the big plan" and add value where you see it. MVP should be say 70% of effort, with 30% we can all choose to use wisely. A complex system built from only MVP is going to be a turd.
Management saying so. Just my experience.
Where it does horrifically wrong, is when somebody who doesn't like the projection decides to ignore agile to correct it. "I'll just remove this dependency, I'll increase this teams capacity arbitrarily etc."
I think there are many methodologies that would work - I think every problem comes from somebody trying to corrupt the rules of the approach.
> increasing degrees of agility
This I can certainly agree with.
But from my experience “agile” is code for ”we aren’t going to consider the future AT ALL, we’ll be paid to redo all this work”.
I’m sure my experience is an outlier but I was managing an outside company to work on an App for us, not being in our wheelhouse at all. What we paid for what we received haunts me.
I have never seen such poorly thought out, poorly documented, and just barely working code turned in as from this group that was touted for their excellence and speed. It was all disposable code. Nothing mattered because it was all supposed to be rewritten, at ridiculous hourly costs.
Speed sure. But you know what, it’s like anything else and good in moderation.
The abstract mentions only 15% of their data points were “true” agile and I get think I get why.
Sometimes you need to think ahead and from what I’ve seen agile is bad at that. You’re just supposed to pay for duplication of work, when the forethought might have been the better asset allocation.
There are many good ideas in "agile" however. The idea behind doing things fast (and loose) is that you will fast get feedback, about whether what you are doing is the correct thing or not.
Now when you realize that that what you are doing is not the right thing, that is when "agility" is needed. How easy will it then be to change what you are doing? If it is easy then your "degree of agility" is high. If not then no. And still, it's very hard to measure your "degree of agility".
This seems to be standard practice especially around modern "devops tools"
* Release very often and very early
* Break backward compatibility every 6 months at least
* Completely ignore reliability, security and defensive programming at first. Rewrite everything over time.
* Deprecate and replace major feature every year
Essentially end users have no choice other than upgrade on every new release and fix the breakage.
I would have tried using agile practices. You would have seen the code that first Friday and raised your hand and stopped more production. Instead, it sounds like you waited for things to be done, later found out it was crap, then wanted a redo (not agile). Agile has sprints, with weekly checkins, you would have found all this out that first sprint and given feedback.
At least in my experience.
"The issue is not the process, it's your implementation".
Dev: "WELL! I can't finish this by friday!" Ok well divide it in two parts, make first part done by friday. The second part goes in backlog.
PM: "When is everything going to be done!!?" Answer: Friday. "What about X and Y in the backlog." Plan it for next sprint.
Important part: Monday we re-group with PMs,POs figure out what is most important to work on this new sprint BY showing them FUNCTIONAL code that was finished the last sprint. There are no "roadmaps", no long term plans, it is due Friday.
Say if dev produce code that technically ticks your boxes, but they think there's an issue/oversight. Ideally you'd pick up the flaw, but letting them create an issue to track it is really important. Opportunity team (as I'm embracing the methodology) should take this debt as inputs, in the same way they would a screaming customer or pointy-haired-boss's ppt.
#edit - If somebody commits to deliver something by end of sprint, I want to see it end of sprint. If they need to work the weekend to do it, then they work the weekend (and yes, I do know I sound like a dick). The reason why this is OK, is that commitment should only ever come from dev. I might like it to be done in a day and have no idea why it will take a week, but if I'd told it will take a week, it'll take a week and that's what does onto any projection.
But 90% of the time, it's pointless since the business isn't agile.
You have layers of management from the CEO through dept heads to unit leaders etc, and then you hit the actual devs/QAs/POs, etc... and agile starts here.
At the end of the day product development involves shipping improvements that matter in a reasonable timeframe. Usually this means that someone, somewhere has to manage a roadmap and make sure that people are getting the dedicated focus time to deliver major improvements over prolonged periods of time.
"We follow an agile methodology": "We will accept arbitrary requests to project scope"
"We have a RESTful API": "Our ad-hoc HTTP API is not stressful to use"
You mean you want some kind of abstract?
Agile was and in my eyes still is, the anti-thesis to anyone in it for the prestige, the power and control.
Its the difference between "Military Orders" based hierarchical command and Mission based command.
You do not say such things out here in public, you go through the proper channels, and i do not want to hear this "initiative" nonsense. If a comment is not approved by the comment-committee, we do not post it.
Just because some startups work hyper-productive with everyone a shareholder principles- that does not scale to us.
I do not want to have this discussion again, happily ever after. Clean up your act, proof that your comment is worth the time to engage, and then, when you earned your spurs, maybe then, we can have this talk about that precious hierarchy of yours.
Just because hierarchy are the arcade chips, most large companies pay their loyal hordes, does not auto-instill a value to the company into it. If that were that way, there would not be a constant need to buy those little, "flatland" startups - with the money the hierarchy-galley earned by rowing.
I didn't say hierarchy, I said structure. There are many different ways to structure an organisation, which will vary according to growth, size, needs, and many other factors. If you want your organisation to function well it's worth putting in the time on structure.