I keep hearing complaints of projects who go sprint-after-sprint with their Agile project and can’t make progress. Regardless, the methodology, I’ve got three observations to pass along to readers. For the past few years, Agile seems to be the hot topic but it’s still no guarantee for project success. Read on for more thoughts:
- Any Methodology is Better Than None: Anyone who starts using a methodology, such as Agile, sees some good results, and then claims that that methodology is the best thing ever is deluding themselves. When you start with nothing, anything is an improvement. I ran across research about this when I was in grad school and it was compelling research. In the years since that, I’ve come to truly believe that it doesn’t matter what you pick – if you pick something, learn it well and stick with it, it’s going to help your process.
- There Will Always Be People Who Make Excuses: Whatever methodology you select, there will always be people who claim it’s no good and will tell you why it’s not working. Every methodology has it’s good and bad points and you will have your areas where you need to improve, too, but don’t throw away what you’re doing only because you need to put more work into it. Learning something that is more “hot” or “cool” won’t make your projects better.
- The Latest, Greatest Methodology Won’t Save You: There is no methodology that will save you from yourself. I’ve seen projects do well with “modified” Agile (it seems that no-one can take a methodology and use it without making their own changes to it so I want to be careful about making any claims about success or failure with regard to this). There are also plenty of projects that just can’t get a foothold in a new methodology. I’ve seen companies that claim they’re entirely switching to Agile but have teams who, sprint-after-sprint, make little to no progress. It’s possible these teams just can’t work properly using Agile or that there’s some other problem within the team. Somewhere, they might not have the right tools or the right training. In any case, throwing Agile at them and forcing them to fail sprint-after-sprint isn’t doing anyone any good. Companies don’t want to spend the time to determine what the cause of failure is, which is why they pick one methodology for everyone, to begin with, thinking it’s some kind of solution for everything wrong within the organization, but it’s not realistic. When a team fails, you have to roll up your sleeves and help them. Too often, this leads to blame. Blame doesn’t solve the problems. Only hard work gets you closer to a solution.
Gloria Metrick
GeoMetrick Enterprises
http://www.GeoMetrick.com/
1. True,
2. Very True,
3. Very, Very True
And the worst methodology of the lot is one imposed by higher management who know an awful lot less about software development than they think they do. I spent a couple of years working (as a permie) for what was then a very large company. Someone in the higher echelons got the idea that structure charts were the way to go, and we were all signed up for a week’s course with someone from the company’s in-house training team. We sat through the first day of the course and at the end, when the tutor asked for questions, we asked “How does this scheme represent AST routines?” (asynchronous system traps, we were programming DEC PDP-11s, which shows you how long ago this was).
Well, after we’d explained to him what an AST routine did, he gave it a minute’s thought and then said, APPARENTLY seriously, “No, those aren’t structured, you can’t use those”. The system we were developing and maintaining of course depended TOTALLY on the use of such routines. 🙂
Bottom line, and IMO – any methodology which is imposed without input from the programmers who are to use it has an EXCELLENT chance of creating problems rather than curing them.
Methodology / Agile Success Issues (all related)
1. Methodology in Name Only. There is a claim that a methodology is being used but it really isn’t. The old processes are still in place.
2. No Methodology is an Island. It is difficult to use Agile (or whatever) when other parts of the team/department/company don’t. You may have a goal to do something in the next monthly sprint, but it won’t happen when dependent tasks have far different scheduling and expect it all pre-planned a year in advance.
3. Methodology shouldn’t be a Layer Cake. It is hard to get benefits when you just add Agile on top of waterfall. But see above.
4. Agile doesn’t mean there isn’t a set of requirements. They may look different, but you gotta have a constrained goal. The clients view of “no progress” may be the same as the programmer’s view of “constantly changing requirements” (aka .. I’ll know it when I see it..).
No surprise that almost everyone has to modify Agile. It has to somehow exist within a non-Agile environment.
When team members come to the Scrum and every day claim there is nothing holding them back yet don’t seem to be making progress, some of Greg’s points are worth looking into, right away.
For example, if team members can’t get what they need from another team because of different priorities, the team member doesn’t always realize that’s a roadblock. Some team members think they’re just being patient and “nice.” Or, they might happen to realize they’ll be criticized for not pushing hard-enough on the other team, which they might already have been doing and getting no traction. Team members sometimes just don’t report if they know they’ll get blamed yet they feel they have no real way to make the thing happen.
Last place I worked before retirement loved methodologies, it seemed every 6 months they came out with another revision to the previous one to fix the deficiencies and created more of the same, just different… Probably explains why simple projects ran over-budget and way over-time but we created marvelous reams of documentations…
One thing I try to tell my customers (and many do actually listen) but the level of documentation needs to fit the team. A tiny team can’t take on massive amounts of documentation and make progress.
When we talk about procedures, the amount doesn’t merely come into play regarding regulated versus non-regulated areas, but actually comes into play more from the size of the team and how much structure they need and want.
Too much structure to work isn’t the solution to not having the structure to get the team to the finish line. In the end, and I know this sounds revolutionary to some, but we do actually have to get the work done. If the structure doesn’t support that, then it’s not working.