Participate in change, don't expect it to happen

One of my peers asked me why our manager kept assigning work to specific resources instead of simply prioritizing it and letting the team pick it up as people were available. The upside of this question is that they are starting to understand some of the core agile concepts, but the downside is that this is a hard question to answer. What they want to hear is that I will go convince management to stop meddling with the team and allow them to be self-empowered and self-managed. They want to find the better way on their own, but it's not that simple.

The manager does this for a reason. To him, it is important to sort his desires taking efficiency into account. In his mind, this is most affected by WHO is going to work on it. Instead of pushing for anybody to be able to work on anything (something that seems insurmountable), he re-arranges his desires and works with the system in place. Unfortunately this is a very short-sighted approach, but we haven't provided much of an alternative. Right now, the manager only trusts himself to make these decisions.

I pushed back on my peer. I told them that it was up to the team to change this situation. We have to do more than simple code reviews. We have to actually insure that multiple people on the team know how everything works so anyone can modify it. We have to build trust with management that we can handle work efficiently in whatever order it arrives. It is a slow path to managers having the freedom to prioritize and granting the team control to manage themselves. We have to build the solution, show it exists, and earn management's trust.

I find it is easy to convince a team of the underlying agile values and principles. The harder part is convincing them that they are an active part of the solution. They see all the ways agile solves their needs, but they forget the needs of the business and management. Teams must take ownership of showing managers how agile solves their needs also. Everyone has to understand that we are trying to optimize the whole system and not just the part that the team plays!

Market Take-over vs. Proven Success...

My first agile project began as a disaster, which is why we chose to try agile. Nothing else had worked, so we threw agile at it knowing the ship was starting to sink. Thus far, we were always 2 years from delivering. The beast was huge and we were doing more work descoping and handling change management than actually getting functioning code out the door. Oh, and we were under ISO and other audits (risk mitigation being more important on a life critical system.)

But, it ended up being one of the best teams and projects I've ever worked on. I still stay in touch with many of the people on that team and it was such a huge turn-around that many of us have been working with agile since then.

This morning I was reminded of this as I read Przemysław's blog post about "Half-dead projects". It reminded me how our project start was focused on a team of 5 clinicians pulling from their various experiences to create the "scope" and requirements needed to displace competitor products from the market. They spent over a year figuring out what it would take to perform a market take-over. The goal was to be a #3 product in the space within 3-5 years. Starting from nothing, that meant we had a long path to pursue. To make it worse, our product had to be a global product fulfilling all the needs of each culture and continent. There were always exceptions and special cases uncovered every day for a specific country or language. We were constantly descoping to pretend our deadline was obtainable. Our focus was on the day where we sold our product to 25-50 customers.

Then one day we realized we were close to being done. Unfortunately it was "dead done", not deployed done. We needed to survive. We had a contract in place with a beta customer... they also needed us to survive. So we threw the kitchen sink at it and we went agile.

On some level we threw out the entire MRS, PRS, SRS, and 50 other piles of documentation. In 3 days, we created a whole new backlog with stories and estimates. Then we stepped back and we realized this was still too much.

