Cadence...

Scrum (like other Agile variants) has rhythms built into it. I got to thinking about this the other day while trying to explain to others in the company what we had been doing within tech. I considered the daily stand-up, the weekly planning session, weekly reviews, monthly retrospectives... we performed multiple activities that provided feedback loops into our work allowing constant correction.

But how to explain this to an outsider? Especially a sales person who spends much of their time on the phone working, negotiating, and waiting. These are folks who don't get to predict when things will happen, only put pressure on making them happen.

The metaphor of a heartbeat or breathing always seemed a little too mushy. I grappled for a different metaphor. Suddenly, I found myself describing cadence. At first the concept of cadence in general, and then in sports.

Next I found myself thinking of the military. I remembered how a few of my friends came back from boot camp brainwashed by these chants. I had visions of how they could line up and mindlessly march all day singing these stupid little songs.

And suddenly I realized it... they weren't silly little songs. It wasn't mindless marching. It was muscle memory training. It was about the rhythm. Backpacking twice your body weight in the rain for eight hours to a perfect rhythm actually has a point. When this team was under the stress of enemy fire, they had this muscle memory to fall back on. It was survival. They would move in unison as a group, and their success depended on it. They could lose sight of each other and still know their movements. Actually, the importance of cadence dates back to European war strategies:

The cadence was set by a drummer or sergeant and discipline was extremely important, as keeping the cadence directly affected the travel speed of infantry. - Wikipedia

As I described this concept to the larger group, it seemed to sink in. For the folks who participate in these events, they suddenly looked at the standup differently. In good time or bad, they were a marker of progress. They insured the team was working in unison. We were moving together as a disciplined group. Just like the rhythm of song, we all kept pace. For the outsiders, there was a small sense of jealousy. They wanted to belong to the group, be part of that rhythm, and feel that constant progress. They wanted to know that everyone in the group had their back. They were envious of credit shared by all and no member left behind.

Cadence... it's much more than a repeated timebox.

Sprint Committments...

This post is my response/summary to a thread on the Agile Alliance LinkedIn group related to the same topic. If you'd like to read all the details, click here.

The question asked by Rene Rosendal was:

I've seen teams who don't seem to take their sprint/iteration commitments very seriously. When a story is in jeopardy, they don't increase their work intensity in the attempt to finish it. Instead, the words "well, we'll just have to carry it over to the next sprint" pass their lips very easily. Obviously the Scrum Master or Product Owner cannot "force" the team to work harder and make things happen. ...

My response was three fold:

• Assuming they made the commitment, you have a team / culture problem... lack of caring or motivation
  
• Or you have an empowerment problem. The team is not actually committing, but someone else is declaring commitment for them. I've seen management assign the sprint goal and work. How can the team commit to something they know is not possible just because someone said it? The team should own the sprint planning session of work.
• Or you have a communication problem. Maybe the team is committed and they selected the work. But the point of agile is that things change. Maybe they found things during the sprint that made them realize the commitment was not obtainable. Did the team go back to the Product Owner/customer and clearly communicate this? Did they negotiate? Did they make sure that the work they were pursuing was still correct in light of this new knowledge?

Other great points:

If the team puts in extra work to complete a story are they penalized by having the organization expect that they will do the same number of points in the next iteration? - Rob Scott

Most sprints my team fails to complete everything on the Sprint backlog. We do not consider this a Sprint failure. Instead, we remind ourselves to focus on getting the topmost things on the backlog completed first, so the items of greatest priority are done by Sprint review. I think this is extremely common. - Dan Greening

Is the product owner easily accessible to the team and actively involved during the sprint? - David Sallet

Fundamentally, commitment is like trust... you can't make it happen, it is chosen by the holder.

Infusing some Kanban...

The team I am working with was starting to have a few issues. We had too much on our plates, lots of noise, and the CEO was raising concerns that we weren't focused on the right things. We also had a feeling that the sprint end and begin was a magical flurry of stressful activity.

So we've implemented some changes:

• Our cards on a wall board is now restricted. Only 5 things can be in flight at a time. Everything is still in VersionOne; but only the top 5 get the explicit visibility of being important enough to be covered every single day.
• The CEO (highest level product owner) is responsible for filling and prioritizing the +5 queue whenever there is an opening. These are the next 5 things expected to move into flight.
• Our standups are no longer going to be asking the 3 questions going around the circle in the sequence we lined up around the room. Instead we are going to first talk through the top5, and then use the time remaining to discuss other notables as people need to. The team is responsible for taking their turn by importance and not going in sequence.
  

