Tag: Lean Software Development

Posted on by — 4 Comments

The House of Scrum

The House of Scrum is a warm house. It’s a house where people are WELCOME. In the House of Scrum people from different backgrounds, in different roles, with different skills and talents work, learn and improve together, as a group, with no finger-pointing at each other or disrespectful work. The House of Scrum is an inclusive house of warm, open and collaborative relationships, not a house that excludes people.

The House of Scrum knows no versus. No business vs. IT, no team vs. organization, no Product Owner vs. Development Team, no development vs. support, or testers vs. developers (of code), our Team vs. your team, or Scrum Master vs. stakeholders. The House of Scrum is a great and energizing place where product development prospers from the combined, creative intelligence of people.

A similar house, just different materials, is the Lean house.
I created this (graphical) analogy when I was gathering, bundling, reviewing, editing and adapting some previously published blog notes to create some white paper-ish… papers. The first one covers this analogy: “The Blending Philosophies of Lean and Agile” (I will soon make it available via slideshare).

This is just partly about the result. I’m also going through it to check and improve my writing skills. Of course quite curious where it might lead me.

The paper, as I foresee it now, has 3 parts:

  1. An introductory overview of the Lean Thinking and mindset as I laid it out in The Power of Lean Thinking,
  2. Stressing the Agile Spirit (over jumping into singular practices) to demonstrate that Lean and Agile are indeed Blending philosophies,
  3. The Scrum Perspective to Agile describes the main game playing rules of Scrum to demonstrate how Scrum implements the Agile principles and how Scrum is quite… Lean.

By the way, I am encountering the interest in this topic, Lean+Scrum, more and more. Organizations are looking to ‘Lean’ to help them revive. And I’ve already had several Lean coaches at my Scrum trainings and they share my enthusiasm for embedding a product development vision upon Scrum in Lean thinking. Let me hereby quickly summarize the compatibilities as follows:

Next papers I will be working on are:

  • “Paving the path of Scrum adoption”, on challenges in challenging the status-quo state of many Scrum implementations;
  • “The customer-oriented enterprise”, an answer to the major Scrum challenges from the perspective of the total organization.

Keep tuned!

Posted on by — Leave a comment

More to Agile than meets the eye

Agile is, less acknowledged than but much like Lean, a set of thinking tools and interwoven principles. They are the levers that empower people to faster create better products in a sustainable and respectful way. Typical misconceptions like using Lean for mere cost cutting, limiting Agile to the software department and expecting one, silver bullet, process prevent the emergence of larger benefits.

In Agile, better software products with Built-In Quality are faster achieved by fundamentally re-organizing all activities in an iterative-incremental way and by performing tasks in parallel on a daily basis. A different approach to Managing Risk & Quality.

But let’s have a look at Agile and Lean as blending philosophies, the matching of Agile practices with the main Lean principles.

There are at least 3 major approaches to Eliminate Waste:

  1. Potentially unused inventories (requirements, predictive plans, overdesigns) are not produced upfront. The highest priority work is detailed just in time. A Team will Pull in the amount of work they deem feasible for an iteration, commit to it and build it upon progressive learning and continuous improvement.
  2. Partially done work won’t pile up as an iteration results in working increments. Undone work is prevented by an overall Kaizen thinking, made explicit in a daily Inspect & Adapt stand-up meeting and an iterational Retrospective.
  3. Active Business Involvement excludes unwanted or invaluable requirements. Knowing that only 20% of software functions are regularly used, this represents an enormous waste while showing much disrespect to the people having to spend their time on it.

A Shared Visual Workspace facilitates fast decisions, high interaction and short communication. Openly available Information Radiators are used for the Team to self-inspect and adapt and for external transparency. It shows the real progress upon real efforts and protects the Team in maintaining Sustainable Pace, to assure product quality.

Iterations are timeboxed to Deliver Fast and usable, end-to-end working software that can be put into production. A review with all stakeholders gives the Team outside feedback, remarks and enhancements. Besides this product inspection, an Agile Team will improve its overall operation with a retrospective meeting. Within an iteration however each Team member has the right to immediately Stop the line.

