2010 in Retrospective: Mike Cottmeyer Edition

Written by Mike Cottmeyer Tuesday, 28 December 2010 02:58

2010… the year LeadingAgile the blog became LeadingAgile the company.

You know guys… 2010 has been a hell of a year. Twelve months ago I had left my job at VersionOne and joined Pillar Technology. I was brimming with excitement about my new opportunity. A few months ago, I left Pillar and ventured out on my own… still brimming with excitement, but now the context is totally different. It’s amazing what can change over the course of just a few months.

As I look back over the course of my career, the most difficult times were the one where I learned the most. This year was no exception. I knew when I joined Pillar that I was venturing into uncharted new territory… I knew that I was going to have to learn a ton to be successful. If I had that deal to do over, I think I’d set more reasonable expectations from both of our perspectives. We set ourselves up for failure… and a lot of unnecessary heartburn.

I know I learned a lot working with the guys at Pillar… and I bet that the guys at Pillar learned a lot too trying to work with me. It’s a shame that we weren’t able to figure out how to work together better. With all due respect to the sales guys out there… it is a tough thing to sell with integrity. You have to truly believe the customer has a need… and you have believe you are the guy to fill that need.

If either side of the sales equation is off, the process can feel pretty queasy. It took me a while to figure out what I could sell with integrity… and by that time, things had gone far enough South that both of us were done with each other. In all honesty… five or six months later… I’m still not really settled about how things turned out. It’s a shame on many levels and I wish it would have turned out differently.

But anyway… I tell you guys this to set the context for my lessons learned for 2010 and to share with you some of what I’d like to accomplish for 2011.

Kind of like last year… this year is all about building business and working with Dennis to finish the book. The trick is to do all of that while spending time with Kimi and the kids and managing to take care of myself. I turned 40 this year and realized that I’ve got to take better care of myself if I want to be able to run at this pace for any length of time.

To that end I’ve got a list of things that I plan to do less of this year:

I’m going to do my best to eliminate unnecessary travel. That means that I’m going to show up at less conferences and community events. It also means that I am going to moderate back the amount of travel I do for face to face meetings, and do as much as I can remote. I want to be involved with Agile2011 and maybe one of the PMI events, but past that, I plan to stay in Atlanta.

Also in the ‘less of’ category, I’ve decided that I’m done working for other people. I knew after just a few months of working for VersionOne, I was ruined on Corporate America. I think that being an independent has ruined me for working for anyone other than myself. You can never say never, at the end of the day I’m pretty pragmatic, and I do value paying my bills. That said, working for yourself is the way to go if you can make it happen.

That brings me to the things I want to make sure keep working well:

I’ve been very fortunate that most of my client work as been in Atlanta. Working in Atlanta keeps me off the road and less guilty leaving Kimi and the kids when I do travel. I want to keep doing work in Atlanta and that means continuing to stay invested in Scrum Atlanta and Agile Atlanta, and also in the PMI community here in town. I plan to continue investing in my existing clients and hopefully maintain an ongoing relationship with the folks that already know and trust me.

The other thing that’s been working well is the amount I’ve been billing. The last few months I have not had any unplanned bench time. That’s not going to be sustainable over the long haul, but for now… being busy is good. All the stuff I am working on is pretty high leverage. The client work is contributing the getting the book written and the book is helping me support my clients. If I can stay working 5 days a week… that is good for me right now.

Which brings me to the list of stuff I need to do more of:

I’ve mentioned that I plan to start taking better care of myself. That means eating better and drinking less (he says sipping on his glass of merlot). It also means going to the gym more and actually doing some serious exercise. I hired a personal trainer to work out with me once a week for the next year. Hopefully that will give me the motivation I need to really lean into staying fit.

For the past few years, my life as been mostly work and family. On the surface that is a good thing, but I’ve got a few hobbies that never seem to get much attention. I am passionate about playing guitar and I plan to refocus on learning some new stuff. I’m also passionate about the outdoors and plan to sleep outdoors much more often over the next 12 months. Finally, my son and I started learning German last year but abandoned it after a few months. I think we are going to restart.

