Keep your stinkin' Maturity Model - prescriptive vs. adaptive

I keep seeing the same question appear in many forums lately- "How do we create a CMMi-like Maturity Model for Agile?" Sometimes this is a global question for the community, sometimes it is a question focused on a specific organization.

A couple of thoughts:

• Not all problems can be solved by the same solution
• Not all teams have the same problem
• Not all teams have the same dynamic and ability to change
• Thus, not all teams will succeed with the same set of instructions
  
• But, all teams can be aided by an experienced mentor/coach

Whenever I hear of Maturity Models, I foresee an environment where the desired process is documented and stable, and the steps to evolving to it are prescriptive, standardized, and audited.

The problem I have with this is that it will most likely constrain the teams ability to explore new ideas and solutions to their problems. Their continuous improvement will most likely be driven through a canal that is managed by lock keepers and limited to the waterway. Kanban has had a refreshing influence on the community, but it is not for everyone. Does an organization create a maturity model that takes in every new idea? Does it have the capability to create a choose-your-adventure pathway?

Yes, I think an agile transition maturity model is possible. But I also think it is improbable to have the right outcome. And, it might be less work to allow the teams to find their own way with a centralized coaching/mentoring staff. What do you all think?

From a recent LinkedIn conversation I was having:

I would suggest that a first step is to inspire the PMO group in your organization to get out and observe the teams. Start documenting patterns. When there is a catalog of "for this problem, here are solution patterns that have worked", you not only have teams learning and growing from each other, but teams of like need mature towards a converged point.

Personally, I'd prefer this over a CMMi approach because it is a mentoring/guidance solution instead of a prescriptive/directed solution. The minute you demand teams follow a certain path, you limit their ability to explore and uncover great ideas. I believe that creativity and exploration through retrospectives is a key part of continuous improvement.

A further experiment in ScrumBan…

I’ve recently evolved my company process to include WIP limits, but before I share this story, I must first provide the following background.

When I started at this company 2.5 years ago, there was a large divide. I was trained in PMI, was a CSM, and I was a staunch advocate of XP/Scrum by the book. On the other side of the divide, the company had little process, little documentation, no source control, and made minimal attempts to plan work a day or two in advance. One could say this was a recipe for disaster, but this is a startup… and the point of hiring me was to improve as they doubled the size of the company.

Several things have happened since then:

• retrospectives and weekly iterations were quickly adopted
• source control is now in place
• we put tools in place to manage our work (VersionOne)
• standups have become common for both teams and projects
• we’ve modified the 3 questions
• we now use a ScrumBan inspired board
• most importantly, I’ve learned that there is more to Agile than Scrum/XP… I’ve become an interested follower/borrower of Lean and Kanban practices. This is an important step for me as a coach since not all environments fit the Scrum/XP model. A mixed bag of tricks helps win the debate, especially when it is gamed against you!

So, what is the new problem of the day? I’ll call it the plan-to-budget problem. I’ve struggled for 2.5 years to find a way to get the company to plan work based on the available capacity. We’ve always had “BUT-we-need-to-do-ALL-of-it”-itis.

I’ve explained velocity and scrum, but this was viewed as too expensive to pursue. “Why should we estimate everything when we only care about certain parts of it meeting a specific deadline?” This is a good point. If only a small portion of our work is deadline driven, and the rest is “do as you can in this order”… then putting time into estimating and projecting everything might lead to waste. (Although this is contradictory to “I-want-all-of-it-by-next-month”-itis.)

Thus, I reduced focus and tried a top5 concept. Hey CEO, pick only 5 things that are important for this week, we’ll do our best with that set before touching other stuff. This worked well for a while since it forced us to admit we can’t get everything done and focused on fewer items. It reduced our “in flight” work… for a while. Two things derailed this approach.

1. The CEO found ways to assign work to people outside the top5 set (most people can’t say no to the CEO/founder when approached).
2. Not all items were the same size (scream together now: ESTIMATE!) so 1 large top5 item could clog the whole pipe.

