First go and read this great post by Bill Caputo. Bill’s site doesn’t seem to allow comments right now so I’ll put my response here instead.
I think part of the problem is that the agile ‘movement’ is so top-heavy with consultants. For many of these consultancies its very hard to sell a story like agile, which isn’t for a specific technology, when it’s packaged as a technical solution. They have to make it a business process problem to get through the door at a high enough dollar rate, or (for bigger consulting firms) to get enough bums on seats to make it worth the effort.
Think of other cross company technology efforts like standards bodies. Are all of these racked to the gills with consultants? No, they have a bunch of CTOs, senior developers, or whatever who are having to live with this stuff every day in a consistent environment. They do have consultants too, but not drowning out everyone else.
I know that the agile movement started with a bunch of really smart people, most of which were consultants, and some of its current leads (tip of the hat to some of my previous colleagues still at ThoughtWorks) are brilliant and continue to add valuable insight to our industry.
However for agile to get to anywhere beyond where it’s become (mostly a big mix of fluffy ideas that are easily billable but which don’t really solve anything without the necessary discipline which most companies are incapable of) it needs a much better diversity of background of leaders. Unfortunately I don’t see that happening – it’s just too big. Take the Agile 20xx conferences – they’re now basically 3 things:
- 101-level training for newbies
- an expo for largely pseudo-agile consulting firms and mediocre tools
- a small amount of people who’ve known each other for ages catching up and complaining about the state of agile.
So I think you’re right, Bill, agile is dead. It served a good purpose, and did a pretty good job of giving our industry the kick up the behind it needed, but it is now pining for the fjords.
To end optimistically though, there’s still a lot of great stuff going on in our industry, its just these days I’m much more interested in technically based conferences and communities, and having conversations on the side of these around process. Its from these technical communities I’ve learned about things like Kanban, for example. And its a blessed relief not to have to justify whether the team I’m on ‘is agile or not’.
Mike Roberts
Interesting post Mike. I work with companies that are just implementing Agile or are adding to the current Agile practices they already have in place. Many companies are still stuck in a rut when it comes to implementing Agile, and so I’m not to surprised that the Agile 2xxx confs had tracks for newbies. As Seth Godin says, we will always be dealing with new people, so producing content on the basics for these folks is a necessity. On the tools and pseudo-agile consulting firms, I see that in many areas of tech, so it was bound to happen with Agile. Companies are going to need to look at how well their current tools and methods work, where they need to be improved, and either go that route or choose a tool that will work better to meet their goals. And for people complaining about the current state of Agile, I’m glad I don’t talk with those people. That gets old real fast.
I don’t think Agile, or at least not Agile principles, is dead. I see more companies going down the road. Ultimately all their goals are the same – better transparency into projects, predicable delivery, and faster delivery of value to customers. Agile is one way to help these things happen.
And whether or not there is a glut of consultants or not weighing down the community, Agile has laid a foundation that we can all build on.
Agile is a good development methodology, maybe the best, but its just a dev method and the danger of quick iterations is the possibility of missing the goal & or increasing disorganization as complexity increases. That’s where a clever bunch of people comes in handy, because they hold it together. If you put a clever bunch of people together then it increases the chance of success…well done to the people who made a shed load of cash of being more competitive than other people who were less creative, intelligent and savvy. However, it still takes huge amounts of cash to do development work and Agile doesn’t do much that is new to remove the risks of failure in IT projects.
Interesting post Mike. I work with companies that are just implementing Agile or are adding to the current Agile practices they already have in place. Many companies are still stuck in a rut when it comes to implementing Agile, and so I'm not to surprised that the Agile 2xxx confs had tracks for newbies. As Seth Godin says, we will always be dealing with new people, so producing content on the basics for these folks is a necessity. On the tools and pseudo-agile consulting firms, I see that in many areas of tech, so it was bound to happen with Agile. Companies are going to need to look at how well their current tools and methods work, where they need to be improved, and either go that route or choose a tool that will work better to meet their goals. And for people complaining about the current state of Agile, I'm glad I don't talk with those people. That gets old real fast.
I don't think Agile, or at least not Agile principles, is dead. I see more companies going down the road. Ultijately all their goals are the same – better transparency into projects, predicable delivery, and faster dekivery of value to customers. Agile is one way to help these things happen.
And whether or not there is a glut of consultants or not weighing down the community, Agile has laid a foundation that we can all build on.;
Well, well – amazing that my brother and I land up on the same page sometimes.
Mike, don’t know if you remember the somewhat tortuous title of my MBA dissertation – ‘multi paradigm multi methodologies as a method of managing IT projects’?! What this is about is that we can look at using both hard and soft paradigms as a means of managing IT projects – and maybe a combination of both is better at different stages of the SDLC (whether or not we’re waterfall, agile etc). There are some great techniques and approaches out there (including Agile, Kanban and other softer approaches) but in my humble opinion, the good project manager should be able to:
1) Select the methodologies most appropriate for the project under development at a particular point in time based on a variety of criteria. These would include scope, organisational culture, objectives, resources (both personalities and constraints) etc.
2) Implement those methodologies throughout the project’s lifecycle at the most appropriate time because that’s what suits – and not because that’s what some Quality Manual says you have to. (Which, as a QA manager, feels a little odd).
What I want to say is, that as an industry, we need to ‘professionalise’ ourselves, and we can learn a good deal from our colleagues in Operations Research. We may be the new kids on the block, but that block wasn’t build yesterday.