Agile - When does it work well, and when doesn't it?

Question

Our team is debating whether we want to become Agile or not. None of us are really fluent in Agile. I'd like some thoughts on when Agile works well, and when it doesn't.

To give a little background, we are a small group of developers, six in total. We have far more work that we can handle. Our priorities change often. What is a high priority today, may not be tomorrow. We have many applications to create and maintain. We have started to dabble in Agile practices to the extent that we have daily scrums and two-week Sprint cycles.

If you need more information to answer this, please feel free to ask.

Thanks.

Answer 1

It appears your priorities are changing far too frequently for either methodology Agile or Waterfall. With priorities changing frequently, you are likely churning in and out of projects leaving a lot of them partly done. The Agile alway be ready to release may help. It has been my experience that getting a methodology in place will improve productivity.

Your situation reminds me of a project I worked on. The developer on the project asked one question at the start, "Do you want me to be do it right or be responsive?" I was on the project when it was two years into a six month project. One week the same functionality was implemented Monday, Wednesday, and Friday. Tuesday and Thursday were spent removing the functionality.

I would suggest you start adopting practices from Agile. Scheduling a short sprint period could help with changing priorites. It may be easier to maintain priorities for a period of a week or two and may make it easier to stabilize priorities. You will also need a backlog (sounds like you have a large one already).

Management may be more willing to hold off new priorities if you can slot them into a sprint in a week or two. You will also be able to identify the priority tradeoffs. If you add something to the next sprint, what will be removed.

Consider having part of the team working Agile while the others maintain the status quo. Rotate one team member each sprint as you are gaining experience. Consider having the whole team participate in a daily stand up status meeting, and the post sprint review. Once you have demonstrated increased productivity and returns to the company you should be able to increase the amount of work being done using your methodology.

Agile is a adaptive methology. Expect to be making major changes to your methodoly for the new year or two. Eventually, you should reach a stage where you are fine tuning.

Answer 2

Ralph Stacey's complexity matrix is commonly used to illustrate the sweet spot for Agile:

For simple projects (where both the requirements and the technologies are well known), the predictability is high so a predictive methodology (waterfall) works well.

For complicated and complex projects (and the vast majority of IT projects are), predictability is low and a predictive methodology won't work, an adaptive approach should be preferred. This is where Agile works well.

When both the requirements and the technologies are unknown, you're close to the chaos and the odds of failure are very high, regardless of the methodology.

Answer 3

Reposting a related answer of mine:

The discussion is usually agile vs. waterfall, right? I am linking an article, but it is in Portuguese, so I'll try to transmit some of its ideas:

Waterfall is like chess. You think and plan a lot, try to foresee every possible issue as soon as possible. There's a lot of planning, but makes sense only on stable and well-known domains, where change isn't much expected.

Agile is like soccer (or many collective sports): decisions are made in-game and should be done fast. There's no much time to analyze every consequence. It is "ideal" for dynamic and unstable domains, where change is always expected (web applications, for instance, tend to fall in this category). Another point to note is: even if you have the best players, if they don't do well as a team, you won't be the winner.

IMHO, Scrum would be useful, because:

• Once every two weeks (or every month, depending on iteration time) you'll be able to see what's working or not. And this is very valuable, specially as an "amateur" team, which is expected to be learning and finding things out much more constantly.
• As amateurs, you probably won't be able to foresee everything (and that's something agile embraces)
• There's more space for sharing experience (stand-up meeting, retrospective, and even planning meeting). And you share REAL experience (you must write code every week rather than just plan)

Answer 4

In my experience, you absolutely need the following for agile (XP or Scrum at least) to work. Without these prerequisites you are likely to fail. Hard.

1. Team must be stable and 100% dedicated to this.
2. Team must be colocated in one workspace.
3. Customer/product owner must be available on site at all times.
4. Support from management. This means providing funds and courage to ensure the points above.

Give these points, you can probably tackle anything as long as you keep to the values.

Answer 5

I'm speaking only from experience; YMMV.

My team was unsuccessful at making agile work. IMO, it was because:

• The very first time the dev team would hear about a project, it was in the form of a requirements document and a deadline.
• Stakeholders were often reluctant to take time to look at the result of a sprint's work, thus they would not take action between sprints if they thought the project was headed in the wrong direction.
• When we showed stakeholders our work, they generally just OK'd it. They would talk about what they would like, to which we would reply "That can be done in about X amount of time," to which they would reply, "Well no need to go over the deadline for that."
• The deployment process was long and complicated, discouraging frequent deployments. So in practice, we often deployed things when a 2-month project was done, not at the end of a sprint.
• Our sprint planning meetings were long and inefficient.
• It seems everyone was confused about what scrum is (and about what our process was), except for the scrum evangelists.

So I'm pretty sure we were doing it all wrong. Don't you do it wrong, too.

Some things that have sped us up, which we continue to use:

• automated builds that work on everyone's machine (HUGE help!)
• a formal arrangement for our code repository
• learning how to apply apply abstraction mechanisms to UI code
• refactoring
• unit and integration tests
• continuous integration

I guess you could say that our code is more agile, though our methodology is less agile. Whereas before we could not keep pace with demands, now we can.

(I'm not saying agile is bad; I'm just reporting my experience. Also, please understand that I do not choose what methodology we use.)