Moving Agile Forward

Rethinking What’s Next in Software Development

Al Shalloway is an acknowledged thought leader in how we design and develop software. In this post, he begins the conversation about where we are headed next. It seems that everyone is in software development these days and most agree that we need to improve. Al notes that the original manifesto mentions the Agile Manifesto mentions “the team 17 times, the customer 3 times, business twice and management not at all.” But rather than impaling the sacred Agile Manifesto cow, he offers us a place to start the conversation with his personal manifesto.

I think this is a wonderful place to start a conversation about where we go from here. If you have an opinion about how the software business needs to change, I encourage you to read this post.

bh 5/30/2017

A Personal Manifesto | Net Objectives

May 28, 2017 — Posted by Al Shalloway

Background and the Agile Manifesto.I have been asked several times to help in the rewrite of an Agile Manifesto.  After having been involved in Snowbird 10 (the reunion of some of the original Agile Manifesto authors along with some others from the Lean/Kanban community) I realized there is no “Agile” community. Rather we have many sub-communities that are so diverse it is hard to think of them as being under one umbrella.
click here for more…

 

Source: A Personal Manifesto | Net Objectives blog

Advertisements

Kanban Distilled for Managers

This is a repost from kanbandistilled.com/ . Their website reports that they will be back soon… but until then, here is a great explaniation of how a kanban can work in software development. If you’re interested, click here for a Lean Glossary (adapted from Richard Durnall’s blog).
 
Bob Hubbard, Atlanta Georgia USA

Kanban is a technique for managing a software development process in a highly efficient way. Kanban underpins Toyota’s “just-in-time” (JIT) production system. Although producing software is a creative activity and therefore different to mass-producing cars, the underlying mechanism for managing the production line can still be applied.A software development process can be thought of as a pipeline with feature requests entering one end and improved software emerging from the other end.

Software Pipeline

Inside the pipeline, there will be some kind of process which could range from an informal ad hoc process to a highly formal phased process. In this article, we’ll assume a simple phased process of: (1) analyse the requirements, (2) develop the code, and (3) test it works.

The Effect of Bottlenecks

A bottleneck in a pipeline restricts flow. The throughput of the pipeline as a whole is limited to the throughput of the bottleneck.

Using our development pipeline as an example: if the testers are only able to test 5 features per week whereas the developers and analysts have the capacity to produce 10 features per week, the throughput of the pipeline as a whole will only be 5 features per week because the testers are acting as a bottleneck.

Effect of Bottlenecks

If the analysts and developers aren’t aware that the testers are the bottleneck, then a backlog of work will begin to pile up in front of the testers.

The effect is that lead times go up. And, like warehouse stock, work sitting in the pipeline ties up investment, creates distance from the market, and drops in value as time goes by.

Inevitably, quality suffers. To keep up, the testers start to cut corners. The resulting bugs released into production cause problems for the users and waste future pipeline capacity.

If, on the other hand, we knew where the bottleneck was, we could redeploy resources to help relieve it. For example, the analysts could help with testing and the developers could work on test automation.

But how do we know where the bottleneck is in any given process? And what happens when it moves?

Kanban reveals bottlenecks dynamically

Kanban is incredibly simple, but at the same time incredibly powerful. In its simplest incarnation, a kanban system consists of a big board on the wall with cards or sticky notes placed in columns with numbers at the top.

Limiting work-in-progress reveals the bottlenecks so you can address them.

The cards represent work items as they flow through the development process represented by the columns. The numbers at the top of each column are limits on the number of cards allowed in each column.

The limits are the critical difference between a kanban board and any other visual storyboard. Limiting the amount of work-in-progress (WIP), at each step in the process, prevents overproduction and reveals bottlenecks dynamically so that you can address them before they get out of hand.

Worked Example

The board below shows a situation where the developers and analysts are being prevented from taking on any more work until the testers free up a slot and pull in the next work item. At this point the developers and analysts should be looking at ways they can help relieve the burden on the testers.

Notice that we’ve split some of the columns in two, to indicate items being worked on and those finished and ready to be pulled by the downsteam process. There are several different ways you can layout out the board. This is a fairly simple way. The limits at the top of the split columns cover both the “doing” and “done” columns.

