High-bandwidth communication
If you’re trying to do agile software development, high-bandwidth communication is incredibly important. It’s almost impossible to overstate the urgent need for team members to be in constant communication with each other and to know what’s going on at all times. That’s the only way people can make the right tactical decisions and adapt to the current situation rather than merely operate according to their understanding of the situation as it was a few days ago, or last week, or last month.
There are several ways to encourage frequent and high-bandwidth communication. Having a co-located team room is probably the best possible way to do this, though I’ve never had the pleasure of experiencing that for myself yet (but I will soon!) If, like all my teams up to this point, you’re sitting in individual private offices, then a daily standup meeting becomes super important. I often get pushback on the standup meeting, with people questioning why it’s necessary and whether the daily interruption is worth it, and here’s what I tell them.
The most important question
I’ve worked at Microsoft for a long time, working in several different areas of the company, and in that time I’ve observed that we often optimize for the wrong things. Historically, Microsoft has optimized heavily for individual developer productivity (in the sense of lines of code written). However, Microsoft doesn’t usually have a problem with devs writing code too slowly; most of our product code bases are enormous. We’re awash in code. What we actually struggle with is that we write the wrong code, or code that doesn’t work right, or we write a bunch of individual pieces of code that don’t interact well when we try to fit them together.
It turns out that an engineer’s job is not just to write software. His or her job is to deliver value to customers in a timely manner, make a valuable impact on the business, and ultimately to earn money for the company. Writing software is an essential step but it’s not actually the end goal. Delivering business value requires more than just individual code-writing prowess. It requires frequent, consistent communication across the entire team so that we’re all pulling in the same direction at the same time and doing things that actually matter. It requires a team-oriented mentality; we don’t make commitments as individuals, we make commitments as a team and we succeed or fail as a team based on the value of what we deliver.
With that in mind, the point of the standup meeting is not to communicate status to managers. We could do that perfectly well once a week over email. The point of the daily standup is to communicate together as a team so that every day each team member can ask and answer the question, “What is the single most effective thing I could choose to do today to help the team deliver business value?”
That’s a very powerful question to ask. Contrast that with the traditional Microsoft model of asking yourself, “What do I need to do to finish all of the tasks that have been assigned to me?” To answer this traditional question, you don’t really need to know what anyone else is doing or what’s going on across the team. You just crank through your assigned work. The problem is that the tasks that were assigned to you might grow stale very quickly; that is, the value that we thought a task had when it was written down might not be the value it has now because reality has a way of changing things over time. If you let “the plan” diverge too far from reality, you end up building software that doesn’t matter.
Avoiding wasted effort
Have you ever had the experience of spending months working on a piece of software only to have that software never get deployed/sold/used? I certainly have. I’ve seen it happen for all of the following reasons:
- When finished, the software didn’t solve the problem the customer wanted solved, either because: A) you never correctly understood the real problem in the first place, or B) you understood the original problem but it evolved and changed between the time you started and the time you finished, so the software you wrote to meet the original problem became ill-fitting.
- You ran out of time in the schedule and while you had a lot of code written, the pieces that were finished couldn’t be easily assembled to solve any problems on their own, so the whole thing was useless.
- You built good software that solved a real problem but your customers weren’t aware of what you were building or how much progress you were making so in the meantime they ran off and invested in some other solution instead, making your solution irrelevant.
The daily standup meeting (and the other sprint meetings we have) are intended to avoid those failure scenarios by creating frequent opportunities for communication. This communication is intended to make each team member aware of exactly what the state of the project is right now, today, so that we can make the best possible choice about how to help drive the team toward delivering real value. The task board is in a big visible location and is updated every day so we can see what’s been done, what’s left to do, and where we need to load-balance. We try to have a customer representative on hand so that we immediately hear about any changes in what the business needs from us and we can get good guidance when we have to make hard tradeoff decisions. We listen to what each team member is doing because we often pick up serendipitous pieces of information that save us far more time than the 15 minutes it costs us. Examples:
Person A: I’m struggling to solve this problem.
Person B: Oh, I solved that same problem last week. Here’s the solution.
Person C: I’m working on this particular task today.
Person D: Hey, I’m working on this other thing and I just realized that’s going to drastically affect your work. We need to talk.
Person E: This really important story is going more slowly than we thought it would.
Person F: The stuff I was going to work on isn’t as valuable to our customers; how can I help speed up the important story?
Person G: I chose to implement this new feature in this certain way.
Customer Rep: Hmm, I don’t think that’s going to work well for us. Have you thought about…
Talk to each other
It’s remarkable the lengths that software developers will go to in order to avoid talking to their teammates. Many of us are introverted in the first place (I certainly am!), plus our industry still has this conception of the mythical cowboy coder who locks himself in his office, getting pizza and soda slipped under the door, and every once in a while code occasionally emerges. I’m not sure that model ever worked all that well, but in any case we (should have) outgrew it a long time ago. It’s simply not workable these days when you consider the speed and volume at which our customers expect us to deliver value. Talk or die. The choice is that simple.
Update: For lots of good patterns related to the daily standup meeting, see It’s Not Just Standing Up: Patterns For Daily Standup Meetings.
SaintGimp 