Should You Use Agile To Build Your Next Home?

Written by Mike Cottmeyer Wednesday, 12 February 2014 07:24


Before we start our conversation about governance in the structure-governance-metrics framework we’re building out, I want to take a minute and see if I can finally tell you guys about the house my wife and I were planning to build this past summer. It’s an important conversation because we need to establish a shared understanding around what it means to plan on an agile project.

Scenario One – Team Agile Home Builder

My wife and I decide we want to build a new home. We find a piece of property we like in a nice neighborhood. We find a builder we like and think we can trust. We have a really good idea of the type of house that will work for us and our family. We decide that we want to spend somewhere around $500K to get the house completed but it needs to be finished sometime before our kids leave school for the summer.

Next step is to reach out to the builder and see what he can do.

The next day we show up at the builders office and tell him about our plan for our new home. The builder is really excited, seems competent, and is very confident he can get the house built within the time and cost constraints that we’ve established. We ask him what’s the next steps for planning construction on our new home. To our surprise, he tells us that he is an agile builder and doesn’t do any planning.

The builder proceeds to explain to us that as an agile builder, he doesn’t do any planning. He will meet with us every two weeks to determine our priorities and figure out the next most important thing to build. Every two weeks we can inspect what he’s built and change our mind about anything anytime. He tells me this is really in my best interest because I won’t know exactly what I want until I see it.

When I ask if I’ll have the house I want when I run out of time and money, he doesn’t know, but assures me I’ll have the most valuable parts of the house early. Furthermore, I could actually move into the house anytime during the build process, and if I decide I’ve built enough house at any time, I can cancel the contract early and pay him for only the weeks he worked plus 20% of the remaining contract.

So here is my question… would you spend your money this way?

Most people when they are spending their own money, want to have some idea of what they are going to get when the time and money runs out. They want some assurance that they’ll have enough bedrooms and enough bathrooms. They want to know the acreage of the lot and if they are going to get a one story or a two story house and how many cars they’ll be able to fit into the garage.

People understand they might have to make some tradeoffs later in the build process. They might go over on carpet and have to make some tradeoffs with the lighting. They might decide they want fancy cabinets and go with a less expensive hardwood floor. They might want to defer decisions about the colors, or the finish, or the bushes they want to put in the front yard. They aren’t willing to leave out bedrooms.

We wouldn’t spend our own money this way, but this is the way we are asking our customers to spend their money when they build software with us.

Scenario Two – Scaled Agile Home Builder

Fortunately for us, this wasn’t the way that our builder asked us to build our house. We did meet with him and describe our dream home. We talked about the property we wanted to build on, the number of bedrooms and bathrooms, and the number of cars we’d be able to fit into the garage. We talked about the quality of the finishes and flooring and how we wanted the yard landscaped. That took about an hour.

After that, we spent a week or two having meetings with the architect. We got pretty specific about the room layout, the number of floors, the layout of the basement, and the placement of the house on the lot. We made high level decisions about floors and cabinets, but didn’t pick any specifics, decide any colors, or pick specific appliances, light fixtures, or door knobs. There was way more left open then decided.

What we did decide was the stuff that would drive the cost of the house. The stuff that would be expensive to change later. We went into the process understanding that a ton of stuff was going to change, but there was also stuff that would be really difficult to change, and those decisions had to be made early. We talked about potential risks once they broke ground and buffered in case anything went wrong.

The result was a blueprint and elevation for the house. We had a line item budget for construction costs, material costs and miscellaneous tools and supplies. Every line item factored in a profit for the builder. Every line item represented some feature or attribute of the house that I would probably care about when the house was complete. We did all that in a few weeks and made no detailed decisions about the home.

It was interesting, the first cut of the plan was about $200K more than we wanted to spend and we were aware that there was some risk and should probably buffer another $50K just in case. Even though I trusted the builder, I had my CPA and advisor review the plan line-by-line just to make sure all the costs were reasonable and we were making a sound financial decision before we decided to move forward.

