Agile Coach Camp 2011 #accus

Written by Mike Cottmeyer Friday, 23 September 2011 12:17

I’m heading to the airport in a few hours to attend the annual US Agile Coaches Camp.  The first camp was held up in Ann Arbor back in my VersionOne days.  I can remember Paul Culling asking me if I was interested in going.  I had never been to an Open Space conference, and to be honest, it sounded like a train wreck.  Needless to say, I was wrong, and the weekend proved to be a great experience… and looking back… a pretty pivotal moment in my agile coaching career.  I’m very excited to rekindle some great friendships, and learn from some fantastic people and very experienced coaches.

I’ll see you guys in a few hours!  Save me a seat at the bar!

Lightweight Documentation… Not Lightweight Thinking

Written by Mike Cottmeyer Thursday, 22 September 2011 06:00

Working software over comprehensive documentation… this line in the manifesto has been used to justify all manner of undisciplined thinking over the years. Just because we value working software over comprehensive documentation, doesn’t mean we don’t ever write anything down… and it especially doesn’t mean that we don’t think through problems. It doesn’t mean that we don’t do the discovery, analysis, and design that often was captured in all that comprehensive documentation.

The problem with comprehensive documentation is that it is a poor communication tool for helping developers understand the needs of the customer. It’s a poor communication tool for explaining to a team of developers how to build a product. It’s a poor predictor of what the product will even do when it is done. Documentation is essentially a transient artifact, intended to keep a record of decisions and communicate intent.  Far too often it’s used as a primary measure of progress… especially in the absence of incremental delivery of working software.

In more traditional environments, people are tasked to create some sort of a requirements document, or maybe a design document or a project charter. Somewhere along the way, many folks start to think that the mere presence of the artifact is all that’s required to build software. The document becomes an end unto itself. It’s not the document that’s important… it’s the shared understanding that came out of creating the document that’s important. The document is simply an artifact representing that shared understanding.

Six or seven years ago I was mentoring a junior Project Manager that was struggling to create a project charter. I sat down with him and started asking him who he had met with, what was his understanding of the goals and objectives of the project, and what he knew about the assumptions, risks, budget, and expectations surrounding the project. His response? I haven’t met with anyone… my job is to write this charter. He somehow had come to the conclusion that the mere presence of a charter was the end goal.

Yes, his job was to write the charter… but ONLY after he facilitated the discussion that generated the shared understanding that was to be written in that charter.

Many folks new to agile feel like they no longer have permission to write stuff down. I encourage them to write down whatever they need to write down, but not to think of the document as the deliverable, think of the document as a record of an agreement that we want to track. Maybe a tool for thinking through a problem.  If you want to use a template or a form to help yourself think through all the things you may want to consider while decomposing the problem… that’s fine. Use documentation as a record of what has been created, rather than a prediction of what should be created.

At the end of the day, documentation does not reduce risk or validate assumptions, and no amount of documentation is a measure of progress on our project. But just because we do lightweight documentation doesn’t mean lightweight thinking… we just want to do the simplest thing necessary to facilitate shared understanding of the emerging product we are trying to build. Shared understanding of the problem, and agreement on how to proceed, is what we are going for. Documentation is never a goal unto itself.

That is why we value working software over comprehensive documentation.

Who Owns the Risk?

Written by Mike Cottmeyer Tuesday, 20 September 2011 10:30

Back in my late 20′s I was a project manager in a pretty good sized IT shop. I worked under a great VP that put me in situations that were really beyond my abilities.  He fundamentally believed that I’d do a good job for him. He trusted that I’d learn what I needed to learn and use good judgement about when to ask for help. There was a point in my career where everything interesting on my resume was a direct result of some project this guy had me lead.

One of those projects was a pretty significant identity and access management initiative where we were building out a corporate LDAP infrastructure. The goal was to establish an integrated authentication engine so clients could basically sign-on to any of our web properties with a single login ID and password. Our company didn’t have any expertise in this area, so I ended up with about a quarter of a million dollars to spend to bring in some consulting expertise.

We ended up bringing in a large, well known consulting firm to help… they were really, really good but as you might expect, very expensive. I decided to negotiate a fixed scope, fixed price contract under the assumption that it would mitigate my risk. My goal was to shift all the delivery risk to the consulting firm so that I would be assured of delivering my project on time and and on budget. Had we had perfect knowledge of what was required, that might have been a good strategy.

