If Value is the Problem, What Can I Do About It?

Written by Mike Cottmeyer Friday, 18 December 2009 05:00

Wednesday I published a post called “Why is Agile so Hard to Sell?“. If you haven’t checked out the comment thread, you should really take a look. Most of the comments were really supportive and added serious value (no pun intended) to the conversation. One comment caught my attention, not because it was negative, because it said something to the effect of “nice problem statement, now tell us what to do about it”. After thinking about it, I wanted to elevate my response to more than a few lines in the blog comments.

One of the tough things about writing a blog is that you really only have 500-1000 words to make a point. Blog posts are better if they are short and get right down to business. For me, that often means that my posts don’t stand alone. Sometimes I get an idea in my head and I’ll noodle around on it for 5-10 separate articles. Often these will start off as an intentional series, sometimes they just end up that way.

As I look back over my writing the past few years, my content related posts tend to fall into one of two different categories.

Sometimes I am writing to help clarify a problem. Understanding that we have a problem is often half the battle. This last post on selling agile fell into that category. I am not convinced that on the whole, we all are on the same page regarding what value means and how to map team value to enterprise value. I see too many folks applying simple process to complex problems and doing some goofy stuff along the way. I am trying to figure out how to clearly communicate that something just isn’t right.

Sometimes I am writing to help clarify a solution. It’s not uncommon when I start out writing a series of posts, that I don’t know 100% where I am going. I may have a general idea where the solutions space lives, but I am thinking it through and exploring language around how to solve it. Sometimes I know exactly how I think a problem should be solved and I am using Leading Agile, and your feedback, to help me figure out how to communicate the idea. Ideas have to be simple and resonate with the community for them to be effective.

So to answer the commenter’s question directly… the solution to the value problem lies in how we go about our agile transformation. It lies in the scope of what we are able to impact. It lies in how we think about roles, and process, and artifacts… in how we give guidance to our teams and what we train them to do. It lies in project management and portfolio management. It lies in Lean, and Kanban, and Theory of Constraints. It lies in thinking less about keeping people and teams busy and more on getting products out the door. It lies in doing less instead of crowding out our highest priorities.

Many of my posts over the past year have dabbled in this space. The book that Dennis and I are writing is going to be all about applying what we know and directed right at the solution to this problem. The challenge is that the solution doesn’t fit into 500 words or less… not even 1000. We are hoping to fit it into around 140,000. We have the tools at our disposal to make this work. We have the knowledge of how to focus an organization on it’s highest priorities. We know how to make investments that are going to really matter. We can talk about incremental adoption and value based agile transformation and put together a roadmap for making this all happen.

So… you have several options:

1. Go back and re-read Leading Agile to see how we are thinking about this.
2. Wait for the book… where this will all be in one place… eventually.
3. Stay tuned to Leading Agile where we’ll continue to explore both the problem space and solution space around this value issue

And, just so you know… this is really what the folks at Pillar and I do for a living. If you are interested in having someone help you jumpstart this process… give me a call. I’d be happy to have a phone conversation with you, we could setup a Q&A or a webinar, or come onsite to talk about the issues you are struggling with. We can help you identify some very tactical next steps that will bring attention to this problem… and how we can work together to fix it.

My team and I have some availability over the next few months, so if you are interested in talking, let me know.

Why is Agile so Hard to Sell?

Written by Mike Cottmeyer Wednesday, 16 December 2009 09:41

What I find incredibly interesting is why defining value is so hard. Agile proponents have been beating the value drum since the very beginning. Put the customer in the room… understand their needs… build what ever they want… deliver software in small increments… get constant feedback… converge on the optimal solution… deliver value early and often. Agile is all about delivering value. Why wouldn’t a management team embrace a set of methodologies so focused on giving them what they need the most?

Here is my take…

