Lean Archives - Agile Velocity

Blog

Merry Value Delivery: What I Learned About Flow as a Blue Santa Volunteer

By: Resalin Gurka | Dec 14, 2023 | Business Agility, Flow Metrics, Lean

So how does Santa deliver millions of toys to everyone around the world?

As a parent, my children have asked this question a couple of times and I’ve always resorted to the vague answer of “Christmas magic”.

As someone who hangs out with a lot of Agile coaches, I can’t help but look at international, magical toy drop-off as a value delivery challenge.

I couldn’t exactly go to the North Pole and observe with a “Gemba Walk”, as coaches like to say, so I did the next best thing: I volunteered for Operation Blue Santa.

(more…)

Blog

8 Ways to Simplify Lean Portfolio Management

By: Agile Velocity | Oct 11, 2023 | Lean, Lean Portfolio Management

Lean Portfolio Management (LPM) has become a pivotal strategy for many organizations aiming to optimize their product development efforts and align them with business objectives. While the Scaled Agile Framework (SAFe®) is a popular methodology to implement LPM, some organizations find its intricacies, ceremonies, and overhead daunting. For organizations who want the benefits of LPM without the framework, there are other streamlined approaches. Here’s how:

(more…)

Blog

Kanban and SAFe^®: BFFs? Exploring Kanban, Scaling, and Lean-Agile Frameworks

By: Andy Cleff | Sep 26, 2023 | Kanban, Lean, SAFe

I recently had the opportunity to listen in during a LinkedIn/YouTube Live conversation between my fellow AV Transformation Coach Colleen Johnson and Roger Turnau, both seasoned Lean-Agile practitioners. Their discussion touched on various facets of Lean-Agile coaching methodologies, including visualizing working on Kanban boards and the challenges of scaling Agile in larger organizations.

As they discussed the frameworks and their respective principles, one intriguing question emerged in my mind: “Could Kanban and SAFe^® actually be BFFs?”

(more…)

Blog

Lean Prioritization Matrix (or Bang For Your Buck Matrix)

By:

Sally Tait & Randy Hale &

| Aug 23, 2023 | Leadership, Lean, Lean Portfolio Management

There are many ways to prioritize work…

MoSCoW (Must have, Should have, Could have, Won’t have)
WSJF (Weighted Shortest Job First)
HiPPO (Highest Paid Person’s Opinion…not recommended but it happens).

We work with organizations that have used all of the above, but our favorite ways to prioritize, and the ones that we recommend, have an undeniable connection to business value or value drivers.

(more…)

Blog

Webinar recording: Start Stopping! A Lean Approach to Portfolio and Budgeting Management

By:

Randy Hale & Sally Tait &

| Aug 15, 2023 | Business Transformation, Leadership, Lean, Video, Webinar

A key to improving the impact of your IT portfolio operations is identifying the things you need to stop doing!

In this video, Transformation Coaches Randy Hale and Sally Tait discuss how to:

Blog

Webinar Recording: Ensure Your Entire Organization is Delivering on the Right Things at the Right Time with Lean Portfolio Management

By: Agile Velocity | Apr 04, 2023 | Agile Transformation, Business Agility, Leadership, Lean, Strategy, Webinar

Companies needing to compete and win with less time, fewer resources, and more pressure to deliver can find massive benefits by implementing and running a lean portfolio. Organizations are often overloaded with competing priorities and more demand than capacity, so how do you decide what to focus on, when?

During this webinar Agile Transformation Coaches David Gipp and Colleen Johnson discussed:

Signs that your organization could benefit from LPM (Lean Portfolio Management)
Why shifting to a value-oriented, outcomes focus matters
The jobs to be done to set up a healthy LPM Function
Success measurements to track progress along the way
How to start the conversation in your organization

Blog

Kanban Best Practices & Cheat Sheet

By: Kerri Sutey | May 27, 2020 | Agile Tools, Kanban, Lean, Team

Image of Kanban board columns Idea, To Do, Doing, and Done The Kanban Method is a powerful way for Agile teams and organizations to visualize work, identify and eliminate bottlenecks, and achieve measurable operational improvements in throughput and quality. This article is a Kanban cheat sheet identifying best practices, meetings, and key terms.

Kanban Best Practices

