Quality First Drives Behavior

If quality is first, it drives a certain set of behaviors.  If market
share is the goal, it drives a different set of behaviours…

Even as Toyota was catching up to No.1, their reputation was slipping…

(Emphasis mine)

The parable of Toyota may be that the tortoise became the hare.  Over decades, Toyota built its reputation and market share in tiny increments through its renowned “continuous improvement” method. In the Toyota mantra, quality was always first, because it led to lower costs, which would eventually lead to higher market share. Eventually.

But in the ’90s, Toyota set out to become the world’s top auto company. Being the best and being the biggest created a tension
that Toyota couldn’t resolve, says MIT operations expert Steven Spear:
“If quality is first, it drives a certain set of behaviors. If market
share is the goal, it drives a different set of behaviors.” 
….
the “Toyota way” … was diluted by the demands of production. “Even in
the late ’90s, people in Toyota would say, ‘This is going to bite us in
the ass,’ ” says Spear. “They just didn’t know when.”

Now they do. …. Toyota will fix its manufacturing problem. Restoring its reputation is going to take a lot longer.

Toyota’s Flawed Focus on Quantity Over Quality – TIME

Lean: Development is not Manufacturing

The conclusions of lean manufacturing theories are not necessarily valid in the domain of (software) product development.

There’s good reasons why it’s so difficult to fix time, budget, and feature scope all at once in a software development project.

I’ve been listening to a talk by Don Reinertsen, and one of his points, although not the main point, is about variability:  if you could reduce variability in the workflow by 10%, or you could reduce capacity utilization by 10%, by far you would prefer to reduce capacity utilization.  That’s where the economic payoff is.

The reason is that increased capacity utilization increases queue size and lead time exponentially.  In other words, if you try to keep all your resources busy all the time, everything takes forever to finish.  This goes for both manufacturing and development.  Variability in workflow, however, is bad in manufacturing, but can’t be avoided in product development, and might even be exploited.

So what else is different about development compared to manufacturing?

Manufacturing Development
Tasks are…. repetitive non-repetitive
Tasks are… predictable unpredictable
Requirements are… a constraint a degree of freedom
Requirements are… fixed evolving
Cost of delay is… homogeneous non-homogeneous
Task durations are… homogeneous non-homogeneous
Variability is… always waste not always waste
Inventory is… physical objects information
Inventory is… visible invisible

Source:
A talk by Don Reinertsen,
Second Generation Lean Product Development: From Cargo Cult to Science

the purpose of education should be to make us more effective at life

The time has come to stop quietly accepting the mistaken – yet popular – notion that education is primarly about getting jobs. The purpose of education is to make us better at using the collective knowledge of the human race in all areas of life. Yes, this includes our jobs, but it also includes raising our children, being informed citizens, managing our households, enjoying our leisure time, and just being good neighbors. Education should be to make us more effective at life. And as a powerful, new and poorly understood technology, computer education should be central to our learning experience

….

*Everyone* needs to learn the fundamentals [of how to use computer technology], right in the core curriculum along with math, science, reading and history.

Thoughts On …: Teaching Magic

Jakob Nielsen, too, advocates teaching life-long computer skills, like search strategies and basic debugging.

agile adoption fails in a “fixed project situation”

i saw an interesting article on infoq.com.

the term “fixed bid” is used in the article, but this article applies to another “fixed project situation“, too, i.e., where the resources are fixed, and there’s a specified, promised feature scope and a specified, promised delivery date. 

(btw, it isn’t really possible to control all of resources, delivery date, and scope and quality of features at the same time…)

In an agile software team you don’t estimate your work till right
before you begin. And you only estimate, in the case of Scrum, the next
iterations work. So how do you know how long it will take? You don’t.
Furthermore, you really don’t care. You’ll continue to deliver
functionality every iteration. As soon as product management and QA say
you have a good enough product; it’ll be released as a production
version. You might have a guess, but until the team estimates it….you
really don’t know long it will take.

