Slack is Unplanned Improvement Work

Full utilization cause delays - http://agileconsulting.blogspot.no/2011/07/explaining-why-limiting-wip-is-so.html
Full utilization is not effective, not efficient, and causes delays

Being busy all the time is bad for you, your team, and your organization.  It is far better to allow for slack, which is not a bad thing, but creates opportunities for improvement without needing to schedule them.

“Recipe” for what to work on next, incorporating slack:

  1. Can you help progress existing planned, started work?
    Work on that.
  2. Can’t do that?
    Find bottleneck and help work to release it.
  3. Can’t do that either?
    Do some (improvement) work which

    • won’t create any work downstream,
    • will improve future throughput, and
    • can be paused as soon as existing kanban related work is available.

A bit more reading related to slack.

#techsafety

At LKNA13 in Chicago this year I listened to @JoshuaKerievsky talk about #techsafety.

He made me think about quite a few aspects of safety and injuries for a programmer. Here’s a few quotes and elements:

  • safety on team (ref own dev competence)
  • «working with CVS is hurting my soul.»
  • safe from uncertain work situation
  • safe to deploy – bugs, crash
  • safe from pressure – politics, policies
  • Emotional Injuries: Schedule Stress, Lost Respect, Fear of Failure, Torn Trust, etc

What’s interesting is his claim that having #techsafety as a primary value would be profitable and produce outstanding results. I think I buy into that, even if he hasn’t had time to prove it yet with his own company, @IndustrialLogic.

A few twitter notes from the session.

Edit: Joshua have written on #techsafety himself:

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

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.

software projects: have your cake and eat it?

would you like to have your cake and eat it, too?

in my opinion you actually can’t; you’re not able to make absolutely sure that a project is on budget (resources), on time (delivery date), and have all the planned features with high quality, all at the same time.  there’s always a risk, and you can only control any 2 out of the 3 factors at the most. If you try to control all 3 factors at once you are most likely sacrificing the quality of the features, and thus you’re not in control over the features anyway.

Scott W. Ambler makes a few interesting points in this article about software development projects – i’ve selected the quotes that’s most interesting (to me) below.

  • “the only true measure of progress on a software development project is the delivery of working software. “
  • “Agile teams choose to produce potentially-shippable software at the end of each iteration, providing concrete and visible feedback to their stakeholders as to their actual progress. “
  • “… the majority of stakeholders prefer this sort of tangible evidence of progress instead of intangible numbers. “
  • “… the majority of our stakeholders aren’t really interested in whether we’re on schedule or on budget.”

“…. In August 2007, Dr. Dobb’s ran a survey exploring how people define IT project success, and we found that 80 percent of people preferred to focus on producing a good return on investment (ROI) than being under budget, and that 62 percent wanted teams to ship their systems when they’re ready to be shipped rather than forcing adherence to a schedule. ”

  • “… the priorities are to spend the money wisely and ship quality systems. “
  • “… shipping high quality software is more important than being on time and on budget”
  • “… instead of measuring progress against your plan, … you should instead be focusing on ensuring ROI and product quality. “

“The agile practices of implementing requirements in priority order and allowing requirements to evolve throughout the lifecycle ensure greater ROI, and agile practices such as test-driven development (TDD) and refactoring promote greater quality.”