As we were reviewing the plan… the builder said something to me that was pivotal for how we were going to manage this project. He told me that I had a 20K budget for hardwood floors. For that price, he assured me that I would be able to get a high quality floor, extra long and extra wide boards, and a very high quality wood with a very high quality finish. That said, my budget was 20K for the hardwood floors.

When it got time to build put in the hardwood floors, it was up to me to choose what kind of floors I wanted to put in. If I decided I wanted a less expensive floor, I could save money and use it for something else. If I wanted an exotic wood like Brazilian Cherry, that would cost more and I’d pay extra. It would ultimately be up to me, but he would work with me to understand my trade-offs and any associated costs.

At Enterprise Scale, Estimates Become Budgets

I instantly made the connection that this was exactly how I coached teams to define, estimate, and plan software projects. You have to have a high level plan. You have to make key decisions early. You have to have time and cost estimates to present to the customer. What you don’t have to do is define anything and everything before you even get started. You have to establish budgets to bound your uncertainty.

At the point the builder made the estimate, he was bound to manage the project to that estimate… the estimate became a budget. The builder had to work with me as the primary stakeholder to help me make tradeoffs to live within that budget. As we break down software requirements, focusing on minimally marketable features and maximizing value, we are effectively doing the exact same thing.

Okay… let me drive this one point home. Just like you wouldn’t build a house with an open ended scope, your stakeholders don’t want to commit to an open ended software project. We have to do enough work up front to put together a credible plan, mitigate risk, and understand costs. We have to estimate the work, set budgets, and make tradeoffs to ensure the product is done on time and on budget.

It is important to be able to tell people what the project is going to cost and when it’s going to be done. It’s important to tell people what they are going to get for their time and money. It’s also important they know the risks and can buffer some contingency. They also need to know what’s locked and what’s open and the kinds of tradeoffs that they might have to make along to way to ensure success.

Why Is This Such a Difficult Problem to Solve?

The problem is that many software teams are trying to build products in less than ideal conditions. They are constantly realizing issues and risks they didn’t anticipate. They are working across too many projects at one time. They have external dependencies that can’t be managed or controlled. People are not dedicated to the team. The result is that people are coming to the conclusion software can’t be estimated.

Going back to the house analogy, it’s as if we are building on rocky soil and are constantly finding boulders that have to be broken up and hauled away. It’s as if we have contractors that never show up when they say they will. It’s as if we are constantly changing our mind between a one story house and a two story house or deciding we want a basement after the foundation has already been poured.

Summing It All Up

The answer can’t be throwing our hands up and refusing to make a commitment. We might have to pay a few thousands dollars to determine if the build is feasible. We might have to pay another few thousand for soil tests to make sure the land can accommodate our new home. You can spend money to mitigate risk. Sometimes you need to do some work to learn what you don’t know.

No estimating, no planning, and not committing won’t be the answer for most organizations. It’s not a starting place anyone can live with.

You have to ask yourselves what it is going to take to stabilize the delivery process. Forming teams that stay together helps, that was my previous post on structure. Having a governance model to control the flow of work helps too, that’s my next post. Having a means to mitigate risk, invest in discovery, establish baseline metrics, and the ability to measure improvement over time all play a part. More posts to come!

#noestimates is a #nonstarter

One final note… Kimi and I never ended up building this house. The neighborhood was beautiful. The plan and elevation were beautiful. We really liked our builder and trusted he could deliver our dream house within the time and cost constraints we agreed on. The problem was that housing prices were depressed in the county we planned to build in and the appraisal came in at 60% of the build cost of the home.

We could have moved forward anyway, but would have been instantly in a house that was worth less than we paid for it, with no indication it would recover in the foreseeable future. So sure, we spent a bunch of time and mental energy, and even some hard cash to find out we shouldn’t build the house. Had we built the house using mainstream agile thinking, we’d have found out too late it wasn’t worth what we’d actually paid for it.

We spent a few weeks of time and a few thousand dollars but avoided what would have been a very, very expensive mistake. That’s not waste in my opinion… that’s good risk management.

Check out the previous post, Shu Level Agile Isn’t The Same As By-The-Book Scrum.

webinar ad

Join the conversation. There are currently 7 comments.

