Note: This blog post was originally written when I was a consultant for OpenSource Connections.
Recently I had a chance to speak about Agile with experienced IT professionals from the 2011 class of the UVa McIntire School of Commerce’s MS in Management of Information Technology. This was a particular pleasure for me since I graduated from the same program earlier this year as part of the 2010 class. My talk was an introduction to agile practices, and talking about the values inherent in an agile team. You can see the slides here:
http://www.slideshare.net/o19s/intro-to-agile-practices-and-values
The discussion covered a lot of overview topics in Agile, in fact too many topics to fit into our one hour time slot! But true to form, the students in the class were great – they asked a lot of questions and we had a very engaging two-way conversation. I much prefer being “agile” in my presentations and having to skip material because the audience is engaged. It’s a lot better than a command and control presentation where only the speaker is talking!
Among the many great conversations were two that I want to highlight on the blog.
Tip #1: Failing Fast does not mean sacrificing quality
Agile’s value comes in iterations
One of the big values of agile development methods is the emphasis on short, iterative development cycles. This allows you to push changes to the customer more often, get their feedback, and incorporate that feedback into future releases. Iterative development allows you to get some incremental value from your work right away, instead of waiting until the “big bang deployment” when all features have been completed and are all released at once. Big bangs are riskier because you haven’t received any customer feedback yet or seen how the customer will use your software.
Failing Fast means knowing what the customer really wants
In agile, we talk about “Failing Fast” because if a customer doesn’t like or doesn’t use a feature we are working on, we want to know that as soon as possible. That way we don’t expend any unnecessary effort on developing a feature that the customer will never use (also referred to in some cases as “gold plating”).
I like the term “Failing Fast”, but it’s important to understand (as one of the MSMIT students pointed out) that the failure we are willing to accept in agile is failure of the business value. In other words, if we are building something that doesn’t deliver the expected value to our customers or our business, we want to know about that failure sooner rather than later, so we can adjust to it.
Failure does not mean failure in the quality of the code.
Code we deploy in agile development methods should still be well tested (preferably using Test Driven Development methods and Continuous Integration), and we should be highly confident that what we are deploying will work as designed. We just aren’t confident yet if the customers will like what we have designed – and that is what we want to find out as soon as possible!
Tip #2: Avoiding Bad Standups
Another particularly interesting discussion we had was about what makes a good “standup.” Many teams believe they are agile because they have standup meetings. The reality is there’s a lot more to agile than daily standups, and if that’s all you’re doing, you’re probably not even doing the standup correctly in an agile way.
Basic rules to follow when conducting your standups
- Stand ups should be no more than 15 minutes.
- Each developer only discusses the three items (What did I do yesterday, What am I doing today, Am I encountering any obstacles)
- All other items of discussion should be taken off line after the stand up, and only involve interested parties, not the whole team.
- Product owners are always invited to the stand ups, but they should be a listener only. If they have questions they can bring them up with individual developers offline.
- As I saw posted on a discussion board recently, standups should be “by developers and for developers.” They should be run by developers, not project management or clients.
Make sure everyone on the team values the standups
One team lead in the class asked how rigidly I believe you should adhere to the 15 minute length. He said that his team is spread out remotely, and so this is often their only form of communication daily, and that their meetings are more typically 30 minutes, but that it seems to be going well.
My first question was “Who thinks it’s going well at 30 minutes? You as the team lead? Or have you asked your team?” I was intentionally being slightly confrontational to make sure he realized that the point of the stand up is developer communication, and to see if he had a true sense of what his developers thought of these daily meetings.
The pitfalls of standups “in name only”
Often times when the stand ups are run by traditional project managers, they quickly become long daily meetings, and the only person who actually likes them are the project managers or team leads. The developers are bored, get distracted and annoyed that they aren’t doing something more productive (like developing code!), and they tune out. Because they tune out, they aren’t even listening to what the other developers are saying, and they lose all benefit of the conversation. The conversation becomes a hierarchical conversation between each individual developer and the project manager running the meeting, not a conversation between developers.
Those type of “standups” lose their value because when developers aren’t talking to each other or paying attention, they will not offer to help remove obstacles for each other or offer advice. It becomes more of a traditional command and control situation and de-emphasizes the collaborative nature of productive Agile teams.
The particular team lead who asked the question was perhaps a bit taken aback by my response, and paused a moment to consider it. Ultimately he said that his team does also see value in the 30 minute daily standups, but I hope that my response gave him pause to consider if everyone really saw the same value in longer meetings that he does. It’s always worth asking your team!
Dealing with remote teams in a stand up
With remote teams, it’s understandable that you might have longer phone calls so people can socialize a little bit (just a little though please!). But in those cases, as I recommended to the team lead, at least still focus on keeping the stand up itself to only 15 minutes. If people want to stay on the line and discuss things for another 15 or 30 minutes, that’s fine.
But if you get the real standup done first within your 15 minute time limit, then at least those who are not interested in socializing or further discussing that day will feel free to leave the call. By incorporating more detailed discussions and socialization into the stand up itself, you are forcing everyone to stay around for the whole call every single day. And that is definitely not going to be efficient for everyone.
In conclusion…
It’s often said that you can understand the basic concepts of agile in a couple of days, but it takes a lifetime to master. The concepts of iterative development, failing fast, and stand ups really are pretty simple if you stick to a few simple rules. But if you don’t master the underlying values of why you are doing Agile, and trying to empower your whole team (not just project management!), then you will inevitably revert back to a control & command environment and lose the benefits of whatever agile practices remain.
