It’s About Context, People!

Written by Mike Cottmeyer Friday, 11 June 2010 03:07

In any given situation, there are a ton of things that could possibly work. One of the most successful projects I ever managed was delivered using a mix of Waterfall, Agile, and RUP. We had a existing product that our customer wanted to enhance. The customer knew exactly what they wanted and never changed their mind. The teams involved had built the original product, and they knew the code like the back of their hand.

We used a big-up-front-design, traditional estimating, and Gantt charts… even on the agile side. We did ‘black box’ the agile teams, but they had to inspect and adapt their way into the overall project plan. We delivered the project on the promised due date, within something like 1% of the original cost estimated, and with everything the customer had originally asked for. My company made the money they expected to make and our client made the money they expected to make.

We didn’t do a death march, there were no 11th hour surprises, the deployment went exactly as expected.

Scrum is an empirical process control method. When you have a high degree of variability, and predictive planning methods are likely to fail, empirical process control can help manage and constrain the chaos and complexity, and optimize your project outcomes. It’s a more expensive way of managing project outcomes, but works better when variability is high. If variability is not high, and the system is well known… it’s possible Scrum is not the best choice, even on a software project.

I think part of our problem right now is that we’ve somehow decided that Scrum is the way to go no matter what the project characteristics. We get so enamored with the benefits the team gets from adopting Scrum, sometimes we forget that Scrum might not be well suited to the business needs of the enterprise. That’s not a knock on Scrum… it’s just that Scrum might not be the best tool for the job. It is up to us as organizational and project leaders to understand our options.

Join the conversation. There are currently 4 comments.

The Gist of My Agile Dev Practices Talk

Written by Mike Cottmeyer Friday, 11 June 2010 03:40

I know this is really high level… but I want to see what kinds of questions this level of description generates. Does it make sense? I’m really trying to figure out how to explain some of these ideas with fewer words.

Talking Points
1. Scrum works under certain conditions, if it works… use it.

2. Scaling scrum works under certain condition, if it scales… do it.

3. Scrum requires significant transformation for most organizations.

4. People underestimate what it really means to transform.

5. Transformation is too disruptive for many companies, these people will fail.

6. We need a credible transition strategy for everyone else.

7. Define a static organization model.

8. Find the constrained capability, create an agile team there.

9. Do agile for a while with that team, do it again with a few others.

10. Define your first agile multi-team project. Use expand and collapse Kanban, across teams, to limit WIP.

11. Define your next few multi-team agile projects, now you have a portfolio. Use expand and collapse Kanban, to limit projects in progress (PIP?), and manage WIP across teams.

12. Define capabilities outside of IT… extend agile to them.

13. Wash, rinse, and repeat

Key Concepts:

1. Scrum will break in complex product organizations.

2. Use a Static Organizational Models as the basis for agile pilots.

3. Use Lean and Kanban to intentionally limit WIP at the project level and the team level.

In general the talk was well received. A handful of people walked out… maybe this wasn’t what they expected, maybe they just needed to use the restroom ;-) A few folks challenged the ideas I presented… Bob Galen and I had a follow-up conversation. More than a handful stayed after, talked to me in the hallway, and took business cards.

This is not everyone’s problem… but if it’s your problem, you need to go into your agile transformation with your eyes wide open… and some credible strategies for incrementally adopting agile.


Join the conversation.

You Need a Static Organizational Model

Written by Mike Cottmeyer Friday, 11 June 2010 12:17

Okay… I want to make an assertion here. In order for agile to work, you’ve got to understand the static organizational model for your company. Why? If you are organizing around things that are transient, like projects, you are doomed to fail. Agile requires teams that stay together, period.

Most organizations are organized around one static model, the resource team. This is our much beloved organizational pattern where we pull all the BA’s into one group and all the developers into another group. People are assigned to project teams, but the resource organization is the strong side of the matrix, the project organization is the weak side. Resource teams don’t deliver value by themselves.

Agile asks us to organize around the parts of the business that deliver value, and in common practice, that is usually the product. It makes sense, we make products, let’s organize around the stuff we make. This is where we get the whole, give the team what they need to deliver, and they’ll give you working software at the end of every sprint routine. Single PO + Single Team = Delivered Business Value.

That works awesome in small product driven organizations. In the complex organizations we’ve been talking about here, this approach is problematic. Why? Investment is not always level across products. Sometimes I need a full staff and sometimes I don’t. Sometimes I want to improve one set of product capabilities and just keep the other capabilities in more of a steady state.

Uneven investment in products over time is what drives our obsession with project work. We know that we don’t need the same people doing the same thing all the time, so let’s deploy ‘teams’ to go build some value for us. When they’re done, we can break them up and have them go do something else. From an agile perspective, the problem is that this approach doesn’t keep teams together over time, and that makes it really hard to really do agile.

I’ll admit, you could create multi-disciplinary teams and run your project work through these static teams. This is on the right track, but still breaks down when the skills required project to project ebb and flow. I’m all for building teams around specializing generalists and bringing work to teams, but in complex organizations it is a stretch that every team is going to have every skill they need to do every project.

So… back to our static organizational model. If we are going to keep teams together, we need to organize the teams in our complex product organization around the things that aren’t likely to change over time. We need a static model for the organization that is resilient. One that reflects the core delivery capabilities of the enterprise, capabilities that can be staffed and deployed to solve specific business problems

In our complex product example, the delivery capabilities might be the various products delivered by the organization. The services they provide to external customers, or to other internal products, become the capability the organizations is expecting them to deliver. A capability could also be something like marketing, or sales, or support, or even some external service provider that you depend on for a fully functional product.

Before you begin your agile transformation, you need to think about your organizational structure. Ask yourself if you are building teams around stuff that will predestine them to be broken apart when the work is done. Are you piloting something that has no chance of long term successes when it get’s out into the wild? It is important to understand what the non-transient, static model for your enterprise looks like, first.

Then, and only then, should you decide where to pilot your first agile team.

Join the conversation. There are currently 6 comments.

Scaling Agile Past the Team – Agile Dev Practices Edition

Written by Mike Cottmeyer Wednesday, 9 June 2010 09:43

If you guys have been following my updates here and on Twitter, you know that I’m out at Agile Development Practices in Vegas this week. I’m speaking in about an hour… and just putting the final touches on my presentation. The content is not fundamentally new, I think though I’m learning how to talk about this stuff better. So… here is the slide deck I plan to go live with. Have fun, and let me know if you have a group that would be interested in this topic. Depending on your schedule and mine, I might be able to come out and do the talk for you live and in person!

Scaling Agile Past the Team – SQE Agile Dev Practices West


Join the conversation.

Interesting Post… 6/1/2010 through 6/6/2010

Written by Mike Cottmeyer Monday, 7 June 2010 01:40

Twitter search won’t seem to give me any of my tweets from before 6/1 today, so this installment of Interesting Post… is going to a be a little short this week. Hope you enjoy…

Interesting Posts from 6/1/2010 through 6/6/2010

Why Is There Still Talk About Agile v. PMBOK?

What DONE Looks Like?

Agile is in the PMBOK so it must be true

Is this noise inside my head bothering you?

Kanban and Conversations

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