Balancing Perfection against Innovation

Jeffrey Phillips from Thinking Faster is struggling with finding the balance between the desire to have perfection with products against the desire (sometimes by the same people) to provide innovative products. His post, "Trading off perfection and innovation" shows us a comparison of the two. Here's just part of his thinking on this (read more of his post to get everything):

One one hand, we have the constant demand for perfection. Six Sigma, Lean, eliminating mistakes and errors to create an incredible, consistent, useful product or service. On the other hand, the need to innovate, to create something new and take new risks to dramatically change a product or market. Both approaches are correct, and relatively mutually exclusive. What does a manager do?

When choosing perfection, we make a series of assumptions about the product or service, its competitors and our ability to keep up with the market. Once a product or service is perfected - it it every really is - even a small change to the process or product can cause major disruptions for a customer, so we prolong the life of any product or process and minimize changes to achieve perfection. If you can dominate your market, or if perfection is important to your customer, then this is a great strategy. However, it assumes that there will be little or no disruption in the market, and that the customer demands perfection over innovation and new capabilities.

When you choose innovation, on the other hand, you will not be able to provide a perfect product or service. If your innovations are truly new, you can't determine in advance exactly what "perfection" is - you can only try to provide what you think customers will value and iterate from that point once you discover and uncover real wants and needs. This approach assumes that customers don't demand perfection, but do demand interesting, innovative products and services that solve unspoken or unmet needs. After all, if you can solve a problem that I have even fairly well that has never been solved before, I won't ask for perfection yet.

The real crux of the matter is that if your position is perfection, then you can't afford to make mistakes, and if you do, you need to quickly and completely correct them. On the other hand (aren't you glad we only have two hands) if your position is innovative, you can't afford not to make mistakes, and you want your customers to participate in and help you learn from your mistakes - you can't learn if you don't make mistakes.

In the end, you have to give up some level of perfection if you want something innovative. Because the very definition of innovative is doing something that hasn't been done before (or at least not that often). You also have to be able to take on risks and make mistakes as part of the experimentation that comes with innovation. I have to agree with him. Too many times, I have seen people take the "tried and true" approach to a solution just to ensure they don't cause inefficiencies in hitting dates. Even though they would agree there is a possible better solution, they aren't willing to pay the price to get there. I like Jeffrey's thinking here, your customers need to understand the tradeoffs. The only way for them to do that is to be more part of the process. For companies that can figure out how to do this, those will be the ones who provide innovative products that their customers believe is more than "good enough".

Commitment, Delivery and Customer Expectations

Since we have been on the road of adopting Agile and Lean in our organization, I have had increasing pressure from stakeholders to give them an idea of when we will deliver functionality beyond the current release. Our releases are currently around 4-6 months at this point, so they are asking for things that will be delivered towards the end of the year and into next year. One stakeholder wanted to go out even further than that (up to 24 months in advance)!

At first, I thought that they just wanted to get an idea internally by developing a high-level product road-map to help us with our priorities. However, my thoughts were that this road-map wasn't going to focus on dates. Why? Because that information would not have any sense of reality. This information is at best high-level and with that not enough knowledge and information to make a better prediction of what could be delivered. That better prediction won't happen until we do release planning for the release that we are considering the future functionality. Even with that said, we really won't be able to commit to dates until we get really into the details of the work during iteration planning.

So, there are really three levels of precision: "fine grain" in the current iteration (90% or greater chance of stories in the iteration getting done), "coarse grain" in the current release (60% or greater chance of stories in the release getting done - this number could go down if our releases were even shorter), then "swags" in future releases (40% or less of a chance of stories getting done in the expected time period - this number going down the further out you go). These aren't exact numbers but you get the idea.

