Our Halloween Jack-o-Lantern

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!

Subscribe to Leading Agile

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

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

Subscribe to Leading Agile

Velocity in the Enterprise, Part 6

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.

Subscribe to Leading Agile

Mike Cottmeyer on Tour

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.

Subscribe to Leading Agile

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

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

Subscribe to Leading Agile

Velocity in the Enterprise, Part 5

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

Subscribe to Leading Agile

It's All Fun and Games...

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.

Subscribe to Leading Agile

Velocity in the Enterprise, Part 4

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.

Subscribe to Leading Agile

Reflections on the PMI Global Congress

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!

Subscribe to Leading Agile

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

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.

Subscribe to Leading Agile

Velocity in the Enterprise, Part 3

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.

Subscribe to Leading Agile

Pillar Webinar Today: When Change is Hard by Bob Myers

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.

Subscribe to Leading Agile

Velocity in the Enterprise, Part 2

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.

Subscribe to Leading Agile

Velocity in the Enterprise, Part 1

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.

Subscribe to Leading Agile