In a fixed bid situation….your estimation needs to take place up front.
….
In the 2nd scenario, if I told the team, … “we’re using Scrum”: they’d estimate the work
the next iteration. They would assume their estimates would be taken
seriously and you’d give them time to complete the work as it unfolds
regardless of whether their estimates fit your original project funding
or not. That’s only fair.

alternatively: they would assume they’d get the “time to complete the work with high quality regardless of whether their updated estimates fit your original project plan and delivery date or not”.

[this leads to failure]….at managing the project and therefore…….”this agile thing doesn’t work”.

The mistake was to assume the company’s leadership … was
organizationally committed to … agile principles. The mere fact
that they are asking you to estimate the funding you’ll need to
complete the project tells us otherwise.

alternatively: the fact that they are asking you to commit to a fixed feature set and a fixed delivery date tells us otherwise. 

this isn’t bad, per se, it just isn’t agile.

[the real problem]

  • Agile is often assumed … to be a development process with no impact on budgeting. This is not the case.
  • Development teams assume leadership understands the implications of adopting agile at the budgetary level.

Developers and development teams often have zero visibility into
budgeting so they are unaware of how their agile efforts are being
accounted for in monetary terms. …. Likewise, management is often ignorant of
development and specifically agile development practices. Agile
adoption requires education to ease the clash and misunderstanding of
these two worlds.

So what are some of the consequences of attempting to adopt agile
practices on a fixed bid project…essentially laying an agile façade
over the waterfall project?

….
Agile does away with the need for a project manager. …. organizing and managing the development effort are more centered on
technical leadership, task and risk management. Timelines and budgets
go out the door.
….
if you’re in a non-agile situation … then traditional PM practices are … essential

….
Doing iteration planning in a fixed bid situation will almost certainly
result in confusion, budget variances, and/or loss of functionality.
….

In fixed bid scenarios the question is not … how much
functionality the team is doing per time period. It really doesn’t
matter. They need to get all the functionality done …

So using … iterations in a fixed bid project sends the wrong signal to the team and your customers.

using iterations in a fixed project situation sends the wrong signal to the team.

you can still visualize workflow, f.ex. with kanban, reduce work in process, do stand up meetings (very short, impediments only), etc.

but in general you should try to get out of a fixed project situation before trying to go agile.

Edit: About that last part… I think there’s a few basic, agile tools you can utilize whatever you’re doing: visualize how you work; get faster feedback; limit the amount of work in progress.

interrupted by an email?

or rather, do you let yourself be interrupted?

then it takes time to get back to what you were doing, and then more time to get back in the flow.

The October issue of Real Simple magazine quotes a Microsoft and University of Illinois at Urbana-Champaign study that claims it takes 17 minutes “for a worker interrupted by e-mail to get back to what she was doing.”

Unclutterer: Recovering from an email interruption

on the tip of your tongue?

don’t try to dig deep in your memory…

look it up right away, or just stop and let it go.


the
longer you try to come up with the word that’s on the tip of your
tongue, the more likely you’ll be to get stuck on that word in the
future.
….
[this
has] implications for the classroom …  “If the student can’t learn
something or can’t remember something… then you often see the teacher
encouraging them to work through it. ‘Just keep trying. It’ll come to
you.’
….
[but] Instead of trying to remember, students should look up the correct answer.
….
[and when you can’t look up right now?]
For those situations, Humphreys’ advises that you “don’t keep trying. Just stop.”
….
So
remember, if you’re trying to help out somebody who’s stuck, you should
give them the answer. Humphreys also says you should “get them to
repeat it back to you. But don’t leave them in this state where they
just have to keep trying, because they’re just going to be digging
themselves into that error again.”

Tip of the Tongue Learning: Science Videos – Science News – ScienCentral

what is quality?

good quality is difficult to quantify, and what is good enough is fluid. it is often easier to point out lack of quality than to specify good quality.

quality is relative

when you think about what is good or bad about a product, criteria may come to mind which are not easy to quantify.  f.ex. “feels good”, “it works”, “good value”, “i just like it”, “luxurious”…