What really worried me is that they wanted these long-term dates so they could make commitments to key customers on when future functionality would be delivered. When I discussed my concerns with the stakeholders and talked about the various levels of precision, they believed we could actually get better at our precision if we just planned a little more. However, that would become waste in Lean terms because we would have a lot of work (inventory) "in-progress", plus what we know now about something that will be started six or more months in the future WILL change once we get there. Even with all of that said, my greater concern was making commitments to customers before we can make commitments with the development teams that they can deliver. It should be the other way around in my opinion. Let's figure out what we can commit to and deliver, then start setting expectations to customers.

One of our vendors lives by this philosophy. If we ask for an enhancement, if it isn't something they are committing to for the next release, they will give the answer "we'll put this in our backlog of priorities and consider this for a future release". Then, they will focus my attention of things of value that are coming in the next release and get my feedback on them. Even if my particular request isn't there, I find great value in what is about to be delivered. Sure, there may be some features I don't plan on using or care about but there are usually features that I care very much about. As a customer, this vendor is setting my expectation based on what they know they can deliver, then based on what they hope they can deliver. Hopes don't cut it! If they had promised me a future date, and then miss that date I would have been much more frustrated as a customer. I would rather not know until they were really confident they could hit that date. I appreciate that this vendor has delivered what they promised and has built a reputation with me that they are making constant improvements to their product. Even if those improvements aren't everything that I have asked for!

This is just one of the bad habits we need to break by moving to Traditional development over to Agile. It wasn't that we were better at providing estimates and hitting dates using Traditional development, because we weren't (especially for features out several releases). Sure, we could try to hit those arbitrary dates by cutting scope, freezing scope changes, adding people, working overtime, cutting corners on quality, and other "tricks of the trade". However, would we really provide what the customer really wants? Isn't the goal of Agile to provide what the customer finds value, even if the cost of that value is sometimes difficult to determine? If the quality isn't there, they don't want it early. If the functionality doesn't really do what they expected, they don't want it early. Why this importance of hitting dates because of commitment to customers, when in the end the customers will be disappointed because what they got in return missed their expectations? Let's commit to dates first as a development team and "internal" customers, then set expectations to our "external" customers as we deliver what is important to them.

I believe we got into this dilemma because we developed a reputation of over-promising and under-delivering (because of the problems with Traditional development). Plus, what we would deliver (usually 8-12 months) didn't really cut it with the customer and left them disappointed and frustrated with how long things take. Therefore, their lack of trust in hitting dates causes them to even push harder for us to commit to completing functionality that is long overdue. We need to build trust again with our customers by delivering high-value and high-quality features more frequently in order to gain back a reputation of under-promising and over-delivering. This will take time, but in the interim we need to change the way we have set future expectations with our customers. This may cause some short-term frustration, but will quickly change as customers will change their focus as well on what is being delivered then what is promised to be delivered. After all, isn't that what really counts?

Transparency is the key

Recently, we did a retrospective at the end of one of our iterations. As part of this process, we show a working demo of functionality that has been completed as part of that iteration. Usually, this goes pretty well but this one didn't end up as well.

During the demo, things started out smoothly. We demonstrated the functionality and everybody was pleased with the results. It was the conversation that happened afterwards where things went downhill.

Those that were representing the customer wanted to know about some functionality that had been talked about but hadn't been completed yet. The Developers assumed that the Customers were accusing the team of not delivering something yet. They got on the defensive quickly saying such things as "That functionality wasn't part of the scope of the project" and "I wasn't tasked with that work so I know nothing about those requirements" and "I don't remember those conversations" and "I thought it was part of a future project". What's was interesting is that none of these conversations were really true, but they were used as a defense mechanism. Once these things were uttered, the Customers also became defensive. "What else have you forgotten?" "Have you even thought about these things?" "Will the current solution accomodate this new functionality that is added later?" "When are these requirements being considered, if at all?"

After we ended the meeting, I met with the Project Manager/Scrum Master who had also attended the meeting to recap. She was as surprised as me to the statements that were made and was a little upset that the Developers had acted that way. I went to talk to the Customers and she went to talk to the Developers. Here's what we learned...

