{ Category Archives }

lean

Coming events: April 21, Vancouver BC

Lean Development for Lean Times

Agile Vancouver is a non-profit user group run by volunteers.

We are affiliated with the Agile Alliance and host lively regular monthly meetings to promote the state-of-the-art wherever we can.

On Tuesday April 21st, we are hosting an afternoon event on the application of Lean Principles to software development. This workshop brings together leading thinkers from Lean Production and Lean software. On the agenda, we have three interactive sessions:

  • An Introduction to Lean Product Development – Katherine Radeka
  • Scrumban: Lean Thinking for Agile Process Evolution – Corey Ladas
  • The Lean Startup: a Disciplined Approach to Imagining, Designing, and Building New Product – Eric Reis

The event will run from 2:30pm to 7:00pm at the Plaza 500 (the same venue as previous Agile Vancouver conferences). Please register to attend this event as space will be limited. There is a $25 fee to secure your registration for the event. If you have any questions about registration, please contact us at registration@agilevancouver.net.
Speaker Bios:

  • Corey Ladas is a master of applying Kanban systems to Agile projects and the editor of Lean Software Engineering blog
  • Katherine Radeka is an expert in the application in Lean principles to product development with a track record of successful products and successful product development transformations
  • Eric Ries is the former CTO of IMVU and champion of the Lean Startup

2009 03 26

Comments (0)

Print This Post Print This Post

Email This Post Email This Post

Permalink

Twitter Weekly Updates for 2009-03-09

  • Kanban regulates work, not workers.
  • Every process is a queue, not just the buffers.  Workflow buffers can be in time, space, or capacity. Each is a tool, none are “correct.”
  • Behold! The mighty Invariant. http://tinyurl.com/dyhelw
  • A Minimum Marketable Feature is the smallest unit of work that has recognizable value to the customer. If a Minimum Marketable Feature could be made any smaller, then either it wasn’t Minimum, or it no longer has value to the customer. The Minimum Marketable Feature is the most natural unit of scheduling for Lean and Evolutionary Development.  The Minimum Marketable Feature is the most valuable product of Rolling Wave Planning.  A Minimum Marketable Feature can be decomposed into User Stories, Use Cases, BDD Scenarios, etc. for detailed work scheduling.  Minimum Marketable Features can be staggered and overlapped for production leveling of skills and roles.  A Sprint Goal is a substitute for having a real business-valued goal. A Minimum Marketable Feature is the real thing.
  • The “Feature Crew” process is a kanban system for Minimum Marketable Features.  A Feature Crew system can scale up to hundreds of people.
  • Alan Shalloway on future of Lean software development: http://tinyurl.com/b3q6f5
  • In Evolutionary Design, the same requirement may be implemented more than once. This is not rework, because no mistake has been made.
  • Bottom up: A Design Parameter is “what the system does.” A Functional Requirement is “why the system does it.”  Top down: A Functional Requirement is “what the system should do.” A Design Parameter is “how the system will do it.”
  • I find greater value in the ideas of Deming, Ohno, and Goldratt. I am not the only person who feels this way.
  • One man’s good engineering practice is another man’s criminal negligence.
  • If continuous testing and continuous integration are good, then continuous planning might also be good: http://is.gd/m98c
  • My opinion of Peter Middleton and James Sutton’s book “Lean Software Strategies” only grows over time. http://is.gd/lFgb
  • The purpose of business is not to give programmers something to do.

Powered by Twitter Tools.

2009 03 09

Comments (0)

Print This Post Print This Post

Email This Post Email This Post

Permalink

Backflows are self-regulating

Some iterative development enthusiasts seem to get very nervous about detailed visual controls, or indeed any kind of suggestion that something predictable happens to new software features while they are under development. I think the fear is that this is (or will become) some kind of prescriptive serialized process that inhibits iteration. 

I worry that an important point has been lost in some of the discussion about the WIP-limited workflow systems that we promote. The purpose of the kanban limits is to inhibit forward flows, not backward flows. Pull workflow systems handle design iteration just fine. I would never have gone down this path if they didn’t, but don’t take that as an endorsement that you should iterate with wild abandon. Consider this advice from Ron Jeffries:

I prefer treating the acceptance criteria given at story insertion
time as definitive. When those tests run, the story is done.

If the customer decides that the story needs more work, s/he can
just make a new story with the changes. AND … there is an
opportunity to learn how to think a little more about what is
wanted, and how to express it.

The basic idea is quite simple: we don’t undertake to build anything
until we have an agreement on what constitutes done. We can go ahead
on a very firm notion, or a very soft one … but whatever that
notion is, we make it concrete and live with it.

Your goal is actually to minimize cycle time and minimize variation in normalized cycle time. Let me say that again. The fundamental measure of a Lean process is its cycle time. The reason you should care about all of this Lean business is because that is your goal. In-process iteration has consequences for cycle time, so please be aware.

The reason why backflows are not a problem is that you can’t really give the kanban back until a process is complete, and a process isn’t complete until the person that gave you the kanban decides that it’s complete. Until then, the kanban is still in process. This might be problematic if we used per-station takt time, but we don’t, so it isn’t. Remember, we’re not operating a factory assembly line, and we don’t pretend to.

Even though one kanban might be exchanged for another one at different stages in the workflow, the total number of kanban in the system never changes as a result of a backflow.  Some consequences of backflow are different for information system development because of the physical nature of the facilities involved. Brains and computers are typically much more flexible and adaptive than machine tools. Which is not to say that iterative backflows are without consequence. On the contrary, the system will react strongly to their presence by freeing up resources to help them to move forward again.  That kind of “swarming behavior” is fully expected and exactly what we want.

2009 02 26

Comments (9)

Print This Post Print This Post

Email This Post Email This Post

Permalink

Leanroom!

Cleanroom is a high-capability iterative development process that can be made to flow:

cleanroom

Is Cleanroom Agile?

“The technical basis for incremental development in Cleanroom is the
mathematical property of referential transparency.”

Who knows?  But we can definitely make it Lean.

Thanks to MP for the riff.


2009 02 04

Comments (2)

Print This Post Print This Post

Email This Post Email This Post

Permalink

Video: Lean Thinking for Agile Process Evolution

Merlyn Albery-Speyer invited me to speak at Extreme Programming Portland (XPDX) this month and was kind enough to put up a video of the event. Thank you to all who put on the event and made these recordings.

Part 1 (45 min): Lean Thinking in software development, Deming and quality, customer pull vs Kano model and gemba:

Part 2 (60 min): Cumulative flow diagrams, pull and kanban, kanban and Scrum, Scrumban:

Part 3 on evolutionary design, minimum marketable features, and feature crews did not make it to video (sorry, maybe next time!)

2009 01 23

Comments (1)

Print This Post Print This Post

Email This Post Email This Post

Permalink

« Older posts
Newer posts »
Close
E-mail It
Socialized through Gregarious 42