Tag: Lean

Posted on by — 8 Comments

The Product Owner – An Entrepreneur

A vast majority of software development work concerns new product development. Every software product is essentially unique. We create previously non-existing products, suites, integrations and product extensions. We never create the same product twice. We expand existing products into the new product area. Competition, market expectations and technologies move so fast that acquired concepts, practices and approaches are outdated by the time they become well adopted, forcing us de facto into new product development anyhow.

Software development, as new product development through and in complex conditions, requires a startup mindset, no matter the size or age of the product or the master company. The Product Owner, as promoted in the Scrum framework, becomes an Agile Product Manager, the product’s president, its mini-CEO, an entrepreneur. The rise in complexity and uncertainty renders big plans into meaningless waste. The Product Owner drives iterative development from an exploratory attitude, aiming at incremental progress through continuing discovery and validated learning.

Every Sprint has a Sprint Goal as next horizon to work against. The Sprint Goal describes a (business) challenge, from an assumption of (market) value for the (Increment of) product. The outcome of a Sprint provides an important learning option. But the learning is only meaningful when it can be assessed against the product’s external impact and adoption; in affirming or negating the assumption of value underlying the Sprint Goal. The goal of the learning is to find out whether an opportunity is real, whether there is an audience willing to use the product, whether the audience appreciates the delivered functions.

In the absence of a release, value remains an obscure assumption. It is a major unknown and a risk for further investments. The unknown remains unresolved, and the risk is out of control, until the product is brought to market; be it a contained market segment, be it a limited or the full user base. With every Sprint without an actual release, the risk increases exponentially that the Product Owner runs out of tune with the evolving market and is wasting money, time and creativity. Increments of product, seemingly incomplete but offering minimal usable feature sets, provide the foundation for validated learning. Users need it to provide the Product Owner with feedback on the actual value of the performed work, the base to decide on the best future direction of the product. No document, design, paper document or simulation provides the same, high level of validation. Without that ultimate validation no informed decision over strategies or tactics can be taken, not in the least the decision whether to continue on the chosen path or to change direction.

Learning requires not only goals and feedback loops, but also measurements and data to support the validation process. Evidence of value is needed to confirm or contradict the assumptions. Evidence-Based Management can guide the entrepreneur and the stakeholders in their investment decisions.

Scrum can be at the heart of such entrepreneurship. Scrum frames the creativity of people to better deal with complexity and uncertainty. The empirical foundation of Scrum is a structured way to steer experimentation and discovery through frequent validation. In a situation where uncertainty is too big to plan, it is a way to make real progress; progress that is founded in reality, not in plannified imagination.

Seeing the Product Owner in Scrum merely as a requirements engineer, a requirements provider or someone to prioritize a preset Product Backlog is unlikely to help organizations capitalize on the entrepreneurial potential of Scrum. Seeing Scrum as a goal in itself results in gazing at internal performance, volume (of features, of hours, of points) and productivity (velocity or derivatives). Scrum is designed as a mean, a mean to maximize the value of software; value to the market and value to the organization and its people. Scrum is designed to make progress, grow and prosper trough validated, incremental learning. The Product Owner, the owner of the product, takes up the essential role of entrepreneur.

In today’s complex and unpredictable world, Scrum can be the engine of innovation and exploration. It is a choice though. It is your call on how you want to use Scrum.

Posted on by — 3 Comments

How Scrum Blends the Philosophies of Lean and Agile

Some management or governance philosophies should not be mixed. Because the mix will be a blurry amalgam and the unique flavor of the individual ingredients will get lost in the mix. In general it’s even worse. Not only the flavor and the envisioned benefits get lost, the total ‘product’ may be even well less performant than the sum would suggest.

Lean is a management or organizational model that thrives on a typical mindset, with powerful but distinct fundaments, principles and thinking. But beyond the assumption that such strategies are best not mixed, I see not only much common ground to Lean and Agile, I am even convinced of the power of the combination. I believe that combining Lean management principles with the Agile product development spirit, as a total outcome, will result in a more powerful mix. I believe that Lean and Agile are truly blending philosophies.

As Professional Scrum Trainer I worked with Scrum.org to release my views as a whitepaper at The Blending Philosophies of Lean and Agile.

In this paper I highlight the main aspects of the distinct views of Lean and Agile, and indicate the similar grounds to them. But I have also included the Scrum perspective to Agile to make very clear how the tangible, yet open framework of Scrum aligns and blends the underlying thinking of Agile and Lean.

My paper elaborates on my statement that the houses of Lean and Scrum are similar houses, just different materials:

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

More to Lean than meets the eye

I have read The Machine That Changed The World, Poppendieck books and the great Lean Primer. I have had a Kanban training by David J Anderson. So I am not an expert on Lean, but still… knowledgeable. At least knowledgeable enough to detect that Lean is far too much confused with ‘eliminating waste’. In its turn mostly a faint excuse for ‘cost cutting’ by mislabeling workers as non-value adding. Quite tiresome.

From that popular misconception it is a long journey to the understanding that Lean is primarily about respecting People and optimizing Value and Quality. That adopting Lean requires to look beyond mere practices, but introduce a mindset and a culture that enables and encourages people to reflect on their daily work and self-improve.

People

The corner stones of any system claiming to implement Lean are People.

They work in a cross-functional way upon a practice of self-management. In a Go See style Manager-Teachers help people on the workfloor to understand Lean and self-management to build better products. The workers get to embody the spirit of Kaizen, the attitude (!) of continuously minding the process and looking for improvements. Every involved person can stop the line if a problem occurs, so the root of the problem can be immediately detected and countermeasures installed.

This refers to all people that contribute to the Product: customers, workers, teams, suppliers, managers. And implies the abandonment of traditional relationships based upon large volume purchases, big negotiation rounds and pressuring one another. Likely to end up with at least one strangled party. It’s about building relationships on profit (and risk!) sharing. Mutual growth.

Waste

To start with, I prefer Avoiding Waste over Eliminating Waste. At least it implies a subtle difference in timing on when to act… Furthermore ‘Waste’ refers to steps in the process, not to disposing of people.

But, naturally, waste can creep in. The base to detect it is Kaizen. But upon that base attitude, a good practice to structurally identify waste is Value Stream Mapping. The full process from ‘idea’ to ‘build’ is timelined. The Value Ratio (time on Value adding / Wasteful activities) is the baseline figure against which to improve.

Another hands-on method for root-cause analysis are the 5 Why’s. Keep searching for the deeper cause of a found problem, until the bottom is reached. And, although not much, it may require more than 5 attempts…

Flow

People work together in Team Rooms and apply Visual Management.

A very popular approach has become the Kanban board. Within Lean in general, a Kanban is a physical signal-card intended to optimize stock or inventory (just enough). The term ‘Kanban’ is however becoming more and more known as the name of the tangible method for software development.

Physical cards represent work items and are placed on a whiteboard to show the work-in-progress (‘WIP’), with limits per state. The Cycle Time is the total time for completing a work item. Work cannot be pushed down the line causing disruptions to the flow. Work is taken in on a Pull base. The Team focuses on optimizing the flow by removing piled up work, thus safeguarding the overall cycle time (i.e. timely delivery).

Process

There is no definite end goal, no final process. The improvement itself is the goal. This however does not exclude installing a proven process at startup as a baseline implementation against which to endlessly improve and adopt installed standards. But the actual process, its phases, roles and states, must be constantly tuned to the actual situation. There is no standard Lean process template to be copied.

And Agile approaches like Scrum are a natural fit to these Lean fundaments. No mixed, but blended philosophies.