Leading Agile

Reuse Creates Bottlenecks

2009-11-09T08:10:00.003-05:00

Here is something to think about. Is re-use always good? Is it always a good idea to have shared services and rely on common components? I jotted down a great quote at Oredev this week but can't seem to recall who said it. "Reuse Creates Bottlenecks". Isn't that what we have really been talking about over the past few weeks? When you have a team... or a department... or a division... or a business unit that has everything it needs to deliver... it sure does make planning easier. Why? Because you reduce dependencies on the rest of the organization. There is less coordination... there are less constraints.

But is that how we tend to think most of the time? We seem to think that we'll pull out all the stuff that is common and share it across the enterprise. That might make sense... it might be the best use of our resources... but it might create unnecessary dependencies that we're going to have to manage for the life of the product. So here is a word of caution... if you are going to move toward shared services, have you considered the impact that decision will have on your ability to be responsive to your external customers? Have you considered what you are optimizing for?

Organizations that have people in functional silos are, in a sense, reusing people. They believe that having folks with similar abilities working for the same manager is the best way to optimize their limited resources, to get the most out of their investment dollar. Agile teams know that optimizing for throughput is better and tend to rely more on specializing generalists to level variations in the need for talent over time. Reusing system components has a similar effect on the organization as resource silos... and leads to the same kind of behavior. More documentation... more up front planning... and more managing dependencies.

So... if reuse is essential... or strategic... go for it. Just understand your trade-offs. If you are doing it because you think it is going to lower costs... you might want to think about it. If you trade shared systems for increased coordination and management overhead... you might not save as much as you think. Anyway... something to think about.

Interesting Post... 11/1/2009 through 11/8/009

2009-11-08T04:40:00.004-05:00

Got a interesting story for you guys...

Arrived in the Copenhagen airport today for my 11:10 AM flight back to Atlanta. I looked up on the board... no flight to Atlanta. I went over to the Information Desk and the lady tells me that there was a flight on the 7th... and another scheduled for the 9th... but no flight on the 8th. Hmmmmmmmm. Since Delta does not have local gate agents, we head over to the servicing organization that handles Delta ticketing. Apparently, Delta has decided that they aren't going to fly direct from Copenhagen to Atlanta on Sunday anymore. Kimi and I are booked on the Monday flight.

Well... we had a VERY helpful agent in Copenhagen that called and talked to a VERY UNHELPFUL agent in Atlanta. I am starting to see a CLEAR pattern with Delta phone agents. Apparently, there was only one other flight back to Atlanta today , and unfortunately the gate for that flight had just closed. Delta was willing to move us to a SkyTeam partner, but not to another airline to get us home as planned. Come to find out, the agent in Atlanta was wrong and there WAS another flight back to Atlanta, through Paris, that was going to leave in a few hours. Our agent in Copenhagen got us on that flight. This guy was my hero today... he was seriously dedicated to providing outstanding customer service.

Here is the lesson learned. About six weeks ago, I did get an email from Delta telling me that my fight had been changed. I get these messages all the time, but up until this point they had only communicated small schedule changes or seat assignments. I didn't catch that they had canceled my flight and moved me to an airplane on an entirely different day. I am not sure if I should be mad at Delta or mad at myself for not paying more attention. I guess I'll take responsibility and be mad at myself. Kimi and I are going to be a few hours late back to Atlanta tonight, but I am very happy to be going home.

With all that drama as a backdrop... this weeks installment of 'Interesting Post' is coming to you from the Startbuck's in CPH Terminal 3. Hope you guys enjoy!

Dean Leffingwell's User Story Primer http://bit.ly/2SoOT6

Oredev 2009 - LIVE (now recorded) Closing Panel Video http://bit.ly/pJ3mB

Fun with Release Planning http://bit.ly/3TOHhC

Technical Debt http://bit.ly/2pzmoB

The "decline" of Agile is our own fault... http://bit.ly/2lQU27

The mistake most developers and development organizations make http://bit.ly/3uvTQH

Why Agile? Why Now? http://bit.ly/opmxS

Five Myths of Agile Development: Myth #4 - Agile Development Does Not Scale http://bit.ly/2m1LJR

Balancing Anticipation and Adaptation http://bit.ly/3c9hSN

Agile Release Planning Musings http://bit.ly/175Ydu

Agile isn't Just About Change http://bit.ly/482noY

Making Agile Requirements Work-No 4 http://bit.ly/35lGAz

Seth Godin Misunderstands Dunbar's Number http://bit.ly/32knNw

Agile Projects and Project Management http://bit.ly/4vEuCK

Organizational Myopia?

2009-11-05T03:09:00.007-05:00

Okay... I want to write a quick little post here to point out something that is becoming increasingly obvious to me. I've talked quite a bit over the past year about the ongoing feature team/component team debate. We talk about how agile teams are supposed to deliver an end-to-end cross-functional slice of the application architecture. When applications get big, I've talked about how sometimes we have to organize around large scale system components or services. So here is the deal... I think that in practice... most people actually get this. It seems that the more I talk to people doing agile in large organizations... the component team model might be THE primary organizational model in the enterprise.

Great right... no debate? Well... actually no. The problem is in the language we are using. If we are only building component features... software that is theoretically 'valuable' to the business... we are not building software that is sellable in and of itself. It is only the integration of multiple services or components that our external customers really care about. To some degree we are deluding ourselves about what we are really creating for the business. We get better at building our feature subset... our component features... but as an enterprise we are not getting any better at getting value out of the overall system. We are not getting better at delivering the end-to-end apps that our customers care about.

