• Home
• About
• How to make your daily standup effective (and fun!)
• Twitter Feed

Blogroll

• Agile FAQ
• Chris Sterling
• Ed Kraay’s Blog
• Lance Kind

 

Leading from the Middle

“The Key role of middle management is reinvention.” Tom DeMarco

Often I hear of Agile Adoption best occurring top down. Salesforce.com did that, from zero to Agile overnight. Other times I hear about bottom up Agile , or Agile in “Stealth Mode”. for a development team is tired of death-marches, a bottom up agile transition can be effective and motivating. This was how most Agile Adoption occurred 5 years ago when I was learning Agile.

And I rarely hear about Agile Adoption from the middle. Yet this is where, from my experience, change typically comes from. This is due to the fact that your middle management is typically where you have slack in a traditional organization. Slack is where you get your adaptability, because it is there that you have the bandwidth to try new things and aren’t under the optimization and efficiency pressure. If an organism or organisation is optimized, then it will be unable to change. Like the Cheetah who is far too specialized to adapt to new environments or prey, it will die off. Humans, however, can adapt to many environments because they are not optimized at any one thing, (except arguable solving problems and using tools).

Middle management has a role even in top-down and bottom up adoption. While they are typically directing operations and ongoing activities, they are the ones who are in charge of implementing change. As the Harvard Business Review states “First, virtually all major strategic initiatives have to be carried out by the middle managers.” In a top-down Agile adoption, while upper management might fund an adoption or read the “The Agile CIO” whitepaper they will need to ask someone to “go do it”.

This is hard work, in my opinion, especially in a situation where you are learning how to become a servant leader and drive change in the organization. This is why I think Scrum prepares teams particularly well for the role of change agent, as a Scrum Master is in charge of serving and protecting the team, which after the team gets its house in order moves to getting the organization’s house in order to support the team.

In the case when Agile is done in stealth mode, the team is doing the hard work of change. However, you need a line manager who interfaces with the other parts of the org, protecting the team while Agile is in its infancy, and heralding success when it has proven its value. This is where a good middle manager will be able to network with other middle managers, directors etc and socialize and herald change through the organization. Hallway conversations can reduce fear about the new “threat” and familiar faces can introduce it as a new option worth exploring. Again, a key element of this is adopting the courage to try new things and introduce change, without fear.

When I was first learning about Agile, I had a terrific manager (Philip Ljubicich) who empowered me to try new things and managed by exception. His motto was “If you’re not making mistakes you’re not trying hard enough.” A Microsoft vet from the very early days, he understood the concept that the minute you mange by methods, you’ve created a system that can’t cure itself. Microsoft, despite all its faults, has created a culture that believes it is anathema to tell your development teams how to work. It has kept their organization adaptable to many changes in the tech world for the last 30 years.

When I discovered this Agile thing, he encouraged me to try it out and see what worked. We tried it, it worked, adapted it and achieved great results. My point here is that had I not been there, had the capacity to learn and the support to try new things, we may have never tried this out. Only because I had a great manager, and because I had the slack to be able to adapt did we change course. If you’re organization doesn’ have managers like Phil, then your job is harder, which is why pilot projects where you demonstrate that Agile is safe and “we’re not switching to anything” until they prove their worth are a good idea. It’s easier to support what I know has worked in our organizaiton than a new untested theory.

In the nineties there was the empowerment craze of flattening org structures, of leaders with inspired vision and teams who shared that vision. People were doing trust-falls and climbing walls and holding hands and singing kumabya.  Middle management was seen as waste. Yet in this craze to flatten org structures organizations they flattened their capacity to change.

Toyota, which has shown itself to be remarkably resilient, past four recessions and the oil crisis, has a surprisingly deep org chart, with many managers for each of its employees. These line managers, however, aren’t career managers, they are those who have great technical expertise in the teams they manage. Why is this important? What happens when you have a spike in the work for a production line, or have a problem that you need to solve? This can go to the middle management core, who can help to eliminate impediments and educate and advocate for their teams throughout the organization.

Of course, the culture of middle management must support these changes, and have the courage to try new things. Otherwise, middle management can often be the biggest impediments to successful adoption, as they work alone, try to cover themselves so they rise to the top and otherwise try to optimize their own organizaitonal silos. Great companies have their middle managers frequently working together, learning and sharing ideas in a culture of collaboration, so they can achieve the strategic objectives of the top brass.

“Hitting the wall” with your Agile Adoption? Try adding technical practices…

This is a great post that uses the familiar metaphor of the gym and physical fitness to apply to adopting Agile. I’ve seen the pattern described here too often.