Agile is (in large part) a reaction to misapplied waterfall development and naive application of project management principles in ways that are inconsistent with how software actually gets built. It was is a reaction to dehumanizing, process and artifact driven management approaches… processes that assumed with enough procedures, we could somehow commoditize the practice of software engineering. We wanted to take the uncertainty out of a craft that is really a blend of engineering and art. Our desire was to make everything predictable and repeatable.

We were trying to treat people like machines that could be infinitely sliced across tasks, tasks that with the right level of process and planning, with the right level of project management and oversight, would somehow magically roll up into working software that our customers would want to buy. Guys like Jefferies, Cockburn, Schwaber, and Sutherland were beginning to realize that successful projects were really the result of high-performing, committed individuals, working together in small teams, all directed toward shared outcomes.

XP, Crystal, and Scrum were born through the realization that these small empowered teams delivered the best outcomes and were the most successful over time. As these agile approaches were beginning to emerge, they all shared this disposition toward small teams, close customer interaction, and frequent delivery of value. The funny thing is that if you talk with most folks working for small companies… this is kind of what they do naturally. Folks are not assigned to a single role… you have a team of high-performing individuals working together for the sake of their collective survival. Big companies seem to have messed this up… but I digress.

Fast forward 10 or 15 years…

Now we have pockets of agile within large organizations… sometimes we might even have agile across entire large enterprises. We are exploring agile methods and trying to see if they can deliver on the small team promise… but in the large. The main difference with these larger organizations is that value isn’t the same as it is in a small team or a small company. There is not a direct correlation between team performance and business outcomes… there is not a direct connection between what the team delivers and what we can sell to our customers. It takes the output of too many small teams coming together to deliver anything of value.

Agile methodologies have typically treated the team like a black box. We give them a prioritized product backlog as an input and we get valuable working software as an output. But now… we have to coordinate the output of several teams… maybe even dozens of teams… into some sort of coordinated deliverable. We are having to deal with getting tens or hundreds of people working together in a coordinated fashion. When that is our context… the message of teamwork and collaboration… close relationships between the team and the customer doesn’t resonate. The only way many of these organizations can get any sense of comfort… any sense they that they are responsibly managing their part of the business… is to ask their teams to commit to the big up front plan

As an organization, we know that we need to deliver value as fast as possible. We know that we need to be able to respond to change. We know that we need to deliver with more predictability and with higher quality. We have an intuitive sense that what we are doing isn’t working. We want to get benefits that agile talks about. We suspect that something like Scrum or XP can help… but we can’t figure out how to apply the small team concepts to our particular business problems. That’s why you get the classic “agile will never work here ” comments. There is an inherent disconnect between the team level guidance agile methodologies talk about and the bigger concerns your senior executives are struggling with.

There is a gap between value at the team level and value at the enterprise level.

At the end of the day, our community needs to develop guidance that helps our executives get the benefits of agile but focuses on real, enterprise class value delivery… value defined in terms of real results and real business outcomes. So, why is agile a tough sell? We are asking our leaders to trust a process that focuses on team based outcomes but doesn’t give them a credible way to articulate how the development organization is going to deliver on the more complex objectives of the business.

Mike Live at Oredev 2009

Written by Mike Cottmeyer Wednesday, 9 December 2009 11:44

I happened to stumble on this video of me doing one of my talks at the Oredev 2009 conference. I knew the Oredev crew had recorded the session, but I was not aware the video had been posted. This particular talk was a one-off for the Oredev conference based on a coaching gig that I did earlier in the year. We explore some of my common themes around product owners and product owner teams and some of the processes we needed to have in place that Scrum doesn’t particularly address. The video is long, but check it out and let me know what you think.

Here is a link to the video. Vimeo won’t let me embed it on this site.

Who Cares About Value?

Written by Mike Cottmeyer Monday, 7 December 2009 01:59