The Developers knew the right answers but felt they were been questioned for things that they weren't focusing on at the moment. So, they tried to do a little CYA for their lack of knowledge with the questions. Instead, they could have easier said to the Customers, "Though we have talked about that functionality, we haven't really focused on it because the functionality that you saw today needed to be completed first (because it was core and highest value). The Scrum Master could have talked about when those discussions would happen. In my talking with Customers, they knew what was being shown and understood the team was to deliver what they saw but just wanted to know how much thought had been given to the design and implementation so far to the next functionality that is being considered. It was an honest question that should have had an honest question. Instead, the Developers interpreted the question as blame for not having more to show in the demo.

I realized that there is still much work to be done to encourage transparency between Customers and Developers. It is ok to discuss roadblocks and issues between groups as they happen. Bad news shouldn't be hidden. It is ok to discuss that there are things that haven't received the focus on the team yet. It is ok to discuss changes and new ideas that weren't part of the original conversations. We should encourage feedback (good or bad). We should encourage honesty in where we are at. If this is done, it will establish better trust and respect between these groups and a healthy relationship will grow. Perhaps we are dealing with years in which Customers and Developers didn't spend much time together and the relationship was strained and distant as the result. When they got together, it was more like contract negotiation across the table than a partnership with much collaboration.

In the end, I was glad to see that this happened and know how to coach others in better communication in the future. Retrospectives are to be a checkpoint on where you are at in the delivery of work. Not just a checkpoint on what you deliver but also how you deliver it. The process is just as important as the deliverables. Both need feedback and constant improvement based on each "checkpoint". This is one of the key benefits of Agile -- to embrace changes based on constant feedback towards providing better customer and business value. How you work with others is a big part of that.

What Value should be

A common theme that you will see throughout Agile and Lean is this concept of customer value. The order that you do the work should reflect the highest value to the customer. This really isn't a new idea, I have known over the last 20 years that I need to produce something that the customer wants. However, the problem is that even though I knew that was the right thing to do, I didn't always think about my work in the shoes of the customer. As a developer, I remember thinking that if I put this cool new function in using some cool new technology that the customer would love it. I mean why wouldn't they, I thought. But many times I found that by not checking with the customer I wasted time implementing something they didn't really want or ask for. This resulted in either rework or leaving in functionality that was never or rarely used. Neither of those scenarios are good, because I could be spending my time on things that the customer really wants. If only I had asked them (or somebody that represented them)...

So, with Agile and Lean, this is one of the "prime directives" - to make sure that what you are doing has value to the customer. This is a good thing, a REALLY good thing. You need to have a customer representative always available to the team. Not just when they determine requirements, but through the whole process - design, testing, and especially demos of the working software as it is being developed iteratively. It's all about feedback and checkpoints along the way that you aren't wasting your time. In the end, it translates to functionality the customer will use more often. This translates obviously to happy customers, which translates to good word of mouth, which translates to more customers...well, you see the point.

But since we have adopted Agile (and looking at Lean), there has been a little problem with this. You see, we have over 2500 customers that are using our products. While it is good to know what they want in the product, EVERY customer may have different ideas of what is important to them. So, isn't this customer value? Shouldn't we be doing the things that matter to them? Of course, but there are too many things coming through the pipeline and it's difficult to know which customer request is more important than others. So, what have we done? We prioritize by the size of our customers. After all, they represent a larger percentage of our customer base right? While that's true, it doesn't give the little guy much of a chance to offer good ideas. And, those ideas might be the best thing for all other customers.

So, while sitting in the Lean class this week I realized that we are focusing on only a small part of value - Customers. What we need to focus on is Business Value. What is Business Value? Well, customer value is definitely part of the equation but it also looks at what is good for the overall business. Does this request support the majority of our customers? Does it support our long-term goals? Do we have the capacity (people, skills) to fulfill the request? Does it fit our business model? Does it align with where we are taking our products? Is it something that our company should do? I believe that if we ask those questions we will have a much better idea of how to prioritize requests as well as know which requests we should take on. How do we measure that? Return on Investment (ROI)!