We let go of this concept and evolved our breakdown further. I was happy to push for smaller stories and quicker closure. Appropriate sizing is a great stress reducer for the team, especially when you involve them in that process. But we slowly returned to our problem of demanding more work than we have capacity for.

This is where I started thinking about Kanban’s WIP limits. After all, this would fit our model well, and we already have the board in place. Unfortunately I knew that this would be bypassed just like the top5 limit. Our problem was a cultural problem, and I had to tackle it at the source.

So, we’ve started a new trial change in our process. After 3 hours of debate, I was able to convince management of the following (meaning they agree with these):

• Giving one person too many things at once will slow down throughput
• Swarming is a good way to get things done faster
• Saying we have to do everything doesn’t mean it will get done
• Not deciding on priority means it will get decided by the people doing the work
• Our biggest issue might be over-committing (actually, over-requesting since nobody was necessarily committing)

The solution? Headshots! I made little headshots of each team member. We plan the queue of work and then prioritize it. Then the CEO points at a card on the board and says “I want that first”. We put 1-N heads on it based on availability, capability, and size of work. The CEO keeps pointing at items until we run out of headshots. If he points at big things, he picks less stuff; if he points to small things, he can pick more (Budgeting to capacity!) When a person frees up, they move to something else on the board. Everyone on the team might have a few things assigned to them in VersionOne, but they KNOW which item is most important (the one with their head on it on the board). Everyone on the team focuses on helping each other finish these items before starting new things. All of this is clearly transparent on the board! It's not rigid like scrum velocity or Kanban column limits, but it is a place to start and a way to prove value (a door to further improvement).

Summary: We aren’t doing true scrum, but some of the pieces. We aren’t doing true Kanban or Lean, but some of the pieces. We aren’t truly self-empowered, self-managed… but somewhat. I would be the first to declare we aren’t “agile” as defined by most in the community. BUT, I’m getting to the point where I believe we have a system that works for us (2.5 years ago, we were a demand-and-control company led by the CEO). It’s a hybrid of many agile approaches, driven by my teaching of agile philosophies, allowing this company of ~70 work better together. Hopefully this new change will help us overcome our capacity/planning issues, only time will tell.

Post agile, one third of you will be gone...

About 6 years ago, I was at a company going agile... I didn't know much about it yet. I didn't realize how it was going to affect me and my career path. I had no idea that it would invigorate me and show me a better way. But there was one thing I heard immediately that I did understand, and it excited me.

The head of the division stood in front of 3,000 employees and stated

"... and after we are done going agile, I won't be surprised if one third of you will be gone."

You could have heard a pin drop. I rarely hear deafening silence, but I heard it that day.

He went on to explain...

"...some of you are managers. You are not the type of managers we will need. Some of you are employees, you won't be comfortable working this way. The pressure will go up, but the motivation and reward will also."

And finally...

"This is okay. It is where we are going. We are committed to it. I accept that this will happen and am respecting you enough to say it right now. Many of you worked hard to help us get to here, but that doesn't mean it will continue to be a good home for you."