Finally, I am going to focus more effort this year on writing. I’ve always written to explore and share what I am learning… the problem is that the stuff I was learning was more about the sales process, and how sell with integrity, and I just didn’t want to write about it here. It’s also tough writing about things I experience with my clients because some of them read this blog… and you have to work really hard to be respectful of their specific situations. As I refocus on the book, I think that is going to help me generate more content overall.

I’ve got the next few months booked up and am pretty sure Q2 will fill up based on the stuff I’ve got in the pipe. I plan to go all-out until the fall and then try to moderate back a bit. One of the things I am really looking forward to about being an independent is working with some of the great talent out there making stuff happen. I want find opportunities to work with other folks in the Agile community and learn from their experiences. That is going to require some space on the calendar.

In closing… I just want to say how thankful I am for this community and the opportunities it has afforded me any my family. I am thankful for the opportunity I had with Pillar and thankful for the success I’ve had since leaving. It’s been a great ride so far and I’m looking forward to see what emerges in 2011. It’s exciting to think about all the change that came in 2010… it will be fun to see what unexpected changes 2011 has in store.

Sharing Risk With The Team

Written by Mike Cottmeyer Wednesday, 22 December 2010 12:07

Many of the teams out there are building stuff that has never really been built before. They are using technologies that are unfamiliar to them. They are working on code bases they didn’t originally create and dealing with customers that don’t really know what they want.

Agile can be a great approach for dealing with this kind of uncertainty. Agile methods encourage you to build a little bit of the solution, to learn incrementally what it will take to build the emerging product, and to get continuous feedback from your customers along the way.

The challenge is that most customers want some idea of what they are going to get for their money. Even in cases where they aren’t sure what they want, and even in cases where the team doesn’t really know how to build it, they want some assurance they are going to get something useful.

Agile teams try to use relative estimation, measure velocity iteration over iteration, get good at making and meeting two week commitments, and hopefully get predictable over time.  The idea is that the team will build trust with the customer and deliver the highest value features possible.

But what happens if you just have no idea of what it is going to take to build the product?  What happens if velocity never stabilizes?

What if you are working in an entirely new problem domain with a bunch of new technology. What if you’re working on a legacy product that is full of technical debt where everything you build seems to have some unintended consequence you have to deal with?  What if you just can’t make and meet a commitment?  How do you even begin to get traction?

Here is my assertion…

If you are in a situation where requirements are unstable… and the underlying technologies are unstable… just accept that there is no way you’re going to be able to run a predictable project. It doesn’t matter if you use traditional methods or agile methods… acknowledge that you have no idea what it is really going to take to build the product.

So what are you going to do? Failure is not an option… doing nothing is not an option… but hope is not really an option either. Let me give you a few things to noodle on when dealing with situations with profound uncertainty…

From a team perspective… you have to intentionally design and run experiments intended to de-risk the project as fast as possible. Until you come to some sort of agreement about how you are going to build the product… until you actually discover HOW you are going build the product… time and cost estimates are a crap shoot at best.  Even relative estimation is meaningless.

From a customer perspective… you have to recognize that you are investing your money in a very risky endeavor.  You are basically entering into a place where you know what you really want, and the team you have to do the work doesn’t really know what it is going to take to get the job done.  You are betting that the team can deliver something that you’ll be able to use, with no assurance they actually can.

To mitigate this delivery risk, customers tend to ask for fixed time, fixed cost, and fixed scope projects. Even though they likely won’t get what they want when they need it, it will be someone else’s fault.  Developers, on the other hand tend to want to shift the risk to the customer by asking for a time and materials agreement… one where they deliver the most value possible given the time and money the customer is willing to spend.

Neither approach is a very effective strategy for running a predictable agile project, and in the end… no one get’s what they need to be successful. I believe that the ultimate answer lies in being able to acknowledge the situation we find ourselves in and acknowledge that we just don’t know what it’s going to take the solve the problem… we have to acknowledge that shifting the risk to the other party doesn’t really help.

In the end, our mindset had to change. We have to learn how to share the risk.

It starts with a willingness to invest in smaller increments, to make smaller bets.  We have to be willing to invest in discovery… to be willing to invest in a set of experiments with the return being nothing more than a learning outcome. If you’ve learned what you need to learn… agree to make the next investment increment. If you haven’t, either make the decision to go forward anyway or kill the project.

