How Big Is Your Bucket?

A few posts back, I asked if an agile team should be expected to call their shots. In other words, should we expect that over time, an agile team should be able to accurately predict what they'll be able to deliver at the end of the iteration? My assertion was that predictability at the iteration level is the only thing that separates an agile project from total chaos. Without the ability to make small commitments on a regular cadence, we have no ability to forecast what we can get done.

I'm working with one team right now that has gotten really good at calling their shots... but... people keep getting pulled in and out of the team. Having a stable velocity is predicated upon the team working together, staying together, and learning how to estimate and plan together. The constant churn at the team level is making it really tough to establish a consistent velocity iteration over iteration. While the team is great at calling their shots, they are still not able to really say what they can get done... and by when.

I'm a big believer that if we can't get some idea of what we are going to deliver, and when we are going to deliver it... pretty quickly after spinning up a team... agile is almost a non-starter for most companies. Many of the companies I work with are not prepared to make an indefinite investment, with no idea of what they are going to get in return. Sure... agile teams fix time and cost, and vary scope to meet iteration objectives... but we have to have some ability to look ahead and manage the expectations of our customers. We have to have good data to help them make good decisions.

What I am really saying here, is that while calling your shots is essential, calling your shots isn't really enough. You also have to get good at understanding the size of your bucket. What does that mean? It means that iteration over iteration, I need to establish some kind pattern for how much feature functionality I can deliver back to the business. Out of the gate, I don't really care what the team delivers... or even how much they deliver... I want to know their delivery capacity over time. Not a hard fixed number, but a stable trend that I can base product decisions.

Over time, we will remove the teams blockers and help them deliver more effectively, but initially... they need to get good at calling their shots... and establishing the size of their bucket. So please... let me know what you think. Am I expecting too much from our agile teams? Should teams just be able to do what they can with no expectation of committed delivery? Even at the iteration level?

Subscribe to Leading Agile

Should Agile Teams Have to Call Their Shots?

What do I look for day-one coaching an agile team? The first thing I want to know is if the team is really a team? Do they have everything (and everyone) they need to deliver an increment of working software? Do they plan together, do they work together, do they deliver together? I'm generally of the mind that if you aren't going to recognize the team as the fundamental unit of value creation, you will struggle with almost everything else agile has to say about product delivery. You might be doing something... it might even produce working products... but it probably won't look very agile.

Once I have the team in place... the next thing I want to know is if they can make and meet a commitment. I want to know if they can be predictable. Right out of the gate, I am not all that concerned if the team can deliver fast... I might go so far as to say, I don't even care that they deliver value. To me, the most important thing is that the team gets good at establishing some sort of baseline velocity metric. I want them to be able to break down work into small chunks, put some sort of reliable point estimate on their work, and get good at doing what they say they are going to do.

Making and meeting commitments on a regular cadence is the heartbeat of an agile team.

Any of you guys ever play pool with your kids? When my kids were younger, they'd just walk up the table, quickly eyeball their shot, and do what they could to get the ball in the pocket. Every now and again they'd actually make a shot, but they'd never beat me playing an entire game. They were doing their best, but they never won. To really be successful playing pool, you have to be able to sink the ball you are trying to sink... and do your best to set yourself up for the next shot (or two... or three). Unless you are able to call each shot, you really don't have any idea how you are going to win the game. Success is accidental at best.

If the team can't call their shot... in other words, if they can't predict their velocity at the beginning of the sprint, there is no point doing any kind of forward thinking, any kind of release planning, or even trying to make a guess at what you are going to put in market when. Your product delivery dates are nothing but fiction. Having a stable velocity is the fundamental prerequisite for managing the expectations of the business. It's essential if you are coordinating with other teams to deliver the release, and essential for making tradeoffs when things don't go exactly as planned. Stability builds trust with your product owner and it builds trust with your business.

Do what do you think? Is it important for agile teams to be able to call their shots? I think it's essential.

Subscribe to Leading Agile

How to Build a Large Agile Organization

Okay... consider this scenario. We have a 300 person IT shop responsible for developing control systems that automate large buildings. These systems require front end developers, middleware developers, firmware developers, and hardware engineers. A feature in this system requires us to write code that touches every layer of the overall systems architecture. As it stands right now, the teams are organized around the major subcomponents within the overall solutions framework.

How does a company like this adopt agile? First inclination might be to break up the component teams and create cross-functional feature teams. Each team would have some number of front end developers, middleware developers, firmware developers, and hardware guys... right? The general idea is that any one of these cross functional feature teams would be able to write software for any part of the overall system. Everyone on the team becomes a specializing generalist.