Visualize the work
The Kanban Method is a powerful way for Agile teams and organizations to visualize work, identify and eliminate bottlenecks, and achieve measurable operational improvements in throughput and quality. A Kanban board can be maintained electronically within a tool or manually on a wall. Kanban boards can be team-specific, represent multiple teams, and even entire departments and organizations. The work visualized can be of any size tasks, stories, features, initiatives, projects, etc.

Limit WIP (Work in Process)
Limiting WIP allows us to reduce context-switching that can harm our team productivity. WIP Limits are applied to specific activity steps within the team’s process as typically modeled by a Kanban board. A WIP Limit is also known as a “constraint”, but not in a negative way. Teams do not have unlimited capacity, so think of WIP Limits as a descriptor of our reality within the work process and focusing mechanism.

Manage Flow
The main point of Kanban is to visualize how value flows through the system. This value is typically modeled as a work item card. The speed and smoothness of the work item movement across a Kanban board should be monitored and discussed in an ongoing manner.

Make Policies Explicit
Until rules are made explicit it is often difficult to have a discussion about how to improve. Making policies explicit helps create a shared understanding about how teams will move work through their system. Explicit policies for Kanban may include WIP Limits, Definition of Ready, Definition of Done, approval processes, and general team working agreements.

Implement Feedback Loops
Kanban is an evolutionary process of continuous improvement. The sooner we can get feedback, the quicker we can pivot if needed. Daily standups, replenishment meetings, delivery planning meetings, and retrospectives are a few practices teams can implement to set up feedback loops.

Improve collaboratively, evolve experimentally
Improvements should be small incremental changes over time that build on themselves and effectively fine-tune your team’s flow of value. Once teams have established their Kanban board and are using it, many opportunities for improvement will arise including removal of bottlenecks, creation of smoother flow, reduction of cycle time (from work start to Done), reduction of lead time (from request made to Done), throughput improvement, and variability reduction/increased predictability.

Kanban Meeting Cheat Sheet

While Kanban does not prescribe any specific meetings, many Kanban teams use the following meetings to ensure alignment of effort.

Daily Standup

Purpose: Team coordinates activities for the day which helps ensure they are working on the right priority items

Example Agenda:

The team walks the board, starting right to left, and provides an update to each other on progress and current WIP. Consider having the team answer:

- - Who can help on this item to get it to Done today?
  - What is blocking your work items from completion (flow)?
  - What did you learn yesterday that would benefit the team?

Weekly Replenishment

Purpose: Create shared understanding of the work and keep team members focused on the most critical work that needs to be done.

Example Agenda:

- - Review Definition of Ready (if the team has one) and WIP limits for Kanban Board columns
  - Review the backlog priorities together and break work down that is to large. Make a collaborative decision about what work items can be pulled in based on current WIP limits.
  - Identify dependencies & risks to be aware of when starting work on the newly replenished tasks. To reduce risk, determine if any work items can be deferred until later so that more knowledge can be gathered.
  - Confidence vote: Make sure all the details of the chosen work is clear to the team.
  - Optional/As needed: Discuss further details. Once the meeting has been concluded, there might be some smaller details that need further clarification. If that’s the case, make sure to address them as soon as possible so your team can be fully prepared to proceed with the execution of the work.

Monthly Retrospective

Purpose: Team reflects on how they are working to identify opportunities for improvement and feedback

Example Agenda:

- - Set the stage by reading the Prime Directive: “Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”
  - Gather the data from the latest metrics such as average cycle time, average lead time, and throughput.
  - Review how often WIP limits were followed.
  - Generate insights from the data. It is important to reflect on the improvements identified from the last retrospective and the impact those changes had on the metrics/process.
  - Decide what improvements to experiments with over the next month.
  - Close the retrospective by checking in with the team on overall team health, team progress and/or decisions made. This is also a great time to recognize and celebrate team successes.

Kanban Terms

Card/Task: Visually represent work items of value. Cards contain information about the work item. They are not different in size because the idea is to break a project down to its smallest tasks and complete them quickly.

Cumulative flow diagram: A visual chart/diagram/report which shows throughput, cycle time, and WIP. Agile tooling can create this for you.

Cycle time: Begins at the moment when the new arrival enters “in progress” stage and somebody is actually working on it until it enters the Done column.

Explicit Policies: Facilitates consensus (agreement) around improvement suggestions and minimizes the chance of misconceptions and lack of understanding.

Feedback Loops: Represent the circulation of info and change between (and during) the team’s meetings (daily standup, replenishment, and retro).

