Let's Define Our Starting Place

I'm telling you guys... if you're not participating over on the AgilePMI Yahoo! Group, you are missing out on some great conversation. Think about it... this is THE issue going on right now impacting the agile community. We talk about agile and transformation... but the traditional establishment holds the keys in most of our organizations. Unless we can show them how to transition safely, we are relegated to bottom-up, grass roots agile initiatives... most of which have a very low probability of making any kind of meaningful difference in our companies.

That said, one of the problems I think we have... not just on the Yahoo! group, but as a community in general, is that we often talk past each other on pretty key issues. I was going back and forth with Dan Mezick and Dennis Stevens on the idea of team authorization. All of a sudden it dawned on me that Dan and I agreed in principle on where we wanted to take the organization, but Dan wanted to discuss the organization as it should be... I wanted to talk about the organization as it was, and how we can be successful in it.

It seems to me, that in any conversation, we have at least three possible starting points for debate:

1. The current state
2. The future state
3. The transition state

My guess is that most people in the group agree that something is wrong with the current state of software project management. That is why they spend time reading and posting and exploring how to do things differently. I'd also guess that most folks in the agile community agree on the ideal end state. We might have some differences of opinion around Scrum or XP or Lean or Kanban, but I think we all value the idea of empowering teams, respecting individuals, and helping organizations deliver the most value possible.

Some of us are so passionate about the way things should be, that point of view becomes the starting place, and they argue for change right now. Others of us have heard those messages and found that they don't resonate given the current regulatory climate in our companies. These people want to talk about what they can do today... without some sort of massive transformation. They don't have any clear way to make the kinds of changes that the 'future state' people are advocating. Others, like me, want to talk about how to get from point A to point B as safely as possible.

Understanding the point of view from which the other person is arguing from can be really valuable as we're trying to move this discussion forward. I hate seeing us run in circles with each other when there is probably more we agree on than we really think. The futurists hold the vision, the today people have the current reality, and the transition folks want to find a way to bridge the two. Maybe if we can start our conversations by clearly stating our starting point... and have more meaningful discussions around all three different viewpoints... we might have a way of moving this thing without constantly going around and around, without ever really increasing our understanding.

By the way... here is a link the Agile PMI group if you are interested in joining the conversation:

http://finance.groups.yahoo.com/group/pmiagile/

Oh, by the way... here is day #3 and day #4 of Summer Camp... have fun!

Summer Camp Day #3

Summer Camp Day #4

Subscribe to Leading Agile

Ultralight Backpacking and Other Saturday Morning Musings

I've been a pretty big fan of Seth Godin for the past few years. I don't love everything he does, but his latest book Linchpin is excellent, and he's been on a roll the past few weeks putting some great stuff up on his blog.

Last week Seth relayed a story about an ultralight backpacker that was able to get his pack down to 14 pounds... including food. I like to fancy myself a bit of backpacker, and I can tell you... getting a pack down to 14 pounds, including food, is really hard.

When people asked this guy how he was able to pack so light, he would tell them "all you need to know is that it's possible". The point being, that when you stop saying that things can't be done, you figure out how to make them work.

That comment has been haunting me for the past few days.

Think about it... we can't do agile here? All you need to know is that it's possible. Can't get stories small enough to fit into a sprint? All you need to know is that it's possible. Can't get developers and QA to work together? All you need to know is that it's possible.

What else is possible if we stop saying that stuff can't be done?

Subscribe to Leading Agile

Updated Agile PMP Deck on Slideshare

I did a final cut of my Agile PMP deck right before Agilepalooza Charlotte. I finally have one that I like so I loaded it up to Slideshare. If you were at my talk at Agile 2009 and want the actual deck I used... this is it!

The Agile PMP V3

View more presentations from Mike Cottmeyer.

Subscribe to Leading Agile

The Agile PMI Community of Practice

The Agile PMI Community of Practice officially launches next week at the Agile 2009 conference... and there are LOTS of things going on!

For the full scoop on all the week's happenings... visit the PMI Agile Wiki to get all the details about receptions... events... and speakers. If you are going to are be in Chicago for the conference... if you are interested in Agile Project Management... you NEED to show up... and more importantly... learn how to get involved. I am planning to be at all the kick-off events and many of the sessions. If you happen to see me... please come up... say hi... and let me know if you have any questions.

On a related note... way back when Jesse Fewell decided to start this project... I had been involved helping to create a space for some discussion and arranging a little kick-off cash. When it came time for the real work... my schedule was too crazy... and I had to bail. Jesse let me off the hook the first time around... but now that the organization is a reality... he has asked me to come back and help the team.

For the next year... I have agreed to serve as a deputy Product Owner for the team... with the plan being to assume primary Product Owner responsibilities in year two. My schedule hasn't settled down at all... maybe with the book gotten a little crazier... but this was an opportunity I just couldn't turn down.

At the end of the day... no matter what I do... no matter where I am in an organization... I am a Project Manager. I think like a Project Manager... I act like a Project Manager... and I really like Project Managers. So... I accepted this role because I want to help Project Managers... and organizations... have more effective project management.

My goal is to evangelize to the PMI membership... help them understand why agile works... and why they need agile tools in their toolkit. I am also interested in bridging the gap the other way. I want to help the agile community get some value out of this relationship and learn where and when some of the stuff from the PMBOK can actually be useful.

It will be an interesting year! I hope to see you all in Chicago.

Subscribe to Leading Agile

Leading Agile on Alltop

Have any of you guys ever heard of Alltop?