(disclaimer: for those who were there with me that day, I know these weren't the exact words... but they were the message!)

9 months later I remembered that statement and I glanced around. I realized I was working with different people. I was on an awesome team. The team I was on before was really good, but they were all like me... the same role. Now I was on a team with really smart hard-working people that weren't like me. We were all different roles and we all have to think and work together to be successful. It WAS harder, but it was ALSO more fun.

And yes, we lost a lot of people. The people that just wanted to tell other people what to do were gone. They either left or were removed. The people who liked sitting in cubes and being told what to do left also.

This is why my first agile experience was so revolutionary. I doubt many of you had such a hard immersion through the transition, but it was wonderful!

The question is, who was left on the sidelines through all of that? Mike Cottmeyer wrote a good piece on this yesterday. How do those remaining managers adapt?

Market Take-over vs. Proven Success...

My first agile project began as a disaster, which is why we chose to try agile. Nothing else had worked, so we threw agile at it knowing the ship was starting to sink. Thus far, we were always 2 years from delivering. The beast was huge and we were doing more work descoping and handling change management than actually getting functioning code out the door. Oh, and we were under ISO and other audits (risk mitigation being more important on a life critical system.)

But, it ended up being one of the best teams and projects I've ever worked on. I still stay in touch with many of the people on that team and it was such a huge turn-around that many of us have been working with agile since then.

This morning I was reminded of this as I read Przemysław's blog post about "Half-dead projects". It reminded me how our project start was focused on a team of 5 clinicians pulling from their various experiences to create the "scope" and requirements needed to displace competitor products from the market. They spent over a year figuring out what it would take to perform a market take-over. The goal was to be a #3 product in the space within 3-5 years. Starting from nothing, that meant we had a long path to pursue. To make it worse, our product had to be a global product fulfilling all the needs of each culture and continent. There were always exceptions and special cases uncovered every day for a specific country or language. We were constantly descoping to pretend our deadline was obtainable. Our focus was on the day where we sold our product to 25-50 customers.

Then one day we realized we were close to being done. Unfortunately it was "dead done", not deployed done. We needed to survive. We had a contract in place with a beta customer... they also needed us to survive. So we threw the kitchen sink at it and we went agile.

On some level we threw out the entire MRS, PRS, SRS, and 50 other piles of documentation. In 3 days, we created a whole new backlog with stories and estimates. Then we stepped back and we realized this was still too much.

So we threw that out and started again. We went to the beta customer and asked... "What do you need to start using this?" What they "needed eventually" turned out to be much different than what they "needed to start". Turns out, a lot of time is spent setting systems up in the health care setting. Provide some screens to start configuring x, y, and z... it will be 2 months before that is ready to be used. Build this next... etc. We focused on one customer... right here, right now. Every 2 weeks (instead of every 3 months), we demonstrated what we had built and we asked what was next. Our product owner made sure that none of our steps were unique to the one customer and our work still fit the long term global strategy (you can't focus completely on right now), and we kept making little victories.

Six months later, that beta customer had software in their hands. Think about that... we went from 2 years to 6 months. It turned to be much more important to have one active customer than 15% of of our product built.

My favorite confirmation was when they told us how much better the process was. How they now understand why it was so hard and that by being involved, they could work with us as a team to make hard decisions and insure something of value was handed to them sooner.

That is one of the core impacts of going agile! You know it is working when you have proven success! I now believe that a market take-over is achieved by convincing EACH customer to buy your product or service. It is not done by defining up front what they all need. Every customer is slightly unique. Prove that you can make one customer happy, then five, then 20, then 100.

You can take over the world one customer at a time with proven successes. You can't do it any other way.

Higher Agile Project Performance...

Recent VersionOne user forum discussion:

How to yield higher agile project performance? Should we implement one agile method, such as scrum, and follow process rigorously, or mix with different agile methods?

I'll paraphrase my response:

As mentioned previously, I'm a believer in Shu Ha Ri. This means, follow the book until you know the why behind the prescribed actions. Do not modify the process unless you know what is removed with your proposed changes. Many people lose more than they gain if they change a process before it is fully understood.

Many waterfall projects could be successful if the team studied and followed the PMI process as documented. Agile will be corrupted just as quickly as waterfall if people keep bastardizing it blindly as they have been. If you are interested in expert opinions on bastardized agile process, check out Jeff Sutherland's view's on ScrumButt and the Nokia test.

My proposal: apply Scrum for people, business, team, project management improvements or apply XP for engineering practices and technical quality issues. You could apply both simultaneously, though this might increase risk with too much change at once. Scrum requires a top down implementation, while XP should be a bottom up implementation (I'm speaking of the top/bottom of your organization).

Eventually, you can yield a higher agile project performance with a blended process approach based on your environment, but you can't jump directly there in the beginning. Also, the person driving your Ri level approach should be experienced (not just trained) in the things being blended. If you do not have this person, then the changes need to be a gradual evolution (one per iteration) allowing for correction.

I would debate that the average team should get through twelve iterations before trying to tweak this. For one month iterations, this is a year. For two week iterations, you might be ready after six months. Why base this on number of iterations and not time? Because you should be learning with each cycle and improving from your retrospectives. Agile is about learning and adapting, not practicing (or feeling pain) over time.

The last option I would throw out is that you don't implement anything by the book... you simply add one practice every two weeks or month. The practice added is one that addresses your biggest pain of the moment. Over time, you will back into a blended agile process that works well. Unfortunately this requires two things... lots of time and patience, and someone with experience to make the right selections at the right pace and help the team implement it in isolation of the rest of the practices. I've seen this work only where the person driving has had experience with a successful multi-year mature agile implementation in the past. If you are going to choose this path, I would suggest the following sequence: retrospectives, standups, large visible charts. Why would you choose this path? Because nobody has bought into agile and you just want to solve the current problems with agile patterns.

Infusing Some Kanban (follow-up)...

A week ago, I posted about infusing a few Kanban concepts into our team process and making other tweaks to our standing meetings. Here is a follow-up for those of you who are interested in how it turned out.

In parallel to the previous bullets:

• our cards on the wall have not been restricted to 5. BUT, the good news is that every time we go over 5 the team yells penalty at the CEO (the product owner) and requests that we swarm on existing cards before moving to new ones. The intention is there. (improvement!)
• the CEO is doing a better job of throwing things into the queue as we pull instead of having a weekend brainstorm and puking out a whole new set of priorities on Monday morning (improvement!)
  
• Our standups are more efficient and effective. At first I thought we were missing things because less was said and we ended early, but I'm slowly growing confidence that we are simply focusing on the correct things, consolidating topics into single threads, and reducing the noise. (improvement!)

Also:

• We are definitely focused on the "what" now instead of the "who".
• Standups are easier to follow for outsiders (if desired)
• It is easier to see where things are getting delayed

I will also say that it has become easier for me to coach. Instead of focusing on all the things I am trying to understand and piece together, it is easier for me to keep an ear for anti-patterns and push the team a little more.

So far, a success. I guess I am now a heretic for morphing the standing meeting away from the 3 questions per person. I can live with that.

Infusing some Kanban...

The team I am working with was starting to have a few issues. We had too much on our plates, lots of noise, and the CEO was raising concerns that we weren't focused on the right things. We also had a feeling that the sprint end and begin was a magical flurry of stressful activity.

So we've implemented some changes:

• Our cards on a wall board is now restricted. Only 5 things can be in flight at a time. Everything is still in VersionOne; but only the top 5 get the explicit visibility of being important enough to be covered every single day.
• The CEO (highest level product owner) is responsible for filling and prioritizing the +5 queue whenever there is an opening. These are the next 5 things expected to move into flight.
• Our standups are no longer going to be asking the 3 questions going around the circle in the sequence we lined up around the room. Instead we are going to first talk through the top5, and then use the time remaining to discuss other notables as people need to. The team is responsible for taking their turn by importance and not going in sequence.
  

Our hope:

• This will shift focus from what "I am working on" to what "the team is delivering for the company".
• We might not get to every topic since not everyone will have an explicit turn, but we guarantee that we are talking about the right things.
• Outsiders can attend the standing meeting and easily see certain items and their status as opposed to hearing about an item across people throughout the meeting.
• We force the business to shift from magically identifying 5 things every Friday (1 week sprints) to constantly filling a pipe of work every day as we empty it.
• It is easier to see if our commitments of date and cost are at risk and communicate that to stakeholders because the topic is covered at once. (Our commitments are more safely limited to the top5.)
  

We see how it goes... (like many issues, we'll implement changes and slowly snap back to a happy medium as we learn and grow)

Incorporate challenges, don't protect against them...

Precondition:
Everyone working for a company should be assumed to have a vested interest in its success because, selfishly put, they want the company to SUSTAINABLY make money so they can SUSTAINABLY make money. (Hopefully they also have pride in the work, their team, and the company's impact on the world.)

Theorem:
By working within a company, employees are likely to have as much or more insight into the domain than the average user of their product or service. Therefore, if one employee has an idea and another employee challenges that idea, it is very likely that eventually some portion of your paying customers/users will have a similar reaction or be affected by the raised issue.

Proposal:
When someome challenges an idea, they are not challenging you personally but instead they are helping insure that the idea will improve the company future and will not detract from other ideas. If the idea is one you support, then it is your duty to accept these challenges as a way to collaborate and make the idea that much stronger.

1. You must first try and UNDERSTAND what they see
2. You can communicate your idea differently in the hope that CLARITY will enable them to support your idea
3. You can enlighten them with FACTS you might have that will change their point of view
4. If they still can't see your idea as one they can support, then you should attempt to debate, collaborate, and COMPROMISE until the idea is one that everyone in the conversation can support and go out and sell to others. [Note: this can be bypassed if the person challenging you can agree that your idea doesn't detract from the larger set of ideas and you have the authority to make said decisions. (This is to combat the everyone-can't-be-involved-in-every-decision momentum blocker.)]
   

The fundamental thought here is that people need to stop baking ideas alone in their head (or a mini-sub-group) until they believe it is perfect and then expect the world to accept it as is. Humans are tribal social people and we have different perceptions of what we want. Once you state any idea that you want others to desire and use, you must accept that you don't control it any longer. It must be molded to the needs of the group you expect to utilize it. Anyone that can help you do this will get you a step closer to success.

This is fundamental in usability, marketing, business... even the selection of what to put on your grocery list (if people other than you share in consuming those items).

Summary:
If your employees aren't drinking your Kool-Aid, then why do you expect your customers to do so? If your team doesn't have the passion you do about trying something new, then they aren't likely to support you as a team when you pioneer new paths!

Credit:
This was inspired by some thoughts triggered by Dale Emery's discussion about resistance as a resource and Denise Caron quotes found in this slideset about agile:

Open yourself to critics and take your capabilities to new heights
Don't fall in love with your product, someone will be there to change it, it's a promise

Get constant personal feedback...

Agile is about constant feedback loops. Release, iteration, daily scrum, pair programming, unit tests... they all provide feedback.

How are you getting feedback on yourself? Are you doing a good job? Do you communicate well? Do your team mates like working with you? Is there anything you can improve?

Something I took away from Agile 2008 is that regular personal feedback (weekly) is much more impacting than a yearly or quarterly review. This is why I've started using Rypple. After every presentation, I send it out to the attendees. I've sent it out to solicit peer feedback to support my self-review with my manager at the end of the year.

I tried something like this before using index cards and received good results, but this platform makes it so much less time consuming.

Try it... it might help you also. Check the site out and watch the quick video for more info.

5 minute retrospective...

Personally I view the retrospective as one of the most important parts of agile and one of the easiest first steps to implement. I find many of my peers agree with me. I've done personal retrospectives for self-improvement, and I've talked about retrospective accountability.

Peter Stevens wrote on the Agile Software Development blog about the challenge of working with a new team and introducing agile concepts. Knowing that "challenged" teams are so busy fighting fires that it's hard to interupt them even to make their sutuation better, Peter attempted to apply Ken Schwaber's idea of 5 minute retrospectives. Cue Bill Murray in "What about Bob" saying "baby steps" over and over again.

It's a good read and it furthers my belief that agile retrospectives are a agile practice gateway drug.

Screw the Practices...

I was at Agile 2008 with several people in a session with J.B. Rainsberger (past Gordon Pask Award winner). He threw out a very interesting theorem, which I will try to channel here (apologies to JB for stealing and tweaking):

Every agile adopter is going through a journey of stages, and we might observe the maturity of an agile coach or practitioner by this path or even predict where the agile community is going. It points out that we continuously evolve our view and flip between pragmatist and purist views (the topic of the session we were in).

1. The Agile Convert attempts to learn an Agile Practice.
2. The Agile Purist follows the Practice to a fault.
3. The Agile Pragmatist starts to realize that the Practice doesn't work in all situations and pursues the Agile Principle molding the Practice to their specific environment.
4. The Agile Purist follows the Principle.
5. The Agile Pragmatist starts to realize that the Principle doesn't work in all situations and pursues the Agile Value molding the Practice and Principle to their specific environment.
6. The Agile Purist follows the Value.
7. The Agile Pragmatist starts to realize that the value doesn't work in all situations and pursues the ??? molding the value, principle, and practice to their specific environment.
8. The self-actualized Agile Follower realizes that Agile is the embodiment of some higher understanding that can be applied in part or whole to any environment to help deliver more value… they forget the boundaries of values, principles, or practices… these are just simple mechanisms to enable the education of agile to others.

Having communicated this to a few people since then, the one piece of feedback I find that people agree on is that this path happens at different rates for different topics in agile. You might be at step 2 for TDD and step 6 for iterations.

J.B. was predicting it won't be long before various agile leaders start bringing up ideas that go against where the community would have initially expected to go. I wonder if Arlo Belshee might have already done this with his "Promiscuous Pairing" and "Naked Planning" concepts (which is why he won the Gordon Pask award this past year at Agile 2008).

Interesting theory. It resonated with me. It reinforces that it is not about the name of what you are doing, or even how you are doing it. Agile is a philosophical approach to delivering a better working environment that produces a better outcome.

Agile 2008 was over a month ago... why am I writing about this today? Because Jeff Langr reminded me of it when he recently pushed back against the Chicken, Pig concept for standing meetings.

Another note: steps 3, 5, and 7 above remind me a lot of the "Ha" level of Shu, Ha, Ri as conveyed by Alistair Cockburn awhile ago. Step 8 feels like Ri.

Improve yourself...

In a few weeks I transition from coaching our tech group within agile values, principles and practices, to training the "product" groups on many of the same concepts and starting to fold them into the agile culture. I realized pretty quickly that it was a good time to reflect on my past two years and think hard about how I approach this effort. Rather than easing into it, we're taking a more formal approach... and as a coach, I need to get along with people as I spend more time with them than I have in the past.

So, time for a personal retrospective.

At the end of a team retrospective I facilitate each month, I handed 3*5 cards out to each member of the tech team and asked them to honestly and brutally tell me at least one good thing and one bad thing about me. They looked at me funny, but after I explained why I needed this they asked for several more cards (funny, ha, ha).

What I got back was insightful. I'll spare you the 34 individual comments and share the most common:

• good: you don't inflict change
• good: you hear our concerns and adapt, you don't force us to do it by the book
• good: you presented the philosophies behind it instead of telling us just to do it
• bad: you talk to fast and cram in too much
• bad: you sometimes try to hard to help people and step on their toes in the process

There were many other insightful comments including the humorous remarks of my nerdiness, male pattern baldness, etc.

What's my point?

I'm proud of the fact that these people trust and respect me enough to give me honest feedback. I'm proud of myself for asking for it even if I felt like hiding in the corner as they scribbled on cards. I hope I have the guts to absorb this feedback and improve my coaching skills.

Peer reviews can be an amazing way to improve yourself if you are open to changing.

Do you have the guts to try it?

"No matter the circumstances you can always improve. You can always start improving with yourself. You can always start improving today." - Kent Beck

Nobody will listen...

Eckford complains that people are head's down. As a contractor, he's in a tight spot as his tenure approaches an end but he still has something to share. Why can't people value collaboration over isolation? Why aren't they interested in the bigger picture and planning for the future game?

I attempt to provide my thoughts on providing advice without inflicting change or burden... what are your thoughts?

My nugget: "timing is everything, sometimes patience is required because they simply aren’t ready yet."

Learn Agile by yourself...

Can it be done? Jon Strickler started the debate. I'm hoping to take the topic to Agile 2008 and see what other people think.

I believe it is a lot easier to learn agile with a coach or someone who has experienced it. It's so easy to get it wrong by following the practices without achieving or understanding the principles or values. But the real question is, can it be done without help?

Many people reply that someone figured it out the first time and they were alone. But I disagree. How many people signed the manifesto? Hasn't the community been about raising new ideas and challenging each other? Don't we grow the community through evolution and collaboration instead of education?

What do you think? I'm turning comments off on this one so you are forced to add to our debate on Jon's blog.