Starting Your Agile Process Engine

Written by Derek Huether Tuesday, 11 February 2014 07:18

agile process

I read an interesting exchange on Google+ about Agile process transformation successes and failures. Here is one of the comments. Tell me if it sounds familiar.

QuoteMarks-ClosedMy previous employers had big problems with Agile. Attempted to use it multiple times and had a nice failure rate of 100%. As far as I know, they are trying again. I’m rather curious. Would be interesting to know how it turns out this time.

It’s hard to say this but I believe it’s ok if they’ve failed a few times, if they understand why and what needs to change this time around to be successful. Usually, they first need to become better planners and more predictable. The recommendation usually catches people off guard.  I’ve interacted with Agile zealots who believe that doesn’t sound like Agile. Personally, I don’t care if it sounds like Agile or not, if we’re able to get teams to deliver consistently over time when others can not.

If you like it or not, I can pretty much guarantee that company mentioned above will fail again, if they don’t have the proper organizational structure, governance, and clearly defined criteria for progress and success.  In other words, their agile process engine is going to stall.

Priming the Agile Process Engine

Beginning an agile process transformation is like trying to start an old vehicle on a cold day.  To add complexity, that vehicle has a carburetor and manual choke knob.  If you’re old enough to remember carburetors and chokes, you’re either going to smile or wince thinking about starting a “cold” engine. The important thing to remember is if you don’t do the proper sequence of events, given the current environment, you’re going to stall.  It could take an experienced driver only a few seconds of asking you questions to figure out what you did wrong and tell you what you need to do. Still, being told what you need to do is just treating a symptom. You, as the proverbial inexperienced driver, will need to learn new skills given the environment.  It takes time, persistence, and finesse.

Carburetors and Manual Chokes

When it comes to running gas powered engines, the only things old vehicles have in common with new ones is they all need a spark and fuel delivery. Getting a new one started is much easier, thanks to a complicated series of electronics, while starting an old one is dependent on what the temperature is and how well tuned the ignition might be.

If you’ve never started a car built before 1990, you need to realize that just turning the key won’t get the engine running. All it will do, especially if it’s cold, is crank away until the battery is dead as a door nail. Instead, you need to set the choke to allow the engine to suck in lots of raw gas so some of the vapor will ignite.

If your old car had a choke knob, you pulled it out to close the “butterfly” valve on the carburetor (this limits air intake, thus allowing a far greater fuel-to-air ratio).

I know this may be way too mechanically nostalgic or geeky for some but bear with me.

Now it’s time to start her up. With your foot pushing the gas pedal down about half of the way, crank the engine until it fires. It will usually start running, but rather rough. As you give it some gas you can slowly push in the choke knob until the engine smoothes out. 

If you do it wrong, you’re going to flood the engine and you’re going to stall.  The same goes for an Agile process transformation.

The Agile Process Transformation

When you decide you’re going to transform your organization, don’t just jump into the driver seat, crank on the starter, and put your foot to the floor. It’s not that simple.  For a car, you should be thinking about how long it’s been sitting or how cold it is outside.  What is the current environment and state of affairs?  For a transformation, you want to do some form of Agile adoption assessment.  Understanding the current environment allows an experienced coach to know what the next crucial steps will be to ensure you don’t stall.  Next, you’re going to want the proper organizational structure and governance in place.  That’s right, you need to know the rules of the road.  Lastly, you’ll need a system of measurements (metrics) in place to provide feedback and know when your transformation engine is warm enough or if your fuel to air ratio is still off.  Are you giving it too much gas?  Are you going to stall?  Do you have both hands on the steering wheel at all times?

As an experience driver, you’d listen very closely to the sound of the engine as she tries to turn over. You’re prepared to either pump the gas pedal or adjust the choke knob. If you smell gas, you know it’s time to curse and let the engine sit a while because you just flooded the engine.  More often then not, the experienced driver can react quickly because they’ve been through this before. It’s easier for an experienced driver to do it, then describe how to do it. Enterprise Agile coaches are experienced drivers.

Agile Process Test Drive