Once the testers have finished testing a feature, they move the card and free up a slot in the “Test” column.

Now the empty slot in the “Test” column can be filled by one of the cards in the development “done” column. That frees up a slot under “Development” and the next card can be pulled from the “Analysis” column and so on.

Next steps

How to get started with Kanban…

  1. Map your value stream (your development process).
    Where do feature ideas come from? What are all the steps that the idea goes through until it’s sitting in the hands of the end-user?
  2. Define the start and end points for the Kanban system.
    These should preferably be where you have political control. Don’t worry too much about starting with a narrow focus, as people outside the span will soon ask to join in.
  3. Agree:
    • Initial WIP limits and policies for changing or temporarily breaking them
    • Process for prioritising and selecting features
    • Policies for different classes of service (e.g. “standard”, “expedite”, “fixed delivery date”). Are estimates needed? When choosing work, which will be selected first?
    • Frequency of reviews
  4. Draw up a Kanban board.
    All you need is a whiteboard and some Post-It™ notes. Don’t spend too much time making it look beautiful because it will almost certainly evolve.
  5. Start using it.
  6. Empirically adjust.

from kanbandistilled.com/

Lean Software Development Podcasts

This is a great series of podcasts on Lean Software Development. 

Listen to the webinar audio Chapter 1: A Developer’s Guide to Lean Software Development 

This show continues a chapter by chapter discussion about the new book, Lean-Agile Software Development: Achieving Enterprise Agility, by Alan Shalloway, Guy Beaver, and Jim Trott.  

This show focuses on Chapter 1, A Developers Guide ot Lean Software Development. We start to answer the question, if Lean’s goal is to focus on speed, quality, and low cost. How do you do it? 

 In the past, the approach has been to try to make every step and every person as efficient as possible. THat doesn’t work. Instead, you have to look at optimizing the whole process. It is different than efficiency and cost; in fact, lowering cost can increase speed to market and lower quality. 

Lean says the better approach is to focus on removing delays. 

Full article: http://www.netobjectives.com/blogs/lean-agile-software-development-chapter1 


 Listen to the webinar audio Chapter 2: The Business Case for Agility 

This show continues a chapter by chapter discussion about the new book, Lean-Agile Software Development: Achieving Enterprise Agility, by Alan Shalloway, Guy Beaver, and Jim Trott.  

This show focuses on Chapter 2, The Business Case for Agility. We cover the five most important reasons for going Agile and how it is that understanding the whys of Agile helps you with this transition. 

It is important to understand the reasons for going Agile. Perhaps as important is understanding the whys of Agile: It helps you navigate your journey as you make the transition. Here are five of the most important reasons for going Agile: 

  1. Deliver value quicker.
    Getting to market quicker is good. It is often possible to deliver some important features in stages. It allows faster return with less investment and that is always good!
  2. Helping customers discover what it is they need.
    Agile is best understood as a process that helps customers and developers discover in stages what it is that software should do. It helps customers focus on specifying what they know and avoid having to guess about requirements that they are not yet sure of. The most important book that covers this is Software by Numbers by Denne and Clelland-Huang.
  3. Better project management.
    Waterfall tends to steer projects based on milestones, which is an inaccurate guide about where a project really is. Agile steers based on working code which is much more accurate.
  4. Improving process faster.
    It would be better if teams learned continually but at least Lean-Agile has them learn after each iteration. Short iterations let teams learn quickly what is working and what is not. It is much better to learn lessons after two weeks rather than after two months! 
  5. Letting your design emerge based on what you are learning.
    While it is often ignored, there is also a technical reason for going Agile. With some discipline and appropriate tools (automated regression testing), it is possible to avoid up front design (almost always wrong or incomplete) and allow design to emerge based on what the team is discovering. This is powerful. There are two good books that describe why this is so: 

Emergent Design: The Evolutionary Nature of Professional Software Development by Scott Bain

Agile Software Development, Principles, Patterns, and Practices by Bob Martin

Full article: http://www.netobjectives.com/blogs/lean-agile-software-development-chapter2-business-case-for-agility

