Ken Schwaber: Sacrificing Quality should be an Executive Management Decision

At Agile2006, Co-founder of the Scrum methodology Ken Schwaber argued that as professionals we should not accept business requests to sacrifice quality in order to meet timelines, and if quality does need to be sacrificed such a decision should be made by executive management and reflected in the financial statements of the company.

Ken advised: 1. Having a ScrumMaster ..

Cameron, I mostly agree with you. But, I know there are situations where very late in the project, the dev team is just finding out about a complete new set of functionality that somebody has promised to the client. At this moment, there are two possibilities: either extend the time/budget (extending the budget is not always a winner, as the late resources brought into the project are not gonna be productive right away) or deliver with less functionality. However, if things are working as per hypothesis (and I saw it for a few times), than the dev team can expect to be asked to finish all functionality (including the new one) in the initial timeframe. Now, how do we call this? ;-]

./alex
--
.w( the_mindstorm )p.

Cameron ... excellent reply - perfect!

Cameron, well-said. This type of logic comes back to an ever-growing problem in business: lack of ownership. Instead of pissing and moaning, take ownership and lead the team in the right direction. Passing the buck up the chain does not help the team and it does not help the company. I agree that quality is very important but it is the responsibility of the software development team (which I am a part of) to deliver quality.

Bryan

Hey Cameron, I think you're latching on to a very specific aspect of Ken's message, which is fine, but...

The over all take away which I thought was very positive was that companies should treat their software as strategic assets and quality of their software should be quantifiable and considered with great importance.

If quality is cut then that represents a loss in value which (as quoted in the news item) will require at least the same amount of money to correct later (and we're talking about important, long lived core infrastructure here, not one off projects). This isn't typical thinking among business stakeholders driving timelines, but if we can bring this thinking into the enterprise it will be good for companies and good for us technologists.

Keep in mind also that the target audience of the session (and indeed the Agile queue on InfoQ) is project managers and they are the ones who would benefit from having this sort of ammunition to deal with the product managers unreasonable requests.

I know there are situations where very late in the project, the dev team is just finding out about a complete new set of functionality that somebody has promised to the client. At this moment, there are two possibilities: either extend the time/budget (extending the budget is not always a winner, as the late resources brought into the project are not gonna be productive right away) or deliver with less functionality. However, if things are working as per hypothesis (and I saw it for a few times), than the dev team can expect to be asked to finish all functionality (including the new one) in the initial timeframe. Now, how do we call this?

.. companies should treat their software as strategic assets and quality of their software should be quantifiable and considered with great importance.

I call it "impossible" ;-)

Sometimes you're lucky enough to squeak by and deliver the impossible, but most of the time the project is both late and over budget.

The problem 99% of the time (for me, at any rate) is that even if the requirements and the extent of the functionality are fixed goals, I still have found it incredibly difficult to deliver on time and on budget.

Add new requirements or functionality to the mix, and you're almost certainly screwed!

But you can't rewrite the upcoming quarterly report to whine about engineering trade-offs on a particular project, unless (maybe) you are Microsoft and the product is either Windows or Office.

Not too happy with this thread so far, because I think what Ken Schwaber really meant is being misunderstood. If, for example, I thought all the posters had actually heard the talk, then I would think the real issue here is something very different.

But, let's pursue things as they are now...

Fair notice: I did not hear this talk by Schwaber, but I have heard Ken talk in a very similar way several times, so I will try to pull that info in, perhaps inappropriately.

First, I think the main issue is quality, and that it should not be sacrificed. Then, Ken says something about reflecting reductions in quality on a company's financial statements. As we (and Ken) know, putting the capital investment in software (or systems generally) on the asset statement would only apply if that asset were "material" (enough bucks relatively) to that company. As it happens, that is true for banks, for example, as I understand. Next, would a reduction in quality be material? Well, of course, it would depend on how large a reduction in quality.

The financial statements thing is mainly rhetorical...what is key is that reducing quality in software is really a "business" decision. In fact, this is true no matter what kind of business you are in. This is consistent with the notion that the software is being built for a real business purpose (eg, inc rev, reduce cost, improve customer satisfaction, etc.). Thus, reducing the quality has, potentially, rather serious business implications (in comparison to the business value of the project).