When I was in high school, I took Drivers Ed.  I sat in a classroom, reading book about cars and driving.  Regardless of how much classroom training I got, it was really just teaching me the basics. Once I jumped into a simulator, I realized how complicated things could be.  Here’s the kicker.  The simulator was a controlled environment.  Everything I learned up to that point got shelved, as soon as I got behind the wheel of a real car.  There were so many variables!  Not only did I have to figure out how to start the thing, I had to figure out how to accelerate and shift gears.  I had to learn how to avoid that old person in the left lane who’s had the right blinker on for the last mile.  And yes, in my youth, I crashed the car more than once.

Working with Agile teams is no different for the coach or the client.  It doesn’t matter how many certification classes you take, it doesn’t matter how many workshops or conferences you go to, nothing can compare to being on the ground with a team and having a client who is insisting on results.

Some Free Advice

When you were a kid, trying to start that 1979 AMC Pacer for the first time in 45 degree weather, you listened to your Dad or whoever when they warned you about the manual choke and what to be mindful of when you were ready to turn that key.


  1. If you think you’re ready for an Agile process transformation, get an Agile adoption assessment.
  2. Be prepared to change your organizational structure.
  3. Get ready to harden up your ALM governance.
  4. Identify metrics that are going to provide you feedback as to conditions on the ground.
  5. Don’t text and drive!
Join the conversation.

Shu Level Agile Isn’t The Same As By-The-Book Scrum

Written by Mike Cottmeyer Monday, 10 February 2014 08:07

Martial Arts

A couple of years ago… gosh, probably more than that now… I got turned onto the idea of Shu-Ha-Ri by Alistair Cockburn. Alistair talks about this concept in both Crystal Clear and Agile Software Development: The Cooperative Game. While it’s been a few years since I’ve read these books, what’s stuck in my head is that Shu means Beginner, Ha means Journeyman, and Ri means Master.

The idea is that, when you are just getting started, you need to follow one way of doing something. As you progress, you’ll learn the limitations of that one way, and ultimately discover that there are other ways to achieve the same or better results. Once you have mastery, you blend and adapt approaches without even thinking about it. That’s the point where the student has become the master.

Quite often though, I hear people using the idea of Shu-Ha-Ri as a way to mandate that new Scrum teams follow the rules of Scrum by-the-book. In a sense, this is fairly consistent with Alistair’s quote from Ron Fox in Agile Software Development. The Shu level student is copying techniques without fully understanding why and that Shu implies an allegiance to a single instructor (page 18, 2nd edition).

I think this is fine when we are learning a given style of martial arts, but what about when we are applying process or methodology to a complex business problem? What if the teachings of the instructor aren’t working? What if the teachings are not applicable to our given context? Should the student blindly apply the teachings without understanding why and without modification?

I think that some of us have taken the concept of Shu a little too far. I think some of us bring a certain arrogance in believing that any one approach is applicable to any given student in any given context. That said, I do believe that as students we progress through a Shu-Ha-Ri process as we learn… it’s just that my Shu isn’t necessarily your Shu when it comes to process.

I have always taught that Shu means the beginner must have one way that can work. If we give the beginner too many choices up front, they won’t know how to choose and may be overwhelmed. As the student gains experience, that one way will inevitably have limitations and need adaptation. Once the student has achieved mastery, they can adapt and blend techniques as necessary.

Let’s say I want introduce agile into a large complex organization like the one I wrote about in my last post. I can teach team level Scrum all day long, but it won’t solve their fundamental business problem. The problem is too large and too complex for team level Scrum. For this organization, a Shu level approach might be an implementation of Leffingwell’s SAFe model.

While SAFe is more complex than Scrum, it may be minimally sufficient for the more complex needs of the enterprise.

When LeadingAgile engages an organization, we’ll bring our skills and experience with Scrum, XP, Lean, Kanban, and SAFe to blend an approach that is minimally sufficient to run that particular enterprise at scale. From the receiving organization’s point of view, this approach is a Shu level implementation… even thought we’ve brought Ha and Ri level understanding to help develop the solution.

