Interesting Post… 10/1/2009 through 10/10/2009

Written by Mike Cottmeyer Saturday, 10 October 2009 12:58

It hasn’t just been my blogging that has suffered over the past few weeks… I have also gotten behind on my blog reading and I haven’t been nearly as active on Twitter. That said… there were alot of great posts over the past few weeks… some of which I did share… that never made it here on the ‘Interesting Post…’ summary. I went out to Twitter to scrape my Tweets for the past few weeks and it would only let me go 9 days back.

That said… I am cutting my losses and going with what I have. So here it is… my ‘Interesting Post…’ summary for the past 9 days…

Is Offshore Testing Worse Than No Professional Testing? http://bit.ly/DNF8V

State of Agile http://bit.ly/2WUtIk

Elbow Room for Handling Technical Debt http://bit.ly/Eg6UC

The Open Space Policy for Managers http://bit.ly/2J8iRg

Ken and the Scrum Alliance — a very personal perspective http://bit.ly/B66R1

New to agile? Keep it very simple http://bit.ly/2PZBXZ

Lean vs. Agile = “Peoples Front of Judea vs. The Judean Peoples Front” http://bit.ly/VqP2Q

Agile and Remote People: Part 1, Telecommuting http://bit.ly/2ej0Gd

The Problem With Planning http://bit.ly/bx668

Big Agile Adoption Approach http://bit.ly/2J92N4

Lean and Kanban Collection http://bit.ly/4D3w64

The Danger of Lean: Ignoring Social Complexity http://bit.ly/q74Zz

An Overview of Lean Software Development http://bit.ly/LsWn0

VersionOne Activity Stream http://bit.ly/mwBB3

Kanban Team beats Scrum Team! http://bit.ly/KbyGS

There’s No Task Easier Than No Task http://bit.ly/1EYI42

Presence in the past does not help today http://bit.ly/1apbFC

The Do-It-Yourself Team Values Kit http://bit.ly/22fXgi

Sure you’re agile, what about your QA department? http://bit.ly/rcz9E

Technical Debt on Your Balance Sheet http://bit.ly/6jK1d

Oh… and by the way… you’ll also notice that this post is coming out a day early. I usually do this post on Sunday mornings. Sunday is a slow blog day and I am usually up ahead of my kids and getting a few things done. I am heading to the PMI Global Congress around lunch-time on Sunday, so I didn’t want to worry about getting this one out. So here you are… a Saturday edition.

One more thing…. the family and I are making our annual pilgrimage to Burt’s Pumpkin Farm to get our traditional giant pumpkin. We’ll turn our giant pumpkin into one big Jack-o-Lantern as we get closer to Halloween. If you happen to be near Atlanta in the fall… Burt’s Pumpkin farm is a must go Fall destination.

Velocity in the Enterprise, Part 3

Written by Mike Cottmeyer Saturday, 10 October 2009 12:37

Last post we talked about two criteria that must me met for us to have any chance of establishing an enterprise velocity. First, let’s explore a situation where the teams are not fully nested under the project.

When Project Teams aren’t Nested

Probably the most common example of broken nesting is where the team is responsible for production support in addition to project work. Production support is inherently an unpredictable activity. You never know when your customers are going to call, you never know what is going to be broken, and usually you don’t have much of an idea how long problems are going to take to fix. You can make the case that these items just get added to the backlog and prioritized, but more often than not… these kinds of issues have to be handled right away and worked until they are complete. This happens at the expense of project work.

In general, you allow some amount of time every iteration to deal with this uncertainty, and hope that over time the law of averages works in your favor. Most teams in this situation are not nearly as predictable as they would like to be… or as their customers need them to be. Let’s say you are clipping along at 25 points/iteration and unexpectedly the amount of production support goes up dramatically. Is this a one iteration event? Is this something that we can fix? We just don’t know. The net result is that while overall team performance may be quite stable… the completion of new features is going to become very unstable.

Another example of this phenomenon is when a team is doing work for more than one project. The team’s backlog is made up of features for project A and project B. The Product Owner is balancing the needs of multiple stakeholders and trying to manage the expectations of the business. If the team is not dedicated to a single project at one time… team velocity can be through the roof while the velocity of any given project might be in the toilet. Either way… when you matrix a team across multiple projects, individual team velocity stops being a predictor of project performance.

Team velocity can be great and say absolutely nothing about the performance of either project.

