What does it mean to be agile?

Question

We have a project that everyone says we will be doing in a agile way but I doubt we have clearly understood what agile is.

In previous projects we had planning meetings, then defined the product back log and allocated the work to developers in 2 to 3 week sprints. Every morning we had scrum meetings (which seemed to go on for 1/2 an hour each time) and each developer got on with it after that. Hardly anyone wrote any tests until at the end of sprint and work that was not completed was added on to the next sprint.

Developers hardly spoke to each other and there was no TDD involved in development. In fact most developers had a spec at the start and just got on with it for the 2 or 3 weeks the sprint was arranged for. There was hardly any communication with the client/stake holder.

QA got involved usually a few months later and by then we found missing requirements which further increased the amount of work we had to do. Clearly there was no feedback loop.

So my question is, where did we go wrong and how can I prevent the team from making the same mistakes.

Answer 1

What you are describing isn't Agile by definition (Agile Manifesto) it is Waterfall with daily status meetings. Agile means easily adapting to change, if there is no interactive feedback loop with the product owner and thus the customers, then what change is occurring?

Agile is about rapid failures, through constant communication with the product owner/customers. It is better to fail sooner than later, less work is done, and less is "lost". And you don't get stuck with the argument, that "we don't have time to do it correctly, since we spent so much time doing it wrong, we just need to continue on this same path, even though it leads to failure".

Sounds like your managment is doing "SCRUM, but ..." where the "but" is where they throw out all the SCRUM stuff that they don't understand or agree with and just do things the same haphazard waterfall way as always, but with new shiny buzzword names to it all.

In SCRUM the daily stand up is NOT about delivering status to management, it is to force developer interaction, so you know what your fellow team members are doing and can help each other out and not duplicate work. If it takes more than 45 seconds per person you are doing it wrong. It is about transparency for the team, if one person is giving the same status multiple days on something that should be a single days worth of work, the team can resolve the persons problem sooner than later.

If you aren't testing each others code as it is written, then you aren't doing it correctly either. Testing should be embedded into the process not an after thought. QA should be included in the planning sessions and give estimates on how long things will take to test.

If you are not meeting Sprint commitments and rolling things over, you aren't doing it correctly. Sprints are about commitments if you are committing to too much work, stop doing that, there is no way you can introduce any predictibility or repeatability if you can't accurately commit to deliverables.

Answer 2

Jarrod provided a good answer (+1 to that) and I'd like to extend on that a little.

Agile isn't just about rapid failures and feedback between product owner(customer) and the team; it is about rapid feedback between all stakeholders involved. To be truly agile (and this is directly from the manifesto) is to recognize that process exists only to help developers in delivering better product. People above process means that as soon as the team recognizes your existing process doesn't work, you change it and make it work.

"Scrum but..." is also an issue, but there's both sides to this coin. If you look at the manifesto you'll see that it's about the team and making tools/processes work for you. No two teams are the same and therefore each will operate slightly differently and that's ok. You could certainly, take the entire Scrum methodology and try to follow it to the letter and see if that works for your team.

Another alternative is instead of pushing another process onto the team and making everyone follow what Scrum tells you to do, try the agile approach: Communicate with the team and see if together you can identify problem areas and solutions for each one. Then gradually introduce changes in the way you work so that problems are addressed.

It might take a little while, but...

1. You will fix biggest issues first which will have the largest impact on your teams ability to deliver product
2. By identifying immediate problems and participating in coming up with solutions, your team members will understand why certain practices are important and won't simply do them because they are told to do them.

If we draw an analogy between Scrum and a design pattern, working the way I proposed would be similar to coding into a pattern, where you keep code as simple as possible and only converge on a design pattern when needed. As opposed to just picking a design pattern and rolling with it (i.e. blindly selecting Scrum and all its processes as one set), which sometimes makes the code more complex and harder to maintain than it could have been otherwise.

The key to understand is that agile is not about coming up with a new process for doing things; it's about continuous change and constant adjustment to existing processes/practices.

Answer 3

if the team (and its management) truly want to "be agile," they should start by reading and discussing as a team the Agile Manifesto and its principals. Then pick one of the agile methodologies that have been created (Scrum, for example), get some training on it, and start by following that. I'd recommend following it pretty closely for a while before modifying it, but that's just me.

They should also look deeply into Engineering Practices which are used to support the particular agile project methodology chosen.