As you might have guessed, these guys knew way more about contracts, and way more about delivering LDAP solutions than I did. I imagine they anticipated we would need services not specified in the contract, but they also knew I had a not-to-exceed budget, and I’m sure they wanted the business. When the inevitable happened, and we realized that we needed services not specified in the original agreement, they created a change request document… actually several of them… and I had to go round up additional funding if I wanted the additional work.

While I was unsuccessfully trying to mitigate my risk with a fixed price, fixed scope, fixed time contract; they were successfully mitigating their risk by aggressive contract management and holding me accountable for everything that wasn’t explicitly called out in our original agreement. At the end of the day, who really absorbed the risk? It was me and my company, I just didn’t know it at the time because I was certain that I had asked for everything I needed up front. It wasn’t until we started building the solution that I realized I was wrong.

Now… let’s tie this back to my previous post on estimating.

When customers ask you for an estimate, they are most likely, either directly or indirectly, trying to shift the delivery risk onto the development team. They want to tell you everything they want, or at least what they think they want now, have the development team tell them what it will take to deliver it… and provided they can meet your time and cost demands… make development 100% responsible for delivery. Since we know that the customer doesn’t know everything they need up front, we aggressively manage scope to protect ourselves from the risk.

Based on the feedback on my estimating post… we all seem to agree that estimates are generally poor indicators of what it will take to actually deliver the product.  We all agree there is a pretty good chance any estimate we provide will be misused by management. We know that making commitments based on bad estimates leads to an unacceptable level of risk for the development team. In response, we suggest that we shouldn’t even attempt to estimate. If we go this route, we are basically asking our customers to assume all the risk associated with the delivery.  We are asking for unlimited time and money and maybe the customer will get what they need.

We assume that as long as the developers ‘do the best they can do, and deliver as much value as possible’ the customer should just take a chance they’ll get what they need, but if they don’t… and quite often thats their reality, they are left with no options because all the time and money ran out. Just because the development team delivered the highest-value-potentially-shippable-product-as-possible… doesn’t mean that your customer has something they can sell to get a reasonable return on their investment. Aside from the fact this conversation is a non-starter with most business leaders I work with… it doesn’t feel like a very good way to run a business.

To me the answers lies not in the either-or proposition of fixed scope, time, and cost… or alternatively establishing no estimates and making no commitments. Both put all the risk on the other party, shifting risk fully to one side or the other. To me, the answer lies in creating a culture of shared risk between the customer and the team. Both sides have to have skin in the game. Both sides have to realize the constraints the other is operating under. Both sides have to realized that estimates are just that… estimates.  Both sides need to be partners in the delivery process.

The estimating process establishes the shared understanding we just talked about and the numbers we come up with give us a planning baseline to measure the progress we are making (or aren’t making).  The development team estimates, but customers realize that estimates have to be managed, assumptions have to be validated, issues have to be dealt with, risks have to be mitigated, and yes… sometimes requirements have to be descoped, or dates have to change, or costs have to go up.  In an environment of shared understanding, shared accountability, and shared risk; everyone is on the hook for managing the delivery process.

Sharing risk means that we trust in the other’s abilities and intentions, we deal with reality when it doesn’t meet with our preconceived notions about what should be… or should be possible. This is not currently the default place in most organizations… our default place seems to be to shift as much risk as possible to our counterparts in the other parts of the business. Creating a culture of shared risk, and having the tools in place to manage that risk, is really the key to make all this stuff work. Insisting someone else assume all the risk doesn’t encourage the behavior we want or need between people that need to operate as partners.

If we don’t estimate, we don’t have any way to know how far we’ve come and how far we’ve got left to go.  It’s that simple to me… I suspect some of you guys out there might disagree.  Looking forward to the conversation.

The Real Reason We Estimate

Written by Mike Cottmeyer Sunday, 18 September 2011 07:06

Over the past few months, various blog posts have popped up talking about estimation, how estimation is unnecessary, how estimation is waste… and that maybe we should stop estimating entirely and just get down to the business of writing software. If our estimates are always wrong, and most of the time they are, why should we even attempt estimating in the first place?

Agilists eschew absolute estimates in favor of relative estimates, and absolute values to estimates made in more abstract units like story points. Story points are measured in non-linear sequences like Fibonacci to further abstract their value from any notion of absolute time. As a result, agile estimates are only relevant in the context of a stable team with a known measured velocity.

