Comparing Kanban to Scrum
David Anderson weighs in on the Kanban vs. Scrum discussion.
UppercuT - The Insanely Easy to Use Automated Build Framework
Rob has posted a series on UppercuT, an automated Build Framework for .NET projects. I tried it and had a build running in 2 minutes!
I recently stumbled across an article about Agile standup meetings told through references to the Chicken and the Pig project fable. The article is a conversation re-cap from the Yahoo Scrum Development group. The theme is chicken participation in standup meetings--how many chickens are too many?
Note: Throughout this blog post I will make references to chickens and pigs. My only meaning in this context is through the project fable mentioned above. I do not intend to convey any additional connotations associated with chickens or pigs. They are simply representations of the different roles in and around a software project.
My answer is 40%. When the number of chickens approaches and exceeds 40% of the total number of attendees in the standup, strange things begin to occur.
On a previous software project, my team’s standup meetings started taking on a presentation-like quality. Team member updates became terse. Real impediments were occasionally muted or missed completely. In general, the standup meetings became less about team collaboration and communication and more about project status updates. So, for a week, I counted and figured the percentage. 40% of the attendees were chickens.
It is not hard to imagine why the intent of a meeting can change over time in such an environment. On this particular project, the team members were actually asked to stand in front of the board and physically point to the story or task on which they were reporting. This was done so attendees could tell which index cards were currently being discussed. So not only was the standup meeting degrading to a forum for status updates, it also was being choreographed!
I understand the pragmatic-minded readers are probably questioning my 40% rule by now. Is there really something significant about 40%? No. It just makes better blog entry titles. My point is that standup meetings are similar to tools in a mechanic’s toolbox. The best tools are the ones that have a specific and narrow purpose. The all-in-one screwdrivers are usually flawed in some major way. They try to do too much, so they do not perform any one function particularly well. In my experience, standup meetings are similar. They do not serve multiple purposes very well.
So how do we know when our standup meetings are not serving their original purpose? Some simple observations will probably suffice. Here is my list:
Is the answer to the standup problem to un-invite chickens? That does not seem to be a good long term solution. Agile projects are supposed to be transparent. I think it is important for management to feel they are welcome to observe the software development process first hand. Agile teams need to be transparent and open to be successful. But openness requires a level of trust; and trust only grows when parties observe common boundaries.
My advice for managers and product owners: If someone invites you to watch sausage being made, don’t complain that it is gross. Up close, software development can be messy and a bit erratic. If you value transparency, then find a way to build trust with the team. If you need a status update, talk to your project manager.
My colleague and co-worker Lee wrote a bare-soul post recently about missing the boat as a developer, and it prompted me to do my own version about Agile development. Lee impressed me with his candor about his experience in software development. He laid his "code" soul bare for everyone to examine. That takes guts and thus the inspiration for this post.
I had a similar experience with Agile software development, albeit was a bit shorter time frame. Like many developers, I was well into my professional software development career before I was exposed to Agile. But even after I was exposed to Agile, I kept it at arms-length for some time, not really sure what to make of the new approach.
My introduction to Agile came at an organization that was in the process of converting from a rigid waterfall/phase-based methodology to Agile. We were learning as a group with the help of a few Agile consulting firms. Our organization had a few green, inexperienced, Agile advocates to provide a start. But for better or worse, we had to mostly stumble our way through the Agile learning curve.
I am a natural skeptic. I probably get that trait from my father who is the skeptic of skeptics. So when faced with these new ideas from the burgeoning Agile community, my natural skepticism kicked in. Abandon big up-front design in favor of emergent and incremental design? Crazy! Software requirements on a note card? Nuts! Writing unit tests before the code? Heresy!
As my organization explored Agile principles and practices, I thought about all the software engineering conventional wisdom that I relied on so heavily in the past. And everything about this new Agile approach just seemed so counter to my professional understanding. But as we experienced Agile development first-hand, it became clear that this movement had substance.
Soon we considered ourselves an Agile shop. It seemed that everything should be perfect. We left our dysfunctional waterfall days behind. We had the support of IT and senior management. We were doing Agile!
But through that experience, it felt like we still were battling a form of Agile low self-esteem. We seemed to continually question if we were doing it right. Were we Agile enough? Oh, there were plenty of helpers along the way. For any organization with a few thousand dollars to spend, there was an endless supply of Agile consultants willing to tell us that being Agile means doing “x.” Or to measure your Agile-ness, you could take an assessment to determine exactly how Agile you really are.
Eventually, I made an important observation about what it meant to be Agile. I found that Agile was just a means to the end, and not the end itself. It is futile to try to pump up your Agile self-esteem by convincing yourself and your team that you are indeed “Agile.” That you have arrived somehow in Agile land. Agile is not a state. Agile is not an end. Agile is just a vehicle, just a means to a goal.
I found my boat. Have you found yours?
I stumbled across an interesting post, Why “No Issues” Is Not An Acceptable Answer where Derick Bailey describes an "anti-pattern" in Agile team standup meetings. He observes it is a bad indicator for Agile teams when team standup meetings repeatedly result in every team member declaring "no issues." I agree that this condition is common, and less than desirable. But I disagree with Derick's proposed remedies.
Don't Be a Bean Counter in a Creative Process
The readers of this blog don't need to be reminded that software development is a unique, creative undertaking. Developers have to be writers, analysts, problem solvers, and engineers every day. Sometimes they have to be all these things in the span of an hour. That kind of journey is always going to have unexpected issues.
One aspect of Derick's recommendations is to document issues as small as 10 minutes and raise them in the daily standup meeting. I can't think of something that would render a standup more impotent. Everyone who has worked in an Agile environment has experienced the occasional marathon standup meeting. There are well known remedies for these lengthy meetings, but they all boil down to one thing: too much information! Just like you don't need to know the details of your co-worker's skin rash, you also don't need to know that Bob found a solution to his 10 minute unit testing problem. You do need to know that Bob encountered a serious bug in the ORM two days before a major release. If that type of issue is not raised during standup, then you really do have a team problem.
Sometimes in our zeal to improve a process, we pinch pennies. We think that we can squeeze another 2 hours of work out of the average developer per week if we can just get them to raise their daily 10, 20, 30 minute issues during standup meetings. In reality, we would just give that time back when we turn our attention from building software to counting beans. If you really believe you can improve software development productivity by tracking 10 minute issues, you need a different profession. This is software development, not a German train station.
Lightweight Methodologies Are Frameworks, Not Therapists
Derick also recommends, as a rule, requiring every team member to raise at least one issue during standup meetings. Do you know what that outcome will be? Every team member will report one issue during the standup meeting! So where does that get us? Well now our standup meetings are oriented toward following a prescription instead of a tool to raise awareness of real problems. We have just shifted the focus of a standup from raising awareness to process compliance.
If we have a team that is not raising issues properly, then we should not look to our methodology (Agile) to provide the solution. Methodology is a framework. It provides us the tools to do team software development. Dysfunctional teams need help with their specific dysfunction. And sometimes, we perceive a team dysfunction when there really is a team asset.
On a previous Agile project, we found ourselves in one retrospective playing a variation of the popular board game, Apples to Apples. But instead of the game's topics, we were using continuous improvement topics that we generated from our last iteration. The idea to play the game came from an Agile coach who had read about the idea in an Agile self-help book.
Our team was doing relatively well on the project. We had our troubles like any other real-world software team, but we were delivering software at a regular clip. So why were we playing a board game during our retrospective? It was perceived from the outside, that our recent retrospectives were not generating a satisfactory number of issues to discuss. We were not meeting our retrospective quota, so to speak. The board game exercise was designed to elicit more issues since it was supposed to be "fun." The result? We definitely registered more issues for that specific retrospective. Did the game help the team recognize and resolve more real issues? No.
Through the normal course of the project, the team matured and developed good working relationships. As any well-functioning and competent team, we increasingly were attacking and resolving issues as they presented themselves instead of waiting for the next scheduled retrospective. Naturally, each successive retrospective generated fewer issues. This should have been judged exactly what it was, a side effect of a maturing software team. Instead it was considered a dysfunction in need of remedy.
For me, this episode was our jumping the shark methodology moment. We forgot that a methodology like Agile is only a framework. Agile is just a tool, it is not meant to perform therapy on a team.
If you find your standup meetings are not producing value for your team, I would suggest digging a little deeper into the team dynamics. Tweaking your methodology is not the answer. I would leave standup meetings to their original purpose:
1. What did I do yesterday?
2. What will I do today?
3. What is stopping me?
Many people are looking to Lean as the Next Big Agile Thing. But the more popular lean becomes the more it will run into the same kind of issues as Scrum is facing now. That doesn't make Lean (or Scrum) worthless, it just reminds us Individuals and Interactions are more valuable than Processes and Tools.