I think that to some degree we are guilty of a sort of institutional myopia. Because we can't control anything outside of our team... because we don't own, or have influence over, the PMO... over management... over the architecture group... over the integrated feature set... we control what we can control... we pretend the rest doesn't exist. We focus on our team. We desperately want to be good at what we do and we want to deliver value. We want to do valuable work. So what do we do? We change the rules. We redefine value and call it a backlog item. We redefine our customer and call him a product owner. We say that we are delivering working software that our 'customer' wants... but at the end of the day... we are just delivering a piece of the overall puzzle.

Velocity in the Enterprise, Part 7

2009-11-02T15:07:00.004-05:00

Okay... we've been going on a while now with this whole Velocity in the Enterprise series. Let's see if we can get things wrapped up with one final post. Last time around we talked about the idea of extending the Kanban metaphor to the enterprise. Just like agile user stories and teams are extended into agile projects and agile project portfolios... Kanban can be extended past the team to drive the flow of value across multiple teams working in concert to deliver multiple projects. Let's explore this a little further... starting with the team... then considering the project... and then looking at the project portfolio. We'll wrap by looking at cycle time and the role of management in enabling the organization to deliver.

The Kanban Team

We've already talked a bit about the Kanban team explicitly defining the states associated with getting a user story from backlog to done. These states are represented on a board... work in process limits are set for each state... and the stories move from state to state until they are accepted by the customer. When work gets backed up at any one process step... either due to an impediment or a constrained resource... the team has to deal with the underlying issue in order to get back to work delivering value. The work in process limits ensure that intermediate work-products get finished before new work comes into the system.

The Kanban Project

Now imagine a project that involves several agile teams all working toward a common set of requirements. Remember... our scenario here is that these teams are in some way dependent on each other to deliver an end to end feature. When teams must work together, it is important that one team not get too far ahead of the others before value gets delivered from the entire system. Imagine that the overall project has a Kanban board... one where the steps required to deliver the value feature include not only the normal design, develop, and test activities... but also include columns for the work delivered by each of the individual project teams.

The teams themselves limit the number of user stories they can have in play before and end-to-end feature is delivered on behalf of the overall project. Likewise, the project limits the number of value stories that can be in play at any one time. Let's be explicit... this can create a scenario where some teams may have to stop work while other teams on the project catch up. This forces the system to deal with the team that is going too slow before they can move forward. We need to focus our resources on speeding up the constraint rather than building inventory of partially competed value features.

The Kanban Portfolio

So... we have suggested that teams limit the number of user stories that can be in play at any one time. We have also suggested that projects limit the number of value features that can be in play at any one time. In a Kanban portfolio... we introduce the idea that the organization limits the number of projects that can be at play at any one time. The Kanban board for projects might have columns like initiation, iteration 0, release planning, execution, and deploy... each with their own work in process limits. These limits inherently result in fewer projects active across the organization... forcing the PMO to get projects finished before new projects can be started. Projects can't be started unless there are sufficient resources available to actually finish.

Cycle Time instead of Velocity

If we look at each level of the organization having only a limited number of work items (user stories, value stories, or projects) that can be in play at any one time... understanding that we are going to intentionally slow down some teams to speed the performance of others... velocity isn't going to be our ultimate measure of throughput. What we are going to start measuring... the metric we are really going to care about... is the amount of time it takes to get any single work item through the system. The team will have a cycle time... the project will have a cycle time... and the portfolio will have a cycle time. The question isn't how we can increase velocity... the question is how we can decrease the amount of time it takes us to deliver value back to the business.

Managing to the Constraint

Now we have a system that is laser focused on the delivery of value... not just at the team level... but across the entire project portfolio. No one team can get too far building user stories before they have to aggregate into a value story. No single project can go on too long with insufficient resources before it gets stopped in its tracks. The portfolio cannot keep approving projects that the organization does not have the capability to deliver. As managers, our role becomes understanding the flow of value across our organizations... understanding where that value is constrained... and redeploying people or teams to do the work that is most likely to actually speed up our ability to produce working software. Only by applying people and money to those areas that are slowing us down can we really get better at delivering faster.

In closing...

Okay... I think we have hit all the major points I wanted to address with this series. We've talked about where velocity works and in what kinds of organizations it is an effective measure. We've also explored where velocity doesn't work and where it can't be used as a measure of overall enterprise performance. With some of the Kanban, cycle time, work-in-process limit discussions, we've proposed an alternative to velocity that will help us measure our overall ability to deliver value.

I am concerned that we still have a problem in that this whole Lean, value stream analysis... this whole manage to the constraint idea is a pretty drastic shift in thinking about how to manage teams and projects. It really asks us to take a whole new approach to planning and delivery in our organizations. The more I think about it... I want to do one more post... an epilogue if you will... to maybe bridge some of this thinking with conventional wisdom to see if we can make a compromise that is easier to understand and implement. Either way... this is not the end of the conversation around this. I sincerely believe that Lean is the secret to scaling agile in the enterprise... but you know... we have to make this stuff simple and easy to understand.

Thanks for hanging in with me as I explored these ideas. As always... open to your feedback!

Our Halloween Jack-o-Lantern

2009-10-31T19:20:00.007-04:00