Lastly, Ken is trying to convey the notion that in Agile (Scrum) the focus is, like the Toyota Production System, on building quality in from the very beginning. And, as increasing evidence shows, you can acually deliver value faster if all the bugs are resolved "immediately", rather than waiting to be found and fixed toward the end of the project.

Does this make sense to posters?

It is impossible to go fast if let quality suffer. If as a team you are tasked with delivering software by a fixed date, then your best bet is to strive for zero defects. Every defect introduced and un-fixed slows the team down. Lean and queuing theory prove (both deductively and by simulation) that leaving defects in a process slows the process down. In the courses and consulting work that I do, I always recommend "stopping the line" if a defect is found. Why do I do this? Because of my direct hands-on technical experience. This is not theoretical for me. It is a passion based on experience both good and bad with quality problems in software I have built. If I am managing an agile project, I do not let the team work on any new functionality if there are known unresolved defects. If a customer/stakeholder wants to proceed with functionality instead of defect resolution, then it is bumped up to the executive level.

The over all take away which I thought was very positive was that companies should treat their software as strategic assets and quality of their software should be quantifiable and considered with great importance.

Not to disagree, but this only applies to a very limited number of IT assets. Companies don't consider their pot-plants to be strategic and so it is with the majority of software projects which are just there doing a job within a department. So the HR department "owns" the HR System, and its HR that is responsible for meeting its KPIs, equally Finance "owns" the GL and other financial systems and is responsible for meeting their KPIs. The only times its worth considering as strategic is when it really makes a significant difference (yield management and forecasting are two that come to mind) but these are again normally within defined business areas who have KPIs.

IT delivers into these things, it isn't a thing on its own. Hint: if you got rid of the company would the IT be there? Did companies exist before IT? . One of the biggest problems with IT is people who try and make out that IT is some mystical beast that deserves higher treatment, it doesn't.

Lastly, Ken is trying to convey the notion that in Agile (Scrum) the focus is, like the Toyota Production System, on building quality in from the very beginning. And, as increasing evidence shows, you can acually deliver value faster if all the bugs are resolved "immediately", rather than waiting to be found and fixed toward the end of the project.

Which isn't exactly news in IT, Mythical Man Month talked about this in the 1970s, and studies in the 60s showed that was the case. Its got nothing to do with Agile its just good practice.

If I am managing an agile project, I do not let the team work on any new functionality if there are known unresolved defects. If a customer/stakeholder wants to proceed with functionality instead of defect resolution, then it is bumped up to the executive level.

... isn't exactly news in IT, Mythical Man Month talked about this in the 1970s, and studies in the 60s showed that was the case. Its got nothing to do with Agile its just good practice.

Ken is pretty bombastic, and certainly gets his points across with gusto. But within here is a point which Ken has made, but not always highlighted, and is the root of the issue, I feel. Decisions should be made by the right people, based on their expertise and responsibility. How does it relate? Simply.

In the above example of managers bearing down on developers, Ken's message is to not compromise on quality. Developers should push back and insist on putting out great stuff. That's fine, but, as others have mentioned, sometimes crap is what's needed, because getting to market is seen as the larger risk.

My point is similar to Ken's, in that it is for the customer to determine what quality means, and what "done" means to him. Everything else is secondary. Now, there are engineering quality aspects, that I think Ken is highly insistent on, and I would tend, to some extent, to agree. However, if pressure is being brought to bear, the appropriate thing is to kick up the business risk that comes out of the technical risk to the customer (Product Owner, etc), and require him to make the call. That's the point of a product owner. If he's not empowered, have him kick it up. I disagree that it's the developers' responsibility to make this decision. However, I agree with the subtler issue that it's the developers' responsibility to expose the risk to the right participants.

Now, realpolitik for a second. Customers are trained not to hear these kinds of messages, and I think this is where Ken gets his hyperbolic style... you have to kick'em in the nuts to get their attention. Personally, I think it's not wise to go into an engagement with this assumtion. Rather, I feel you have to make your own assessment of the organizational culture, change capacity and natural change velocity, and determine if the message can be heard through rational discourse, or if it needs escalation. But I do feel that quality issues have to be exposed.

