How Big Is Your Bucket?

Last Updated on Thursday, 15 November 2012 12:38 Written by Mike Cottmeyer Friday, 20 August 2010 03:49

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.

Learn More

Should Agile Teams Have to Call Their Shots?

Last Updated on Thursday, 15 November 2012 12:38 Written by Mike Cottmeyer Saturday, 7 August 2010 09:33

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.

Learn More

How to Build a Large Agile Organization

Last Updated on Thursday, 15 November 2012 01:03 Written by Mike Cottmeyer Sunday, 28 March 2010 12:54

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?

Learn More

Managing to the Constraint

Last Updated on Friday, 16 November 2012 12:50 Written by Mike Cottmeyer Saturday, 21 November 2009 01:27

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.

Learn More

What We Call Stuff Matters…

Last Updated on Friday, 16 November 2012 12:50 Written by Mike Cottmeyer Thursday, 12 November 2009 12:39

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.

Learn More