Part of our problem discussing value is that value is a pretty elusive concept. What is valuable to me might not be valuable to you. It is easy to blur the line between what might be considered a valuable contribution and something that actually adds value to some desirable business outcome. Value can be created at many levels within the organization. You have to ask if the value you are creating can be easily translated into something meaningful to the business stakeholders. In other words, can we get the value you are creating within the organization, out of the organization?

Think about this… if you are an internal IT organization, your customers are your internal business stakeholders. The hardware and software solutions you build are enabling business processes that are valuable to the operations of your company. The value created is in the well-executed business process… not the hardware or the software you built. At the end of the day… the well-executed business process is the ultimate value proposition.

If you are a product delivery organization, your customers are the people that buy your software. Your software is only valuable to them to the extent that it enables their business processes. Value for the product delivery organization lies in its ability to build the right product, with sufficient quality, and getting it in the hands of paying customers faster than its competition. Value for the product company is derived from your customer’s willingness to pay for a product that helps them create value within their organizations. Your value proposition is not identical to that of your customer… and at the end of the day… you are one degree removed from where real value is created.

Let’s say for a moment that you are a product manager for that product delivery organization. Your goal is to get software out the door that you think your customers will use. Value is created when you define the right features and are able to engage the organization to get the features implemented into the software solution. Sure, those features have to sell, but the focus is on getting them built into the solution. Delivered end-to-end features equals value into the product. Here your value equation is two degrees removed from the real creation of value. Your software feature has to be sold to a customer and then used to actually enable the right business outcome.

What if you are a product owner working with a single team within a multi-team product delivery organization? Your customer might be that product manager trying to get an end-to-end feature out the door. Your job is to add a new feature into some major sub-component in a large systems architecture. You own that product, but it actually takes several products working in unison to deliver an actual slice of working software across the overall enterprise systems architecture. You are providing services back to the larger enterprise class system. Value to you is created when that service feature is delivered back to the project and you are now three degrees removed from the business enabling value proposition. Your service has to be integrated into the product feature, which then has to be sold, which then can be used to enable a business process.

Let’s keep going… consider for a moment that you are a technical team lead. Your customer is the product owner that defined your backlog and is trying to get enterprise services out to the Product Management team to deliver on the project outcome. Value to you is defined as some increment of working software (a user story) that enables some given transaction within the system to execute. Maybe we are accepting a data value through a system interface, transforming the data based on other system inputs, writing that transaction to the database, and giving the user feedback the operation completed successfully. Here you are four degrees removed from the business value equation. Your user story has to be combined with other user stories to enable the component feature, component features that have to be integrated into a larger value feature, sold to a customer, and then used to enable some desirable business outcome.

What if I am a developer on that team? My customer is my product owner, but it is also my team. My definition of value might be a unit-tested increment of code. If I am a tester on that team, my definition of value might be a passed test case. If I am a technical writer, my definition of value might be updated system documentation or tech manual. At this point, I am at least five degrees removed from actual business value. My work has to be integrated into the user story, which has to be integrated with other user stories at the component level, components which have to be integrated at the value feature level, which have to be sold, which have to then be used to enable our customers business processes.

So… no wonder that value is so difficult to talk about. Value is not only domain sensitive, it is context sensitive… it is role sensitive. It is sensitive to where you live in the overall development lifecycle. We have to either drastically reduce the number of hops between developer activity and the actual real business enabling value proposition OR we have to learn how to align all this lower level activity to support business outcomes that might be up to five degrees removed from the people doing the work. So next time you tell someone that agile focuses on business value… at what level of business value and how many degrees removed are you from what your customer actually cares about?

I think we have trouble selling agile because we are not talking about value at the same level our customers care about value.

Interesting Post… 11/30/2009 through 12/6/2009

Written by Mike Cottmeyer Monday, 7 December 2009 01:14

Hey… it’s been a few weeks since an installment of Interesting Post update. I have to apologize for not being consistent with these, but I hate doing these summary posts when I’m not generating other new content… it feels kinda like cheating