Feature Teams or Component Teams

The component team challenge is probably just a special case of the nesting problem, but since this pattern is so institutionalized, I want to talk about it specifically. Just to level set here… if every team on the project is not working on end-to-end… potentially shippable feature… you probably have some sort of component team structure. Component teams are common in more complex problem domains because many companies are trying to scale by reusing common architectural sub-components. Because the solutions are so big, it is difficult to get the right skills and domain expertise across the entire product. All this leads to teams organized around components.

We might not like it.. but this is out… there and unlikely to change.

From the perspective of each individual team… they have a prioritized product backlog… can get to done-done… and can burn down the backlog iteration over iteration. From the perspective of the enterprise, it takes several teams working in unison to deliver an enterprise class value feature. The Product Owners for these teams are balancing the needs of competing stakeholders… just like in the matrixed project example… but now we have an additional coordination layer to make sure that our teams are working with other teams to sync enterprise level feature sets. We have another example where team level velocity can be excellent while project level performance suffers.

The project is trying to throttle service creation through several teams. When all the services are in place, the project is going to integrate those services into an complete end-to-end feature. How do we normalize the project velocity in this environment? How do we predict the flow of value at the project level. The basic fact is that by rolling up velocity you can’t. You can try to take averages over time but that strategy will fail. Why? Any team at any time can starve the value creation process. You can have 8 teams building great services and one team struggling. That one team will prevent the creation of enterprise value.

Now let’s make things even more complicated. Usually were not just running a single project, we are running a project portfolio. We have several projects that are dependent on the services of these component teams. Now the backlog of each component team is a mixture of features required for multiple projects. In this case… we have a team that is building services for many projects and services have to come together to deliver enterprise features. At anytime in the project… team velocity can be fantastic. We could be stable and improving at the team level and unable to deliver anything at the project level.

Great Teams… Bad Businesses

What’s frustrating is that every team can be doing great agile. They can have a coach, great teamwork, great collaboration, great engineering practices, run great meetings, have outstanding velocity… and the business thinks they are failing. The business doesn’t care about all that stuff… they value delivering end to end features to market as fast as possible. So we have a problem… an impedance mismatch of sorts… between the team and the enterprise. Here is the problem as simply as I can say it… typical Agile scaling assumes a many to one relationship between teams and projects. The reality is… that in many organizations… we are dealing with many to many relationships between teams and projects.

This many to many relationship is what breaks velocity.

So… you have a choice. Either you structure your organization such that velocity works… or you find something else to measure enterprise portfolio performance. Over the next few posts, we’ll explore an alternative to velocity at the enterprise level.

Pillar Webinar Today: When Change is Hard by Bob Myers

Written by Mike Cottmeyer Wednesday, 7 October 2009 12:57

Later this afternoon Bob Myers, the President and COO of Pillar Technology, is delivering a webinar called “When Change is Hard – How to Create a Culture of Change in Your Organization”.

Bob is going to go over several case studies based on Pillar’s experience helping companies lead large-scale agile transformations. I’d expect this to be a pretty candid discussion about things that went well… and things that didn’t. Bob is a super-practical guy and has a ton of great experience working with big companies in the thick of significant organizational change. If you are looking for some really practical guidance… or the opportunity to ask the really hard questions… this is the place to be.

The talk is today at 1:00 ET. If you can make it… head over to the Pillar website to register. I think it will be time well spent.

Velocity in the Enterprise, Part 2

Written by Mike Cottmeyer Tuesday, 6 October 2009 08:17

One of the advantages of using a software solution for tracking team velocity is that it is pretty easy to roll the data up. The idea is that you have lots of individual teams that all contribute completed features to a larger project or program. But… if I know that comparing velocity across teams is problematic… does the idea of rolling velocity up even make sense? Consider this… let’s say we have a feature that could take a single developer 3 days to finish. One team might think this is a pretty small item and give it a point value of one. A neighboring team might consider a similar feature a 16. Its the same amount of work for both teams its just that the second team has a different numbering scheme for the work.

When the features are complete, and you roll-up the data across the teams, you’d burn down a cumulative 17 points for completing both features. Looking at the data over time, and considering the law of averages, the roll-up does work… as does the burndown… it’s just that you risk the team with the larger point values obscuring the progress of the team with the smaller point values. Because this doesn’t result in a very clear picture at the portfolio level, many organizations start normalizing velocity across teams to try to tell a better story. By normalizing, I mean they come up with a standard definition for the size of a single story point. Having this baseline understanding takes some of the messiness out of rolling up velocity but the approach isn’t without some risk itself.