While it's not impossible to cross train someone who specializes in UI development with someone passionate about firmware (or hardware)... but my guess is that most folks aren't up for it. My bet is that most organizations don't have the test coverage to make this kind of experiment safe. I've talked with several organizations that have given this a shot, and the change was so disruptive, they couldn't get anything done. Seriously... nothing done.

I'd like to suggest for a moment, that our goal here isn't really creating cross- functional feature teams; the goal is to build teams that have everything they need to build an increment of working software. I think that there is a difference between the two. To be agile, we need to to build teams that can stay together over time, become high performing over time, and build trust with their customers over time. They need to build working product.

We tend to assume that in order for this to happen, we need to organize teams around end-to-end features. I agree with this approach when we are talking about small teams and small products. This advice breaks down when we talk about larger teams, and larger... more complicated... more technologically diverse product lines. The agile community needs a more stable, more robust scaling metaphor for discussing these kinds of organizations.

Here is how I have started thinking about this over the past few weeks, and I am starting to think that the language works... let's start talking about building teams around those things in our organization that are least likely to change.

If we are a small product company, with a single product... the thing that doesn't change might be a product. If we are a larger product company, with a more complex product offering, I might organize teams around a somewhat static grouping of features. If we are in a really large organization, one with multiple interdependent products, where investments are not level over time... the thing we organize around might be a component or some set of services.

The thing is... it's not always the flow of features into a product that is often the least transient. Sometimes we can't build a team with enough specialists... or specializing generalists... to get the job done. When that happens... and at some scale it will happen... we want to start looking for the stuff that doesn't change. When we find the stuff that doesn't change, that is where we start building agile teams. That gives us our best shot at keeping teams together.

When you take this approach, you have to keep in mind, that there is no longer any one team that is responsible for end-to-end value delivery. Each team delivers 'done-done' work every iteration, but as an overall enterprise, you'll have to develop the capability to manage the flow of value effectively across each of your various agile capability teams. This is where agile stops giving good guidance and we need something else.

That something else is Lean/Kanban.

So think about this... build agile teams around the persistent objects in your enterprise, whatever they happen to be. Use Scrum or XP or Kanban or whatever other agile method floats your boat at the team level. The teams can become hyper-productive and have as much agile goodness as you can get out of them. To scale all this agile goodness, use a Lean/Kanban approach to manage the flow of value across teams.

So, getting back to my initial question... what's the most effective agile strategy for our large control systems company?

Organize agile teams around the front end, the middleware, the firmware, and the hardware. Create an enterprise backlog of value features that get broken down into user stories and distributed across teams. Subordinate each team's backlog to the enterprise backlog, and create a pull system, where new features only get started once the teams have capacity to work on them. Set work in process limits for each team to reduce the amount of work we can get started before we roll back up into a value feature. Invest in constrained capabilities to improve the overall flow of value across the system.

Make sense? Any questions?

Subscribe to Leading Agile

Managing to the Constraint

There is a part of me that is a little uncomfortable with my conclusion at the end of the 'Velocity in the Enterprise' series. Using a Kanban metaphor at the team, project, and portfolio level makes sense... I also think it is the right way to look at things... but I have a hard time recommending things that I think are really, really hard to actually do... at least without providing some sort of transition state to help you get there. I want to explore another mechanism for accomplishing basically the same effect, but without having to fully re-factor your entire organization.

For the purpose of this post, we are going to make some assumptions about your organization. We'll assume that in some form or fashion you are organized around small cross functional teams. These could be either feature teams or component teams. As long as we have a team that can establish a velocity, that's sufficient for our discussion We'll also assume for the time being that each team is working in a many-to-many fashion across several projects (or some combination of projects and non-project work). In short, we have assumed ourselves into the exact environment where velocity at the enterprise level doesn't work.

What if... rather than introduce a new planning framework... and a new language around Kanban, constraints, and cycle time... we just handled things a little more implicitly?

Managing Projects

Here's what I mean... Let's say that we have a project with a backlog of 'value features'... items that will actually create value for an end-user... something our customer is willing to pay us for. What would our project goal be? Just like a team wants to establish a stable velocity, to be able to use past performance as an indicator of future performance, the project needs to be able to do this too. Our goal is to be able to reliably and consistently deliver value features. As a project team, we pull the next set of value features into the iteration. Next we break down those value features into user stories that get allocated out to the various team level backlogs.

As a project, we know that we're only going to start things we can finish. We know we aren't going to tee up work that isn't going to get done in the next iteration or so. What we'll find is that some teams will have too much work and other teams won't have enough. Those teams with too much work are our constraints... they are our critical path. How do you shorten your critical path? You apply resources or you figure out how to do things in parallel. Shortening the critical path is the only way to actually shorten the project. At the project level, our job will be to groom backlog up to the point we have consumed all the resources on our most constrained team. The availability of capacity at the constraint limits how fast we can deliver value features as a project team.