Every year we head up to Burt's Pumpkin Farm to pick out the biggest pumpkin we can carry. We usually end up with one BIG one... one for each of the boys... and a few that we can bake up and turn into pies. Just for fun... I thought I would show you guys the results of this year's pumpkin carving activities.

It's hard to tell size with these dark photo's... but this is our big family pumpkin. I work with the kids on the design and the approach... but the carving duties are mine. We went with a design we have used in the past... pumpkin in flames!

The pumpkin on the left was carved by my seven year old son, Noah. The one on the right by my twelve year old son, Daniel. Daniel has started off wanting to carve a pug face on his pumpkin, but ended up with something more abstract.

This final pumpkin was carved by my thirteen year old, Zach. Zach was less than enthusiastic about being asked to participate in our forced family fun... but I do think that once he got started he had fun with it.

Happy Halloween everyone!

Interesting Post... 10/26/2009 through 10/31/2009

2009-10-31T16:26:00.007-04:00

Agilepalooza was a great event this week. It was good to hang out with the crew from VersionOne and all the great folks in Boston. I'm back in Atlanta for a day or so and then off to Oredev in Sweden. Living a bit of the crazy life right now... but all is good.

The kids and I got up early and carved our giant Jack-o-Lantern. We spent the next part of the day at a VERY STRANGE event for Pug enthusiasts (Pugfest... my 12 year old son wanted to go) and now the Florida Gators are on the tube. We are beating Georgia 14-1o and I sure hope they keep the lead. They are looking MUCH better than they have the past few weeks so I am hopeful! Tonight is Halloween so I am sure we'll do a little trick-or-treating in a bit. Nice to have some family time with the kids before I head out for the week.

Enjoy this weeks installment of "Interesting Post..."

Agile Projects and Project Management http://bit.ly/4vEuCK

Why We Delegate: The Darkness Principle http://bit.ly/2ZuUXc

Making Agile Requirements Work-No 3 http://bit.ly/3JZe1S

Ares 1-X Flies http://bit.ly/1hk3fc

Quote from Seth Godin on the Scientific Method http://bit.ly/sStkK

Central Agile Calendar? http://bit.ly/353u9K

Agility and the Motocross Tester http://bit.ly/IkmDM

The Power of Being Personal on Your Blog http://bit.ly/23k2hV

Lean and Scrum - Chicken and the Egg http://bit.ly/3JqcW4

Making Agile Requirements Work-No. 1 http://bit.ly/3nXLJj

"Change isn’t made by asking permission. Change is made by asking forgiv.. http://bit.ly/1sMPHB

A Story, not *the* Story http://bit.ly/2K3fnH

Uses for Google Voice http://bit.ly/2ww0zt

An Strawman Argument for Agile Project Management http://bit.ly/CTF6P

Kanban Drives Culture and Organizational Maturity Changes http://bit.ly/2P2Fnd

Trolls http://bit.ly/4CThIf

Switching stories mid sprint http://bit.ly/jcVJm

How to Give Yourself to Whatever the Moment Brings, and Forget Stress http://bit.ly/40uZB1

Velocity in the Enterprise, Part 6

2009-10-28T21:29:00.004-04:00

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.

Mike Cottmeyer on Tour

2009-10-25T08:18:00.006-04:00

This is the time of year in the agile community, where if you have made the decision to work the speaking circuit, your life spins out of control for a few months.

It started this year with the Agile 2009 conference in Chicago and is going to wrap up mid-November with the Agile Development Practices conference in Orlando. Between now and Orlando, I am heading to Boston to speak at VersionOne's Agilepalooza. This will be my second Agilepalooza and these are really excellent events. After Boston I am heading to Malmo, Sweden for Oredev 2009. This is my first year speaking at an Oredev conference, and my first trip to Sweden, so I am pretty excited. My wife gets to come along for that one so it will almost be like a little vacation! After I get back from Sweden I turn right back around and go to Orlando for Agile Development Practice to reprise my Agile PMP talk.

My goal this year was to reuse as much content as possible so I wouldn't have to be building so many new decks. Last year everything I did was brand new and I thought I was going to die! Anyway... I've gotten a lot of mileage on the Agile PMP deck and even managed to create a little new content along the way. By the way... if you are ever interested in having me come out and speak... let me know... we might be able to work something out. Here are the abstracts for all of my upcoming talks as well as my updated bio.

Agile Adoption and Scaling - Agilepalooza Boston and Oredev 2009

Agile methodologies are helping teams deliver software faster and with much higher quality than ever before. Given the success of agile at the team level, many managers are exploring the possibility of implementing these methodologies across the entire product delivery organization. These managers launch their adoption efforts only to uncover many common myths, misperceptions, and obstacles that derail their efforts before they really get started.

Organizations fail to become agile because they don’t understand what makes agile teams work. Breaking past traditional organizational constraints, even the constraints imposed by some of the better known agile methodologies, will free managers to create situationally specific strategies that support the formation of teams and enable them to deliver both reliably and consistently back to the business. Agile teams become the building blocks of agile organizations.

This talk will explore a roadmap for agile adoption that begins with teams and demonstrates how teams work together to deliver more complex projects and portfolios. Mike will expand the team concept to include capabilities and show how capabilities can be organized to optimize value across the enterprise value stream. At each step of the adoption process, Mike will demonstrate how to choose the policies, practices, and metrics that create learning and drive sustainable organizational change.

Agile Adoption past the Team - Oredev 2009

