How Agile is Agile?

Agile ain't just any damn thing - Ron Jeffries

Here is what I want to know... when does agile stop being agile? Is agile only agile when we have 6 or 8 people sitting in one room doing pair programming? Is agile only agile when those 6 or 8 people are delivering cross functional features every week or two? Do I have to pass the Nokia test to be agile? Can agile be agile when I have to blend it with some PMI style practices? Can agile be agile when I have to do documentation to meet our corporate governance standards? Is agile agile when I blend it with RUP or Lean or Kanban? How about when I have 1000 people working across three continents, can that be agile?

Maybe the question really is... how agile is agile?

Maybe it's time to recognize that Ron is right. Agile ain't just any damn thing. Maybe we need a new term for what might be agile-like, but adapted to meet the needs of larger more complex enterprises. I am generally of the mind that agile is about quickly delivering value to our customers, getting fast feedback, being able to quickly respond to change, creating people centric organizations... one where individuals can make difference. One where we plan, but are not beholden to the plan. One where everyone is aligned toward creating the best possible outcomes. For me, it's always been more about the value I am creating than the rules I follow to create it.

So... maybe we are just learning that agile isn't as agile as we thought.

Thoughts?

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

It's about time...

Subscribe to Leading Agile

Getting Started with Agile... Two of 'Who Knows'

Okay... way too big a gap between meaningful blog posts. Since it has been so long, you might want to go back and take a look at the first post in this series called "Getting Started with Agile... One of Five". There is a bit of irony here around how this post came to pass.

I did almost all of this post two weeks ago. The post got really long. There were a few parts I was still hammering out, a few parts I still am as a matter of fact. The whole post sat on the shelf waiting for the unfinished parts. This morning I decided to break the post in smaller parts and start releasing it in chunks... pretty smart huh? ;-) Amazing how sometimes it is hard to eat your own dog food!

Here goes...

At last year's Scrum Gathering in Orlando, I heard Ken Schwaber make the comment that in his opinion, over 75% of all organizations using Scrum won't get the benefit they hope from it. That is a pretty depressing perspective, especially coming from one of the guys that invented Scrum. I don't know about you, but I am pretty convinced that this agile stuff works. I've seen it work, and I've seen it work well. If we know agile works, why do we have so little confidence in our ability to make it stick in most organizations?

Personally, I am not prepared to believe that Scrum's failure rate is because people don't implement Scrum properly. That's the whole Scrum-but argument. Scrum is such a light framework, if you give it a serious go, it's pretty hard to really do it wrong. That said, I do believe that many organizations aren't prepared to fix the organizational disfunction that Scrum is going to show them. Scrum's primary benefit is that it shows you the stuff you need to fix. If you aren't willing to fix the problems, you aren't going to get the benefit.

How many companies using Scrum are really trying to transform the entire enterprise? I'd wager that most Scrum teams live within a larger, more traditional enterprise. In these organizations, structure and culture are going to trump anything that a single Scrum team does with people, process, or tools. You could have the best team members, run a perfect Scrum, have big visible charts everywhere, and I bet you still stand a chance of falling into Schwaber's 75% statistic.

For everything we do to build a high-performing agile team, the organization is going to work to pull that team a part. The pull might be intentional, led by people that are threatened by any change to the status-qou. More than likely, the organization just doesn't get it. The value delivered by the Scrum team just get's lost within the larger underperforming organization. Even though the team was effective, it just never really translated to any kind of measurable value for the larger organization.

So therein lies the problem. What does it mean to have a successful Scrum team in an organization that isn't performing very well? What do you do when Scrum helps you identify an impediment that can't be solved by the team, but no one outside the team seems to care? Scrum ends up being a local optimization within the larger enterprise value stream. Unfortunately, it doesn't matter how hyper-productive your team becomes... getting higher team velocity isn't your biggest problem.

The trick to adopting agile is to form a team around a business problem the organization actually cares about solving... one that will increase bottom line performance. And this is where the conversation get's interesting. Many of us aren't responsible for improving the whole system. We are only empowered to do our part. We can only operate within our circle of concern. Our challenge is to figure out a way to make our local improvements, but in a way that is respectful of the whole.

There are a few things I want to suggest that will help you understand how your company looks at value delivery. For the rest of this post, I want to talk about aligning your agile pilot team to something your organization actually cares about. The important thing to realize is that not every company has the same kind of goals. If we are going hook ourselves up to big business problems, we need to understand how our companies look at value... how they look at the unit of production. For most, a unit of production is not a single user story delivered by a single team.

Next post we'll talk about a few 'units of production' that I see larger organizations really care about.

Subscribe to Leading Agile

Agile Coach Camp, North Carolina, March 19-21

Are you registered for the Agile Coaches Camp this month in Durham, NC? If not, you should. I'll admit... I was a bit skeptical about the first Agile Coach Camp in Ann Arbor. The guys at VersionOne asked me if I wanted to go. I was like... fly to Michigan... on a weekend... with no agenda... no speakers... we all just get together and figure it out? Sounded like a train wreck to me, but for some reason, I went anyway.

Needless to say, I had never been to an Open Space conference...

I learned that there is something very powerful about being a room full of passionate people that are trying to make the world of software development a better place. It was a pretty amazing experience... some of the closest relationships I have in the agile community were formed at the last Agile Coach Camp. Nothing like a couple of late nights, talking about agile stuff while smoking cigars and drinking martini's, to bond a group of strangers together!

Head over the the AgileCoachCamp Wiki for more information about the camp and links to register. I have no doubt this camp will be as powerful as the last one. Seriously... you gotta be there... I'll be there... go... register now!

Subscribe to Leading Agile