What we have (in effect) done, is create an abstraction layer between team performance and project performance. At the team level I care about velocity because I can use it as a metric for continuous improvement. I can use my velocity to predict throughout and make commitments. At the project level I am not trying to map team level performance to project performance... I have abstracted them from each other... because at the end of the day, all I REALLY care about is project level velocity... it's the project level velocity that delivers value. I will also have to pay attention to the velocity at the constraint too... but not because it is directly correlated to project performance... but because that is where I need to focus resources and improvement initiatives to get my project to go faster.

Managing Portfolios

Now here is the deal... projects need to be prioritized just like we prioritize user stories. The number one project in the queue needs to get all of the resources at the constrained team. Okay... maybe the first and second interleave a bit... but in general... the constrained team should always be working on the most important stuff. This is going to force some amount of serialization of the project portfolio... we are only going to have one or two of the most important initiatives going at any one time. We'll be able to have that conversation because we know what subset of the organization is constraining our ability to build software. Giving them more stuff to do will only slow them down.

But what about those teams that have extra capacity? We learned earlier that some of the teams are gong to be less busy than the constrained team. True... but here you have a few hard decisions to make. You can either redeploy those people to work at the constraint... or... you can give them features to build that can be delivered independent of the constraint. Here is the hard part... if you a team work to do, work that requires resources at the constraint... and the constrained resource isn't available to do the work... your taking a pretty significant risk that the team is building the wrong product or that teams will get out of sync with each other. You risk that they are creating waste and distracting your organization from it's highest priority objectives.

So what happens at the portfolio level? Just like the project velocity is abstracted from team velocity... the portfolio will establish a velocity that is independent of the team as well. At some point we'll be able to measure how many 'project points' we are able to get done a quarter. We still care about team velocity... we still care about value feature velocity... it's just that we don't count on these metrics to be directly related to portfolio performance. We are in effect applying the same principles of abstraction between individuals and teams to team and projects and ultimately projects and portfolios. Each layer in the management hierarchy has its own velocity but it is not directly related to any of the velocities of the lower order management structures.

Managing your organization by managing to the constraint allows this to work.

Velocity in the Enterprise, redux

You see... we are really applying many of the same TOC (theory of constraints) principles we talked about when we talked about enterprise Kanban, but rather than try force a whole paradigm shift... we are leveraging much of the same language and all of the same principles to actually make velocity work. The difference is that we are leveraging the management team... or the project management team... maybe even the product owner teams... to allocate (or limit) work based on knowledge of the constraint, and to stop assigning work when teams are at capacity. We are dealing with the constraint implicitly using shared understanding of the methods and principles rather than the explicit constraint of a Kanban board.

Subscribe to Leading Agile

What We Call Stuff Matters...

In my post 'Organizational Myopia' we talked about an increasingly common problem with the language we use. We 'talk' quite often like we are delivering a cross-functional end-to-end feature of the overall system, when in reality... we are really only delivering a subset of the solution. We are delivering a 'feature' that has to be integrated with other 'features' in order to deliver real customer value. Why does this matter? It matters because when we allow ourselves to only care about... only track progress on... only get better at our little slice of the world... we risk investing money and time building 'features' that might never get sold to an actual customer. Focusing on end-user value is critical to overall organizational success.

Part of our problem is that the language we use to describe value is ambiguous... it's open to interpretation. Exactly what is a user story? We can go with the Ron Jefferies definition... a card, a conversation, and a confirmation. What is Ron saying? A user story is a placeholder for a future conversation about the requirement. That conversation is supposed to be with the 'customer' and we've already discussed that a 'product owner' is not necessarily our end 'customer'. What about Bill Wake and the INVEST model? A story should be independent, negotiable, valuable, estimate-able, small, and testable. This definition is more specific as long as we are clear about what adds value. Valuable to the customer? Maybe... but again... who is the customer?

Back in my project management days... we were blending methodologies all over the place and had to get really specific about the language we used. People were learning and we couldn't take anything for granted. The default corporate methodology was RUP so we talked a bunch about use cases and I spent a lot of time explaining how to break down requirements in that language. During that time we had the notion of a use case, a use case scenario, and a system level use case. Use cases were an umbrella description... an aggregate maybe... of some number of use case scenarios. Each use case would have a primary success scenario and some number of alternate scenarios. A single success scenario and some number of alternate scenarios were typically the minimal increment of business value.