At the end of the day… it’s really about accepting reality and dealing with it.  We don’t know and no amount of up front discovery is really going to help us know.  Rather than pretend, constrain the investment and work to narrow the cone of uncertainty to the point where you’re willing to make the bigger investment.  If you don’t know… and you can’t find out… stop pouring good money after bad.

The Agile Blind Spot (Guest Post by Jurgen Appelo)

Written by Jurgen Appelo Thursday, 16 December 2010 11:47

Note from Mike… After 320 or so posts… this is the first guest post on LeadingAgile.  The idea of having  people do a guest post is a bit odd to me.  LeadingAgile is a labor of love and very personal.  I’ve got a ton of respect for Jurgen, and really admire his work, so when he mentioned the idea… I really couldn’t say no. This is a great post… hope you enjoy!

It’s nearly 10 years that the Agile Manifesto was written, and everybody and their grandmother loves pointing out “weaknesses” in the original document. Allow me to jump on that bandwagon and add my own thoughts to the ever-growing pile.

I believe a “weakness” of the Agile Manifesto is that it doesn’t (explicitly) recognize that all software projects need people being smart, disciplined, and attentive. The “people over process” paradigm is great, until you find out that your team consists of two trolls, a parrot and a hairdresser, and a relatively bright project manager, who happens to be deaf, blind and mute. No amount of coaching will help a team like that to magically self-organize and to deliver a successful product. I call this the agile “blind spot”. Agile (as promoted by the manifesto) is great only when the team is great (or at least good enough). To be fair, the need for great teams is probably even twice as important in non-agile environments, but the Agile Manifesto too leaves the competence issue unresolved…

To address this problem, I usually compare agile management with traffic management. Traffic management is the art of reducing the number of casualties in traffic, despite the fact that most drivers are either dummies, lunatics, or flat-liners.

Wikipedia claims that my home country, The Netherlands, has the lowest traffic-related death rate in the world. Yet we live with 17 million people, and 136,000 km of roads, crammed together in an area smaller than West Virginia. And I know for certain that the drivers around me are not a hair smarter than elsewhere in the world. (To be honest, San Marino and the Marshall Islands have an even better score. But it’s hard to compete with a hill in Italy and some rocks in the Atlantic.)

The Dutch use no less than seven complementary approaches to achieve such a low death rate. The principles behind these methods could be used by agile managers who want to lower the fatality rates among their own projects:

• Culture: I’ve been told by a good friend of mine, an expert in traffic management, that the Dutch culture is one of the most important contributors to the (relative) safety on our roads. Dutch people care. About their car, their money, and other’s people’s lives. (And in that order, I think.) Translation: No matter what other methods you apply to achieve competence in a social system, in the end it all depends on whether people actually care.
• Instructors: In the Netherlands, you can only learn to drive with the help of an instructor. Putting a “learning” sign on the roof of your own car, or getting help from your dad, is simply not allowed. For at least 20 or 30 lessons you are instructed by someone who is driven around the city all day by pupils, and who asks big piles of cash for this privilege. (I would demand a similar amount of money if I had to watch the same scenery 40 times a week.) Translation: Teach people how to do their jobs properly. Again, and again, and again.
• Driver’s license: You must take a test and prove that you are capable of participating in (Dutch) traffic, or else you won’t be allowed to go out on the roads by yourself. Translation: Require that people are properly tested before allowing them to participate in (challenging) projects.
• Traffic signs: I think we are the country with the most traffic signs in the world. There’s not a square kilometer left that doesn’t have some neatly positioned signs, road markings, traffic lights, cameras, or other regulatory stuff on it. (And when it’s raining even our cows are aligned in the same direction.) Translation: Decrease the chance of problems in your teams by using smart and proactive tools, checklists, alerts, notifications, and other regulatory stuff.
• Traffic police: Yes, we all hate them. Me too. I paid many hundreds of Euros for speeding tickets last year. (I prefer calling it the “speed tax”.) Translation: Have a process manager walking around whose job it is to take samples of the results in your projects, and check whether quality output is being produced. And if not, well… you decide.
• Car horn: This is a favorite part of my car. Letting other people know that they are endangering either you or someone else is crucial in keeping the number of fatalities down to a minimum. Translation: Make sure your team members have the guts to tell each other how to improve their daily work. Let them honk their horns, or give each other a finger. Figuratively speaking, of course.
• Government: When everything else fails, the government will step in. They investigate what went wrong; they make new rules or constraints; and they decide who’s right and who’s wrong. Translation: Management will need to clean up the mess.