It's a pretty neat site that aggregates some of the best content on the net. They have custom pages organized by topic... you can create an account... and setup a custom page with all the stuff you are interested in reading about. Months and months ago I submitted Leading Agile for consideration for their site... today I got selected. Not a huge deal... but cool none the less.

If you haven't had a chance to visit the main site... or the agile site... head on over and take a look.

Subscribe to Leading Agile

10 Questions with Mike Cottmeyer

Last week I did an interview with Bob Williams from The Merchant Stand blog.

Bob and I go back a ways... he was the Product Manager for a team I did some project management for many, many years ago. He and I have stayed in touch... and it's been fun to watch as his interests have moved from product ownership and into e-Commerce and Internet Marketing.

Bob's questions centered mostly on how I transitioned from traditional project management to agile project management and what I see as the future of the agile movement. Head on over and take a look if you are interested. Here is a direct link to the post.

Subscribe to Leading Agile

Working Software or Customer Value

A few years back when I was still doing hands-on project management work... I used to teach internal classes on iterative and incremental product development. Officially... we were teaching a very light-weight instantiation of the Rational Unified Process. Unofficially... we were teaching agile values and principles within more of an Agile Unified Process framework.

The audience was always full of hard core waterfall folks... developers... testers... business analysts... project managers... one of the main things we'd try to talk about was the idea of frequent delivery of working software. I'd explain that charters and market requirements documents and detailed design specifications were not what provided value to our customers... all our customers really cared about was the working software.

Inevitably... someone from the audience would raise their hand and ask the question: Are you telling me that these detailed requirements documents... the ones I spend months and months creating... are not valuable? Are you telling me that the only one delivering value on the team were the developers?

I'd have to carefully explain that while those things were valuable... to the extent that they enabled communication... to the extent that they helped people understand... they were not the value that our customer's expected. If we had to kill the project 3 months in... would you rather have a detailed specification or an increment of potentially shippable code?

The potentially shippable code is always going to win.

The same idea holds for organizations with multi-part... multi-step value streams... organizations where it takes the activities of several teams working in coordination to deliver value back to the business. Even the smallest organizations... organizations with the simplest value streams... are going to need sales and marketing and support to deliver a viable product to market. Software doesn't usually sell all by itself.

More complex businesses... businesses with more complex value streams... are going to need not only sales and marketing and support... but also the ability to integrate the outcomes of many feature teams and component teams to get a product into the hands of their end-users. Does it do us any good to invest in one part of the value stream if the other parts are falling behind? Value is only created when all the parts are integrated into one cohesive whole.

So... when one part of the delivery organization gets too far ahead of the other parts of the delivery organization.... be it by writing all the requirements up front... or by building out one part of the component architecture too far ahead of all the others... it is easy to start confusing valuable activities with real value delivered into the product. It is especially easy when all that activity results in great team velocity and real working... albeit incomplete... software.

Subscribe to Leading Agile

Be a Get Things Done Guy

I don't want to be a Scrum guy. I don't want to be an XP guy. I don't want to be a Lean guy... or a Kanban guy... or a DSDM guy... or a RUP guy... or a PMI guy. For that matter... I don't even want to be an Agile guy.

As my experience has broadened over the past few years... as I have worked with more and more teams... it seems that most any process can be successful... even Waterfall... with a great team of engaged human beings... passionate... and working toward a common goal.

It seems that most of the time... when we start comparing one way of doing things with another... we tend to compare our best process implementation with the other side's worst. My last waterfall project came in exactly on time... within one percent of budget... with all the scope originally asked for.

And yes... the product was very successful in the marketplace.

Can I please just be a 'get things done' guy? To the extent I can use Scrum or XP or Lean or Kanban or DSDM or RUP or PMI to be a 'get things done' guy... that's what I really want do. To the extent that these labels... or even the processes themselves... get in the way of delivery... we'll figure something else out.

The bigger the tent... the more tools we have at our disposal... the better chance we have to be successful. At the end of the day... it's about delivery.

Subscribe to Leading Agile

Lean or Kanban or Agile

Here I am.. Sunday afternoon.. Mother's day. Just got back from taking the family out for a low key Mother's day celebration and now I've got a little quiet time before the week begins. The conference last week was quite a rush... had a great time... met a lot of great people. Before the week gets going I want to sort through some of my thoughts on this whole Lean/Kanban thing.

A bit of history... Mary Poppendieck was one of the first few authors I ever read when I got formally introduced into the agile community. I recall how much her book resonated with me then... and looking back I can see how much it influenced how I think about agile... and the agile movement as a whole. I tell you guys that to say I have never made much of a distinction between agile and lean. To me... it was just a different way of looking at the same fundamental truth.

A buddy of mine recently told me the story of the blind men and the elephant. The general idea of the story is that we have a bunch of blind guys in a room with an elephant (sounds like a problem waiting to happen to me). These guys are each touching the elephant on different parts of its body. The guy touching the tail says an elephant is like rope... the guy touching its leg says the elephant is like a tree... the guy touching its ear says it is like a giant leaf. You get the idea. The point is that without being able to see the whole... they each describe the elephant from their own particular point of view.

As I watch people debate over what it means to be agile... it seems we were a bunch of blind men arguing over the nature of the elephant. If your point of view is small, colocated teams... scrum brings a valid perspective. If your focus is more technical... the practices of XP tend to resonate. If you come from a larger more structured organization... you might need AUP or DSDM. If you have a really small team of experienced developers... let's talk Crystal. Context is everything.