Listen to the webinar audio Chapter 3: The Big Picture

This show continues a chapter by chapter discussion about the new book, Lean-Agile Software Development: Achieving Enterprise Agility, by Alan Shalloway, Guy Beaver, and Jim Trott. 

This show focuses on Chapter 3, The Big Picture. We talk about why, if you want to see improvements in throughput in product development, it is vital to focus on the entire value stream, the entire process from when an idea is formed until it reaches the user or customer. In fact, a transition to Lean-Agile involves agility in at least four areas.

It is not enough just to focus on helping developers. In order to see improvements in the throughput for product development, you have to look at the whole value stream: the entire process from when an idea is formed until it reaches the user or customer. You want to focus not on where you are spending your money but where you are spending your time. And this means looking at the time you spend waiting as well. Keeping people busy can be counter-productive if it keeps them from being available on the most important things. Think of it this way: What is the impact if projects are having to wait on the most productive, highest value people just because they are working on too many things?

Agile coaches often have a technical background. This means that too often, Agile deployments focus chiefly on helping developers. This is good and necessary but it is not sufficient. If delays are being caused elsewhere, then improving development will only offer marginal gains. When you are transitioning, you have to look at improving agility in four areas:

  • Team agility
  • Technical agility
  • Management agility
  • Business agility

Of course, where to start depends on your situation.

Read more: http://www.netobjectives.com/blogs/lean-agile-software-development-chapter3-big-picture

 Listen to the webinar audio Chapter 4: Lean Portfolio Management

This show continues a chapter by chapter discussion about the new book, Lean-Agile Software Development: Achieving Enterprise Agility, by Alan Shalloway, Guy Beaver, and Jim Trott. 

This show focuses on Chapter 4, Lean Portfolio Management. The premise is that managing the work you are feeding the team is more important than how well the team works.

What you want is for the business to drive small increments, giving the development team just enough to get value out at a sustainable pace. It is possible to do a better job planning! There are many techniques and that is the subject of another book. However, just knowing about shorter planning increments does help. Smaller, well-defined things running through the pipeline is better than big batches that clog things up.

There is another benefit. We build these big project plans and even though we know they won’t work as laid out, they seem to take a life of their own. If someone proposes a change request, it is a huge effort because those plans are so cumbersome. Lean portfolio management cuts through all of this! Since we are planning in shorter cycles, if a new change comes through, we just compare it with all of the other requirements in the next cycle and insert it if has higher business value. Those change boards – so bedeviling – become a thing of the past.

Read more: http://www.netobjectives.com/blogs/lean-agile-software-development-chapter4-lean-portfolio-management 

Listen to the webinar audio Introducing Kanban for Software

Phil Cave is a new consultant with Net Objectives. Phil has a long history with Lean, XP, Scrum, and Kanban. He has worked at all levels: developer, lead, manager, division manager, vice-president, Lean coach.  Phil just got back from Krackow, teaching our Lean Software Development course. Half of this course involved helping them integrate the Kanban technique into their Lean-Agile software methodology. Kanban is gaining ground as an important technique for Lean-Agile groups because it is widely applicable in both process-oriented and specialty-oriented shops. It does not require fundamental shifts in work (unlike other Agile methods) if that is not appropriate for you. It is something we need to learn more about.

Here at the end of the year, I want to express how grateful I am for you. I hope you have a blessed holiday and a warm new year. I look forward to being with you again in January.

Recommendations


Links above are from the Net Objectives website at:  http://www.netobjectives.com/

The Three M’s – The Lean Triad

Posted by Roman Pichler on Feb 27, 2008 @ http://www.infoq.com/

The discussion of applying lean principles to software development has largely focused on identifying and eliminating waste (in Japanese: muda). Lean Thinking equally aims to remove overburden (Japanese: muri) and unnecessary variation (Japanese: mura). Muda, muri and mura are called “the three M’s.” Together they form a dissonant triad. All three M’s must be eliminated to create a sustainable lean process. This article discusses the relationship between the three M’s and argues that the elimination of overburden should be the first step for software development organizations in order to create a lean process.