Smart, disciplined, and attentive people don’t need a driver’s license, or traffic signs. They don’t need to be taken off the road by the police, and others don’t need to scold them about their dangerous behavior. They simply do their jobs well. And that’s what most agile development methods assume. It is their blind spot. But the world isn’t perfect, and neither are most drivers, sorry, employees. Therefore management has to figure out how to address the blind spot, and how to drive safely.

This article is an adaptation from a text out of the book Management 3.0: Leading Agile Developers, Developing Agile Leaders by Jurgen Appelo. The book will be published by Addison-Wesley, in Mike Cohn’s Signature Series, and will be available in book stores near the end of 2010.

But, It Just Had to Get Done… Didn’t It!?

Written by Mike Cottmeyer Wednesday, 8 December 2010 02:56

Last week, I had an interesting conversation with one of the development teams I’m working with right now. A few weeks prior, we had gone through a story mapping and iteration planning exercise, and I was coming back to coach them through their first review and retrospective. The team had delivered a good amount of what they signed up for, but like many teams delivering their first sprint, they didn’t get everything done.

At one point during the retrospective, we learned that several team members had taken on additional work that wasn’t supposed to be part of the sprint. The work hadn’t been brought to the team, wasn’t written as a story card, wasn’t visible on the story board, and certainly wasn’t a shared commitment amongst all the team members. While we were discussing the impact the unplanned work had on the sprint, one of the team members said “but Mike, what did it matter? The work just had to get done.”

Interesting insight… the work just had to get done. I asked the question… what happened to the work we agreed HAD to get done during sprint planning? It didn’t get done, did it? What about all of this unplanned work, did it actually get done? Well come to find out, it didn’t get done either. As a matter of fact, our QA folks didn’t even know the new work was coming. So I challenged them, if the work HAD to get done, why didn’t you get it done? It didn’t get done because they ran out of time.

But you told me the work HAD to get done… why didn’t you do it?

The reality was that the work didn’t really have to get done… otherwise it probably would have gotten done. The reality was that the team either couldn’t say no, or didn’t know how to say no. Lot’s of companies are in a situation where the only SLA that’s meaningful is ‘right now’. The teams are so unpredictable, everything has to be done immediately… it is safer to say ‘yes’ (and not deliver) than to tell the business ‘no’. The irony is that the work doesn’t actually get done immediately… the team just has to agree they’ll try.

In the absence of a predictable delivery cadence… this is almost an unsolvable problem. If you are using Scrum or XP… that means that you have to have a stable velocity. If you are using Kanban… you have to establish a predictable cycle time. Unless you can reliably tell me when something will get done, everything is always going to have to be done now. Once the team has become predictable, you put the organization in a better position to respect your overall capacity.

Most people can wait a few weeks if they know you’ll actually deliver.

What Will I Get & When Will You Be Done?

Written by Mike Cottmeyer Monday, 6 December 2010 08:23

If you are thinking about designing an organization to deal with agility at scale, ask yourself this question… how will you know what the organization can deliver, and how will you know when they are going to be done?

If you can’t answer those questions… you’ll never be able to convince anyone to adopt agile.

If your answer involves gigantic release plans to sequence dependent teams months in advance… that’s kind of defeats the purpose. If your answer involves a big interdepartmental Gantt chart… I think you could make the case you’re not actually doing agile at all. If your answer has the words “trust me” anywhere in the answer… I don’t believe that’s a basis for a meaningful conversation.

So… think about what you are planning to do to drive agile adoption in your organization.

Ask yourself how are you’re going to tell the business what they are going to get and when are they going to get it. The challenge with driving agile in a real enterprise, with real business drivers, is answering these questions while preserving the business agility that the organization ultimately cares about.

Do you have an answer?