Kanban: The word literally means ‘signboard’ or ‘visual card’. In the late 1940s, it became a term for Toyota’s inventory management system and later evolved as a process management method.

Kaizen: The Japanese word for “continuous improvement”.

Pull System: No new work is started until started items are finished. When there is capacity, a new item is pulled in.

Swimlanes: The horizontal divisions of a Kanban board, helping to optimize the workflow. The columns represent steps, and swimlanes categorize work. Swimlanes can be used to represent classes of service, projects, etc.

Throughput: The number of items, passing through a system or process. According to Little’s Law, Average Throughput = Average WIP divided by average cycle time. The throughput of your team is a key indicator showing whether your process is productive or not.

Work In Progress (WIP): The amount of work in flight at the same time.

Blog

Lean Economics 101: Parallel Development Is Killing Your Productivity!

By: Mike Hall | Apr 09, 2018 | Article, Lean

This is another in a series of blogs on the topic of Lean Economics, emphasizing the economic aspects of product development. You can find the first post about WIP limits here.

As a developer, do you work multiple projects in parallel? As a leader, do you have a team which works multiple features in parallel? Is there more work than people?

Parallel Development is working multiple projects or features at the same time, as shown in the diagram below. It is a common situation I often see when coaching or delivering training. Parallel Development has, unfortunately, become commonplace in industry and accepted as the default standard way of organizing work as our work lives become busier and busier–just assign more and more projects to people, and hope they figure out how a way to get it all done!

Often times when I query for reasons behind this type of work model, the refrain is a familiar “We have more work than people. Thus, our people need to be good enough to work multiple projects and show good progress on all of them.”

Parallel Development: The Efficiency Killer

There are many disadvantages to Parallel Development including:

Delayed delivery of business value
High cost of context switching
Inefficient work model
Low employee morale

All of this can lead to a frustrating work environment where employees are routinely interrupted to begin work on a new project with no regard to their current workload. Everyone is 150% (or choose your number) allocated piecemeal across multiple projects. If the feeling of “starting is common, but finishing is uncommon” is pervasive, then your current work model is economically challenged and likely needs a major adjustment.

In a Parallel Development approach, the business value of each feature is delayed as the team members routinely multitask by working on multiple projects and features as shown in the figure above. Time lost in context-switching can be more than time applied to business value. Often in this situation, the desire to “show some progress” to all stakeholders is deemed more important than delivering value at the earliest point in time.

Serial Development: A Better Way!

The good news is this: there is a better way! Serial Development is when the Agile team focuses on a single project and single feature at a time.

Advantages of Serial Development include:

Consistent, early delivery of value
Limited context switching
Focused development work
High levels of employee satisfaction

Serial Development requires courage!

It requires the courage…

to ruthlessly prioritize features–not only within the same project but comparatively across multiple projects as shown in the figure below.
to allow the team to focus their development efforts on one feature at a time.
to inform your stakeholders as to when their features will likely be developed instead of “We have started, but not much progress yet”.

And Serial Development requires courage in the form of coaching your stakeholders that Serial Development will help ensure that their feature(s) gets the development team’s attention at the absolute earliest opportunity based on prioritization.

Comparison: Context Switching

Not convinced? Let’s compare Parallel Development versus Serial Development in terms of context switching. Parallel Development experiences significant context switching costs as the team members bounce back and forth across multiple features and projects trying their best to keep everyone happy. The generally accepted authority on the cost of context switching comes from the seminal book Quality Software Management: Systems Thinking by Gerald M. Weinberg.

In summary, if you are working on 5 projects in parallel, you are only 20% productive! Moving over to a Serial Development model will help you gain back the 80% productivity lost in context switching. Multiplying this by all members of your team can result in significant levels of productivity gain for the entire team!

Comparison: Value Delivery

Now let’s compare Parallel Development versus Serial Development in terms of delivery of value. I’ll use a simple example from one of our training courses. This example is feature-based but also applies to working multiple projects.

Setup: You work on a team that has a team backlog consisting of 3 features: A, B, and C. Each feature takes the entire team 1 month of time and delivers 1 unit of value. Let’s investigate the value graph across two scenarios – Parallel and Serial Development.

Scenario 1: Parallel Development with an assumed 40% context switching overhead (ref: Quality Software Management: Systems Thinking). The team multitasks across all 3 features making some progress each month (approximately 20% complete) while experiencing the context switching cost. At the end of month 1, no feature is completed. At the end of month 2, no feature is completed. Same for month 3, and same for month 4. Finally, at the end of month 5, the team delivers all 3 features.