Our applications were complex and quite often any given use case scenario would touch several significant system components. We might have a use case scenario that hit the mainframe transaction processing engine, the enterprise data warehouse, a statement processing engine, a set of web-services, a message bus, and a java based customizable front-end. Each component would have a series of system level use cases that expressed the changes that had to be made for each of our components. Whereas the 'actor' for the use case or use case scenario was likely an end-user, the 'actor' for the system level use case was likely another system. It was only by building out a number of system level use cases that I would have a scenario, and only some number of scenarios before I had a 'feature' that was relevant to an end-user.

Given this as our backdrop... where does a user story live? Is a user story a use case? How about a use case scenario? Could it be a system level use case? I think that in practice most folks would agree that a top level use case is too big for a user story. A top level use case is more like an epic or a feature group. I tend to think of a user story more like a use case scenario. There is a primary scenario, and some number of alternate scenarios, that each individually provide some capability to an end-user of the system. We can prioritize these items, decide what is minimally marketable (how much error handling for example) and be potentially shippable when we are done. Sound like user stories to me. Lately though... and this is the nut of the discussion... I've talked with lots of teams that are using the idea of a system level use case as the definition of a user story.

System level use cases ARE an increment of working software. They do have 'value' in the sense that they are meaningful to the overall system. They are potentially shippable. The problem is that your customer doesn't care about them. Another problem is that a team's velocity delivering these system level use cases is not in any way related to your ability to deliver an end-to-end use case scenario. So... here we have the language problem. If my backlog is filled with system level use cases... but I talk about these use cases as if I were delivering a use case scenario... and measure my performance like I am delivering a use case scenario...then I am only pretending that I am delivering value and my team based metrics are pretty much crap. Many, many teams are starving their organizations... not delivering real value to the business... but think they are doing great agile.

That is a problem.

So... a few posts ago... when we were talking about program level Kanban, project level Kanban, and team level Kanban... this is what we were talking about. We might have any number program level use case... small projects moving its way through the system. These use cases are broken down into any number of use case scenarios and then ultimately system level use cases [that are assigned to teams]. The teams are responsible to deliver the increment of software... the enterprise is responsible for prioritizing that work, planning that work, sequencing that work, and making sure that the work comes together into some sort of aggregated deliverable. If the work of the team is not ever aggregated... in a systematic, disciplined way... we run the risk of having great team velocity and really poor organizational velocity. We need both.

The main takeaway here is that language matters. What we call stuff matters. Thinking about the entire enterprise like and end-to-end system matters. When we allow organizational myopia... when we bend the words to make things work... when we play games with language, we are going to have problems. You need to know what these words mean for your organization... how all of this works together... and what it takes to ensure we are driving real value for the business.

Subscribe to Leading Agile

Velocity in the Enterprise, Part 6

Okay... so the travel marathon starts today. Spent an hour in the Sweetwater Pub in the Atlanta airport earlier this afternoon. Had a nice Sweetwater IPA and a great bowl of 420 Beer Cheese Soup. Very tasty. Got on the plane and the weather was so bad in Boston, they kept us on the ground for extra hour while air traffic control cleared things out for us. So... I did a little writing... took a little nap (the beer made me sleepy)... and then got up and did some more writing. The good news is that Delta bumped me to first class at the last minute... so while I was late getting into Boston... at least I had a big comfy chair. Here is the result of my flight today... if you disagree... I am blaming it on the IPA ;-)

... last post in this series, we discussed that when we have a many-to-many relationship between teams and projects, velocity is not a meaningful metric at the project level. Velocity CAN be used to establish a steady throughput at the team level. Velocity CAN be used to help the team get better. Velocity CAN'T be used to establish the rate of flow of integrated end-to-end stories at the project level. Velocity CAN'T be used to establish the rate of flow of small independent projects at the portfolio level. In other words, the performance of the team IN NO WAY directly implies overall organizational performance at the project level... or at the portfolio level. Period.

Value Streams and Work-in-Process Limits

To get this worked out... we are going to have to take a look outside of some of our typical agile thinking. I want to explore for a moment some of the recent thought leadership around Kanban and see if there is anything we can apply. What new idea is Kanban fundamentally bringing to the table? To me... Kanban's primary contribution is that it is making the flow of value within the team explicit. We all know that every team has to move a user story from definition, to analysis, to design, to development, and ultimately test and deploy. This doesn't say anything about who does what, or in what order, it's just that Kanban elevates these steps, puts them on the board, and helps the team visually track how the features are being delivered.

By setting work-in-process limits on each step in the value creation process, on each column of the board, the team can easily see where there are constraints and bottlenecks limiting their ability to deliver valuable software. We can see when requirements are piling up in front of the developers. We can see when code is piling up in front of QA. We can see when we are building and testing a bunch of stuff that never gets integrated or deployed. Putting a visual control in place allows us to focus our time and attention on identifying and getting better at the parts of the process that are slowing us down.