Discussions of agile often assume that there is a single team, assigned to a single product, with a single dedicated customer guiding all the product decisions. In reality, many organizations are building complex products that require the efforts of more than one development team. When teams have to coordinate to deliver a highly integrated product, the product owner’s job often becomes too big for a single person.

Not all the interesting scalability problems are reserved for the enterprise. Product Owners have challenges when trying to coordinate the deliverables for only four or five dependent development teams. Quite a few organizations are expanding the role of Product Owner to include Product Owner Teams and Product Owner Teams with Architects. These teams work in partnership with the Product Owner to maintain the product backlog and drive integrated decision making.

This talk explores a 3 month coaching engagement where the customer needed to coordinate requirements and design across five highly dependent development teams. Mike will show how the teams went from zero to hyper-productivity in a matter of sprints by implementing solid engineering practices and deploying a Product Owner team to coordinate deliverables across the entire product delivery organization.

The Agile PMP: Teaching an Old Dog New Tricks - PMI IT&T SIG webinar, Agilepalooza Boston, Agile Development Practices, and the Agile Edmonton User Group

Agile methods emphasize trust, empowerment, and collaboration—moving us away from command and control project management to harness the passion, creativity, and enthusiasm of the team. In established organizations, success with agile practices hinges on how well traditional project managers adopt new ways of thinking about project structure and control. Building on the principles of the Project Management Body of Knowledge (PMBOK®), Mike explores how PMPs with experience in traditional development can adapt their styles and practices to become effective agile project leaders. Mike tackles the hidden assumptions behind the PMBOK and explores agile approaches for managing time, cost, and scope. Taking an in-depth look at PMI Processes and Knowledge areas, he also explores ways to adapt them to agile projects. Project managers, business analysts, and other stakeholders will leave with a new way of thinking about project management practices within the agile context and new tools for delivering value in the face of uncertainty.

Bio

Mike Cottmeyer is the Vice-President and General Manager of Pillar Technology Southeast. Pillar Technology is the leading provider of agile transformation services helping companies develop the technical practices and leadership competencies required for sustainable organizational change.

Prior to joining Pillar, Mike was an agile consultant, coach, and evangelist for VersionOne. Before VersionOne, Mike was a senior project manager for CheckFree Corporation where he led a portfolio of projects for their online banking and bill payment business unit. Mike has 20 years of experience leading IT initiatives using a combination of traditional, agile, and lean project management best practices.

Mike is a certified PMP Project Manager and a certified ScrumMaster. He co-created the DSDM Agile Project Leader certification and holds Foundation, Practitioner, and Examiner level certificates. Mike is an honorary member of the DSDM Consortium, a founder of the Lean Software and Systems Consortium, and helping lead the AgilePMI Community of Practice.

Mike speaks internationally on the topic of Agile Project Management and writes for several blogs including http://www.leadingagile.com and http://blog.versionone.com and occasionally for http://www.agilesoftwaredevelopment.com . Mike co-authored the paper "Rethinking the Agile Enterprise" for the Cutter Consortium and is co-authoring a book on Agile transformations for Addison-Wesley.

Interesting Post... 10/17/2009 through 10/25/2009

2009-10-25T08:07:00.005-04:00

Okay... so the hard reality is that these aren't going to happen every week. Actually... I suspect that this might be my last 'Interesting Post...' summary for the next couple of weeks. I'm getting ready to head off for two weeks straight travel so I might be lucky to get even a regular blog post or two out while I am gone. As you guys know... traveling can be hit or miss with me. Sometimes I get out there and am inspired... sometimes traveling wears me out. No idea how this trip will play out ;-) Anyway... more on my travel schedule and upcoming speaking engagements in the next post... for now it is time for another installment of 'Interesting Post...'

Kanban Drives Culture and Organizational Maturity Changes http://bit.ly/2P2Fnd

Trolls http://bit.ly/4CThIf

Switching stories mid sprint http://bit.ly/jcVJm

How to Give Yourself to Whatever the Moment Brings, and Forget Stress http://bit.ly/40uZB1

Scale in London http://bit.ly/4aFeZn

Self-Organization vs. Evolution http://bit.ly/2tbkqC

The Agile Playground #2 http://bit.ly/Y3cnV

Standard work in Agile development http://bit.ly/WXhgz

Why You Should Know What You’re About http://bit.ly/1MIIyw

The effect of adding new people to project teams http://bit.ly/1avU1K

Scrum, Bikram Yoga and The Attention Economy http://bit.ly/2L6YqL

Challenges with Daily Stand-ups... http://bit.ly/1pXAp1

Why Project Managers Fail http://bit.ly/123wAk

Is Kanban A Relabeling of Scrum? http://bit.ly/17y2hO

The Real Project Shrink. http://bit.ly/POgxy

Empathy http://bit.ly/GTcvb

Agile Business Service Management http://bit.ly/11ZIHI

Why Should You Care About Social Media? http://bit.ly/qBsaK

Humans Don’t Scale http://bit.ly/W2shj

PMBOK v4 and Agile mappings http://bit.ly/29lLPi

Solution Verification and Validation http://bit.ly/MgDlV

Agile is treating another disease http://bit.ly/1p8URW

Velocity in the Enterprise, Part 5

2009-10-23T20:19:00.006-04:00

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 ;-)

It's All Fun and Games...

2009-10-20T07:07:00.004-04:00

Last week I did career day at my kids school. I can't even manage to explain to my wife most days what I do for a living. What the heck was I thinking trying to explain my job to a room full of 8th graders? Do I talk about consulting and training? What about writing the book.. my blog... or all the social networking? What about all the meetings and travel and speaking at conferences? All of this is in some way related to how I make a living but really hard to explain to a room full of kids not old enough to get a part time job at McDonalds.