Scenario 2: Serial Development focusing on 1 feature at a time. At the end of month 1, feature A is delivered. Context switching cost is minimized and occurs only during the planning associated with kicking off work on the new feature, e.g. during sprint planning and backlog refinement. The team delivers predictably, early and often, 1 feature per month. Delivered features continue their value month-to-month as the next feature is being worked on.

Comparing the two value graphs, which is better in terms of value delivery and cost of delay? In the Serial Development approach, the customers not only enjoy the incremental value of the features delivered as soon as possible, but they receive all 3 features in total much earlier than in Parallel Development!

Comparison: Revenue

As a final comparison, let’s look at a simple revenue example. In the above graphs, assume each feature delivers $100,000 of revenue each month.

For Parallel Development, the total cumulative revenue at the end of each month is:

Month 1: $0
Month 2: $0
Month 3: $0
Month 4: $0
Month 5: $0
Month 6: $300,000

For Serial Development, the total cumulative revenue at the end of each month is:

Month 1: $0
Month 2: $100,000
Month 3: $300,000
Month 4: $600,000
Month 5: $900,000
Month 6: $1,200,000

For Serial Development, the total revenue at the end of month 6 is 400% greater than Parallel Development. The bottom line for this example – developing features serially delivers the business $900,000 in additional revenues!

Four Steps to Begin Serial Development

Ruthlessly prioritize the feature requests across all project demands.
Group the user stories in your team backlog based on a single feature for a single project.
Pare the stories down to a minimum marketable feature that can be launched. Ideally, the team will be able to complete the highest priority minimum marketable feature in the next sprint (or two).
Encourage swarming within the iteration to focus on a few high-priority user stories and complete them as early in the sprint as possible. Effective use of WIP limits can lead to swarming

Stop the madness! Parallel Development is wrought with waste and creates a chaotic environment for employees. Serial Development is a much more economical work model ensuring the earliest delivery of value to the end customer and higher employee morale. If your team members are currently mired in Parallel Development, then take action to shift over to a focus-based Serial Development approach. This may take a bit of courage and hard work, but the benefits are so well worth it.

For more on how you can build lasting business agility, you can check out our Transformation Services page.

Blog

Lean Economics 101: The Power of WIP Limits

By: Mike Hall | Mar 13, 2018 | Article, Lean, Product Owner, ScrumMaster

This is the first in a series of blogs on the topic of Lean Economics, emphasizing the economic aspects of product development.

I have a friend who once emphatically stated “Agile will never work at my company because we have more projects than people! Everyone here works on 5 or 6 projects at the same time. It’s important to show some progress on all efforts to keep everyone happy.” Do you have firsthand experience being in this situation? I’ll share my response to him at the end.

The concept of Work In Process (WIP) – also called Work In Progress – comes from the world of Lean manufacturing. In Lean manufacturing, WIP is considered a form of inventory – the materials that are currently being worked. As such, it is actually considered “waste” because it ties up cash. That’s right – WIP is waste! It needs to be reduced.

Effective Use Of WIP

Effective use of WIP is when the team takes on a small amount of work, focuses on it, and works it to completion in a short period of time before pulling any additional work. This approach enables a consistent flow of value from the team (as indicated in the diagram below) and is considered much more desirable than context switching across multiple efforts in parallel.

Warning Signs You May Be Ignoring Lean Economics

Warning signs that you might not be considering the economics of product development include:

Many things started, but very little finished recently
Heavy multitasking
Costly context switching
Slow, painful deliveries
Lack of accuracy when predicting delivery scope and dates
Low product quality and constant rework

All of these add up to a very frustrated team overloaded with work that just seems to never get completed. Reliance on “heroes” is the norm. Overtime is rampant. Customer satisfaction is dropping. Stakeholders are screaming. We scream back: “We need more people!”, or better yet “Please just let me focus on one thing at a time!”

What is a WIP Limit?

The amount of work occurring at any one time is “limited” to what the team can accomplish in a short period of time and established by a constraint called the WIP limit.

A great description of the economics of WIP is described in Donald Reinertsen’s seminal book The Principles of Product Development Flow. At the time of this writing in 2008, less than 1% of all product development teams were managing WIP constraints. With the success of Agile methods and a renewed focus on the economics of product development, this number has improved greatly over the past years.