Developers start out the first three sprints and produce production ready software every iteration. It seems like everything is going well. Then under the gun of the ScrumMaster to keep their velocity high, they build up technical debt (like sprinters developing lactic acid) by not paying attention to technical excellence and practices that will maintain a sustainable pace. This slows their speed to a halt until they clean up their technical practices and adopt test driven development, continuous integration, mercilous refactoring.

The question for me is not whether or not this pattern occurs, but how to best introduce Agile so teams can recognize when it is happening and address it.

On the Scrum side, folks like Mike Cohn suggest introducing Scrum first (using the iterative or requirements first pattern described in his outstanding Agile Adoption presentation). This has the advantage of allowing the team to self organize around the practices needed to maintain agility.

On the XP side, folks like James Shore recommend introducing the 12 XP Practices first (Mike Cohn describes this as “Technical Practices First” Pattern). The tradeoffs to Jim’s approach is that it is costly to start with all 12 practices from day one. Teams may reject the approach altogether, while getting none of the benefits of the practices. But the teams that do will have sustainable pace and agility.  The benefits to Iterative first or requirements first are that the teams learn how to self organize and undergo the cultural change necessary for bottom up commitment based planning. The downside is that somce Scrum is silent on engineering principles, and focuses on developing a self healing system rather than prescriptive practices. The down side to this is that teams may fail. Yet if they are using the retrospective and sprint review effectively, however, effects of failure are minimized (since they can inspect and adapt) and teams will have the added benefit of becoming a self healing system.

My experience is that the end state of having Scrum teams that us XP is a great combination. The paths to getting there are varied, and I’d rather a group learn how to think for itself then think implementing a set of practices will make them Agile. It’s the mind set shift to Agile principles that is important in my opinion, not the discrete practices used.  This prevents Agile and Scrum from becoming yet another prescriptive methodology that says “do these steps in these ways and you will be guaranteed success”.   What do you think? Have you experienced the pattern described above?

The connection between sailing and software

I wrote this post about sailing “inside” vs “outside” the boat. I learned much from participating as a crew member on a sailing team. It positively influenced my work with software teams, as I’m sure any team sport would.

How will we demo?

If you are struggling with concrete enough acceptance criteria, acceptance criteria that doesn’t specify the “how”, just the “what”, one technique that I find especially helpful is specifying “How will we demo?” to the story. This usually puts the product owner and the team in the right frame of mind for what we’re getting at with acceptance  criteria something both specific and actionable. For instance, if you are designing a shopping cart, the question “How will we demo this” may bring up a discussion of one book from the catalogue being searched for and added to a shopping cart and displayed for view. Typically I’ll have this as part of the template for a story card. Part of the beauty of this method lies in the act of imagining what will count as done in the future. There is something about the act of forcing humans to “remember the future”, of what the screen or web service will look like in two weeks during the iteration demo, that helps substantially when trying to get enough detail to estimate or commit to a story.

Restickable Glue Stick - Another reason 3M has a stranglehold on the Scrum Community

I like 3M post-it notes for sprint and release planning. It makes it really easy to have multiple people interact with stories and tasks. Unlike electronic tools, I don’t become a bottleneck for planning. However, I’m not against electronic tools.  In fact they make sense for distributed teams and for backing up data that is on cards. So, what’s a girl to do?

This is where the 3M restickable glue stick comes in.  It’s like regular glue stick, except you can use it to make anything into a repositionable sticky note. This means you can print your backlog from Excel, Google docs, Rally, VersionOne, etc. onto paper sheets or Avery card stock, slap some restickable glue stick on each story, cut them out and stick-em to the wall. When the product owner wants to change priority on a story, just pull it up and move it and stick it where you want it. Rather than hard to use clear Scotch tape, which is hard to unstick, or bright blue painters tape which may cover your story card, this is hidden and easy to use.

One stick of this stuff lasted me about 10 sprint planning meetings.I recommend a stick in every Scrum Master’s kit.

In a later episode, I’ll explain how I like to print out my backlog to Avery card stock to make planning easy.

Planning Poker Timer

Timers are valuable when you want to timebox a discussion. I’ve used this planning poker timer when I’m with a team and we are planning our iteration. I also use it when setting 30 minute work goals for myself. It has a nice bell when the time runs to zero, and changes from green to red, giving a nice visual cue.

Mickey Phoenix created this manual planning poker timer which I like even more, if you’re into analogue. kind of a Rube Goldberg contraption with a sand timer and a bicycle bell.

Bucketing stories for quick estimation