It seems to me that much of our debate is out of context. When we get dogmatic about one methodology... about one set of practices... we are often not taking the other person's context into consideration. That is why the Agile Manifesto was so powerful... it was a set of value statements... it was a set of principles... that was broad enough to be applied in a situationally specific way. We have to take the local context into consideration.

I don't think the Lean/Kanban proponents are saying they have found a better way... I think that we are continuing to learn and to grow and to better understand what it takes to deliver great software. It seems to me that the Lean/Kanban movement is not out to replace XP or Scrum or DSDM but to help organizations that are having trouble adopting these practices... or have adopted them and need something else to increase their productivity.

Here is a quote from the Schwaber and Beedle book "Agile Software Development with Scrum"...

"Empirical process control models are elegantly simple. They employ feedback mechanisms to monitor and adapt to the unexpected, providing regularity and predictability. The actors in a Scrum team empirically devise and execute the best processes possible based on their skills, experience, and the situation in which they find themselves"

The line about the team devising the best processes possible based on their slkills, experience, and the situation in which they find themselves has always resonated with me. I think that Lean and Kanban give us another set of processes and tools that can help the team improve. I do not believe Lean and Kanban are at odds with Scrum... nor do I believe that Lean and Kanban are going to be successful without the engineering discipline encouraged by XP. We are just another set of blind men looking at a different part of the elephant.

My personal take...

Kanban is a visual process control tool that helps teams effectively manage the flow of work through the sprint. Scrum gives guidance that the team decides what they can do... and the team decides how it will get the work done. Kanban gives the team another way to inspect and adapt and to learn how to get better. I am not hung up on the fact that Kanban is iterationless... I can apply it within the iteration. If I determine that the iteration has become waste and no longer need it... I'll get rid of it.

My goal has never been to do Scrum... my goal is to build great software as fast as possible. In Scrum process improvement is implicit... the team inspects and adapts and find ways to get better. In Kanban we put specific visual controls in place that help the team better understand the flow of work through the sprint and make targeted improvements as necessary.

To me the idea of Lean is a bit broader... lean deals with the enterprise. Lean is about managing the flow of work across teams. How do I take an idea that comes from biz dev... turn it into a product idea... get the work assessed and approved... built... tested... delivered to the customer... billed... and supported. Lean can give us some guidance here for how to manage the flow of value through the organization. Kanban is a tool... Lean is a philosophy.

A team could use a Kanban board to manage the backlog item through the development phases... analysis, design, code, and test. An enterprise could use Kanban board to manage the flow of an idea from inception through development to billing and support. The principles of Lean can be applied within the team and across the teams. Understanding value streams... identiying constraints... eliminating waste are all explicit ways of helping the team get better. These are principles and tools that explicitly help the team inspect and adapt and make better decisions.

As a founding member of the Lean Software & Systems Consortium I hope we continue to build on what is out there and resist the urge to make this something wholy new. Remember... agile is all about uncovering better ways of developing software by doing it and helping others do it.

Lean/Kanban gives us another set of tools to help that come about.

Subscribe to Leading Agile Subscribe to Leading Agile

Scrum Gathering Agile Architecture Talk

One more post about the Scrum Gathering last week and then we'll get back to our discussion of the Agile Product Owner. I've got at least three or four or ten things left to say on that topic, but like I said last time... things are just nuts right now.

The first day of the gathering... the first session of the day... was hosted by Jim Coplien and Jeff Sutherland. The talk was called 'Not Your Grandfather's Architecture'. That talk was one of the first times I have heard someone make the case for intentional upfront architecture on an agile project. Prior to that talk... most of the agile architecture discussion seemed to be driven by Scott Ambler and Dean Leffingewell. It was cool to hear another side... especially being presented at a Scrum Gathering.

My primary takeaway from the talk centered around a few comments made by Jim Coplien. Jim compared architecture to DNA and design to the expression of individual genes. He was making the point that function emerges... not form. Jim stated that the tradtional Western notion that form follows function was just not true.

Jim encouraged the audience not to play stupid, to build on what you know. If there are key decision that need to be made and you know the answer... don't pretend you don't. Jeff Sutherland reinforced that point by talking about how PatientKeeper spends months doing analysis and prototypes before scrum teams start building out features. Both speakers drove home the point that the mind of the end user needs to be embedded in the software and teams need to focus on useable software... not just working software as the Manifesto tells us.

So... I personally agreed with much of what Jim and Jeff had to say and found it refreshing that this point of view was being discussed at the gathering. My experience has taught me that in any moderately complex organization, certain key decisions must be made up front regarding the software architecture... so this talk particularly resonated.