Time-Cost-Function is missing a fourth variable, Quality, and it's usually invisible. We need to expose this to the business. It's their risk to take or mitigate. Sometimes, what they need is garbage. We don't like it aesthetically, but we don't like some of the UI's they ask us to build either. We counsel, but ultimately, the customer needs to get what they want, in the order of priority they specify, at as high a velocity as their empowered teams can sustainably generate. If they want to freeze cost and time, and squeeze in more feature, then the fourth, oft-hidden variable gives way. Ken says we shouldn't let them, that to do so is dishonest, and has strategies for achieving this. Some may disagree with his strategies, but regardless, such decisions need to be bubbled up to those who are truly supposed to make the business risk decision. (I know I said the same thing four times - it was deliberate. This can't be sufficiently emphasized, in my view)

regards,
Christian.

In terms of how to get out of such a mess, Ken advised:

1. Having a ScrumMaster teach the product owner how to maximize value, Sprint by Sprint
2. Scrum Master doesn't allow his team to present any increment that isn't done
3. CEO is appraised of root cause of the problem and privdes support
4. We can only change ourselves (it's your responsibility to fight for quality). We have a professional responsibility to reject delivering poor quality or overcommitting on iterations, "not just because of quality, but because it can kill your company".

Excellent point Mishkin. Unfortunately, what
goes wrong after this is the meeting where the dev team is blamed for
"creating those defects",

Many of you are missing his point. I wasn't at the talk either but have heard the message from Ken many times before.

Please remember, his "bombastic" comments here are in direct response to his experience as a consultant in the field. I've personally had similar experiences. Here is the typical scenario Ken is referring to:
- Company needs features faster then their team can produce, so "management" puts pressure on the team.
- The only variable left for the team to cut that isn't fixed is quality, so it goes down.
- Team's velocity starts to lessen over time because the code is getting so hard to maintain.
- But management has gotten used to the inflated rate of delivery and now puts even more pressure on the team.
- And so the cycle continues until the team's velocity trends toward zero. Now you have an almost unmaintainable system and management calls in a consultant to ask what's wrong with their team.
- The consultant is now in a position where he has to break it to the CXO that the product is "design dead" and the only real option is to scrap it and start over. For some companies that might be feasible, but for many companies this means that they won't be able to recover; they are going out of business.

This might not be the case for companies where software products are not their main source of revenue. But Ken's point is that upper management needs to make decisions that impact the overall viability of the company. Do they need to micro-manage each and every quality decision? No, but they they should make the higher level policy about cutting quality at the project level because it has dramatic impacts down the line.

The post will certainly be complete when the video is there. In the meantime, we have knee jerk reactions to what people think I have said. However, most interestingly, all of the reactions like this stem from the belief that developers own the date, cost and functionality to be delivered. Since they haven?t heard the talk and do not know Scrum, they do not understand that these are owned by the Product Owner. We developers own velocity and quality. Our incursion into date, cost and functionality is totally inappropriate in a Scrum project.

Also, what I said was that for every $1 saved by reducing quality it costs $4 to restore it.

Also, what I said was that for every $1 saved by reducing quality it costs $4 to restore it.

Which isn't exactly news in IT, Mythical Man Month talked about this in the 1970s, and studies in the 60s showed that was the case. Its got nothing to do with Agile its just good practice.

1) "such a decision should be made by executive management and reflected in the financial statements of the company."

Who ever you report to is the organization's representative for you.
The executive management has approved the next line of staff to represent the company when dealing with their sub-group's members, and it repeats down the corporate triangle. So you don't need to ask the exec about the company's decision to reduce the quality.. you ask the delegated representative.. i.e. your boss / client stakeholder.

(Often when I ask them to confirm the quality of the app they want me to build for them, they'll go to their org representative. i.e. their boss. to confirm.) No one wants to agree to the low quality, so we end up doing it right.. or as it escalates up someone agrees to the level of quality, and they are held responsible for their decision.

2) "Not compromising on quality is not only your professional obligation..."

Got it wrong here.. your only obligation is to provide your employer/client what they have decided they want to buy from you. If dollarama tells their china warehouse to make cheap pens, when only 60% of them working.. i.e. low quality.. then that warehouse is obiligated to achieve that level.

Remember, quality usually means there needs to be some money and/or time investment upfront. It's for the people with the money (employer/client) to decide if they want to invest their money into it for the mid and long term benefits.

Not everyone buys quality HugoBoss socks.. some people prefer to buy low quality, low cost, high risk (of breaking), dollarstore socks.

---

The benefits of "Agile" is that we can offer our employer/client a higher level of quality (less risk). It is for them to decide if they want to buy it.

Rajesh