For many organisations, Agile methods are replacing the traditional waterfall or cascading approach to web development. But it’s not always easy to implement, and sometimes Agile implementations fail. This isn’t usually down to the process being adopted, but another reason that can affect every team…
Agile as a project management method is such a great tool. Since I was introduced to way of working, I’ve been excited by the greater segmentation and breakdown of tasks, encouraged when I see items flow across my Kanban task board, and delighted when I’m scoping out a project. I have also been slightly uneasy at the unknowns–the potential for a new client requirement, for the stories that seem to spiral out of control because they need breaking down.
When Agile Fails
I’ve also encountered something that can stop Agile dead in it’s tracks. Something that is hard to overcome because sometimes, the habits have become so ingrained in an individual or organsation that it’s too difficult to overcome.
You see, in order to work in an Agile way you have to let go a little bit. It may be your project, your baby, but without the team having a meaningful stake in it, without them feeling that they own or are responsible for it, it can’t succeed.
"In order to work in an Agile way you have to let go a little bit."
If you’re used to telling people what to do, this might be something hard to get used to. Your relationship with your co-workers must change if Agile is to succeed. Your colleagues become just that-colleagues, not subordinates.
Now we take on the role of coach and guider instead of “manager”. But as a result, something better happens. We take on the role of “director”–someone who directs things, without necessarily being hands-on with every aspect of development.
Lose Control – in a Good Way.
Designers too need to let go of the total control they once had over the visual aspects of a project. Instead they guide decisions, as well as being guided themselves, by project requirements, by build requirements, and by the greater good of the project and the team.
If a designer is used to asserting his or her control over a project, that could react badly with the team, especially if there are cross words or absolute statements said out of frustration.
Think about it: what impact will venting frustration have on the team? Will they want to include me, or will I be excluded, even ignored?
Instead, visual designers can work with a team, and see satisfying results of being included as equal partners in the project. They can see developers and others involved using their guidance and recommendations in the project.
And what can be more satisfying that being approached by others for your thoughts? This can happen if designers lose control in a good way.
When a team is empowered to share equal roles, and be responsible for their segment of work a team flourishes. Once they have understood each of their roles and built mutual respect, the agile process can roll ahead well.
I’m not saying there’s never a need for animated discussion, for honest talk. There’s always a need for that-in the appropriate setting and with the appropriate amount of respect for your colleagues.
But if we learn to let go, to cede control to the group, to nurture the team to its full potential, to encourage discussion, encourage the challenging of assumptions, then Agile teams will not only avoid problems, but can really succeed in delivering a great project that everybody can be proud of.