Even though we have blended approaches to create the Shu level implementation, there are many more options available to solve even more complex problems. As the client learns, they will learn the limitations of our Shu level implementation and begin to adapt their own process. This is Ha level understanding. In time, and with practice, the organization will progress toward mastery and achieve Ri.

In summary… don’t confuse a Shu level implementation of enterprise agile with a by-the-book implementation of Scrum. Your organization may require more advanced mechanisms to implement agile at scale. What you need is one combination of approaches that works consistently while you are getting started. Once you’ve got that working… you’ll learn, inspect and adapt, and make it your own.

Check out the next post, Should You Use Agile To Build Your Next Home?

Check out the previous post, How to Structure Your Agile Enterprise.

Join the conversation. There are currently 11 comments.

How to Structure Your Agile Enterprise

Written by Mike Cottmeyer Wednesday, 5 February 2014 08:58

Build new business


First of all… this is a really, really, really big topic. If we are lucky, we’ll get a start and maybe lay a foundation for future conversations. My goal in the next 1000 words or so is to at least introduce the foundational concepts, and frankly… help me see where I want to go with this. So… with all my pre-qualifications in place, let’s see what we can do.

Over the last few posts, we’ve talked about what it takes to do Scrum well and explored many of the anti-patterns that cause Scrum to fail. One of the biggest challenges to adopting Scrum is the ability to form complete cross-functional teams. Before we get into how to solve the problem, let’s first explore why it’s so hard to begin with.

First of all… let me share that I have NEVER worked on a small agile team. I’ve coached many of them, but my introduction to agile was in the context of large enterprise class financial systems… things like online banking and bill payment. The kinds of systems where the company makes a penny or two on every transaction and does millions every year.

Think about what it takes to build these kind of systems. Quite often you had a hundred or so people involved… maybe more. You are dealing with a very diverse technology stack. At the time, we had people building software in .NET, Java, C, and Cobol… interfacing with an Enterprise Data Warehouse, leveraging web services, PeopleSoft, and any number of other systems.

To make things more complicated, quite often the systems we were building were actually systems of systems. Not just in the Systems Engineering sense of the word, but actually products of products where the product we were building was made up of other products, each with their own customers, product management, and deadlines.

Our job was to introduce changes in these systems, not break any of the other existing functionality, make sure we delivered on time, without getting in the way of anyone else delivering on time. Needless to say, these were pretty complicated delivery efforts and required tons of analysis, architecture, and business sponsorship across the entire organization.

All said, the core team of folks was maybe 100 people or so, but we were interfacing with an organization that all said was at least 400 people.

Okay… so now think about the guidance that we give for the formation of a Scrum team. A cross-functional group of 6-8 people that have everything necessary to deliver a working, tested, increment of the product. How in the world would I get 6-8 people with the skills necessary, the understanding of complex workflows, and the domain knowledge to touch this many systems?

I’m not suggesting that it’s *impossible* to do this, but I’ll tell you… most products have not been built with the underlying architecture, test harnessing, or continuous integration necessary to even take a stab at shared code ownership across such a diverse stack. At some point, the lack of sub-system level ownership would very likely erode the integrity of the overall solution.

Even suggesting this would be incredibly risky proposition and likely a non-starter in most organizations.

So where does that leave us relative to forming Scrum teams? The idea of feature based teams in organizations building these kinds of systems, at this level of scale, is not practical guidance. If you can form a team like this in your environment… stop reading now and go do it. It is clearly the simplest way to go. If not, you have some work to do to figure this out.

Forming Capability Based Delivery Teams

Most organizations can be viewed as a series of capabilities. A product is effectively a capability. A feature set within a product can be a capability. Services that support multiple products can be a capability. Things like accounting, and finance, release management, and deployment can be capabilities. Performance testing and integration can be capabilities.

At the team level in any organization, rather than getting hung up on the idea of the cross-functional feature team, the idea is to form Scrum teams around capabilities. The capability based Scrum team operates just like any other textbook Scrum team, it’s just that their output is a capability that can be consumed by other capabilities within the enterprise.