As I was thinking about it... the one thing that pretty much unifies everything I do is Software Project Management. That seemed like a pretty good angle so I went with it. Now that I had my hook... I found myself faced with a pretty substantial ethical dilemma. Do I really feel good about encouraging a room full of fresh-faced young people to go into the bone-crushing abyss that is Software Project Management? Do I really want to pave the way for my kid (who happened to be in one of my sessions) to consider Software Project Management as a viable career path?

Being a project manager... any kind of project manager... can be pretty life-sucking. You've got all this responsibility... no one usually works for you... you have to deliver a 'fixed scope' project where the scope is constantly changing. You only have so much money to spend and a team of people that are being pulled in a thousand different directions. You have to sometimes build fragile relationships with people you don't really like... play a pretty brutal political game... and try not to piss anyone off so you still have a career the next time the business decides to do a major re-org.

It can suck being a Software Project Manager.

So I put together a few slides explaining all the cool stuff that I've done in my career. I talked about my book... my blog... and my Twitter and Facebook accounts. I talked a bit about traveling around helping other people learn how to do Project Management better. Since no one really knew what Project Management even was... I anchored it to things like science fair experiments and building tree forts. I talked about managing time, cost, scope, and risk. I talked about the thrill of delivery and the pressure that comes with trying to make everything work. I was candid too about the parts that aren't so fun like being responsible for outcomes when people don't actually work for you.

I mean... I am pretty realistic about what I might have been able to accomplish, but I think I was able to explain my job in a way that wasn't totally boring. The biggest thing though I wanted to get across... the one thing that tied all the social networking and blogging and speaking back to Software Project Management... was that these kids are responsible for creating their own opportunities in life. They might not create their opportunities the same way I created my opportunities... but they are responsible for making things happen. They can be in charge and choose their own path. And for the record... I love being a Software Project Manager... it's just that some days... I can't quite figure out why ;-)

When my son got home later that afternoon, I asked him if he got any feedback from his friends and if they like the presentation. He told me that compared to the next person I was awesome. Then I made the mistake of asking what the next person did for a living... she sold Mary Kay cosmetics. Oh well!

Career Day at Buford Middle School

View more presentations from Mike Cottmeyer.

Velocity in the Enterprise, Part 4

2009-10-19T07:21:00.003-04:00

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.

Reflections on the PMI Global Congress

2009-10-13T18:50:00.006-04:00

It was a pretty quick trip for me down to the PMI Global Congress this week. I didn't even try to get in early for all the LIM stuff and didn't stay for the training sessions that are happening the rest of the week. Pretty much flew in... gave my Agile PMP talk... and got on my way. I've gotten to the point where most conference sessions don't really interest me. The value for me happens in between sessions and over drinks afterwards. That said... the time in between session and over drinks is worth the price of admission.

One of the coolest parts of the conference was getting to meet and spend some time with Bas de Baar. I have been following his Project Shrink blog for a few years now and it was cool to share ideas on project management, social media, and other career related stuff. It was the first time that I got to spend any significant time with Dave Prior (Valtech) or Rodney Bodamer (AgileX). Also spent some time with George Schlitz and Brian Bozzuto... both from Big Visible... both great guys. It's the connections that make these events so special. I was sad that Michele Sliger won't sit next to me anymore ;-)

It will be really intriguing over the next few years to see how the PMI Agile community of practice evolves within a traditional top down organization. It will be fun to see if agile methods are embraced or rejected by the masses. As complexity and uncertainty in software project management goes dramatically up... I can't imagine that standard project management approaches to building software are going to hold. At some point the facade is going to implode and we are going to have to get real about what it takes to manage software portfolios. Hopefully we can lead enough change in that time to really make a difference.

As you'd expect from a conference by Project Managers for Project Managers... everything was well planned, well run, and top notch. The Gaylord Palms hotel is always a great choice for a conference (was there for the Scrum Gathering earlier this year) and the reception at Universal Studios was a nice touch. Having the conference in Orlando gave everything a much different vibe from the conference in Denver last year. Denver seemed much more corporate... Orlando felt a little more laid back. Oh... and my talk went pretty well too.

All in all a pleasurable trip... but happy to be going home!

Interesting Post... 10/1/2009 through 10/10/2009

2009-10-10T08:58:00.010-04:00

It hasn't just been my blogging that has suffered over the past few weeks... I have also gotten behind on my blog reading and I haven't been nearly as active on Twitter. That said... there were alot of great posts over the past few weeks... some of which I did share... that never made it here on the 'Interesting Post...' summary. I went out to Twitter to scrape my Tweets for the past few weeks and it would only let me go 9 days back.

That said... I am cutting my losses and going with what I have. So here it is... my 'Interesting Post...' summary for the past 9 days...

Is Offshore Testing Worse Than No Professional Testing? http://bit.ly/DNF8V

State of Agile http://bit.ly/2WUtIk

Elbow Room for Handling Technical Debt http://bit.ly/Eg6UC

The Open Space Policy for Managers http://bit.ly/2J8iRg

Ken and the Scrum Alliance — a very personal perspective http://bit.ly/B66R1

New to agile? Keep it very simple http://bit.ly/2PZBXZ

Lean vs. Agile = “Peoples Front of Judea vs. The Judean Peoples Front” http://bit.ly/VqP2Q

