BT

Ken Schwaber: Sacrificing Quality should be an Executive Management Decision

by Floyd Marinescu on Jul 26, 2006 |
At Agile2006, Co-founder of the Scrum methodology Ken Schwaber made a passionate case for maintaining software quality. Drawing examples of teams sacrificing testing, refactoring and other practices in order to meet deadlines, Ken 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's message: Not compromising on quality is not only your professional obligation but it is also important for your own joy of work and is critical for the company.

Ken started talking about companies that choose to cut quality in order to speed up time to market / competitiveness. The problems with doing this is that it reduces team velocity on future iterations, eventually companies can back themselves up into a corner and velocity can be negligible.
For every $4 of competitive advantage gained by cutting quality, it costs $4 to restore it; and

software is an organizational asset and decisions to cut quality must be made by executive management and reflected in the financial statements.
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". 

InfoQ recorded this session in video and it will appear on the site in the next few months.

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

I call bullsh** by Cameron Purdy

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.


Yes, because (gosh-darn-it) we're important, and the universe (not to mention the executive management of our company) revolves around the state of our current software project, and the executive management of our company should just be sitting waiting to revise the financial statements of the company just to show what idiots they are for making us sacrifice the quality of our masterpiece.

If the CEO wants this f***ing project done on time, he can come tell me himself that he wants me to cut quality, and that's all there is to it.

Ken advised: 1. Having a ScrumMaster ..


OMG -- surprise! Now _that's_ agile.

To be taken seriously, one needs to start with some real-world assumptions:

1. The project being late is unacceptable, although a slight amount of lateness is expected.
2. The project going over budget is almost as unacceptable, although if it comes to being late or being over budget, most companies prefer the latter -- if it's actually going to get the project done.
3. As someone working on the project, it's your job to figure out how to do the impossible -- that's what you're paid to do.

Turning around and trying to drag "executive management" into your mess isn't going to work unless you're trying to become part of the "oh-so-recently-employed". On the other hand, if you're a consulting ScrumMaster, you can wash your hands of your disaster and move on and get paid to tell people about how executive management screwed up your last project.

Yes, there's obviously something terribly wrong with most companies, because this situation occurs in the first place. Deal with the root of the problem, or stop whining. Trying to CYA so late in the project cycle by pretending that you're important enough that your feelings should be reflected in the financial statements of the company has to be about the stupidest thing I've ever heard.

Peace,

Cameron Purdy
Tangosol Coherence: Clustered Shared Memory for Java

Re: I call bullsh** by Alex Popescu

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.

Re: I call bullsh** by Jason Lenhart

Cameron ... excellent reply - perfect!

Re: I call bullsh** by Bryan Ross

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

Re: I call bullsh** by Floyd Marinescu

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.

Root of the problem by Cameron Purdy

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?


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.

Software architecture and developement (and testing and maintenance) are very difficult to do well, and even more difficult to predict in terms of time and budget. We live in a world in which it has to be done sooner, cheaper and better, and [unfortunately] you can't pick only two.

Companies want predictability in terms of time and budget, but projects don't tend to get funded if the estimates are realistic, because there's an expected inflation in projections. At the same time, assuming we can get better (as an industry) about estimating cost and time, we still have to deal with the fact that requirements change all the time, and almost always change for the worse (in terms of time and budget). That's what "agile" needs to focus on -- dealing with the inevitability of change from the point of view of architecting and developing and managing a project.

Peace,

Cameron Purdy
Tangosol Coherence: Clustered Shared Memory for Java

Understood by Cameron Purdy

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


That's an ideal, and of course it can work in a software company, which I think we (Tangosol) have proven. But for companies that are not software companies, software development is typically going to be considered as a cost center, which is not a profit center (or even a revenue center). The way that companies deal with cost centers is to cut costs.

I agree that project managers need ammunition to push back with, but I don't think calling the CEO onto the carpet to deal with a product manager is going to work in a company of more than 5 or 10 people.

Peace,

Cameron Purdy
Tangosol Coherence: Clustered Shared Memory for Java

Re: Root of the problem by Alex Popescu

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!


So, we both call it the same :-].

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.