When I was doing my 'Noodling on Kanban' series, I spent an hour or so talking to David Laribee comparing and contrasting the various aspects of Kanban with other agile methodologies. He said one thing that really stuck with me. He said that Kanban respects a reasonable division of labor (David's words). Scrum leaves the division of labor up to the team... it assumes specializing generalists. It assumes everyone can do everything and we can therefore treat the development process like black box. Kanban allows for the fact that sometimes we don't have specializing generalists, or at least that everyone doesn't do everything, and gives us explicit tools to manage how value flows across a series of somewhat independent agents (my words).

Bringing this back to our example... we might find a bottleneck between requirements and dev that tells us we need more developers... or maybe the constraint is with testing and we need more QA folks... or more maybe we need more folks that can deploy the code. We might find that we have a persistent problem with the build servers, or the CI environment, that is preventing us from getting value out of the system. I am not saying that we can't figure out these things in a self-organizing Scrum team... it's just the Kanban board helps us visualize it and make it more real. It gives us explicit controls to 'stop the line' when we have a problem rather than leaving that up the chance.

Cycle Time

Another aspect of Kanban that is new to the agile community is the idea of cycle time. Cycle time measures the time it takes to bring a new feature all the way from backlog to final delivery. If you look at VersionOne's implementation of cycle time, the tool can tell you how long (on average) that it takes to complete a single user story, and how that time changes depending on its relative estimate. We might be able to say that an average one point story takes 5-6 days. We might be able to say that an average two point story takes between 11-12 days. If you have cycle time... some folks believe that the iteration boundary becomes meaningless... that velocity becomes meaningless... that the team can get predictable just based on knowing how long it takes us to complete a story of some given size.

There is a bunch of evidence coming from the folks applying these ideas that the approach is working and can actually make the team more effective. To me though... at the team level... it is kinda six in one hand, half a dozen in the other. If the iteration is waste... if you don't need sprint planning, daily stand-ups, or review meetings... don't do them. If you don't need velocity measured at iteration boundaries... use cycle time. But... what if we can't use velocity because in our environment velocity doesn't work? Now it's not a matter of cycle time or velocity... velocity just isn't an option. Could cycle time provide an alternative?

Cycle time in the Enterprise

What I want to in my next post is extend the Kanban planning metaphor outside the team and see if we can apply the same principles across teams. Just like Kanban supports a reasonable division of labor across individuals with various degrees of specialization... Kanban will also support a reasonable division of labor across the teams that make up our product delivery organization. Rather than thinking about the value stream as being made up of specialists delivering on the steps in the development process, think about the value stream as being made up of the components required to deliver a complete integrated feature back to the business.

Subscribe to Leading Agile

Velocity in the Enterprise, Part 5

Before we start talking about an alternative to velocity, let's take a moment to recap the last few posts in this series... I've basically stated that velocity only works in certain circumstances and in certain types of organizational structures. For velocity to work as advertised... first, the organization has to be totally feature driven. Every team has to work on a complete end-to-end slice of user functionality. Second, the teams have to be totally nested underneath the project in a many-to-one relationship. If teams are supporting multiple projects, team level velocity isn't meaningful at the project level.

What's interesting is that most companies have a really hard time achieving this ideal structure even within the technology organization. At this point, we haven't even considered the parts of the business outside of product development. What about sales... what about marketing... what about accounts receivable? In some form or fashion... these guys are responsible for getting the value out of the system too. Are these guys going to be nested underneath the project team hierarchy as well? I doubt it. So when we start looking at the enterprise value stream... velocity is almost a non-starter. The answer I believe lies in thinking about the collection of teams required to deliver a value feature much in the same way we look at the individuals on a single team. Let me explain.

A team is a collection of people necessary to deliver an end-to-end feature. You might have several developers... a BA... a tester or two... a customer... maybe an agile PM or a ScrumMaster. The team considers one or two small features at a time... they collectively negotiate the requirement and decide how the feature is going to be constructed. The team breaks the feature into tasks and the tasks are completed by the individual team members. They collaborate... they self-organize... they work together to make sure that all the parts come together in the form of a cohesive whole. The cohesive whole is then reviewed by the customer and accepted by the business.

The team always works on the highest priority features with the goal being to get to done as fast as possible. The team values finishing one feature before they start a new one. Team members help each other and balance the work because each team member has skills outside their primary area of specialization. There is an implicit understanding that there has to be some design before you can code... some code before you can test... some test before you deploy. Some of the steps are handled sequentially... some are handled in parallel. The team handles all that sequencing because the unit of work is small enough that they can handle it.

The measure of progress isn't activity... it isn't tasks on a plan... it is completed features.

Now... let's build on the core concept of a small team working to deliver a discrete feature and explore how it could be applied to a team of teams working together to deliver a small project. The collection of teams is analogous to a collection of individuals... the small project is analogous to a single user story... releases are analogous to sprints... user stories are analogous to tasks. The teams get together at the beginning of a release to collaborate on the one or two small projects that they can deliver in the next three months or so... they break the project into user stories that are assigned to teams. Teams then deliver their individual pieces and work together to integrate those pieces into an integrated whole. The whole is accepted by the business and released to an external customer.

In this example we haven't done away with velocity all together... each team can track its own individual velocity to help measure throughput and get more predictable. In this case though... the only meaningful velocity is the velocity of small projects that make their way through the overall system. Just like tasks and activity don't measure progress at the team level... from a project perspective... team velocity is useful but not a measure of real project performance. The rate of delivery of small independent projects is the metric we really care about.

Hopefully this is all making sense so far. We haven't solved the entire problem but this should give us a solid baseline for the next few posts. Hang in there... we'll get through all this eventually ;-)