price can lead you to buy one product and not another, even if they otherwise seem to be of equal quality.

your needs and wants change over time.

different situations influence what price is a good price, or what you get from a purchase.

different people have different values and backgrounds, leading to different choices.

however, someone is deciding on quality – you buy something or not, you get to sell something or not…

so maybe the question should be: who decides quality?

the stakeholders decide

some people are more invested in a product, and it’s not only customers, but really anyone who’s affected by or is affecting a product.

customers are necessary for the existence of a product in the commercial market, but it is not sufficient for a product to only meet the customers’ needs.  others must also be satisfied, such as stockholders, employees, and governments.  in the government sector a paying customer might not even be necessary.

who are the stakeholders, anyway?

those affected by or affecting a product, i.e., stakeholders, include:

  • customers – decide to buy or not
  • partners – add value
  • employees – add skill, expect f.ex. meaningful work
  • owners – add capital, expect increased value
  • governments
  • analysts like Gartner, Forrester

sometimes there’s conflicting expectations due to the fact that stakeholders don’t all want the same things… which makes it more difficult to figure out what good quality is.

ISO on quality

you might have an impression of ISO as a bit too formal, but in this case i think they’re onto something.

the ISO 9000 family (the 200x versions) describes quality as the ability to satisfy requirements; from the stakeholders, explicitly expressed, or just implied.

so what is good quality?

it’s about product and process – both what we make and how we make it.

it’s about compromise – conflicting needs means not every stakeholder get everything they want.  if reaching a deadline to make a customer happy means working a lot of overtime making employees unhappy, it might be worse quality all in all than missing the deadline.

it’s about all of the stakeholders. yes, it might be easy to focus a lot on the customer, but you need to keep all the stakeholders happy – or at least happy enough.  e.g., your bank needs to trust that you can pay back a loan, and the government expects you to file your taxes.

it’s about expectations.  a customer might expect certain functionality which is normal among competing products, and get unhappy if it’s not there, but might not think to include it in the requirements in the first place.  even if you’re not a mind reader, this is part of the quality of the product.

it’s not just a point in time – f.ex how the technical quality of software over time sustains (or not) stakeholders’ needs and expectations over time.

you need to recalibrate your understanding of stakeholders from time to time, since time and changing circumstances make stakeholders’ expectations change – and thus change what is good quality.  e.g., owners of a company probably expect more profit after a few years than in the very beginning of the company.

to sum it up: as you can see, in my opinion quality is relative, and is defined by what stakeholders need and expect.

å skriva for web

det er annleis å skriva for lesing på web enn for lesing på papir.

dette er for oss som treng litt råd og “hugselapp” når det gjeld å skriva noko som er lett å lesa på web.

viktigaste fyrst

folk skummar ofte websider.  skumlesing gjer at den viktigaste informasjonen bør koma fyrst – start gjerne med konklusjonen.

avgrensning: skriv korte avsnitt, kortfatta setningar – mykje kortare enn på papir.  ha ein idé per avsnitt.

bruk gjerne overskrifter og lister

  • bruk gjerne lister for å ramsa opp fleire poeng
  • bruk gjerne overskrift – primært som hjelp til skumlesing
  • teksten skal gi meining på papir – unngå “klikk her” o.l., og bruk heller lenker med meining
  • det er lettare å legga merke til feit skrift enn kursiv skrift
  • skriv gjerne direkte til lesaren – slik får du lettare kontakt
  • anekdoter heller enn kompakte data

nøkkelord, søk

få fram nøkkelord – gjerne i overskrifter og i starten på avsnitt, som blikkfang.  tenk også på kva folk søker etter når dei ynskjer å finna innhald som det du skriv – og bruk slike ord i tekst og overskrifter.

som på papir

det som er smart når ein skriv på papir er også smart på web:

  • tenk på målgruppe
  • tenk på sjanger – kva vil du med teksten?
  • la konklusjon/ samandrag/ innleiing svara på kven, kva, når, kor, korleis

kjelder

lesetips