Many teams aren’t any better with agile estimating than they are with traditional estimating and I think this is what leads many folks to reject the notion of estimating entirely. If agile estimating doesn’t work any better than traditional, why bother estimating at all? Personally, I’m a big fan of estimating and teach it to all the teams I work with. Estimating can work… but only if you understand why you are doing it.

You see… estimating isn’t about estimating at all. Estimating is about creating a shared understanding of the requirements, and a shared understanding of the solution. When teams have problems estimating, its almost never an estimating problem, it’s a shared understanding problem. If you can get to the bottom of your shared understanding problem, you will fix your estimation problem.

Shared understanding problems can result from any number of organizational dysfunction’s. Some of the most common are on the product side… insufficient business involvement, insufficient understanding of the business problem, and insufficient requirements decomposition tend to result in sprint planning meetings that are too long and not detailed enough.

When there there is too much of the wrong kind of discovery going on during sprint planning… teams will get tired and frustrated and end up committing to the sprint deliverables without sufficient understanding of what they are going to build or how they are going to build it. They’ve estimated and discussed, but they’ve never gone deep into the details. This always results in too much discovery going on during the sprint, too much unanticipated work, and too many missed deliverables.

The other big shared understanding problem comes from technical debt… poor architecture, quality problems, or even just teams that are unfamiliar with the code base, all result in making commitments without a clear understanding of what work actually needs to be done. When you couple a general lack of understanding about the requirements, with a general lack of understanding about the code, it’s no wonder people are frustrated with estimating.

Giving up estimating is basically giving up being able to give the business any idea of what they are going to get or when they are going to get it… even at a high level. My take is that we can’t give up estimating, we need to get better at estimating, but that means that we need to get better at creating shared understanding. It’s my opinion that creating shared understanding is the main reason we estimate.

It’s not so much the number that matters… it’s the shared understanding matters. If we are estimating without creating shared understanding, we are missing out on the value, and the estimates will always be poor. If our estimation process increases the level of shared understanding, our estimates won’t necessarily be right, but they should be consistent… and consistency is all we need especially for establishing a stable velocity.

So… if we want better estimates, or at least more consistent estimates… our goal isn’t better estimating, it’s more shared understanding. The question now becomes… how do we create more shared understanding?

On a Personal Note…

Written by Mike Cottmeyer Saturday, 17 September 2011 02:00

For all intents and purposes LeadingAgile ‘the blog’ has been on hold while I’ve focused all my time on LeadingAgile ‘the company’. I knew all this was coming, but sometimes you just don’t have a sense of what it’s really going to be like until you start doing it. Launching LeadingAgile was like taking on three full time jobs. Between working with clients, trying to find new clients, and handling the finance, accounting, and legal stuff… it has been a busy year.

Early on it was fun and exciting, but also really stressful and time consuming. Looking back, I was pretty out of balance, but not in a totally unhealthy way. Covey talks about good stress and bad stress, and I think my work fell into the good stress category. I was fortunate to have enough work so finances weren’t an issue… but my schedule was non-stop trying to balance all the stuff competing for my time.

LeadingAgile passed the one year mark last month and the future is looking pretty bright. I’m in a great place right now, both personally and professionally. I’ve finally been able to get my diet under control and managed to drop 35 lbs. I’ve been able to prioritize getting into the gym a few times a week and overall feel pretty healthy. I’m finally comfortable having a day or so off every now and again, and don’t feel like I’ve got to sell every moment of my time.

With regard to blogging, there have been times over the past two years that I just didn’t have anything I really wanted to write about… or if I wanted to write about something, it wasn’t a topic good for LeadingAgile. This blog isn’t really about trying to spin up a consulting company or my struggles developing and managing an active sales pipeline… but for the most part, that’s what I was learning about and what was present of mind.

Over the past few months though, that has started to turn. I’m finding that my desire to write about agile related topics is on the rise. It’s kinda sad though… while I want to start writing again, things are so incredibly busy, it’s hard to find time to write. When I have time to write, it is hard to find the energy to write. When I’ve got the energy to write, sometimes I just don’t want to write. The good news is that I’m keeping a list

Anyway… I’m hopeful that over the next few months I’m able to get back into the groove of writing, not only here, but also on the book. There is a big part of me that misses the process of writing, and the engagement with you guys that comes from actively contributing to the community. Writing has been a very powerful tool to help me organize my thoughts over the past few years. Hopefully, I’ll muster up some self-discipline and get back into it.