Agile and Remote People: Part 1, Telecommuting http://bit.ly/2ej0Gd

The Problem With Planning http://bit.ly/bx668

Big Agile Adoption Approach http://bit.ly/2J92N4

Lean and Kanban Collection http://bit.ly/4D3w64

The Danger of Lean: Ignoring Social Complexity http://bit.ly/q74Zz

An Overview of Lean Software Development http://bit.ly/LsWn0

VersionOne Activity Stream http://bit.ly/mwBB3

Kanban Team beats Scrum Team! http://bit.ly/KbyGS

There’s No Task Easier Than No Task http://bit.ly/1EYI42

Presence in the past does not help today http://bit.ly/1apbFC

The Do-It-Yourself Team Values Kit http://bit.ly/22fXgi

Sure you’re agile, what about your QA department? http://bit.ly/rcz9E

Technical Debt on Your Balance Sheet http://bit.ly/6jK1d

Oh... and by the way... you'll also notice that this post is coming out a day early. I usually do this post on Sunday mornings. Sunday is a slow blog day and I am usually up ahead of my kids and getting a few things done. I am heading to the PMI Global Congress around lunch-time on Sunday, so I didn't want to worry about getting this one out. So here you are... a Saturday edition.

One more thing.... the family and I are making our annual pilgrimage to Burt's Pumpkin Farm to get our traditional giant pumpkin. We'll turn our giant pumpkin into one big Jack-o-Lantern as we get closer to Halloween. If you happen to be near Atlanta in the fall... Burt's Pumpkin farm is a must go Fall destination.

Velocity in the Enterprise, Part 3

2009-10-10T08:37:00.008-04:00

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.

Pillar Webinar Today: When Change is Hard by Bob Myers

2009-10-07T08:57:00.004-04:00

Later this afternoon Bob Myers, the President and COO of Pillar Technology, is delivering a webinar called "When Change is Hard - How to Create a Culture of Change in Your Organization".

Bob is going to go over several case studies based on Pillar's experience helping companies lead large-scale agile transformations. I'd expect this to be a pretty candid discussion about things that went well... and things that didn't. Bob is a super-practical guy and has a ton of great experience working with big companies in the thick of significant organizational change. If you are looking for some really practical guidance... or the opportunity to ask the really hard questions... this is the place to be.

The talk is today at 1:00 ET. If you can make it... head over to the Pillar website to register. I think it will be time well spent.

Velocity in the Enterprise, Part 2

2009-10-06T16:17:00.004-04:00

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.

Velocity in the Enterprise, Part 1

2009-10-05T21:21:00.005-04:00

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.

Leading Agile in the Top 200

2009-09-29T07:36:00.005-04:00

Jurgen Appelo has released the latest installment of his Top 200 Blogs for Software Developers. Leading Agile has managed to creep it's way up to the number 30 spot. Just to put this into perspective... just two quarters ago Leading Agile was sitting outside the top 100 at the 105 spot. Last time around Jurgen had Leading Agile at 56. This blog has jumped 75 places in just about 6 months. That is pretty cool. I appreciate all you guys for making this blog what it is... and I appreciate Jurgen for continuing to keep score ;-)

Stability first... then speed!

2009-09-29T07:22:00.006-04:00

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?

Change is the only constant...

2009-09-26T10:47:00.007-04:00

Last week I mentioned that I was pretty much consumed with some big things going on in my life. Well... I am finally ready to share some really big news. This week I am leaving VersionOne and joining Pillar Technology. It is a bittersweet announcement... so I want to accompany this announcement with a little backstory.

Two years ago when I joined VersionOne... I set off on a journey. At the time, joining VersionOne felt like a huge risk. I was going from a company that had twenty thousand or so employees to a company that had less than 100. I was going from a company with a diverse product set to a company that really only had one. I was going to stop managing projects for a living and become a trainer and consultant.

My wife and I talked about the fact I would now be on the road more... sometimes with only a few days notice. I'd be travelling overseas and going to conferences. We talked about what this change would mean for our kids... my career... our finances... and my employability should I ever decide to do something different. It was just a huge unknown... but it was exciting. It felt like the right thing to do and the risk seemed manageable.

Looking back with a little hindsight... it was the best of all possible opportunities. I've had the chance to work with some great people... the VersionOne folks are truly the best in the industry. I've had the chance to work with some excellent companies... companies who recognize that the status quo is no longer going to be enough. I've had to the opportunity to work with, and become and expert on, the best agile project management platform on the planet. I've had the opportunity to become a public speaker... find my voice as a blogger... and now as an actual author.

I really love working for VersionOne but for the past few months I've been thinking that it might be time to get back into the world of delivering projects. Even though having exposure to a diverse set of companies is huge and my pre-VersionOne experience was still extremely relevant... I wanted to get back out and build longer term relationships with people that are in the thick of building agile organizations. I wanted to get in and help lead change in a more meaningful way. I wanted to be a part of building the enterprises that I write about here on Leading Agile.

I didn't really know what life after VersionOne might look like. I always felt that if I worked hard and made a positive contribution to the community... things would play out. I recently started toying with the idea of becoming an independent coach or possibly starting a boutique consultancy. Having a stay at home wife... a mortgage... and three kids that like to eat... those options always felt pretty risky. I wasn't sure as a start-up that I'd be able to have the kind of impact that I really want to have. I need to be able to scale... and scale fast.

Enter Pillar Technology.