I guess sombody can try to do it, but I think he/she will be "so much fired" (or at least "more" fired than those engineers :-]).

We definitely need to improve the way we develop, in all aspects (including here predictability too). What I would like to learn or find out is that other people involved are also trying to improve the ways we are interacting. So to say, I cannot agree that, we, the techies, are the only ones breaking the time and budget terms. And I am sure that all those involved must improve over time, so we finally become more efficient.

BR,

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

Re: Understood by Joe Little

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?

Lean and Agile by Mishkin Berteig

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.

Re: I call bullsh** by Steve Jones

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.

Re: Understood by Steve Jones

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.

Re: Lean and Agile by Alex Popescu

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.


Excellent point Mishkin. Unfortunately, what goes wrong after this is the meeting where the dev team is blamed for "creating those defects", and for staying to long on fixing them (try asking what means "too long" during such a meeting :-]). Or another approach: the PM/technical lead are asking for more skilled people (so they reduce the probability of initial defects), but this is considered overbudgetting.

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

Re: Understood by Christian Gruber

... 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.


It might "just [be] good practice", but I think Lean and Agile is just good practice. It's empirically studied good practice, or rather practices, studied in combination in trials (projects). It may not be news, but since our industry fell victim to the fantasy of waterfall and large-scale prescriptive management, "smart" stuff from the Mythical Man Month or other sources is innovative... or at least restorative.

Christian.

Tracability and forcing the right people to make decisions by Christian Gruber

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.

Re: Tracability... one more note by Christian Gruber

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".


In reference to this, 1 and 2 are great, 3 is great, though it may not need to be the CEO, if the product owner(s) in the company are actually empowered POs, and #4 is where I think things get sticky. It's true, but I agree with it only insofar as it is made clear that the customer gets to specify the "level of doneness" and "acceptance criteria" that they wish. This also speaks to #2. If the customer wants half-finished garbage, you define the backlog item (story) such that its acceptance criteria and definition meet the lowered expectation. Taking the lean principle of "eliminate waste", oft practiced in XP and other agile methods, such a definition of the feature would involve the fastest implementation path without duplication, that meets the requirement. If the requirement is of poor quality, you'll get delivery of poor quality product. (this last sentence should probably be a mantra.)

The place where it gets crazy is that you can define poor quality, or levels of doneness in ways that make it easier to do quickly, since the team has a lower burden to meet, but acceptance criteria can also be articulated such that, while the LOD/Quality is low, the requirements don't actually take any less time to implement. Very, very often, quality speeds things up. Refactoring a limited API to be more generic, for instance, and eliminating code as you go can result in an capacity to add features with less effort, so later iterations see higher velocity as the system stablizes.

Also, as Mishkin implied earlier, building quality in results in fewer defects, which results in less "in your way" when adding features. They might want half-finished garbage, but what features they do require have to actually work to a certain degree. If waste/defect prevents you from easily adding features that work at all, then the "go for broke, don't worry about quality" attitude will actually reduce team velocity.

regards,
Christian.

Re: Lean and Agile by Chris Wheeler


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


Blame aside, defects are a form of waste. Finding defects early is celebrated too often in place of preventing defects altogether. So, if I was a CEO, bothered by every defect on every project as described in an earlier post, I'd bloody well want someone to start taking responsibility and find out why so many defects are finding thier way into code to begin with.

That said, I'm beginning to see more and more that XP/SCRUM/Agile projects are terrible at pushing the right kind of information to CEO's and other high level stakeholders. Often, Agile is counterculture to the organization, and pushing the wrong (or zero) information to a CEO doesn't help with adoption and sustaining.

Chris.

Missing his point by Victor Szalvay

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.

Incomplete description results in incomplete reactions by Ken Schwaber

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.

Re: Incomplete description results in incomplete reactions by Daniel Serodio

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

Interesting figures, where did these came from? Don't get me wrong, but I'm always wary of figures when their source is not mentioned...

Re: Understood by Paul Oldfield


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.


Most of the Agile practices have a long pedigree. It's strange that the industry seems to have forgotten much of what was once common knowledge and recognised good practice.

Humility please! Prod belongs to the employer/client that is paying for it! by Rajesh Duggal

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

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

22 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2013 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT