Agile isnt a silver bullet

It has been 13 years since the Agile Manifesto was officially published. Have we solved all of the project teams issues? – not even close. In this post I want to summarize some of the knowledge pieces that explain whats not agile and why agile isnt a silver bullet. Lets start with a wonderful quote on this subject

“The next thing that happened is … that [agile] becomes such an overused word it starts to lose any meaning. So now the question is, does it meaning anything? ” ~ Alistair Cockburn

Article 1: Alistair Cockburn on what’s agile, what’s not

You know you’re not doing agile if:

1. The team is co-located, but people are not sitting within the length of a school bus to each other.

2. They’re distributed, and there is an absence of microphones and webcams and one or two meetings a day.

3. They have not delivered anything to real users in the last three months. Some of my agile friends would say that’s much too long, but I’m being generous there.

4. If no user has seen real running software inside the last month.

5. They don’t have the output of last month’s reflection workshop or retrospective on the wall.

6. They don’t have fully automated unit tests, and a large number of acceptance tests aren’t automated.

7. They’re not having a build integration at least once day. Good groups do it every half hour; there are groups that get away with it every other day.

8. They write big requirements documents, and they don’t know how to split those up into smaller pieces so they could deliver a piece of software every month.

9. They have itty-bitty requirements on the order of “here’s what happens when you click here,” but they don’t have long-term vision for what they’re trying to accomplish.

10. People keep saying, “It’s not my job.” One of the things about proper agile development is that there is group accountability for results. Very specifically, if the requirements are not coming in fast enough, whoever has a bit of spare time (programmers, testers, etc.) drops what they’re doing and helps gather requirements; if tests aren’t getting done, people with some spare capacity help test and so on.

Article 2: When Agile Fails – Boris Liberman

Three instances when Agile fails:

1. There’s not enough research.

For projects that involve research it becomes clear that over time the iterations cannot be completed as a single piece of work. You absolutely have to spend an entire iteration designing the work that will have to be done. During the next iteration you have to get that work done. Now, each design effort turns out to be a bit of research with great uncertainty as to the results and duration.The outcome of this is either “design to time,” which leads to a potentially low quality/under-featured product, or a project that slips its schedule because the problem turned out to be more complex than was originally anticipated.

2. The schedule (inevitably) slips.

The actual complexity of the problem does not decrease because the team uses Agile. As such, Agile does not provide a solution for the situation where the assessed duration of a project is significantly less than the time that it will actually take, making the timeline difficult to follow.

3. Your team isn’t jelled.

If your team is not really jelled, you have to pay extra special attention to the developers, since under Agile framework the cost of an error can be very significant, due to the very likely possibility that there is a lack of detailed project plan existing before the Agile process kicks in.The process of “jelling” the team, where people grow to trust each other, understand their team’s strengths and compensate for team member weaknesses, is a very lengthy process. Agile is very much a double-edged sword here. If people on the team are predisposed to openness and are of relatively similar experience, background, etc., the team will jell easily. Otherwise, extra effort has to be invested here from the standpoint of the organization.

Not agile