Capabilities as defined here tend to have pretty well defined inputs and outputs, contracts and service levels with the rest of the organization. They typically rely on a less diverse technology stack and the level of domain knowledge necessary to iterate the product is less relative to the entire system you are trying to build.

The comparison we like to make here draws a parallel between refactoring a legacy architecture into a services oriented architecture. The goal is to get each of the services loosely coupled and highly cohesive. Similarly forming Scrum teams, we want each team to be loosely coupled and highly cohesive… just not necessarily responsible for an end-to-end slice of the entire product.

That said, if you think about it… we might just have a semantic argument at play. One man’s product is another man’s service. So from the point of view of the Scrum team, they are building a product… it’s just that the product is a service that can be consumed by the rest of the organization… building blocks if you will… that the enterprise software is based upon.

Forming Products From Collections of Services

The problem with services oriented teams is that, more often than not, our customers aren’ buying services from us (although sometimes that actually does happen)… it’s our internal product organization that is consuming the service. In this case, you may very well have a traditional Scrum team formed around a product or feature set of the product consuming the output of the services teams.

In this case, these Scrum teams operate more like a textbook Scrum team. They have a backlog, meet with the Product Owner, and produce working tested software every sprint. But get this… by definition, these teams wouldn’t have everything necessary to actually deliver the software, they are dependent on the services in order to create an end-to-end slice.

Here is an interesting insight…

The problem with this scenario, isn’t that the product team is dependent on the services team… the problem is that the product team and the services team are both delivering their backlog at different rates and potentially at different times. When an end-to-end feature requires both teams to deliver their piece… we create a planning dependency between the teams that is difficult to manage.

I’m clearly jumping into the governance conversation here a bit… but it’s these planning dependencies that are killing large scale agile adoptions. You can go the SAFe route and try to get everyone into the room to work out an integrated release plan. We’ll often do something similar but leverage a smaller group of people, running features through a Kanban system.

The idea is that we’ll manage requirements decomposition through a Kanban, but have queues to batch requirements into sprints or releases if the organization isn’t ready for a continuous flow delivery model. Either way, the challenge remains… when you have a large, multi-team system, it’s very likely that you’ll find bottlenecks in the system. Some teams will go faster than others.

The problem with bottlenecks is that one team races ahead building services while the product is struggling to make forward progress. Quite often, it’s the products that are able to race ahead and the service creation that struggles to keep up. In both scenarios, you end up effectively with partially complete code that no one can use.

High Cohesion and Loose Coupling

To alleviate these problems between teams, we come back to the idea that teams must be highly cohesive and loosely coupled. That means that we should avoid at all costs committing to features that require more than one team to be done in the same place at the same time in order to make an integrated delivery.

Maturing agile enterprises, need to move toward a model where the product teams and the services teams operate on their own individual cadence and are able to deliver software at whatever velocity they are able to commit. In practice, this results in three rules for team-to-team interaction in a large enterprise.

1. Product teams can only commit to delivering features based on services that currently exist. This is the least risky approach.

2. Product teams can commit to delivering features based on services that are on the near-term services roadmap. This carries some risk, but is usually pretty manageable.

3. Product teams inject dependencies, by requiring a service be created while the feature is in flight. This is the highest risk scenario and should be avoided if at all possible.

Basically, Scrum tries to solve the dependency and bottleneck problems by requiring each team to have everything necessary to deliver a working tested increment, asking each of the team members to serve as specializing generalists, and having people swarm on backlog items to get done and stabilize velocity. I totally agree with all of this, it’s just not practical at scale.

We’ll explore this more when we talk about governance… but for now… let’s recap where we are.

Large organizations often can’t implement the idea of a complete cross-functional feature team. In these organizations, Scrum teams need to be organized around capabilities, products and services that must be combined to evolve delver software at enterprise scale. The more effectively we can decouple the delivery teams from each other, the less planning overhead we’ll require.

Product Owner Teams

I’ve been on record for quite a while that I believe the single product owner construct is a myth in most organizations. I get why this was created and why it should work. Without a singe voice of the business to give clear unambiguous guidance to the team, the team is going to thrash. The problem is that a single person with the necessary skills and authority to create the backlog don’t often exist in companies.