Our hope:

• This will shift focus from what "I am working on" to what "the team is delivering for the company".
• We might not get to every topic since not everyone will have an explicit turn, but we guarantee that we are talking about the right things.
• Outsiders can attend the standing meeting and easily see certain items and their status as opposed to hearing about an item across people throughout the meeting.
• We force the business to shift from magically identifying 5 things every Friday (1 week sprints) to constantly filling a pipe of work every day as we empty it.
• It is easier to see if our commitments of date and cost are at risk and communicate that to stakeholders because the topic is covered at once. (Our commitments are more safely limited to the top5.)
  

We see how it goes... (like many issues, we'll implement changes and slowly snap back to a happy medium as we learn and grow)

Don't abuse the metrics...

Tim Ross blogged about his concerns on burndowns. He offers some interesting points on how they can hurt including:

1. too much pressure early on
2. it doesn't handle the unplanned
3. it is unforgiving
4. PM's and customers misread it
5. it discourages refactoring
6. it focuses on a predetermined time

Hmm.... my responses:

1. really? most people feel it at the end
2. it is a reminder of the reality of the clock
3. neither is the market, it is changing whether you deliver or not
4. well... yes, that's true with any data point
   
5. not if you refactor constantly
6. or you could say it focuses on meeting a completion of commitment
   

Okay... some of that is me playing devil's advocate. I can relate to some of the points that Tim makes. Unfortunately, he proposes a solution where teams focus on the task board and maybe even hide the burndown for only the manager's eyes.

Umm... no. If you are really interested in going agile, then you have to understand that there is a power shift from the managers to the team. Instead of having people above (who aren't doing the work) ask for ridiculous things and make useless statements, the team is now more in charge of the process. But, the idea of a self-empowered, self-managed team is that the team has to be willing to be accountable for the work. This is not just the validation and quality of that work, but also the predictability of its timely delivery.

My view on this matter is two-fold:

• The burndown is an indicator. Bad trends in burndowns should be a flag for resetting expectations. When expectations are adjusted (be it the developers, customers, or managers), then everyone should know about it (that is why we do sprint planning and sprint review together, right?).
• ANY METRIC can be abused. If your culture stinks, or there isn't a trusting relationship between the team and the customer or managers... then any metric can be abused to support finger pointing. This is not specific to the burndown.
  

This is why many waterfall projects fail. It takes so long to uncover problems that when they are realized by lower management, they can delay the discovery further by gaming the metrics and reports to protect their jobs as long as possible.

"My definition [of agile] is that you accept input from reality, and you respond to it" - Kent Beck

A burndown is one of many measurements of reality! Unfortunately I think the answer in this situation is that the group needs to improve the cultural issues instead of throwing out the burndown.

Agile Turkey Day...

Last year my wife decided to be ambitious and host Thanksgiving for her family at our condo. I thought this was a bad idea based on our small place and having two new kids to deal with, but I accepted responsibility to clean the condo from top to bottom so she could focus in the kitchen.

Preparation went pretty well, she even made many dishes in advance. But the one dish you have to cook on the day of the event is the turkey itself. (Well, you don't have to, but part of thanksgiving is stinking up the house with the bird.)

Unfortunately this was the day the oven thermostat broke, meaning it couldn't hold a steady temperature. We didn't realize it until the turkey should have been done and the thermometer said it was still a few hundred degrees off.

It quickly turned into a scrum process:

1. Check the bird's temp
2. Estimate a new time for when it will be done
3. Wait the the oven to work its magic
   
4. Repeat

Every time we did this, our estimate became more accurate, but the oven became worse at holding the temperature (and our constant opening and closing of the door didn't help).

Several hours late, we finally took delivery of the bird and ate our meal.

Customer feedback: That was the moistest turkey ever. Tasted awesome. Was ALMOST worth the wait.

Hope your and our Thanksgiving are going better this year. Happy Gobble Day!

Best day of week for sprint boundaries...

Chris Spagnuolo asked the Agile Linkedin group about the best day of the week to set sprint boundaries.

Some interesting points were made by the group including:

• Mondays are sometimes focused on fires and recovery from the weekend break
• Fridays are prone to people losing focus and being worn out
  
• Vacation and holidays more frequently cover Monday and Friday
• If a sprint ends badly on a Friday, people might feel pressure to work the weekend
• If a sprint ends well on Friday, then the weekend is a clean slate
• Sprint planning and review activities are a nice break from work and therefore work well on Fridays
• We can't control a lot of this anyway

Pick your poison!

High release frequency can be empowering...

There are a few advantages for you and your customer when you release frequently (monthly or more). Here's one possible train of thought-

--- thinking like the customer---

Pro - Smaller changes are easier to handle

Instead of giving me one huge drop every six months or year, I get a smaller drop more frequently. I don't have to train users (and be trained) on a lot of changes that affect me, instead the delta is small and easy to manage. I can take a few changes in the software and focus on adapting to them. I have time to learn how to leverage this new functionality to my needs without splitting focus in as many directions. I can provide feedback to the software team based on what I learn instead of waiting for six months in the dark and wondering whether they will change that thing I complained about last release.

Con - the cost of change has a base price

But, it costs time and money to take on an upgrade regardless of how small or large. This minimal costs is never less than $X. This $X cost multiplied by the number of releases per year can cost more than the old single release approach cost me.

Pro - the customer chooses to take a new release

Ahh... but I don't have to take every release. Sometimes releases have changes in them that my group doesn't need or use. We can completely skip a release (or two). If I know what is in the release (and it's a smaller list to review now), I can very quickly decide to move along because there is nothing for me this time. End result, I only take releases when their value is worth investing in taking.

--- thinking like the software team---

Con - our customers are on many different versions of our software

Oh crap, the customer base is on 20 different versions of my software. How do I support all of this? Yeah, that kind of sucks. Is there anything you can do about it? Well, you have to have a good CM approach. And you have to make sure your team makes smart choices between when to fix/patch something vs. forcing the customer off of a version.

Pro - it forces you to provide value in each release

But wait, there is a way to help get people off of your older versions of software. If you are building something of value in each release, then customers are more likely to take the drop. Fix the things they don't like, add features they ask for, improve performance and next thing you know... they want to upgrade.

Con - you gotta stay on top of the market and customer needs

But this requires me to know what my customers want! That's hard! I guess I need them to be tied to the team somehow. They need a voice in prioritization. We need a way to get their desires onto the backlog. We have to mold and evolve our strategy to mirror the changing market.

Pro - you are in touch with the market and customer needs

HAH! We figured out how to do that. It was hard, and it costs a little more money, but we make soooo much more money than before. Customers are loyal and love us. They tell others about our stuff. We know what the market wants. People buy our stuff. In good economies we grow market share by beating our competitors. In bad economies we grow market share by outlasting our competitors. Case studies and leads are easy to find. We are spending a little more money, but we are making a lot more money because we can charge a premium for something we know the market wants.


Do you have a story to share to reinforce any of these points?

Iteration-less agile...

In case you haven't heard, some groups are starting to try iteration-less agile techniques. I like the idea, and I can envision it working; but I agree with Amit that it should be left to really mature teams.

But, it's not a stretch if you have been researching Kanban and Lean concepts.

Nail, meet Hammer....

I've touched on the topic before:

• What do you do when you find bugs after the story is closed or the sprint is over?
• How do you split stories, and when is it cheating because you are simply using it to squeeze them inside sprint boundaries?

Well, Jeff Langr tackles a similar question. Complete Stories, not Iterations. Nail, hammer, bang. Repeat.

Figured it might make sense to hear it from someone else if you haven't gotten the message yet. If you have, then here's another source to use when explaining it to someone else.

The train game...

To follow up on a previous post about agile coaching games... today, Infoq posted an article about the session run by these guys at Agile 2008.

I'm happy to announce that a game I recently created and tried successfully in my own company was submitted and accepted by Don McGreal and Michael McCullough into the Tasty Cupcakes wiki.

If you would like to try the Train Game and have questions, feel free to contact me. I'd like to polish it up a bit and improve it based on other people's experiences since I have only run it once.

Update (10/27/2008) - another good post on agile coaching games.

Shorten your iteration...

You can't allow the implementation of agile to be a 30 day version of waterfall. All you do in this scenario is take that over-worked / over-stressed window that you have every release and make it happen more frequently. This is a great way to make agile fail. Instead think that about how to reduce that pain and improve the situation. Allow your cycle to happen more easily, so that the business and customer can resteer priorities before what you are working on is out of date.

If it was painful to release every year, fix that problem so that you can release every quarter. As your pain tolerance decreases and you realize that it is painful to release every quarter, then fix those problems and release every month.

Every time you shorten your iteration length, your team will realize that there are things that are time-consuming and painful. They will argue that doing it more frequently is less productive. Instead of deciding not to shorten the iteration, decide to fix the pain point. Each time you challenge yourself to do this, you will find yourself in a better place.

This is one way to force yourself to achieve true agility.

For example:
Your team will allow deployment to production to take 2 days if you are releasing quarterly. Mention a monthly iteration and suddenly people notice that you are losing 2 days 3 times as often. Instead of fighting the monthly iteration, fix the problem and make deployment take one day or less. Everyone wins.

Martin Fowler has been overheard saying "If it hurts, do it more often"

Iteration/Sprint != Waterfall...

This discussion about code reviews has triggered a bunch of thoughts in my head. For now, I'll stick to the loudest one.

Sprint boundaries are supposed to provide transparency to the customer and the business, not be a scramble for shippability. The end of the sprint shouldn't create a flurry of check-in activity leading to a pile of new tests to find previously unknown bugs (which can't be fixed in time for review).

Instead, the daily meeting/scrum should provide a heartbeat for the team and every day or so, stories should be completed. Adopting agile should convert you from yearly releases to quarterly releases, to monthly releases, and maybe even weekly releases.

Have you ever flipped a rock in the woods and watched all the critters scramble and disappear? This is not what the day before sprint review is supposed to be like!

Instead of thinking of the sprint review as a point in time to have stuff working for demo and approval; you should be thinking of it as a time to have the customer, product owner, and team assess progress and determine if the upcoming plan, priorities, and communicated delivery dates are still realistic.

Here is another great list you can use to spot an agile team.

Tests after story closure?

As a customer I tend hang out in the VersionOne google-group user forums. Sometimes I find myself providing agile coaching feedback unrelated to the tool. Today was one of those days.

A peer was asking questions about the tool when running tests. But their team regularly closed stories in one sprint and had the testing team test that work in the next sprint. I had to share the following feedback:

"Flags are raised in my head whenever someone says that their testing team works on the prior iteration's work.

This is problematic for the following reasons:
- the development team has moved on to new work
- if the testing team finds something, they must "interupt" the development team to go back and fix the bug
- this throws off velocity (or it is gamed and false)
...and this whole concept feels like a mini-waterfall since it ignores that the product should be "potentially" shippable at the end of an iteration.

What we did on my last team was have a CI (continuous integration) build that ran every night separate from the check-in test/build process. If everything passed, then the test environment was automatically updated in the middle of the night. Thus, our test team was part of the sprint team and they tested stories as they were built. Stories were not closed unless Dev, Test agreed AND the customer accepted them. This removes the pitch-over and splash-back feeling.

It can also remove a lot of interruptions and debates that pit QA against Dev.

Having said all of that- you may not technically be able to do this today. Or, your culture may not be ready to truly be agile. As a pragmatist, I say whatever you are doing is better than not. I just wanted to throw this out there as a potential goal to strive for. "

I'm glad I said the last part... my peer responded with appreciation but noted that they were working through the technical hurdles to creating an automated build.

The Death March...

Allintheplanning mentions how one of his peers relates the agile iteration to the movie groundhog day. Is the iteration a good or bad thing?

My nugget: "... In agile, it’s allowing the rhythm to sound more like a drumbeat than a heartbeat. The drumbeat enslaves, a heartbeat gives life ..."

The Boundaries of a Sprint...

How do non-developers get involved in the iteration rhythm? How does a business or UI person have all the answers on the first day of the sprint when developers need them? This is a great problem and people learning scrum seem to evolve through different levels over time.

This was the point to Karl Scotland's MMF post, and he did a great job of modeling it for easy digestion.

I commented on the sprint boundaries in general and my experiences through this process in other teams and how it was predicted by our agile coaches at the time.