Subscribe to Leading Agile

Velocity in the Enterprise, Part 4

Lot's of companies are finding out about velocity the hard way. There are many, many contexts where velocity just can't be used effectively to measure enterprise throughput. These companies are doing some interesting things with velocity in an attempt to compensate for organizational structures that are just not setup to be really agile. These organizations start tracking individual velocity... they start mapping points to hours... they start planning sprints in advance... they start mapping dependencies to try to get some level of predictability. They start doing predictive, plan-driven project management under the guise of agile.

These organizations might be delivering software incrementally... which of course is better than one big-bang delivery at the end... but they are not able to really inspect and adapt... they are not able to do lightweight planning... they are not able to do lightweight artifacts. They are not able to keep the cost of change low... and we know that when the cost of change is isn't low... we get resistant to change... and being resistant to change is the antithesis of agile. So... it is a pretty interesting dilemma... and we need an answer.

We want to be able to use velocity at the enterprise level, but at the end of the day... our projects and portfolios... our teams and our organizations are not setup properly to be able to make velocity a meaningful measurement. Recognizing the problem is the first step toward defining some meaningful alternatives... the next step is defining some meaningful alternatives ;-). No matter what we come up with... we have to accept the fact that much of what we are reading in the agile literature is not going to work without some sort of measured, planned adaptation. Scrum (by the book) isn't going to work unless you can transform your organization overnight... and in most companies... that probably isn't going to happen. Here are a few approaches I have used with varying degrees of success:

Only Build Software with 6-8 People

Believe it or not... this is the answer that lots of people come up with. Why bother to solve the scaling problem at all? Let's just have small teams take over the world of software development. Let's never build anything big or enterprise class. Sure... small always makes things easier... but it is definitely going to limit the size of the problems we'll be able to solve. And somehow this just feels like we are punting on the problem. Maybe we just forget about the rest of the organization and get really good delivering what we can control? We just pretend we are small when the enterprise around us is really big. That works great until you realize your team is doing awesome but the enterprise can't deliver anything of value. Any guarantee that your team won't be the ones to go at the next round of layoffs?

Totally Restructure the Organization

We could tell the leadership of our organizations that we have to move to a nested feature team model. For that model to work... we need to get to a place where we have total test coverage, true shared code ownership, we'd have to be comfortable that any developer could touch any part of the system, and we'd have to let go of any sense of having a unifying architectural vision. After all... Enterprise Class Systems Architecture just emerges... right? We'd need to have a solid commitment to building teams around specializing generalist and trust that no solution would ever require any meaningfully specific domain knowledge to build out the product. Everybody gets to do everything.

It wouldn't be trivial, but I think you might be able to pull off this approach transforming a 50-60 person organization. I maintain though... at some size... at some level of scale... taking the nested feature team approach is going to become unmanageable.

Combine Velocity and Traditional Project Planning

This is a more honest approach than trying to force velocity to work when the conditions necessary for it to work are not in place. Rather than bend velocity into something it isn't by mapping points to hours... or tracking velocity at the individual level... go ahead and concede that enterprise velocity just isn't going to work in your company. I would rather see a project manager use high-level Gantt charts at the portfolio level and use velocity and burn-down at the team level. The teams can use velocity to forecast and make higher level project commitments.