We’ve been a big fan of a construct called a Product Owner Team and implement this construct almost everywhere we coach. The idea is that to sufficiently groom a product backlog you need several points of view. We encourage the PO Team to have of course the product point of view, an architectural point of view, an analyst point of view, and a project management point of view.

I’m not talking about roles or people, I’m explicitly talking about the perspective brought by each of these disciplines, regardless of who actually does the work. When you are working in a methodology based on the idea of fixing time and cost, and varying scope to meet business goals… it requires more than just the business’s point of view to make the appropriate tradeoffs.

When we are working in a predictive-convergent organization… remember that concept… our job is to figure out how to solve relatively fixed business problems with somewhat pre-determined solutions. By having these four perspectives working together, you can make real time trade-offs about what to build and how to build it to optimize your chances of being successful.

I kept promising to tell you guys the story about my house… that would have illuminated some of my thinking here… but that will still have to wait for another day.

Portfolio Governance Teams

Similar to the Product Owner Team structure, we find that many organizations need cross functional teams of leaders to approve the investment increments at the portfolio level of the organization. Depending on the size of the organization, this can be a team of directors and managers. I’ve implemented it as a team of the CIO, CTO, the VPs of Engineering and Marketing.

Most organizations have some sort of governance model in place… a phase gate model if you will. Again… we’ll talk more about this when i do a post on agile governance… but for now, just think about leaving your existing phase gate model in place, model it in a Kanban, run much smaller batches through the system, limit WIP, etc… you get the picture.

For the same reason I like cross-functional teams providing guidance on requirements decomposition, I like cross-functional groups of leaders providing guidance on how work is approved and flowing through the system. When delivery is blocked, the leadership team can see it, and help get the resources necessary to the teams to get things moving again.

That Still Isn’t Everyone

At this point we’ve talked about teams formed to help work get approved and into queue to be built, teams of people that are responsible for requirements decomposition and high-level architecture, and teams of people responsible for building products, and different teams of people responsible for delivering services. What about the rest of the organization.

Some organizations have strategy groups, marketing, sales, integration, release management, performance testing, infrastructure, DevOps, SCM… and many, many others that I’ve failed to mention. Should we tuck these people into Scrum teams, or maybe disband these groups and let the Scrum teams do everything themselves?

That might work for smaller organizations… but again, in many of the large organizations we work with, these functions are necessary, and maybe even necessarily separate. For us, this is where the Lean part of Lean-Agile program and portfolio management comes in. It doesn’t matter so much how these teams work, if they use Scrum or Kanban or Waterfall.

What matters is that these teams agree to work with the other parts of the organization in small batches, limiting work in process, and reducing cycle time. At scale, there are going to be upstream and downstream groups that have to work together to get the product you’re building into market. Coordinating the delivery across those teams is the current problem de jour in the scaled agile discussion. I don’t believe that Scrum is the answer in these kinds of organizations.


Okay… where does that leave us? When you are designing your agile enterprise… you’ve got to ultimately take into consideration how you are going to form teams, how the work of those teams gets coordinated, and what you are going to measure to know you’re making progress. We explored (in somewhat gory detail today) the structure side of the problem.

I tried my best to make the case that the notion of the cross-functional feature team will break down at scale. There is just too much subject matter expertise, too much domain knowledge, and too diverse a technology stack for one team of 6-8 people to build much of the large scale software that is getting built today.

If this is your reality, that means you’ll have to consider implementing Scrum teams based on products and services, or more generically, capabilities that can be reused across your organization. Governance is largely the way that work gets coordinated across these teams, but the more you can decouple teams, and have them work at their own pace, the more agile you’ll actually be when you are done.

Product teams and services teams don’t make up the whole of the agile enterprise. We have many upstream and downstream groups that have to be able to work effectively with the Scrum delivery teams to get the product into market. IMO… this is something that Scrum doesn’t have much to say about. SAFe is making a pretty good stab at it.