Most teams use a default WIP limit according to the available capacity of the team and what makes sense for the effort at hand. Development teams can set their WIP limits for the number of user stories (or tasks) in work at any one time. This WIP limit can provide opportunities for pairing and cross-training.

A Program Management team may have a WIP limit for the number of features being researched, the number of features ready for development, and the number of features currently being deployed. As you move into higher levels of planning in the organization, from individual programs to whole portfolios of programs, executives and business owners may have a WIP limit for the number of business cases being developed, the number of initiatives being considered for funding, and number of initiatives in development at one time. This level-by-level WIP approach helps to create an alignment of available capacity to the demand, and also provides a very important visible indicator as to what initiatives are truly being worked on and even more importantly, which ones are not!

Who sets the WIP limit? WIP limits are determined by the teams involved in the work at their respective level (team, program, or portfolio). Thus, team members at each level need a basic understanding of Lean economics and how adjusting the WIP limit can impact the flow of value – both positively and negatively.

What is the Right WIP Limit?

A WIP limit that is too small will result in idle workers and minimal flow of value. A WIP limit that is too large will result in delayed delivery and increased average cycle time (time from work starting until done). A WIP limit that is “just right” will result in optimized value flow and predictable delivery cycles. Often times finding the optimal WIP limit takes a bit of trial and error.

WIP limits can be adjusted from time to time in an experimental attempt to drive even higher levels of value. For example, an Agile team of 7 developers may adjust their “in work” user story WIP limit from a default of 7 down to 3 to ensure that a healthy amount of “swarming” is occurring on the highest priority user stories committed for the iteration. This supports the concept of demoing stories to the Product Owner as early in the iteration as possible and the possibility of continuous deployment. WIP can also be adjusted downward to account for the typical vacations and personnel outages that teams experience.

Visualizing WIP

WIP limits can be applied as work flows through the different stages of development. A common team-level storyboard example follows with WIP limits indicated in the appropriate columns. These WIP limits cannot be exceeded, forcing team members to consider helping others in pursuit of the larger goal of getting a user story to Done over beginning a new one.

Teams at the program and portfolio levels use the same technique with their specific column names and WIP limits.

What’s the Big Deal?

Applying WIP allows us to “stop starting, and start finishing”. Some advantages of WIP and the use of WIP limits include:

Improved flow of value through your team pipeline
Productivity gains due to less context switching
Ability to focus
Identification of bottlenecks and waste – leading to subsequent remedy
Improved cycle time
Promotion of cross-training and less reliance on “heroes”
Encouraging a focus on quality!

Conclusion

Now, regarding my friend’s comment about working 5 or 6 projects at once – I used the left hand portion of the first figure (“Working on many items in parallel”) to explain that his approach was making some progress on many things, and every time period check would hopefully show an adjustment in the horizontal progress bar. I deemed this approach “moving yardsticks” instead of truly completing work. In the end, all (yes, all) of his project stakeholders will end up disappointed to varying degrees. I then explained the tremendous cost of context switching across multiple efforts (ref: Quality Software Management: Systems Thinking). I also pointed out that his leaders were suffering from an unwillingness to make tough prioritization decisions, and that this often requires a cultural change at the leadership level – stay tuned for future blogs in this series discussing these concerns.

After a few more (lite) beers to let it all sink in, I explained the good news – there actually is a much better way! Organize all of the work into a single team backlog. Prioritize the work such that single features/stories can be worked to completion and context switching is reduced. Apply WIP limits at all levels (team, program, and portfolio) to ensure a healthy flow of value through the team’s work pipeline. And then say goodbye forever to unmet expectations!

Blog

Order Up! Agile and Lean Lessons From The Restaurant Industry

By: Resalin Gurka | Mar 15, 2017 | Article, Lean

Photo by Alexandra Gorn on Unsplash

Three weeks ago. It’s Friday night. We’re in a lazy mood so we hop in the car and go to the new neighborhood pizza place, Aviator Pizza. It’s our second time to go and it’s even busier than the first time, which is a good sign. The burger joint that occupied this space prior to Aviator didn’t last long.

Seems like blue skies are ahead for Aviator.

We order at the bar and find an open table to wait for our food and I spot the sign next to the side door. Written on a small chalkboard, “Grand Opening – March 4th.”

Since I started working in the Agile industry, I’ve started to see Agile and Lean thinking outside software development. Apparently, work followed me to pizza night. (more…)