So, you’ve been running a few sprints, you have a velocity and a backlog. The trouble is your team tends to estimate your stories in your planning meetings and it really drags the meeting on for a long time. Never fear, I learned a technique for taking a wily backlog full of unestimated stories and getting team estimates on them quickly called bucketing. Kane Mar and Chris Sterling both have good posts on this topic as it was discussed in the Scrum Trainers meeting (called affinity estimating). I hope I am not wearing the topic thread bare by repeating it here. I hope to say, it works! And that imitation is the sincerest form of flattery.

While planning poker is a good technique (I own a set of Mike Cohn’s planning cards myself) and may be used to get more accurate estimates, I’ve found bucketing to be more efficient. Plus, accuracy is not really what we’re after in this excercise, just a reasonable approximation of relative size. Here’s a technique I’ve used before to estimate a set of 80 stories in under 2 hours, called bucketing.

What you need to prepare:

• A backlog for the current release. These don’t need to be prioritized, but it will help if you are going straight into sprint or release planning.

• A printed version of your stories, either hand or printer printed. I printed my stories out onto Avery 3×5 cards and put 3M restick-able glue on the back of the cards to make them into post-its. You can just as easily do this with yellow 3M post-it’s or their genero-brand Staples cousins . (I like the super sticky variety, for longevity of stickyness, especially if you’ll be saving them for later use or sticking to a cork board).
• A bell or timer that one of your team mates can use to speed things up, if necessary.

Attendees

• Developers
• Scrum Master
• Product Owner

Instructions

1. Write these numbers and symbols on a whiteboard horizontally. 1, 2, 3, 5, 8, 13, 20, 40,60, 100, ?.
2. Arrange your stories nearby the whiteboard. I like to stick them on Sticky Easel Pad paper. (No, I don’t work for 3M).
3. Pick up the first unestimated story. Read the title of the story and any other information on the story card. You may have one of your team perform the role of reading off the card.
4. Allow people to ask clarifying questions of the product owner.
5. Have someone propose a bucket, or points to put the story into
6. Ask if there are any strong objections to this. If not, put it into the bucket. Tell the team you can change this later (anytime during the event and at sprint planning) to reduce the fear of “getting it right”.
7. Move the next story and repeat the process above.

If your team members get stuck on a story for a long time, feel free to put it into the question mark bucket. Or you may have a team member ask “Can I timebox this?” and set a sand timer down for 2 minutes. When the 2 minutes are up, ring a bell. Then ask if the team needs more time. (timeboxes that are hard stops are just more stressful and annoying than ones that have optional extension)

You may find you have to split, or group similar stories into one. That’s fine, and even helps get the backlog ship shape.

The point of this excercise isn’t to get the estimates perfect. You won’t be able to do that, even if you had all the time in the world. The point is to get them between 50% and 70% accuracy. The benefit of this is that now the product owner will have much better information about the relative costs of the stories she is proposing. And having gone through all of the stories for a release, you will have a much better understanding of the product.

Variations

• Use T-Shirt Sizes (S, M, L, XL) for stories if “size doesn’t matter”.
• Have folks silently group stories into buckets. This is called affinity estimating and as Kane describes here, is an even faster way to get quick estimates on the backlog.

This will prepare you much better for the next essay in this series, which will be release planning.

Agile Open Northwest

I attended Agile Open Northwest. It used a cool concept called open space. No set speakers, no powerpoints, no agenda. In the beginning, 120 people meet and some of them propose topics and then post the topic up on a wall with a room and a time. I proposed and hosted two topics:

• How to make standups effective (and fun)
  • Photos
• How Do I Conduct A Multiple Team Release Planning Event
  • Photos

Look who’s got a Lookahead Plan?

After seeing Mike Cohn’s presentation on Agile Estimation and Planning, I got very excited about a technique he described as lookahead planning. A lookahead plan is simply a quick look at the next couple sprints to determine what stories are coming up, typically done at the end of a sprint planning meeting.

All you do is after the team is committed to the sprint, just take 15-20 minutes with the team to move stories from the backlog into two quadrants (butcher paper or whiteboard squares) labelled sprint n+1, sprint n+2. Indicate the velocity your team has committed to (I will used the velocity we committed on as a team in the last sprint) in each quadrant. Then, just have your product owner and team move them into the sprint until the points from the story fill up your sprint velocity buckets. Bang, you’re done.

We just tried this after our normal sprint planning, and it worked pretty well. We noticed immediately that there were a few stories that were irrelevant, and a couple missing stories that we needed to get estimates on, one story that needed more acceptance tests filled out for it and one that needed a followup on a third party vendor. This kind of work we used to wait until a few days before the sprint to do, and made our sprint planning meetings take much longer than necessary. I suspect that doing it 30 minutes at the end of a sprint planning meeting will more than pay for itself by having a more tightly run sprint planning meeting next sprint, with all the lookahead work we’ve done. I’ll keep you posted.