More generically though… the idea is to model the rest of the organization into a Lean/Agile value stream, run smaller batches through the organization, limit WIP, and work to reduce cycle time and reduce time to market. At scale, business agility isn’t about how effective Scrum teams are… it’s about how effectively the entire organization can get product into market and generate a return.

Hope this gives you guys some things to think about. IMO… this is the missing piece of the puzzle for many companies.

I usually try not to directly pimp our services when I write, but helping people solve this problem is a significant part of our practice at the moment. We use all sorts of techniques from interviews and collaborative sessions to a very structured approach called Capability Modeling that allows for structured conversation and results in a heat map of your organization that can be used, not only for forming teams, but for having conversations about the impact of changes you might want to make to your technology platforms. It’s proving to be a pretty powerful lever for making organizational changes at scale.

Good luck, let us know how we can help. Looking forward to your feedback.

Check out the next post, Shu Level Agile Isn’t The Same As By-The-Book Scrum.

Check out the previous post, Structure, Governance, and Metrics on Large Scale Agile Teams.

webinar ad

Join the conversation. There are currently 12 comments.

The Top Five Agile Methodology PPTs

Written by Torrey Dye Tuesday, 4 February 2014 07:00

agile methodology ppt

Are you looking for the best Agile Methodology PPTs? Check out our the LeadingAgile list of the best Agile Methodology PPTs! We have scoured the web to pull together a list of the greatest Agile Methodology PPTs we could find. We hope you find these helpfully whether you are just starting your Agile journey or are well on your way and just looking for ways to improve.

1st Agile Methodology PPT

Our first presentation was presented by Mike Cottmeyer and Dennis Stevens at the Agile2013 conference. The presentation explains how to create safety and visibility for management when doing an enterprise wide agile transformation.

 2nd Agile Methodology PPT

Our second presentation was presented at the 2013 PM Symposium in Washington DC by Derek Huether. This presentation explains how to be successful with Agile at Scale by putting culture last and predictability first.

 3rd Agile Methodology PPT

Our third presentation is from Rick Austin. This presentation covers how to do story mapping and requirements decomposition.

4th Agile Methodology PPT

Our fourth presentation was presented by Mark Kilby at the South Florida Agile Conference. This presentation discusses the five sources of conflict and various tools to help your team navigate it for better collaboration

5th Agile Methodology PPT

Our fith presentation is from Dennis Stevens. This presentations describes an approach to integrating Risk Management into Agile in the Enterprise.


I hope you found these Agile Methodology PPTs helpful. I hope that if you are just starting your Agile journey these presentations inspire you to take the next step. If you are well down the path of your Agile journey, I hope these Agile Methodology PPTs provided you some ideas on how to improve.

What other types of presentations would you like to see?

webinar ad

Join the conversation.

Public Training Locations

Upcoming Training Classes

2-Day Agile Requirements Course
2-Day Agile Requirements Course
April 7-8 Orlando, FL
Advanced Agile Development with Dr. Alistair Cockburn 3 Day Master Class
April 14-16 Alpharetta, GA
3-Day PMI-Agile Certified Practitioner Course
April 14-16 Reston, VA
3-Day PMI-Agile Certified Practitioner Course
April 28-30 Alpharetta, GA
3-Day PMI-Agile Certified Practitioner Course
May 5-7 Denver, CO
2-Day Agile Requirements Course
May 15-16 Alpharetta, GA
2-Day Certified ScrumMaster Training Course
May 19-20 Alpharetta, GA
3-Day PMI-Agile Certified Practitioner Course
June 9-11 Alpharetta, GA
3-Day PMI-Agile Certified Practitioner Course
June 16-18 Reston, VA
2-Day Agile Requirements Course
June 23-24 Orlando, FL
2-Day Agile Requirements Course
July 10-11 Alpharetta, GA
3-Day PMI-Agile Certified Practitioner Course
July 21-23 Westminster, CO
3-Day PMI-Agile Certified Practitioner Course
August 11-13 Alpharetta, GA
3-Day PMI-Agile Certified Practitioner Course
August 18-20 Reston, VA
2-Day Agile Requirements Course
August 25-26 Orlando, FL