Heard these phrases before?
“How hard can adopting Agile methodology be?”
“If I go on a ‘Certified Scrum-Master’ course, it will all be ok, right?”
It is very common for agile to be misunderstood by all levels of user.
For a new team, starting to implement agile methodologies can be a daunting job and the initial task is often to read a book and take it from there. I’m not saying there is anything wrong with reading a book, infact why not read 2, 3 or more? But in my experience, reading a book only helps the person that is reading it, that book will need to go around everyone in the team, including Project Managers, CEOs, Customers and everyone else involved in the project. Then comes the fun bit of figuring out that everyone has interpreted the book slightly differently and they ‘don’t agree with all the principles’, this should ring alarm bells but in a lot of cases doesn’t. If members of the team don’t agree with all the principles of Agile, then implementing it effectively will prove problematic. Once everyone has read and digested a book (or 2), the next stage should be to get everyone into a room for some interactive training, this can be a chance for an Agile Consultant/Coach to come in and show the team how it works or it could be a chance for the team to get together and discuss everything they have understood, either way the important thing is that EVERYONE buys into it. A Development team that buys in but a Development Manager that doesn’t can cause no end of issues with how the project will be run, or the more common case, the team buys in but the higher level management still want to see plans and schedules and a final release date. Of course, especially for a team new to agile, a firm schedule is very difficult to estimate when a teams velocity is unknown and a ‘firm’ schedule does slightly defeat the point of the term ‘Agile’.
A problem that is maybe a bigger concern is the team that ‘half-heartedly’ buys in to Agile, they send one person on a Certified Scrum Master course and then have all the sprint related meetings (Kick-Off, Planning, Daily Stand-Up etc) but do very little else, so no TDD, no Pair Programming, no backlog burn down. This probably suits the members who are ‘non-committal’ over the process as it means very little extra effort apart from a few meetings. The problem with this is that there will be no marked quality improvement in the deliverables and they won’t neccessarily be delivered any quicker. It is imperative that when implementing the agile processes, that it is disciplined and everyone is fully accepting of what is expected of them.
Agile should be implemented on strong foundations of understanding and willingness to change from top to bottom. By change, the most important one is a change of attitude over the priorities, working software instead of intricate design documents, willingness to respond to change over following a strict plan (not to quote the agile manifesto of course!). The team will need to be motivated and recognised for successes, so maybe a pizza delivery lunch once a sprint or maybe even a day out team building, these kind of gestures will get the team bonding and wanting to work together to produce the goods! The agile process should be a positive change, if it isn’t working, analysis of the root cause should be done and any issues resolved. There may be a chance that the change to agile isn’t right for the team/project and if that’s the case, then a process that brings the best out of the team should be identified. It isn’t for everyone, but those who use it and use it well have never looked back.
It should be understood that a difference in results will not happen overnight, to get the whole team on board and to produce reliable frequent deliverables of higher quality will take time and investment.
So be patient, I believe it’s been said before: “Good things come to those who wait!”