Normalizing velocity can lead to bad behavior. Why? One of the main reasons teams use velocity is to abstract the estimate from any notion of time or effort. If you map a story point to a unit of time… even temporarily…. it can lead managers to start resource planning based on points delivered. It can also create unfair comparisons between teams because it doesn’t account for team dynamics in the performance equation. It also doesn’t take into consideration the accuracy of the estimates and all the stuff we know contributes to making estimates uncertain. That said… even with those risks… normalizing velocity is almost a necessary first step when trying to assess progress on a multi-team program. Its a risk I’m willing to take.

Okay… given all that… even if we correctly understand velocity and are open to normalizing the numbers… that is still not enough to make velocity a meaningful metric in the enterprise. For a velocity roll-up to work, we have to make sure two key things are in place:

1. The sub-teams have to be completely nested underneath the program or project in a many-to-one relationship.
2. Each team has to be working on a feature that is relevant at the program or project level. It can’t take more than one team to deliver a feature.

We’ll talk about these constraints more in my next post… for now… give all this some thought and let me know what you think. Stay tuned.

Velocity in the Enterprise, Part 1

Written by Mike Cottmeyer Tuesday, 6 October 2009 01:21

Okay… so I am hoping that things have settled down enough and I can get back into my writing groove. It’s amazing how turning your life upside down impacts your ability to write on any kind of a regular schedule. I think I had underestimated how much I depend on having the right environment around me to be creative. Now that the transition from VersionOne to Pillar is pretty much complete… it’s time to start getting back into some sort of routine. This blog sure isn’t going to write itself… I am guessing the book won’t either.

Today I thought we could take another look at team level velocity and project velocity.

More specifically… I want to explore a bit where velocity works and where it doesn’t. I’ve talked quite a lot over the past year about how having a stable velocity is critical for having a well run and predictable agile project. We haven’t talked much about what it takes to have a well run and predictable agile project portfolio. About a year ago I started working with company after company all having the same fundamental problem… team level velocity wasn’t rolling up into enterprise level velocity. If we want to have a stable and predictable agile enterprise… the business has to know what it can expect. At every level of the organization, the performance of the team needs to be able to predict the performance of the enterprise. In many organizations… this just isn’t happening.

Before we can explain why velocity breaks in many organizations… I want to first talk a little bit about why velocity works… and get started on looking at the challenges with measuring velocity across teams.

Why Velocity Works

Velocity is fundamentally a measure of throughput. It’s a measure of how much work the team can deliver iteration over iteration measured in terms of completed features. The features are estimated using some abstract value like story points or ideal engineering hours and the value of all the estimates are added up to determine the size of the backlog. As the team completes a feature, the point value of that feature is subtracted from the total of the estimates and the feature list ‘burns down’ over time.

For this to work as designed, you have to understand a few things. The features you are burning down have to be small and independent. When you get to the iteration the features have to be totally done and defect free. There is no going back to readdress a feature without adding new work items to your queue. It is important that the team get good at making and meeting commitments so that the rate of feature completion gets steady over time. By measuring the rate at which features are ‘burned down’ from the backlog, you can begin to use past performance as a measure of future performance.

There is a bunch of stuff that is tucked up behind this idea of backlog, burndown and velocity. First, velocity builds in the idea that estimates are inherently inaccurate and deemphasizes spending a bunch of time creating detailed estimates up front. Features are estimated in abstract units that are generally defined by the team. In other words, one team’s story point is not the same as another team’s story point. Second, value is implied by the features relative position in the backlog. It is generally assumed that the team is building the highest value features first.

These factors make measuring enterprise velocity a challenge. You can’t compare velocity between teams because the units of estimation are all over the place. Different teams use different standards, make different assumptions, and have different team members doing the work. Different teams might have more external dependencies and might require skills or people not present in the team. They might require specialized domain knowledge that isn’t always available. In other words, it’s not just that points are different team to team… every team has a different ability to deliver the work.

So… my first challenge with velocity is that it isn’t really a meaningful measurement across teams. If it’s not meaningful across teams… what does that mean for the enterprise roll-up. We’ll explore that a little in my next post.