Optimizing The Whole is achieved through active Business involvement and the on-site presence of all technical skills to turn ideas, options and requirements into working software. The Value Stream is optimized because traditional waiting activities like hand-overs and external decisions are eliminated. No macro hand-overs due to a sequential process. No micro hand-overs within the collectively responsible Team.

And, finally, a Manager-teacher, facilitates the Team in teaching the process and removing impediments.

Attached is my complete paper on The blending philosophies of Lean and Agile. It was previously published as 2 blognotes, one for the Lean part and one for the Agile part of the text at the Capgemini Techno Blog.

Posted on by — Leave a comment

Definition of… Agile Testing

Poppendieck - Implementing Lean Software DevelopmentThe book Implementing Lean Software Development (from concept to cash) by Mary and Tom Poppendieck gave me an additional perspective and language (terminology) on quality and testing, thus enriching my existing insights.

Traditional testing is focused too much on bug hunting, mostly after a development cycle and including a devious rewarding or penalty policy. There is too little attention for verification of quality while building.

The development process should be oriented towards creating quality upfront (i.e. before UAT, release or whatever post-process control), and verification during the development process. If verification reveals a defect, the ‘line’ is stopped, the cause identified and resolved.

logo-myfragilityMy My.Fragility framework holds Quality Loops. These are performed continuously and at least daily. It is based upon eXtreme Programming practices. They serve as engineering standards within the Scrum process that is at the heart of my framework. It shows our focus on quality and integrated testing:

My.Fragility - Quality Loops


Posted on by — 2 Comments

Kanban and Scrum (done or to be done?)

Kan and Ban are Japanese for Card and Signal. A Kanban (signal card) originates from the Toyota Production System (TPS) where it is a physical card that visualizes a pull question for inventory. It serves to minimize stock in a ‘Just In Time’ strategy and is a way to ‘eliminate waste’ while assuring a continuous flow of goods.

In an Agile context, a Story Card is a Kanban. Out of eXtreme Programming it grew into an established Agile practice in describing a feature. A Kanban Board holds the active Story Cards per ‘status’, thus being an Information Radiator (term by Alistair Cockburn, also my inspiration for the Games metaphor).

My.Fragility_logoMy Scrum Product ànd Sprint Backlog items are User Stories. (‘Minimal Marketable Feature’ is more generic, but I stick to ‘User Story’) The Sprint Backlog is made visible by sticking a printout from my (Excel) tracking model on a wall. Around the Daily Scrum (we do it standing up) each Story Lead writes the estimated time to finish a Story on the printout and I create the Sprint Burndown. That works fine. We use a Kanban Board only for feedback from functional testing. This is generally too small to create a Story (would be ‘waste’).

Velocity is a way to optimize the inventory and the continuity of work. Traditionally ‘velocity’ equals the #Story Points (gummy bears) that can be finished in one iteration (a Sprint). However, I apply an overall Velocity as a multiplicator on Story Points (ideal time) to result in #planning days. The size of the inventory (in #Story Points) for a Sprint is determined by dividing the available #planning days of a team (minus 2 slack days) by expected Velocity (Yesterday’s weather). Note: continuity is also assured by the presence of the Product Owner. He/she makes sure that no functional issue remains unsolved, on the spot!

Posted on by — Leave a comment

Scrum and the Cooperative Game

In many (IT) partnerships and implementations people seem to prefer to strangle each other rather than assure mutual benefits.

I’m applying Scrum (over 4 years already), in my projects and in my management. It continuously helps me to cross fences; between suppliers and customers, business and IT, analysts and developers, x-layer developers and y-layer developers, etc.

In my Scrum-based development process I use Pre-Game Staging to name the barely enough preparative phase for 1 stage of software development. The “Games” metaphor was described by Alistair Cockburn in his biblical work Agile Software Development. I strongly agree with him that software development should be a Cooperative Game.

  • Cooperative: a team of people works together towards a common goal, not to fight each other.
  • Non-zero sum: the players are not opposed and do not try to win by getting the other at zero. There are multiple winners.
  • Finite and goal-seeking: the game ends when the goal is achieved. The game is not meant for just staying in existence.

You will find this as well in the integrated prerequisite for supplier-customer relationships (possibly multi-tier), from Toyota’s Lean Production to Poppendieck’s Lean Software Development. It offers far more certainties than our commonly applied bidding processes. Think (read) about it!