I first encountered Pillar Technology last year at the Agile Coaches Camp in Ann Arbor. I was impressed with them from day one. Everyone I have ever met from Pillar has been top notch... not just from a technology perspective... but as human beings. Pillar does great work and has fun doing it. I liked these guys before I ever started thinking about working for them... so when we started talking it felt like it could be a good fit.

What makes this move more interesting for me is that I am not going to Pillar as just an agile coach... I am going to build an agile consulting practice in the Southeast. Pillar is already the premier agile consultancy in the Midwest... I am going to help them go nationwide. I'll have the resources... and the talent... at my disposal to really help organizations lead the kind of transformations I am so passionate about. Now when I talk about learning to do small team agile... I can bring in the developers and coaches to help make it happen. I will be able bring in the kinds of leaders that can help organizations learn what it means to do agile project and portfolio management. We can help lead real... enterprise level transformations.

While the move to Pillar comes with some mixed feelings... joy over the new opportunity... sadness over leaving my friends at VersionOne... I am convinced this is the right 'next move' for me and my family. Pillar Technology is a VersionOne business partner and I am still just a few miles away from the VersionOne offices. I am looking forward to co-branding a few white papers and doing some joint webinars over the next year. I'll still be representing VersionOne at the PMI Global Congress and helping out with the upcoming Agilepalooza in Boston next month. There is tremendous synergy between our shared missions.

I will say though... if you ever thought... hey! it would be cool to have that Mike Cottmeyer guy come and do some work for my company... now might be a good time to reach out. For now... you can contact me on my personal email mike [@] cottmeyer [dot] com. Let me know what I can do to help. Even though I am going to focus on the Southeast US... there is no limit on where we can work together.

One last story and then I'll let you guys get back... when my wife got pregnant with our first son, we were living in Michigan. We knew that wasn't where we wanted to live so we started making plans to move. During that time, we were saving a down payment on our first house, getting ready to move to Georgia, getting ready to have a kid, Kimi was going to be a stay at home Mom, and I was going to start a brand new job within my company.

Over the past 10 or 15 years our family has probably experienced at least two more... maybe three... periods of extremely disruptive change. Some periods centered around kids... some around jobs.. and others around changing location. Most seemed to have something to do with all three. So while we don't have any more kids on the way... I am still planning to birth my book... build a business.. and maybe a few other things I've been noodling on. When I decide to shake things up... I really like shake things up ;-)

Interesting Post... 9/13/2009 through 9/20/2009

2009-09-20T08:51:00.004-04:00

Sunday morning... still raining here in the ATL. Let's get down to business. Here are all the most interesting posts from this past week. Hope you enjoy.

Interesting posts from 9/13/2009 through 9/20/2009

Project Management 2.0 - How Can It Be Described http://bit.ly/HUj8F

Does the productivity decline if you don’t time box? http://bit.ly/lvlxj

How do you measure software quality? http://bit.ly/9LRfD

KanBan Redux http://bit.ly/2ZD6n4

Do What’s Effective For You http://bit.ly/2kUxh

I have heard of kanban! http://bit.ly/9XvTF

Have you heard of KanBan? http://bit.ly/TRH19

Theory of Constraints and Big Agile http://bit.ly/3H4K9M

The Only Lean Path is an Unclear Path? http://bit.ly/COw1f

The Poppendiecks on Lean http://bit.ly/Seb4E

How to Be Childlike http://bit.ly/1ayQJX

Creative Solution Finding and Big Agile http://bit.ly/2eXSYr

Top-down and Bottom-up Project Management: Leveraging the Advantages of t.. http://bit.ly/VDYbe

The Problem With Planning http://bit.ly/4GfuJc

The empowered consumer yesterday, today, and tomorrow http://bit.ly/KtV3g

Scrum and Kanban - Like Chocolate and Peanutbutter http://bit.ly/EkR8A

What Does It Mean To Have A Plan? http://bit.ly/7J5NB

Agile Mentor Newsletter http://bit.ly/9MXRZ

Thoughts on Lean Thinking http://bit.ly/oHbDL

More on Servant Leadership http://bit.ly/FnASl

Performance without Appraisal: Build Feedback into the System http://bit.ly/1ZvJYO

Time, Budget, Scope http://bit.ly/2pmJ

against kanban part 2 http://bit.ly/TowCZ

Using User Stories http://bit.ly/3ExoxY

Ssssh….Agile Is All About Micromanaging http://bit.ly/Rig4G

Mockups and Simulated Data helps with Agile Development http://bit.ly/Fx5It

One Piece Flow -- Transitioning from Scrum to Kanban Part II http://bit.ly/AsgGM

Transitioning From Scrum to Kanban, Part 1 of 3 http://bit.ly/17lqGd

Writing on a Rainy Saturday...

2009-09-19T09:49:00.007-04:00

It was kind of a weird week. Had lots of stuff going on that really took all my attention. I hate to go all five days of the work week without being able to manage even a single blog post. That said... I have been able to get down a few ideas that I plan to write on next week. The only wildcard will be a trip I've got booked to Portland.

Sometimes travel results in more writing... sometimes less... we'll just have to see.

For now... I wanted to point you guys at some work Dennis has been doing on our book over the past week. The week before last I did a few posts documenting some of the major themes of our book. This past week, Dennis did some of the same.

I'm just about to the point where I feel good about putting together the first and second level outline of the book. Hopefully that will result in some momentum and maybe a chapter or two over the next few weeks. We'll see how things play out.