The project schedule is created by the project manager using team-based velocity data. The key is to update the project schedule... iteration over iteration... as the team builds and learns about the emerging product. The schedule becomes a high-level roadmap that governs where we all need to be and when. Just like an high-level architectural vision can guide and constrain the solution, the high-level project schedule will guide and constrain our iteration objectives. At the end of the day... it is really never the Gantt chart that is the problem anyway... it's the attitude that the Gantt chart is Gospel that causes problems. Used appropriately and at the right level of abstraction... the Gantt chart can be an okay tool for solving this enterprise integration problem.

Abandon Velocity all Together (Almost)

The solution is going to take more than a few paragraphs to explain... but I want to touch on a few high level ideas before we wrap. The answer to the velocity problem is going to be found by looking outside the boundaries of traditional agile approaches and building in some of the principles and practices that seem to be just outside mainstream agile. We are going to need Lean... we are going to need Kanban... we are going to need the Theory of Constraints. We are going to need to think differently about how we select and approve project and how we are going to build our project portfolios. We are going to have to make smaller bets and build systems in smaller chunks. We need to start focusing on the flow of value that LEAVES the organization rather than the "value" we create INSIDE the organization.

We'll explore some of these ideas over the next couple of posts.

Subscribe to Leading Agile

Velocity in the Enterprise, Part 3

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.

Subscribe to Leading Agile

Velocity in the Enterprise, Part 2

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.

Subscribe to Leading Agile

Velocity in the Enterprise, Part 1

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.

Subscribe to Leading Agile

Stability first... then speed!

So many folks want to flip a switch and magically become agile. They want all the benefits without any of the hard work that comes along with really transforming the organization. People think that just because they read a book... or took a few days of training... that they can expect instant productivity. They don't realize that agile methods only show you your problems... it is still up to you to fix them.

I'll often see this thinking manifest in questions like "how many iterations until I can expect my team's velocity to start going up". There is so much underneath a question like that, it's hard to give a solid answer. Is there a prioritized product backlog? Is there a product owner grooming the backlog and available to the team? Is the team cross-functional? Are they dedicated to the project? Do they have everything they need to be successful? Are there external dependencies?

All those things matter... and right out of the gate.. you are not quite sure the kind of impact those answers will have on the team's ability to deliver.

My recommendation is generally to look at team performance in three phases. The first goal is to measure what is... to establish a performance baseline. Next start thinking about getting stable... stable performance is key to running a predictable agile project. Once you are stable... now you can start thinking about getting faster. Adopting agile is a learning process and you can't improve a system when you don't understand what is broken.

And that is really the key... it isn't about getting a better velocity. It's about fixing the broken parts of your organization. It's about looking at where you are and comparing it against where you would really like to be. It's about understanding the impediments standing in your way and dealing with them in a meaningful way... in a way that really, truly helps the team get better. It's about getting more efficient at creating value and really improving the processes that allow value to be created.

Those kinds of answers don't translate into a great marketing pitch. How long will it take to get agile? I don't know... how many iterations will it take to remove the organizational impediments that are slowing the team down? How many iterations will it take until you are willing to fix what is really broken? How many iterations until we are ready to stop applying labels and start REALLY transforming the organization?

Subscribe to Leading Agile

Comparing Value and Velocity

Is there a difference between the value a team delivers and their velocity? Said another way... if I increase the velocity of the team... aren't I getting more value from them over time? Like so many things we talk about here... the answer really depends on your context.

You might be inclined to make the argument that velocity is really just a measure of how many story points the team can complete in a given iteration. There is no explicit dealing with value... only relative size. But... if the Product Owner is prioritizing the backlog... and asking the team to deliver the highest value features first... isn't there an implicit correlation between value and velocity?

My take is that there is a correlation between value and velocity at the team level... it is when we get beyond the team that relationship starts to break down.

Think about this scenario... let's say them team is cranking out feature after feature... adding great stuff to the product... their velocity stabilized a few sprints back and is getting better and better every iteration. The company has a great product but a terrible sales team and even worse marketing. While the product is technically superior to their competition... how valuable is it if no one buys it?

You might make the case that all those really cool features ended up having very little value to the market. Great velocity... not so much value.

Here is another scenario for you... let's say you have four teams that have to work together to deliver a new product suite to the market. Teams A, B, and C have fantastic velocity but team D just hasn't been able to get their stuff together. Team D ultimately delays the release... and the overall product is late to market. In the meantime... the competition just released the latest version of their product and yours doesn't do so well.

How much did the velocity of teams A, B, and C help the overall value of your product? Again... great velocity... not so much value.

Okay... last one. Let's say you have 7 component teams that have to deliver features into several major architectural sub-components. All the teams are rockin'... they have met all their high level milestones... they know where they need to take their part of the project. One of the teams realizes a significant risk and their velocity tanks. The rest of the teams keep going... they are building great stuff... stuff that certainly has to be built someday... but again... that one team causes us to delay the release.

