Agile software methodology cannot be blindly applied to any team and any project to magically solve all of your problems. Scrum, Kanban, XP, Lean, whatever your favorite flavor of agile none of them are a finished product. I believe we’ve forgotten where the Agile methodology came from 17 developers getting together to discuss lightweight development methods. Read the language of the Agile Manifesto they were uncovering better ways of developing software. It was and I believe still is being uncovered. We’re not done.
Take documentation for instance. In the manifesto, one of the principles is Working software over comprehensive documentation. Like many other developers, I also don’t enjoy writing documentation. However I think far too many Agile managers and developers look down their noses when their clients ask for documentation. Yes, detailed comprehensive documentation will most likely be an albatross around the client’s neck as the application grows and evolves over the years and said documentation rapidly becomes outdated. But does that mean we should produce no documentation? We can certainly follow loosely defined naming and structure conventions to produce self-documenting code. Perhaps deliver a short document that explains the conventions used. I would go so far as to suggest that the functional requirements be maintained as a living document and updated on completion of the project to document what was delivered. How often does your team work out the design over a whiteboard? At the very least, take a photo and make it readily available to the team developing and then later to the team eventually supporting the application. Remember while we value working software over comprehensive documentation, it doesn’t mean that there is no value in documentation.
Many of the more popular agile methodologies come with processes and tools that their adherents rigid follow. Rigidity is not Agile. I’ve been told at various times that in order to be properly agile; I must conduct daily standups, have a co-located team, and have full client participation,. While this is definitely not a comprehensive list of all the things I was told I must do or I was doing it wrong, I think it’s illustrative of how their processes and tools have pulled us away from individuals and interactions.
I’ve worked with teams for whom the daily standup was critical. It had a clear impact on project success. Without the standup, we would not have been able to identify and address the issues that came up during the project with the speed and ease that we did. I’ve also worked with teams for whom the daily standup could have been an impediment. They were highly resistant to unnecessary meetings and preferred to all work in the same room with open lines of communication throughout the day. This team was able to function at a high level the cross talk wasn’t disruptive, but instead foster a tremendous level of collaboration. They were already achieving what I would have wanted the standup to accomplish. Clearly not all teams are as tight knit and collaborative, but the point here is to not lose the individuals and their existing interactions in an effort to impose a process. Evaluate the tool, in this case the daily standup, and figure out if it will work for your team; not how to make your team work with the tool.
Sometimes it is impossible to put together a team that can all sit in the same location. The developers available for you to bring to bear on the project may not all be staffed out of the same location. Your client may not have adequate seating for your entire team, but still prefers you to maintain an onsite presence to work with their development team. There are many reasons why a team might not be able to be physically co-located. However, I don’t believe that means you have to abandon agile principles. If adequate conferencing tools don’t exist or your team is even divided amongst time zones, a daily standup at the beginning of the day might not be possible. Again determine your intent and evaluate alternatives. A possible solution is to leverage the paradigm of social media tools like Twitter, Yammer, and SalesForce chatter and implement a solution that allows the team to communicate asynchronously over a dedicated stream for the project. For extremely geographically separated teams, consider having hand-off standups at the end of each team’s day the team finishing its day fills in the other about what they’ve just finished for that day and what roadblocks stood in their way and the other commits to what they will finish that evening.
The team might be bought in to the Agile Methodology, but is the client? Is this an absolute requirement? I don’t know about everyone else, but very rarely do I get complete buy-in from the client on the Agile methodology. At the start of the project, the client will agree to the sprint planning sessions and sprint reviews. They’ll agree to the concepts of the project backlog and malleable requirements. It all sounds great to them. Then the reality of the project steps in and the client isn’t available for all of the planning sessions or sprint reviews. They want to trust me to make the right decisions.
The argument is that I’m setting myself up for failure by letting the client trust me. I’d agree if I just took that at face value. When the client trusts me, they don’t trust me to make all the calls on priority, scope changes, and acceptability of deliverables. Rather they trust me to mesh their unavailability with the agile requirements and find a solution that will make it work. We have options when the strict interpretation of sprint reviews and sprint planning fall down. While not ideal, we can get buy in on the priority and assume that when the client is unavailable that priority will remain unchanged get buy in on that assumption. Determine if there are surrogates for functional areas, who can sign off what is being delivered each sprint. If not, how often can the stakeholder meet? consider adjusting sprint length to accommodate.
Sometimes the buy-in from the client is just lip service. They agree to the Agile methodology, but once the project kicks off they start demanding detailed project plans. Understand what the client is trying to accomplish it may be they are bought into the process, but they report to someone who isn’t. I’ve found success in these situations by creating a preliminary project plan based on feature priority. I let the client know that the plan is subject to change to meet their changing demands on scope and priority. Often they have trouble conceiving how the development team could accomplish all they’ve set out to do in the time allotted the plan helps alleviate those fears.
The reality here is that you need to find out what works for your team and your client. If it’s not working, find something that does. Don’t get hooked on the ceremonies over writing code. There are a good number of developers out there that seem to hate agile with a passion. From what I’ve read, it sounds like they’re working on teams that have gotten lost in the ceremonies and missed the boat on the entire point of Agile methodology enabling developers to write good code. Talk to your team about what’s working, nothing can be sacrosanct. Challenge everything and work to be continually improving the process. Help the community uncover the next evolution of the methodology. We need to be continually evolving the methodology, figuring out what’s still working and what has stopped working. When it stops working, stop doing it and try something else. We’re far from done.?