(see the complete article: http://www.infoq.com/articles/lean-muda-muri-mura)

bh

Kanban

Kanban is a lean approach to agile software development.

­­Actually, Kanban means many things. Literally, Kanban is a Japanese word that means “visual card”. At Toyota, Kanban is the term used for the visual & physical signaling system that ties together the whole Lean Production system.

Most agile methods such as Scrum and XP are already well aligned with lean principles. In 2004, however, David Anderson pioneered a more direct implementation of Lean Thinking and Theory of Constraints to software development. Under the guidance of experts such as Don Reinertsen, this evolved into what David called a “Kanban system for software development”, and which most people now simply refer to as “Kanban”.

­So while Kanban as applied to software development is new, Kanban as used in Lean Production is over a half century old.

Does Kanban matter to me?

Do any of these sound familiar?

  • “We’ve done Scrum for a long time now and our process improvement has levelled off. How can we take our process to the next level?”
  • “Our needs and priorities shift on a daily basis”
  • “We don’t like fixed-length, fixed-commitment iterations”
  • “We are spending too much time planning and estimating”

If so, read on. Along with Scrum and XP, Kanban should be part of the process toolkit of any agile company. The choice of where & when to use it can only be made by you though.

How does Kanban work?

There are many flavors, but the core of Kanban means:

  1. Visualize the workflow
    • Split the work into pieces, write each item on a card and put on the wall.
    • Use named columns to illustrate where each item is in the workflow.
  2. Limit WIP (work in progress) – assign explicit limits to how many items may be in progress at each workflow state.
  3. Measure the lead time (average time to complete one item, sometimes called “cycle time”), optimize the process to make lead time as small and predictable as possible.

This is a direct implementation of a lean pull scheduling system.

Here’s an example of a simple Kanban board, with WIP limits in red.

Here’s a more complex one (see Kanban kick-start example for a closer look & description)

Kanban board ­

What are the benefits of Kanban?

Some commonly observed benefits are:

  • Bottlenecks become clearly visible in real-time. This leads people to collaborate to optimize the whole value chain rather than just their part.
  • Provides a more gradual evolution path from waterfall to agile software development, thereby helping companies that previously have been unable or unwilling to try agile methods.
  • Provides a way to do agile software development without necessarily having to use time-boxed fixed-commitment iterations such as Scrum sprints. Useful for situations where sprints don’t make much sends, such as operations and support teams with a high rate of uncertainty and variabilty.
  • Tends to naturally spread throughout the organization to other departments such as HR and sales, thereby increasing visibility of everything that is going on the company.

Can I combine Kanban with my current process?

Yes. In fact, you should combine it.

In Kanban the first step is to visualize your current process, just as it is, in order to see where the bottlenecks are. Then you introduce WIP limits and start a path of evolution that may or may not modify or replace your current process over time.

See “Kanban & Scrum – making the most of both”, where Henrik Kniberg and Mattias Skarin illustrate how Kanban and Scrum relate to each other.

Where is Kanban used?

Our coaches at Crisp have helped several clients use Kanban to improve their process. In fact, a surprising number of our clients have found that Kanban is an extremely useful complement (or sometimes even a replacement) to other popular agile methods such as Scrum. Typical manager comment: “It really helps us visualize our projects and situation”.

There is also an increasing number of case studies available at www.limitedwipsociety.org.  Here are a few examples:

Common misunderstandings about Kanban

  • Myth: With Kanban you don’t use iterations
  • Fact: With Kanban iterations are optional. Do it only if you have a need for it in your context.
  • Myth: With Kanban you don’t estimate
  • Fact: With Kanban estimation is optional. Do it only if you have a need for it in your context.
  • Myth: Kanban is better than Scrum/XP/RUP/whatever
  • Fact: Kanban is just a process tool, and there is no such thing as a universally good or bad tool. It all depends on your context
  • Myth: Kanban is a drop-in replacement to Scrum/XP/RUP/whatever
  • Fact: Kanban is just about managing workflow. It hardly replaces anything. What it does do, however, is drive change. In Kanban you start with whatever process you have, visualize it, introduce WIP limits, and then evolve from there.

Further reading