Coming to Consensus

2009-09-13T11:06:00.006-04:00

It's one thing to do stuff... it is quite another to write about what you do. It is tough to be clear and articulate; always making sure to leave your reader in a better place than when you got them. I've learned that the hard way over the past few years while doing papers for VersionOne and writing this blog. That said, collaborating with Dennis on the framework for our book has taken this challenge to a whole new level.

Over the past few days I stopped writing about the book because we hit a bit of a wall. We knew some of the words we were using were overloaded. What we didn't realize was how much that overloading allowed us to have a conversation without having any idea what each other were talking about. Okay... that might be a little strong... but getting through it was pretty frustrating. Having two strong willed, capable dudes... both with a strong vision and sense of direction... trying to merge complex ideas into something simple and digestible has proven pretty challenging.

That said, I think we made some headway this week around our use of the word Capability.

Last week I talked about three types of capabilities: Value, Core, and Supporting. I had described Value Capabilities as the stuff we provide back to the business... stuff we might sell to an actual customer. Our problem wasn't that Value Capabilities don't exist... it's just that in our model all capabilities have a value attribute. I inadvertently overloaded the word Value as well as the word Capability. From here out we are going stop using the expression Value Capabilities and replace it with the idea of Product Capabilities. Same concept, different language.

I've never been a big fan of how we were using the expression Core Capabilities. Again... it's not that these kinds of capabilities didn't exist... its just that describing them as core didn't prove descriptive enough and led to some confusion. We'll keep the category basically the same... it will include all the stuff we directly do to deliver the Product Capabilities... stuff like writing software and testing... but we are going to call them Delivery Capabilities. It seems a little more descriptive for the purposes of our conversation.

Finally, we talked about the idea of Supporting Capabilities. I had described these as the things you need to be good at to support your ability to deliver Product Capabilities. I had included environmental things like building CI environments, invoicing and collecting payments. I had also included stuff like managing the project and communicating status. Dennis has convinced me that we need to separate these into two categories. To that end, we are now going to think about these in terms of Supporting Capabilities (CI environments, invoicing and collecting payments) and Controlling Capabilities (managing the project and communicating status).

Again the specific capabilities in each section might ebb and flow as we get deeper into the conversation but I think we have the major categories right. The story around capabilities is really important to our core message. As you adopt and scale agile... the core things you DO to deliver product get expressed differently at each level of the five phase adoption model. For us and for the book... this was an important idea to get worked out early in the writing process.

Interesting Post... 9/6/2009 through 9/12/2009

2009-09-13T10:14:00.005-04:00

Time for another (almost) weekly installment of Interesting Post. Every week I feel like the number of agile related articles was pretty light... but then I go to build this post... and realize there was a ton of great content out there. I guess I just want more ;-)

One thing to keep in mind though. I think these are ALL great articles... very insightful... very interesting... but I don't necessarily agree with every point they make. I chose the tag "Interesting Post..." very carefully. I share these posts because I think they contribute to the conversation in a meaningful way... sometimes I agree... sometimes I don't. So with that...

Interesting posts from 9/6/2009 to 9/12/2009

Friday Round Up http://bit.ly/1sKBAb

Plan the Work - Work the Plan http://bit.ly/OR1aU

Agile is never 'no process' http://bit.ly/3fEVO6

ScrumBut – Part 5 – Retrospective after every sprint http://bit.ly/MhIJW

Leading by saying No – The New CIO Series http://bit.ly/30nEuL

An Irrational Approach to Change Management http://bit.ly/1vBKbn

Proceedings of Lean & Kanban 2009 http://bit.ly/35bx0d

Business Agility – Dynamism or Stasis http://bit.ly/kvNhn

ScrumBut – Part 3 – Daily Scrum http://bit.ly/4u5Ql0

Managing Leaky Organizations http://bit.ly/fWEr5

Download "Do It Yourself Agile" For Free! http://bit.ly/fzBR3

Eliminate Architecture http://bit.ly/baNJx

Time, Budget, Scope - Pick Two - NOT TRUE http://bit.ly/3qYL0g

For $65/pp, Send Your Whole Team to Agile Training in Boston Oct 5th http://bit.ly/4DVVHx

Many Contracts Have Wrong Focus http://bit.ly/xssNm

The faster we go, the tighter we cling http://bit.ly/96DHE

Achievable avalanche opportunities http://bit.ly/lDIGT

Applying the Decoupling Principle to Scrum http://bit.ly/3nuaLB

Quote of the Day http://bit.ly/Uu9Yx

Project Failure Sins and How to Stop These Sins http://bit.ly/2BaI4d

ScrumBut – Part 2 – Team members sit together http://bit.ly/3OkVAB

Why I Hate Document Templates http://bit.ly/CMwU3

ScrumBut – Part 1 – Timeboxed Iterations http://bit.ly/REacd

ScrumBut – Part 0 – Introduction http://bit.ly/c4z9R

Toward a Next Generation Capability Maturity Model http://bit.ly/UHNZI

On Paper I Was Once a Millionaire http://bit.ly/imPmb

Run this one through Babelfish... http://bit.ly/ERKHK

Shu Ha Ri for Kanban systems http://bit.ly/fI5fx

The Best Leadership Is Good Management http://bit.ly/2bL1lN

'All About Agile' Is No More! http://bit.ly/R3fVj

D = V * T : The formula in software DeVelopmenT to get features DONE http://bit.ly/12KDvF