So we threw that out and started again. We went to the beta customer and asked... "What do you need to start using this?" What they "needed eventually" turned out to be much different than what they "needed to start". Turns out, a lot of time is spent setting systems up in the health care setting. Provide some screens to start configuring x, y, and z... it will be 2 months before that is ready to be used. Build this next... etc. We focused on one customer... right here, right now. Every 2 weeks (instead of every 3 months), we demonstrated what we had built and we asked what was next. Our product owner made sure that none of our steps were unique to the one customer and our work still fit the long term global strategy (you can't focus completely on right now), and we kept making little victories.

Six months later, that beta customer had software in their hands. Think about that... we went from 2 years to 6 months. It turned to be much more important to have one active customer than 15% of of our product built.

My favorite confirmation was when they told us how much better the process was. How they now understand why it was so hard and that by being involved, they could work with us as a team to make hard decisions and insure something of value was handed to them sooner.

That is one of the core impacts of going agile! You know it is working when you have proven success! I now believe that a market take-over is achieved by convincing EACH customer to buy your product or service. It is not done by defining up front what they all need. Every customer is slightly unique. Prove that you can make one customer happy, then five, then 20, then 100.

You can take over the world one customer at a time with proven successes. You can't do it any other way.

Great stories...

If you haven't seen these great blog posts you should check them out:

Lean Team Software Process by Corey Ladas

snippet: An alternate metaphor for software value is a refined substance, like gasoline or ice cream. The raw material is customer requirements, domain knowledge, time, and energy; and this is transformed into manifest behavior of a computing system. This view suggests that software has no more customer value than the sum of the scenarios that it supports. Then there is no bright line that defines “complete”, there is only relatively more or less value delivered. When I fill up at the gas station, I need more than one gallon and less than 100 gallons, and when the pump tells me I have enough, I expect to pay the exact value of the utility I expect to receive from the product. Software can be delivered in this way: keep giving me more until I have enough, then stop and charge me for what I have consumed.

Metrics, Schmetrics II by Matthew @ Creative Chaos

snippet: All of those examples are fungible - a gallon of gas can be traded for any other gallon of gas. A penny saved is a penny earned. They are all the same.

Yet test cases, lines of code, these things are not the same. You can have a test case that takes two hours to set up, or a half-dozen similar ones you can run in thirty seconds.

Scrum vs. Kanban by Mike Cottmeyer (ignore the Idol intro and title at the beginning)

snippet: I think that in some ways Scrum is hitting a wall because some of us think that Scrum is the answer to everything. Is Kanban the new answer to everything? Is it going to replace Scrum and XP or DSDM or AUP or Crystal? I can't even imagine how we can have these conversations without understanding where and when is the best context to apply these principles. I feel like a broken record but there is a time and place for all these techniques.

Help! Our estimate was off by a lot!

Another LinkedIn discussion, this time the question was along the lines of estimates that turn out to be incorrect. In this case, the person asks what the team should do when something estimated at 6 hrs turns out to actually take 26 hrs.

Wrongly estimated stories normally create more pressure on team which in turn impacts the quality, velocity and off course targets.

Is there any way to handle this issue? It is ok to pop out some stories in between sprint?

Most of the initial responses focused on the fact that estimates are always slightly wrong and that this error will normalize itself out. One person before me suggested mid-sprint correction with reflection during the retrospective. I agree that trends of estimate problems should be reviewed, but the real question was... what do I do right now in the middle of this sprint?! My response:

If you uncover something mid-sprint where your estimate will be 4x greater than originally thought, I would assume you have uncovered an impediment or complexity that was unknown during planning. This will happen from time to time, even on a mature team (otherwise you might not be doing difficult enough work!).

My advice would be to pull the product owner/customer in immediately. They need to understand the issue (and hopefully the cause). They need to decide if that story is still important to them at that cost. They may want to descope it knowing that everything else in the iteration is more important than that one thing. Or... they may tweak the requirement to get the majority of it and work around the problem.

I follow most scrum ideals, but I don't believe that a sprint's scope cannot be changed mid-iteration. (Actually, I'm doing a Kanban/Scrum blend now). It makes sense to re-evaluate when these things happen because the team has to remember that the largest goal is delivering the right business value. Delaying multiple expected items for a single item is a decision that should be left to the product owner/customer.

I'm curious to see what others add to the discussion thread. Unfortunately, I think most people are focusing on pure Scrum (ignoring other Agile flavors) and are assuming this is an immature team. I don't know if that is the case for this person or not.

When is a story too large?

Peter Steven's posted on the Agile Software Development blog today on the topic of "When is the story too big?" It's a really good article if you are on a team having trouble with that single story that deep-sixes the entire iteration.

Some of his points are:

• Past Performance is a good guide to future performance
• Stories should be small compared to the size of the sprint
• ‘How to demo’ makes the complexity clear
• Splitting Stories which are too big

On the second point he states:

My own rule of thumb is that no story should consume more than 40% of the teams estimated capacity. Why? An estimate is merely an estimate. If your team is knowledgeable in the technology and domain, each story has a nominal tolerance of +/- 50%. So 4 days could be 6 days, and you would still be in your tolerances. A six could be a nine. Assuming your capacity is 10, then committing to a 4 leaves a lot of room for error. Committing to a six exhausts your margin for error, especially if you commit to other stories. And anything bigger has a high risk of not getting completed, even if things go well.

I actually took this a step further in my comments:

I would decrease your 40% further.... I am a strong believer in MMF (minimal marketable feature) and encourage items that can be broken down smaller to be. If something can be built and marked DONE in a day, that is better. Remember, sizing allows for change in scope and priority mid-iteration if needed. Large stories block this.

Thus, my rule is around the 25% mark. If a story will consume more than a 1/4 of the resources in a sprint AND it can't be broken down further, then I call for a spike. Use the spike to R&D the riskiest parts of the story and flush out the demo/acceptance criteria. Timeboxing the spike to 10% of the sprint forces re-evaluation before creating a huge time sink (allowing time to refocus 2nd spike in the same iteration if necessary).

The outcome of this timeboxed "spike" should be a more clearly defined, lower risk, and possibly broken down set of stories. Containing the work to a timeboxed spike insures the team continues to deliver other stories in the meantime.

Also... these stories should be tackled early on in the release cycle. If you wait until the 2nd to last sprint in the release cycle, your risk will probably cause you to miss it.

A lot of people forget about risk management in agile, I believe that proper story sizing is part of the risk management that teams must be accountable for when becoming a self-empowered, self-managed agile team.

Your thoughts?

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.

Lean Kanban Conference...

There's some really good stuff coming out of the first day. I'm not there, but I'm following along on Twitter (#lk2009) and Mike Cottmeyer is doing summaries on his blog with every presentation!

Catch it while it's hot: http://www.leadingagile.com/

What is a self-managed team?

I previously discussed a LinkedIn discussion thread about team's and various personalities. (Here's the LinkedIn discussion, and here's the prior blog post.) I focused on the personality aspect of the question, but Hemant came back with another question:

It is not yet clear what a self organising team really means / stands for.

Having spent some team managing teams, am yet to see a group of individuals so completely balanced that they choose the right approach without getting swayed away by a particularly persistent individual. [who in all probability is from the business side of things and insists on providing solutions instead of requirements].

Guess more efforts/reading is required on my part to understand this better..

This is a great question. I wonder how many people think that self-managed is focused on the roles of the team vs. the needs of the team from outer management? Here's my attempt to define a self-managed, self-organized team:

A self-organized, self-managed team is a team that needs little influence or direction from the organization above. The team itself becomes very good at working with the Product Owner/customer and knowing what to do next. There is little need for a project manager or resource manager on a day to day basis.

On some teams there are passive leaders, on others everyone plays an equal part. But the point is that they no longer need direct instruction/orders from above because they are more in tune with the customers needs. This allows the upper organization to be lighter (cheaper) and focus more on strategy instead of tactical issues.

What does self-organized and self-managed mean to you within the Agile domain?

Gaming the System: Velocity...

To take my previous point further (prior post), Alex Hamer wrote an interesting post about how his management wanted him to "find ways to improve velocity". He correctly considers things like training and coaching, but is concerned that management isn't thinking down the same lines and is "approaching with caution."

I've seen this management request before. Typically it comes from the frustrated Product Owner who projects the current velocity against his "desired release scope" and is frightened by promises he has made to customers. He understands the new system and velocity, and decides to use the "whole team" concept to suddenly include you in the problem. Next thing you know, he's standing over the team asking for "more velocity!".

Feels like the old way of working again, doesn't it? Agile doesn't solve the problems you felt under waterfall, it simply exposes them in a big ugly way. You can either cave and play the old games, or you can hold your ground and help management become agile with you.

Here's my sarcastic advice to Alex:

Your gut is telling you the right thing... you don't forcefully "increase velocity", you have to help your team get what they need and it will increase on its own over time.

The easiest solution is to start accounting for the velocity of vacations and conferences or training. These are guaranteed points and therefore will drive up the average. After a few sprints of the higher number... disclose that you've gamed the system. Then drive home that forcing metrics only forces gaming of the system. Remind them that this is why waterfall fails in most environments. They are only pushing you to go back to the old way of doing things under a new name.

Help your project sponsor become agile!

Gaming the System: Sustainable Pace...

Awhile ago, Bruce Zhang raised an interesting debate about sustainable pace as tied to the number of hours a team member worked each week. He closes with the statement that it is more important to remove waste than increase work hours, and work hours are not the appropriate metric for measuring sustainable pace. (His post was inspired by another old article on InfoQ.)

I know the debate is an old topic, but related to my next post I have to weigh in.

As I understand it, the 40 hour work week is a result of the U.S. government studying Henry Ford’s assembly line factories. Ford discovered that each individual is slightly different, but the “average” manual labor worker produces the most (with quality) somewhere between 35-45 hours. This is a human limitation.

One could argue that time has passed and we are more (or less) capable due to technology. One can also argue that this would be a different set of hours for mental labor (white collar) instead of physical.

One thing I have noticed is that as Agile teams mature and truly adopt practices such as pairing and TDD, they tend to be more productive around 35 hours (as opposed to 40). I worked on a team that produced A LOT more than pre-agile, and they went from lots of overtime to normal weeks. They were burnt out by Friday at 3-4pm. They needed a good weekend of recovery to come in ready to go on Monday.

Can anyone verify the 40 hr week, Henry Ford point I believe I heard before?

How to manage various personalities...

You shouldn't have to manage them, only coach/advise them. Period.

In "Good To Great" by Jim Collins, he spends a very important early chapter on the concept of "getting the right people on the bus", "in the right seats", and the "wrong people off the bus". He even goes as far to propose that heavy management hierarchies are a compensation for having the wrong people on the team and needing to manage them. (Note: this is the chapter after he explains the 5 levels of leadership, so that is not the assumed cause of issues.)

Why am I mentioning a great business book on an agile blog? Here's a question from a LinkedIn group:

From the Manifesto - The best architectures, requirements, and designs emerge from self-organizing teams.
This seems to do away with the team structures. Wouldn't it be disruptive, given the various personalities that a team can have?

I read into the "various personalities" phrase; here's my response (still waiting to see what others say):

Does the team have "personalities" that can't act professionally and in the best efforts of the team unless their role is clearly defined and with boundaries?
If this is true, I would argue that managing those individuals cost more productivity than they provide in both the waterfall and agile environments. They need to be molded or removed.

It might seem harsh, but we need to insure that teams are enabled by their members and not hindered. I know it is hard to find great people, but when we do hire, they should not only possess the required skills but also fit the culture of the team. Here's another take on this topic from Johanna Rothman.

Agile is designed to deal with...

I typically like the things Naresh has to say. Like other agile coaches, he's blunt and to the point. If you aren't interested in working through 95 pretty interesting slides about how agile is becoming the new waterfall, here's the one I like the most:



Click the image to see the source with all slides.

The Support Team...

An Agile LinkedIn group participant asked how to run an agile team focused on supporting a product that a different team built and delivered.

First thought... who decides which resources get the glory of working on the sprint team that creates and delivers features and business value each sprint vs. the hazing of working on the support team that fixes the crap. I really hope that if you decide it is necessary to split into these two groups, you at least flip flop the assignment or slowly rotate resources between teams to make it feel like one big team. Otherwise, the supporters will only be mad at the creators and you will fall into the typical us/them developer/QA turf war.

A sub-question was posted on how to handle "critical" issues. It was stated, these are the things that are more important than anything the sprint currently being worked. Several points here:

• If these critical issues are bugs or defects, and they happen often... then it's time to have some courage and discipline and go upstream and ask difficult questions. WHY are these things happening, and HOW can they be reduced in frequency? Instead of adapting to handle them, go to the source and stop them. If you can't because "they" are a different group under different management, then you aren't in an agile organization.
• If they don't happen very often, then this is a simple answer. Let the product owner decide whether the item is more important than items currently in the sprint. If it is, then it should be estimated and should displace a set of stories that are lower priority and of equal cumulative value.
• Work one week sprints. As a support team, you need the ability to be more flexible. Shorter sprints allow for quicker reaction and re-prioritization. Also, work can't stagnate without being noticed. Deployment is quicker (although you might deploy daily and not wait for the sprint end).
• Think about applying Kanban. Loosen the strict requirements of scrum and use Kanban to drive how many things you have in flight at a time. Use iterations as a measurement and assessment tool, and use Kanban to drive priority and work. Walking the board will put the daily focus on priorities.

I know that last bullet blows some of the Scrum rules out of the book, but his questions were Agile questions, not Scrum questions. So, I went with the blended solution approach.