The best part of this, is that for the longest time, I could not figure out how to keep my release plan up to date. It would look great after maybe one sprint, but after a few would become staler than tube socks in a high school locker room. With lookahead planning, it just take a few minutes to update the most important sprints (the next two or three) from the product backlog.

How I do standups

Everyone has their own flavor of standups. Some do it standing up. Some do it sitting down. Some do it in a club with a microphone. I’ve never been that brave.

For me, the scrum standup goes like this. I break it into 3 parts.

1. Preparation
2. Meeting
3. Close

Preparation

As you can see, the meeting begins before everyone joins. For me, answering the question “What did I do yesterday” can lead to me missing a few things. So I like to bring a list, written on a 3×5 card of what I did yesterday, what I’m planning on today, and what’s blocking. It helps me to remember, especially if it is the Monday after a weekend. Also, if anyone is out, I print out their standup report so I can read it aloud.

The space

I like to have everyone stand around a circular table, where we have our conference phone. The team members should stand be fairly close together, not HR violation close, but close enough to hear the soft spoken introverts without having to repeat anything. We stand in the team open space, by our task board, whiteboard, burndown chart and our blockers board.

I will call into the conference call a minute or two before the standup begins. My product owner typically will join the call, since she is located off site. Note, it’s a good idea to turn off the conference call feature that makes callers wait for a chairperson. Otherwise, you’ll end up missing a standup one day and no one knows how to dial in the product owner.

For my standups, I actually standup and have all the team standup in the meeting. I find you reach decisions more quickly if you do.

Even though I’m the Scrum Master, I’ll typically stand with the team in the circle. I know Mike Cohn doesn’t, for fear that everyone will report to him, rather than eachother. However, I feel I that I’m a part of standup as much as anyone else, that since I’m asking others what they’ve done yesterday and will do today, I should be held to the same standard, even if it is just going to meetings, filing paperwork and sending emails.

Latecomers

We punish latecomers by making them dance or sing a song. I have yet to have someone sing a song, but have seen some very entertaining dancing (our SDET has graced us with the Madagascar dance “I like to Move It Move It!” a few times.) It’s a gentle way to reinforce that we start on time.

Meeting

During the actual meeting, I’ll ask who would like to start. Rather than start with one person, I find it’s more democratic to let someone who is ready go first.

We’ll go clockwise. Once we tried to go in alternating order, like a pinball machine. It didn’t work. Perhaps if we had a “conch shell” ala Lord of the Flies it would.

What I do during this meeting is very carefully listen to people for any hidden impediments. Things that they are really stuck on, but they just mention it in passing. Jeff Sutherland came to speak to us at a company meeting a while back, and he said, that the most valuable part of standup is the impediments. Even if they are buried in the mass of status, these need to be pulled out and recorded.

Blockers Board

Therefore, I actually have a pile of Post Its, a Sharpie and a block of butcher paper that I use to record impediments during standup. Any impediment that is not resolved by the end of the person’s report (allowing 1 minute to resolve issues max to keep things moving) goes on the “Blockers Board” . This has three columns. Impediment, Who, When. Typically, my impediments just have the name of the impediment (with a note about who reported it on the sticky) and a who (I go through and assign whos after standup). If the impediment will be there for awhile, or it has been there for awhile, I’ll assign a due date to it so there is more impetus to clear it. Occasionally we’ll go a few days with some stale impediments on the board, but the majority usually get cleared by the next standup. This helps individuals, I believe, to feel like there is value to them bringing impediments, because they will be actioned and someone held accountable.

Offline Topics

We also record offline topics that come up during the standup on the whiteboard, along with who needs to stay to discuss. Folks are pretty good about taking issues that might extend standup past 15 minutes offline by asking “Can we take that offline”?

Close

After the official standup, I’ll excuse the product owner and go through any outstanding impediments on the Blockers Board. Usually, I’ll tear off quite a few, but the ones that stay get a star so we can track how stale they are. Then, we’ll ask those who need to stay for offline topics to stay. If we are good, we’ll have kept the meeting to 15 minutes. If we are bad, we’ll have dragged on a few minutes after, but that is not so bad, as long as it doesn’t happen too often. If it does, people are de-energized by standup and do not leave feeling like they got something out of the meeting.

I’ve toyed around with the idea of ending with a catchy phrase like “let’s go get things done!” or “I love it when a plan comes together”. Maybe I’ll try this tomorrow.

Copyright © 2008 The Daily Standup | Wordpress Theme by Carsen Klock | Powered by Wordpress