Last post I mentioned (in reference to one of my #scrumgathering tweets) how I felt about this whole agile architecture debate. One of the downsides of thinking out loud... and in public... is that sometimes you have to *actually* defend your point of view. Dave Nicollete called me on this whole architecture thing a few days ago... and now I owe him a response.

Here is Dave's comment to my last Scrum Gathering post:

"... in the many discussions and debates about agile methods and architecture, people just assume everyone knows whether they are talking about enterprise architecture or solution architecture. Often, when you scratch below the surface of an argument on this topic, you find one person was thinking of enterprise architecture and the other was thinking of solution architecture. Which of these do you think doesn't lend itself to an emergent approach, and why?" - Dave Nicolette

Here is my take on the software architecture thing in a little more detail. I tend to talk about architecture and design on three levels: enterprise architecture, software architecture, and detailed design. I have found these three levels useful to explain a few key concepts:

Enterprise Architecture represents the key decisions around the business platforms and technologies the organization is willing to support. Wikipedia quotes a formal definition of Enterprise Architecture from the MIT Center for Information Systems Research as "the organizing logic for business process and IT infrastructure reflecting the integration and standardization requirements of the firms operating model".

Software Architecture is the set of high level design decisions the organization makes when choosing what components will be used to create the software product and how those components will interact with each other and the outside world. Going back to Wikipedia, the software architecture of a program (or a computing system) is the "structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships between them".

Detailed Design is pretty much everything else underneath the software architecture. Detailed design is the sum total of all the other decisions, most of the decisions actually, about how the software will actually be constructed behind those higher level external interfaces.

Jim Coplien made the comment that you cannot refactor across class hierarchies. I am not a hard core technical guy but I think what Jim is saying is that Enterprise Architecture decisions need to be intentional... Software Architecture decisions need to be intentional... we inspect and adapt and refactor our way through the details behind the class hierarchies. In reality, these higher level decisions are really business decisions expressed in technology rather than technology decisions in and of themselves.

There is a fine line between the right level of up front planning and too much up front planning. It can be a slippery slope. As a project manager I simply want the team to understand what I call the 'big block architecture', what changes are going to be made in each of the blocks, and what the lines between the blocks mean. It is amazing to me how often teams cannot explain this basic level of information to me early in the project. Not understanding this has wreaked havoc on every moderately complex project I have ever worked on.

Okay... so there it is. There were lots of other cool points made throughout the talk but I think I've gone on long enough. Next post... we'll get back to the Product Owner stuff.

Subscribe to this blog Subscribe to Leading Agile

Handling Support on Agile Teams

Anybody have a team that is responsible for both new development and support activities? I got a great question from one of my readers last week that I'd like to share.

I have a team that’s responsible for both supporting what we’ve already created and released as well as developing new features or enhancements to what’s been released. I’m about to split a scrum team up from 12 people to 2 teams of 6. Most folks have no desire to do support full-time.

With only rough estimates of potential weekly incoming product defect ticket rates, we’re trying to determine how best to deal with this situation so that we can maximize our teams’ velocities while ensuring that we can deal with incoming product defect tickets within appropriate resolution times. The natural tendency is to have a very conservative velocity, but we’re hoping for something better than that.

This is a problem not unique to agile teams. Software organizations have been struggling with this one for years. The root of the problem is that your project needs a predictable throughput. Stable velocity is essential for a well managed predictable agile project... but your support activities make establishing a stable velocity nearly impossible. Support is a variable the team can't really define or control.

I'd love to tell you to just add the support tickets to the backlog with all the new development work and prioritize them sprint to sprint along with the other product features. The problem with this approach is most times support tickets are a drop everything, get the customer working activity. Support tickets also defy estimation. You are never going to know how long they will to take... you don't know their tasks... you might not even be able to predict their relative size. Service requests just have to get done... and they have to get done now.

I don’t know that there is a magic answer to this question. Like most things, it is a matter of understanding the particulars of your environment, and of your people, and coming up with something that meets your individual needs. Here are a few approaches I have tried in the past with varying degrees of success. Would love for you guys to reply to this blog with your ideas an other approaches for dealing with this difficult issue.

Approach One

Alternate the teams between support iterations and new development iterations. The team would establish a steady velocity (every other week) based on their new development work and that steady velocity could be measured against the remaining backlog to balance the scope and end date. If the team is not 100% consumed with support during a given sprint, they can use the extra time to get ahead of the game on their upcoming development sprints.

Approach Two

Assuming you have some historical data on how much time you spend doing support, allocate a fixed amount of bandwidth to support activities each sprint. For example, each team would allocate 30% of their time to support activities and velocity would emerge based on the time they have remaining to do new development.

Assuming the support needs will vary iteration to iteration, you will have to account for that variability in your commitments to your organization. I'd track best case, worst case, and average velocity based on what the team has been able to deliver iteration over iteration. You would then express this variability to the business as either a range of delivery dates or as a range of product features that could be delivered by a fixed date.

Approach Three

The last (and maybe least desirable approach for your team) is to have one team responsible for development and one team that is responsible for support. That would allow the development team to get into a groove writing new code and the support team to establish patterns for how much and how quickly they can get through support tickets. Because no one wants to do support full time, you would rotate people in and out of the support team and back onto the new development team.

I'm interested in your thoughts. Please weigh in with how you've handled this issue on your teams and what has worked (and maybe more importantly) what hasn't.

Subscribe to this blog Subscribe to Leading Agile

My Agile Lightbulb Moment

Yesterday, Michele Sliger asked me if I would do a little writeup on my agile "lightbulb" moment... that point in time when I got it... when I was able to cast off the chains of traditional project management and accept agile as the one true way to salvation.

Okay, okay... Michele just asked me to write my "lightbulb" moment... I added all that other crap.

I find these kinds of stories fascinating... what makes one person able to see the benefits of agile when others cannot? What series of events could lead one person to look for a better way, and furthermore, be able to recognize that better way once it when it presents itself?

The switch to agile requires us to see the world in a new way.... to use a different map... to look through a new lens. Many folks who practice traditional project management fundamentally see the world through a lens of predictability. Traditionalists believe that with enough planning we can create a stable project baseline and manage the project into a successful outcome.

Agilists tend to see the world through a lens of unpredictability... they are more willing to embrace uncertainty. Agile project managers still want to manage the project into a successful outcome but they are more willing to allow the definition of success to emerge through the life of the project. The interesting question to ask is what leads someone to hold one world view over the other?

When you have been brought up in a business environment where projects are relatively predictable, the idea of predictability is reinforced. When projects go wrong, you try to track the failure back to some failed process... or some piece of missing information. The fundamental assumption is that with more planning we could have prevented the failure.

Our project management education teaches us that solutions come in the way of process, documentation, and control.

My early professional experiences were in environments of total chaos. It was not that I was working in poorly run companies (I was working in very large, very well run companies) but that I was constantly working in environments with new and emerging technologies. Furthermore, I was working with people that were knowledgeable, but not necessarily experts in the technologies we were trying to deliver.

Growing up professionally in this kind of environment taught me that uncertainty was the norm. As technology guy, working with other technology guys, I rebelled against managers that though we could standardize process around activities that were ultimately unknowable. My experience never reinforced that predictability was something that could be attained.

When I was promoted into formal project management, I tried to learn the science and best practice around my new job. We started using MS-Project to plan out our work and I got my first copy of the PMBOK Guide. The problem was that I could never get comfortable my plans ever quite reflected the reality of what was really happening on the project. The more I spent time planning, the more the projects seemed to drift off schedule.

There was a profound disconnect between what the books were telling me and what I was experiencing in real life.

To cope with uncertainty, I started laying out high level milestone plans and doing rolling wave planning to flesh out the details. I had to to trust the team to deliver. During critical times on our projects my teams would have daily meetings to talk about what we were doing and to discuss problems in real time. We started estimating in relative units and calculating how fast we were moving through our list of deliverables.

We found using these approaches that we could deliver more reliably, with less overhead, and deliver greater value to the business.

It would be a few more years before I discovered that others had already figured all this stuff out. It wasn't until I started working with a development team that was already practicing XP that I realized there was a science behind what we had been doing... that there were other practitioners out there... and that there was an informal body of knowledge that I could lean on to expand my understanding.

I have always thought of my "lightbulb" moment, not so much as the moment when I understood (my career had perfectly positioned me for understanding) but more when I found my tribe. My moment came when I discovered that there was a community out there to validate and support what I intuitively already knew to be true.

Subscribe to this blog Subscribe to Leading Agile

Mike Cottmeyer... Agile Coach

I have quite a unique opportunity...

Normally my job with VersionOne involves training and a bit of consulting. I spend most of my time on site with customers, for only a few days at a time, trying to get across as much agile knowledge... and teach as much about our product... while helping them paint a vision for their agile journey ahead.

Over the next two months I get to change things up a bit... I'm working with a client here in Atlanta as an agile coach. I get to spend some time working with a REAL team, actually putting some of the stuff I talk about into practice. It is a nice treat and it feels great to get back into the day-to-day of helping folks with live projects.

I am really looking forward to the change of pace... and the opportunity to stay out of Hartsfield-Jackson International Airport for a few weeks. As an added bonus (if the last few days are any indication) this engagement is going to provide months of stuff to write about. Nothing like getting busy to start the creative juices flowing.

Prior to my first day with the new team, there were a few things I wanted to get a handle on pretty quick. I want to share with you guys what I felt was important and see if anyone else out there wanted to contribute to my list:

• How well does the team understand agile roles. Who was doing what on the project?
• How are they managing the project? How are the critical meetings being run? What metrics is the team tracking? How well does the team facilitate meetings? Are they using collaborative approaches for estimating and planning? Is someone dealing with impediments?
• How disciplined are their engineering practices. Are there any critical practices missing?
• Is their organizational structure supportive of agile teams or is it an impediment? Do they have any alignment issues between projects, product, teams, management, or software architecture?
  
• What is their leadership style like? Are they more command and control or do they take a more participative approach?
• How strong is the product vision? How well are the user stories articulated? Do they understand the full scope of the project or expect the backlog to emerge? How much requirements churn do we expect?

What do you think? What would you need to know about a team to be an effective coach?

Subscribe to this blog Subscribe to Leading Agile

Progressive Estimation and Tollgates

Kelly Waters from All About Agile picked up on my post yesterday about project velocity. Kelly made a great point about how we can use a toll-gate approach for estimation and project funding.

Here is Kelly's comment:

In some methodologies - for example RUP - there is an initial stage of the project ("inception") to do some high level scoping before seeking approval for full funding. It's also quite common in waterfall projects to complete the reuirements analysis before going on to request full funding. In these cases, only the initial stages need to be funded and then the team knows more by the time they ask for the rest of the money.

This is an essential concept for large scale agile development, and here is why.... coherent software architecture, UX and UI design, and requirements are not going to just emerge from multiple small teams working independently on a significant, enterprise level initiative. Without some degree of lightweight, up-front planning (to integrate the activities of several teams working together) it is unlikely that we will converge on a well integrated product.

Schwaber talks about this when he talks about iteration 0. Leffingwell talks about this when he refers to an architectural runway. In my opinion, these guys are dancing around the idea of Inception and Elaboration. This almost has to be done because RUP is such an unpopular topic in the agile community... otherwise people tune out. Ambler is more direct explaining these concepts when he talks about the Agile Unified Process.

By introducing these higher order agile concepts, we can help teams learn to effectively structure large scale agile implementations, and furthermore, help teams understand what decisions need to made and when... from both a busines and a technical perspective. A year or so ago I did a post called the Agile Heart of the Unified Process (back when this blog had no subscribers whatsoever).

Rather than reinvent the wheel, I am going to grab some text from that article and update with some commentary to tie back to Kelly's original comments... the text in bold was added today.

Inception

The goal of Inception is to minimize business risk. This means that you have to understand the vision for what you are trying to create, have a high level understanding of the requirements, and have defined the characteristics of the systems architecture you intend to build.

Begin Inception with a single Scrum team. The team should at a minimum have a ScrumMaster, a Product Owner, an Analyst, a Quality expert, and an Architect. The product backlog will include the features necessary to create the Vision, Use Case Inventory, and Candidate Architecture. It may be necessary to include features in the Inception backlog that prove key aspects of the business vision.

Inception is the least code focused of all the RUP phases. This is due to the requirement to have an idea of where you are going before you begin the project. Since Inception is the least focused on creating working software, and without working software the team is not mitigating risk, it is in the team's best interest to make decisions quickly and get on with the business of delivering working software.

At the end of Inception, there is a business decision that must be made. Do we have a strong enough product vision, and a strong enough architectural vision, to fund the next increment of product development. This is a good time to reestimate the backlog and decide if the value proposition of the project still holds.

Elaboration

The goal of Elaboration is to minimize technical risk. This involves choosing the smallest subset of features that will prove out the significant technical assumptions made during Inception. At the end of Elaboration, the system should be fully functional with the subset of features you have chosen to build. The system should be fully tested and the team should be confident that the architecture is stable.

During Elaboration, you may still have a single Scrum team. It is likely that you will add several more senior level technical folks to help begin building the system. The product backlog includes the features necessary to prove the application architecture and to deliver any non-functional components required to build out the system. It is important that the Elaboration backlog contain features the team will need to collaborate at scale. Source control, build environments, automated testing infrastructure, instant messaging, and collaboration software should not be overlooked when preparing to scale an Agile team.

At the end of Elaboration, we have another business decision. Have we built enough of the application to validate our technical assumptions. Can we move forward with the project, scale into multiple agile teams, and move forward with confidence we have a workable and proven solution? This is the next point where you need to reestimate the backlog. After proving the solution, updating the backlog, reestimating based in what we have learned, do we have a business case for moving forward?

Construction

The goal of Construction is to mitigate logistical risk. This is where the bulk of the software is created and where the Agile team really begins to scale. The core team that helped build the foundation of the system during Elaboration is broken up to seed the newly created Scrums. Each team is organized around a major component of the architecture or a significant feature set within the overall scope. Each team is a complete cross-functional entity that is responsible for delivering its part of the system. These teams are coordinated by a master team that includes a more senior ScrumMaster, Architect, its own technical staff, and the Technical Leads and/or ScrumMasters from the component teams.

At this stage, the backlog is completely feature driven, progress is extremely measureable, and the teams are focused on delivering the bulk of the business value to the customer. As is true during every phase, the code delivered at the end of each Construction iteration is fully tested and integrated with the rest of the system.

Construction is the most like the prototypical agile project as described in most of the common literature. We have several independent feature teams working in concert. Each is tracking velocity and burndown and making product adjustments as necessary to converge into a solution that delivers the most business value possible. The business is involved actively assessing progress iteration over iteration deciding when enough of the product has been built to take the solution to market.

Transition

This phase deals with training and hand-off to the customer, final user testing, and resolving any issues that were not caught earlier in the process.

During this phase, the team should be able to scale back down to a single cross-functional team or two. The backlog is related to the remaining documentation, training, and defect resolution features remaining to get the product in the hands of the customers.

I think of transition like many talk about hardening iterations. This is the place where we clean up anything leftover. If we need any final user acceptance, doc work... whatever, this is where it goes. We are asking our customers if they are ready to accept the project deliverables.

Subscribe to this blog Subscribe to Leading Agile

Agile Doesn't Fix Anything

Hey... are you any of you guys out there contemplating going agile? Be warned. Agile doesn't fix anything. Seriously... if you have problems with your development organization, making the switch to agile WILL NOT fix anything.

Agile will actually do the opposite of fixing things... it will make them more broken. Teams with poor communication will communicate poorly more often. Developers that don't code well will break the build more often. Defects will be injected more frequently and quality issues will be everywhere.

While waterfall lets these problems hide, agile has them smack you right in the face.

Waterfall teams get a period of quiet because most everything early on is documentware. We don't actually have to deliver any working software. Even once we start building code, the heat doesn't really turn up until we are ready to integrate, and that could take months. Not until we hand everything over to QA, and find out the product doesn't work, does the crap really hit the fan.

We get to pretend nothing is wrong until it is too late to do anything about it.

Agile on the other hand is noisy and chaotic... it will bring all our problems to the surface early. It will seem like agile is causing the problems when it is merely pointing them out. Agile will force our reality upon us in a way that is going to get pretty uncomfortable. As project leaders, development managers, and especially team members... we have to be prepared to do the hard work ahead of us.

The easy part of agile is holding a sprint planning meeting and doing a daily scrum. Writing requirements as user stories is fine, but what happens at the end of our first sprint when none of them are actually done? What about when we get to the end of sprint three and our automated builds are still not working? What happens a few sprints later when QA still can't test anything?

These might have been some of the same problems that you thought agile was going to fix. Guess what, those problems are still there. The value is not that agile fixes your problems, but that you get to find out about them early... while you still have time to do something about them. It is still up to you to fix them.

So the title of this post... while provocative (sorry about that... two in one month) is true. Agile isn't going to fix anything. Agile WILL put you in a great position to identity those things that needed to be fixed anyway. Agile doesn't let anything hide, it forces us to get real about where we are vs. where we want to be. If you want to be successful, your organization will still have to deal with the broken stuff.

Our goal is to build great product... better, faster, and more reliably than our competition. To do that, we have to relentlessly pursue excellence and we must understand the gap between our current reality and where we need to be. While agile isn't going to fix anything for us, it can provide a way to see that gap and position us to do something about it.

Subscribe to this blog Subscribe to Leading Agile

The Unified Process and Scrum

Earlier this year I did a presentation at Agile 2008 on using RUP as a scaling framework for Scrum. The talk was pretty poorly attended and clearly controversial. Earlier this morning I was up on my Slideshare account, pulled the talk up, and did a quick walk through on the presentation.

I really think the concepts here are solid and central to any serious conversation about scaling agile in the enterprise.

If you get a minute over the holidays, take a look at the presentation and give me some feedback. How could we take these foundational concepts and make them more palatable to the broader agile community?

Using RUP As A Scaling Framework For Scrum

View SlideShare presentation or Upload your own. (tags: agile rup)

Subscribe to this blog Subscribe to Leading Agile

The Secret to Organizational Agility

Are you ready... here it is... to be agile you must... break dependencies at all costs!

Dependencies are created when any two discrete elements within your organization require each other to do all or part of their job. At the enterprise level, dependencies are everywhere. They are created by the very way we have decided to structure our businesses and how we setup and execute our project work. This makes them very hard to identify and even harder to remove.

I believe that breaking our dependency on dependencies is the core challenge associated with orchestrating any sustainable enterprise agile transition.

Agile transitions don't fail because Scrum is insufficient. They don't fail because people have not sufficiently applied the right XP engineering practices. Our problem is not a fundamental misunderstanding of the Agile Manifesto nor an unwillingness to become the right kind of agile leaders.

While any given organization may have some or all of these problems, they are not our primary concern.

The underlying issue is that agile project management principles, agile engineering practices, and agile leadership philosophies assume you have already eliminated your dependencies! Most teams are trying to become agile without validating that core underlying assumption, no one has even told them they should try!

Think about how we describe our ideal agile implementation...

First, we start with a small team of cross functional individuals with sufficient skills such that anyone can work on any part of the system. Next we allow this team to only work only on a single project during any given sprint.

We then grant this team a dedicated product owner empowered to make decisions on behalf of the business. We allow them to work on small independent functional requirements which can be reprioritized at any time.

We give this team an empowering individual tasked with removing any organizational challenges the team might encounter. We remove any process constraints and allow them to do the work any way they want as long as they deliver working software.

Lastly, we assume they have an object oriented architecture that lends itself to test driven design, continuous integration, and constant refactoring.

This scenario perfectly describes a team with no dependencies. They have 100% of everything they need to get the job done.

Let's look at what many teams deal with trying to adopt agile...

People are typically part of a team of specialists that are matrixed into a cross functional project team. Because these people are specialists, their services are not needed 100% of the time. To maximize the utilization of the individual, they are assigned to multiple projects and any number of teams.

Product owners are doing market research, meeting with customers, and attending trade shows. The team is left with a less than empowered business analyst to make the decisions for the business. In reality, the product owner was just a proxy for a large group of uninvolved stakeholders anyway. No one gets access to real customers or real market data.

Many teams are trying to sprint through product development using a traditional MRD or PRD. They are not using requirements written as functional threads of system behavior that can fully tested at the end of the sprint. These requirements are not able to be reprioritized as we learn more about the evolving system.

Many teams are working with traditional project managers who are doing their best to be agile, but have been trained to manage dependencies and tell people what to do. Even if they want to be agile, they are not usually empowered to do anything about the real impediments the project teams are working through.

Teams are trying to be agile with tightly coupled software architectures, insufficient test coverage, legacy code bases, and unable to do a daily build.

This perfectly describes a team operating under the crushing weight of dependencies created by flawed organizational assumptions.

Let's look at some of our common assumptions that lead to unnecessary dependencies….

We assume that we must optimize for individual performance and therefore we matrix team members across projects. This creates dependencies between projects that did not have to exist. We find ourselves managing who is on what project and when they will be available for other projects. We create a network of dependencies [between projects] that restricts our ability to change course. Any change has a series of painful cascading impacts on our portfolio.

We assume parts of our solution are just too complicated and must be handled by specialists. We choose to assign certain people to specific components. By default, we create dependencies between products that share the same components. We also create dependencies between requirements that impact the same component. We create project dependencies between teams (and between team members) when we have these specialists assigned to a team of specialists.

We assume that our product owners are too busy for the team so we assign someone else to proxy for the business. We create a dependency between the team and the business that results in a tendency to over-document and manage the relationship between contracts. When contracts are used we create dependencies between the team and the business that must be maintained, enforced, and put under change management.

We assume the market is demanding all the features at one time so we do not focus on small functional slices across the entire systems architecture. Why bother, it all has to be done anyway? This thinking leads us to consider everything before we can consider building anything. When the requirements are all dependent on each other, there is no need to prioritize, no ability to change our minds, and no ability to learn from the emerging system. That big up front design document starts to look pretty reasonable.

We assume that architectures cannot be decoupled or that test coverage is too expensive. This causes us to think about making every change when we are making any change. Batched changes are made outside the context of working software. They are integrated and tested all at once... probably near the end fo the project. By creating dependencies between code changes, we loose the ability to learn from our mistakes, refactor, and hold teams accountable for outcomes.

Dependencies force us to measure hours worked, or modules delivered, or lines of code, when what we really want to measure is working software.

Why does all this matter?

Some of these dependencies are real. Many could take years to overcome. Just realize that every dependency you accept, every one you choose to leave in place, is going to fundamentally limit your ability to adopt agile methods.

Every single one will require a trade-off that will reduce your effectiveness and ability to respond to change.

By focusing on project management technique, engineering practices, or even leadership philosophy first… we miss the mark. We are inclined to pick from a smorgasbord of tactics and choose what can work for our particular organization. We are not forced to deal with the foundational problem, and therefore pick and choose our way into a meaningless agile implementation, one that will not deliver the essential value the organization is trying to deliver.

By focusing on the relentless pursuit and elimination of dependencies, we position our organization to potentially adopt ALL of the agile best practices. We can then pick and choose based on our values and principles, not on the constraints of our tangled up dependency based organizations!

Reduce dependencies at all costs. This is going to become my mantra for 2009. Expect to hear more on this topic as the year unfolds!

Subscribe to this blog Subscribe to Leading Agile

Agile PMP Webinar

If you missed my talk on the Agile PMP: Teaching an Old Dog New Tricks, the one I did down in Orlando a few weeks ago, you are going to get a second chance. I am doing a shortened version of the talk for the ASPE webinar series. The talk will be on December 18th at 12:00 PM Eastern time.

I'll look forward to having you join us... here is a brief abstract and info on how to register.

PMI / Agile Transition Webinar:
The Agile PMP: Teaching an Old Dog New Tricks
(Live Event: December 18, 2008 | Speaker: Mike Cottmeyer)

Building on the principles of PMI® and the Project Management Body of Knowledge (PMBOK), Mike Cottmeyer will explore how a PMP can adapt their knowledge and experience to become an effective agile project leader. Mike will tackle the hidden assumptions behind the PMBOK and explore a more agile approach to managing time, cost, and scope.

Webinar Title: The Agile PMP: Teaching an Old Dog New Tricks
Date: December 18, 2008 12:00 pm, EST
Cost: Free
Register: HERE

Additional Resources:

• Mike Cottmeyer's blog post going over some of the base information for his presentation at Agile Development Practices in Orlando, FL
• Mike Griffith's blog on the PMI/Agile SIG.

The picture on this post is also from Mike Griffith's blog.

Subscribe to this blog Subscribe to Leading Agile

Slideshare Beta.... The Agile PMP: Teaching an Old Dog New Tricks

The past few days, I have been trying to figure out the best way to upload (and share) slide show presentations with my Leading Agile readers. LinkedIn offers a SlideShare plug-in but I have to send people to my LinkedIn profile in order to see them. I would rather direct traffic someplace that adds more value.

I am experimenting now with a full blown SlideShare account to see if I can embed a link right into this blog post. Please give me you feedback on how it works out. Once I test this out on http://www.leadingagile.com... we'll give it a try on http://blog.versionone.com.

This is my deck from last weeks Agile Development Practices conference titled 'The Agile PMP: Teaching an Old Dog New Tricks. The talk went really well and got outstanding feedback. Please post a reply if you have technical difficulties

The Agile PMP: Teaching An Old Dog New Tricks

View SlideShare presentation or Upload your own.

Subscribe to this blog Subscribe to Leading Agile

More Talking to Project Managers

Here is my last post for Artem's Agile Software Development... republished here for the benefit of my Leading Agile readers.

Last post we explored some ways to introduce agile concepts to traditional project managers and how to make a case for agile in a way that has a chance to really resonate. We explored how to discuss time, cost, and scope… talked a little about dealing with uncertainty… and a little about the factors that are really constraining our projects.

If you are interested in catching up with the conversation, go back and take a look at my post "How to Talk to Project Managers" at http://agilesoftwaredevelopment.com/blog/mcottmeyer/how-talk-project-man...

This past Tuesday, I was up in Vancouver doing a workshop on these very topics. About half the class self-identified as a PMP certified project manager… the others were either uncertified project managers or development leads. Most of the folks rated themselves a three or four (out of ten) on their agile expertise. We had a few folks in the class that rated their knowledge in the five to eight range, and after doing the course, I agreed with their assessment.

Most of the people in the course were there to learn more about agile or to learn how to sell agile in their organizations. They wanted to understand the agile value proposition and how to go back and communicate agile in a way that really resonated with their businesses. We were off to a good start.

My talk generally followed the outline from "How to talk to Project Managers". People were taking notes and seemed engaged... but, sometime around lunch things started getting more difficult. After laying the foundation around the triple constraints, uncertainty, and project drivers; I had hoped to move into agile principles and project management techniques. What I found is that I had left out a critical component of the discussion.

I had not addressed how their organizations were currently structured and the barriers this would introduce to agile adoption. I started talking about teamwork and collaboration and they were thinking about matrixed organizations, task sequencing, and resource management… I had needed to address this issue head on and my failure to do this caused the class to spin a little out of control.

We ended up spending a great deal of time talking about merits of generalization and the challenges associated with specialization. We talked about how to deal with agile teams when some degree of specialization is required. We explored what it meant to be a team and what creating teams would mean for their organizations. We talked about the differences between iterative and incremental development versus agile development. We explored what it means to be a project manager in an agile organization.

What I learned was that there is a bunch more we needed to talk about before we could move to agile principles and practices. We needed to introduce a few more concepts before we started talking about agile project management. We needed to address matrixed organizations, building teams with specializing generalists, and the role of the project manager on an agile team.

Here is some thinking I've done on these topics over the past year:

http://www.leadingagile.com/2008/07/managing-too-much-complexity.html
http://www.leadingagile.com/2008/04/what-about-me.html
http://www.leadingagile.com/2008/10/agile-or-iterative-and-incremental.html
http://www.leadingagile.com/2008/06/project-managment-is-not-enough.html

Happy reading. Please comment on how you are talking to your organization about agile and what messages you have found that resonate. If I use something you submit in a talk, I make sure to credit your contribution.

Subscribe to this blog Subscribe to Leading Agile