Most of the teams were doing great... one team not so great... where did all the value go?

Lean tends to take a broader look at value delivery across the entire value stream... across the enterprise... Scrum by it's very nature tends to look only at the delivery team. So... at the single team level... you can make a great case that there is a correlation between velocity and value. It's an implicit link, but it is there. When you start looking outside the team... across the entire value stream... that is where the correlation between value and velocity starts to break down.

When the Lean folks say that Scrum focuses on velocity and Lean focuses on value... as I see it... this is the reason why.

Subscribe to Leading Agile

Throttling the Agile Enterprise

It feels like a year ago I did the post Enterprise Constraints and Feedback. The past few weeks have been filled up with the Lean & Kanban conference and some client work that required my undivided attention. Toward the end of that post, we talked about 6 principles that allow your organization to properly throttle work through your agile enterprise. I wanted to take a moment this afternoon and explore those a bit and see where it takes us:

Make small bets by approving smaller projects

How many of you guys have been on an 18 month project? How many of you have been on an 18 month project that got killed or totally re-scoped after a year or so? The reality is that in today's economy the uncertainty associated with large scale software development projects is just too high. The longer it takes to get product to market, to get real customer feedback, and to start generating revenue... the more risk you accept as an organization. Given our track record of project failure... smaller projects are less risky projects... and therefore better projects to approve.

Prioritize for finishing projects rather than starting projects

This is a complicated one. It gets into this whole discussion around keeping work in progress to a minimum and optimizing for the overall throughput of the organization... rather than for optimal resource utilization of the individual. If you are an agile organization, and have bought into the idea of organizing around teams, you should be pretty good with the idea of 'done done'. 'Done done' means that we don't deliver partially completed work. The only features that count are the ones that are ready to be shipped to the customer.

Interleaving a bunch of partially complete projects just makes the overall system deliver value less effectively. If we have three projects in the portfolio that are all planned to take three months each... and I do them one at a time... when will they be done? The first one will be done in three months, the second in six months, and the third in 9 months. What happens if I try to do all three at once? Best case you might deliver the first in 7 months, the second in 8 months, and the third in 9 months. More likely you'll deliver the first one in 12 months and the other two will get killed.

Don't start projects that you are unable to finish

Building on this idea of prioritizing for finish rather than start... if there is more than one team that has to work together to deliver a project... or even a MMF... and we can't get all the work 'done done' within the time-frame allotted, don't start it. We usually use some form of logic that goes something like... well, we have this person or this team with nothing to do... let's get them working on the next project. Keeping people busy is not a good reason to start project work.

The problem is that starting the next project dilutes the organizational focus from working on the projects that are already in process. Chances are pretty good too that when the other teams free up requirements will have changed or we'll learn something that leads to significant rework. This is tough pill to swallow... but I would rather that idle team go help another constrained team... or even do nothing... rather than start work on a project that is underfunded and low on the priority list.

Work on the highest priority projects first

All of these are pretty closely related, but if we always prioritize the project that is most valuable to the business... and we always focus on getting projects to 'done done'... and we don't waste effort by working on things that don't have the support of the rest of the organization... we know that we will always be delivering the most valuable features to the business with the least amount of waste from building software that might not ever be consumed. This might mean that teams are idle at times... it might mean that teams need to be redeployed... and it might mean that you need to let some folks go.

Make sure to read the next section before you go and start laying folks off from your team... there is hope!

Provide support for those teams that are slowing down your ability to deliver

If you find that a large part of your organization isn't busy because one particular team is slowing everyone else down... cool, you have just found where you need to go help. An enterprise full of teams building software is a continuously shifting set of constraints just waiting to be optimized. Someone at the Lean/Kanban conference said that a perfectly optimized organization has only one constraint optimized at a given time. An organization with every team optimized is actually the least optimized overall system.

Having identified the team that is slowing down your ability to deliver, you have identified where you need to go get better as an organization. By focusing your attention on the team that is preventing the other teams from delivering valuable work to the organization, you are focusing on the area of your development organization that is going to yield the most productivity gains for the overall system. It does not make any sense for a team to get better delivering software if they are not your primary constraint.

Establish an enterprise level velocity

If each team has a velocity sprint over sprint... and we start making smaller bets... and we prioritize for start... and we don't start things we are not able to finish... and we start working on the highest priorities first... and we elevate our constraints... you know what happens? We can start measuring project velocity across the enterprise just like we measure point velocity within the team.

Pretty cool idea... let me know your thoughts on this one.

Subscribe to Leading Agile Subscribe to Leading Agile