LeanOrange | Scaling Lean|Agile in Government

Agile C’MON MAN – BUFD

January 17, 2013 — Leave a comment

[youtube http://www.youtube.com/watch?v=fhCks3bvTdA]

BUFD = Big Upfront Design = C’MON MAN!

Its been 12 years since the Agile Manifesto was signed and we are now living in a world where Continuous Deployment and HDD(Hypothesis Driven development) are driving rapid, profitable, product development. It seems Lean|Agile methods should be peaking mainstream adoption. So why is BUFD still prevalent? Why do I feel compelled to say “C‘MON MAN?”

bufd Simply put, I think its a case where the wrong people are in the driver’s seat. Often, we see IT driving product development instead of the Business. The larger the IT organization or project, the more “steering wheel time” IT seems to have. So what happens when you put a bunch of engineers in charge of product development? You get BUFD. That’s just how engineers think. I know…I am one!

So how did we get here?

After all Agile Manifesto principle #4 clearly states business and IT should work together daily. So aren’t they? Well yes…kind of! We usually see business folks involved with product development at planning, demo’s, and grooming sessions. However, they aren’t driving it. Why not? I think its largely due to the fact that they don’t know how!

Agile practices organically grew out of pain from development teams. Naturally, mature Agile practices consolidated on the delivery end of product development where development teams play. I think this has put product development organizations in a situation where they have relatively immature discovery practices as compared their delivery practices.

In layman’s terms organizations need better business practices to discover what IT should be working on and when!

In the next blog we will explore how we can put the business in the drivers seat to drive value and steer away from BUFD.

In Business Driven

The Death Spiral explained – Lean Laundry

January 10, 2013 — Leave a comment

LaundryPile A funny thing happened while I was writing our previous blog on Lean Laundry. I realized that my wife and I’s laundry mismanagement put us in death spiral mode. “Death spiral” mode is a common phenomena in software development that leads to the demise and failure of software projects. It is specifically prevalent on large scale software development efforts.

If it hurts…do it more often!

This is a principle in the Continuous Delivery book. Basically, if delivering software is hard, do it more often…not less often. Over time delivery events will become routine.

My wife and I were doing the exact opposite. Doing laundry had turned into a weekend long event. I kid you not. We have literally done 10-12 loads of laundry over a weekend. Because this sucked up so much energy and time, it drove some wonky behavior. You would think we would be more motivated to do laundry more often to keep up with the demand. However, it was quite the opposite. Sounds like software projects…eh? 😉

Laundry death spiral

The pain of doing laundry drove us to add buffer capacity in the form of an extra laundry basket. However it was only a matter of time before this overflowed and we were right back where we started, only worse. We were in the death spiral!

Bigger piles of laundry were leading to bigger piles of laundry and laundry inventory was everywhere. Piles of folded clothes could be found in random places from the last big batch of laundry. The worst of all was that the number of unmatched socks constantly floated around 25-30 pairs. This necessitated the need for a dedicated unmatched sock sorting bag to collect the large inventory of sock “defects.” Sound like a defect backlog? 😉

Software death spiral

While our personal laundry death spiral is a bit comical, it is a microcosm of software development projects. However, building software is exponentially more complex and can snowball out of control if not dealt with! The software death spiral goes as follows:

Software features, like laundry, begin to pile up for one reason or another
Deploying them becomes more complex and painful leading to more infrequent deliveries.
Infrequent deliveries lead to bigger releases.
Customers begin to stuff more features per release knowing that it will be longer to realize value. Releases get bigger.
Scope creep occurs with last second customer requests. Customers know if they don’t push for it, they will have to wait for the next big release to come around.
IT adds buffers and resources to manage the side effects of big release SDLC’s.
- Defect backlog(s) – think unmatched socks
- Organize functionally to gain functional efficiency for big batch processing
- Heavy weight vetting and requirements processes to manage those *pesky* customers
This continues until that vast majority of development work are defect backlog items
Customer(s) finds a different IT provider

Solution

Just like the solution to our laundry death spiral, the solution to software death spirals lies in Lean thinking. Shallow, uncommitted backlogs and frequent deliveries are two practices that will drive a ton of positive behavior momentum. With enough momentum you can reverse a the death spiral.

Shallow backlogs

Laundry – Use small laundry baskets equal to washing machine capacity.
Software – Keep product backlogs shallow and uncommitted. This maximizes flexibility and decreases wait times. Afterall, committed backlogs are just queues!

Frequent Deliveries

Laundry – Wash laundry when one of the small basket fills up.
Software – Deliver to production when a small batch of work has been completed. End of sprint delivery is a good goal. After that, check out Continuous Delivery principles and practices to enable smaller releases.

In Continuous Delivery, Lean

Lean Laundry

January 3, 2013 — Leave a comment

Fat Cat My wife and I were traveling home last week from visiting family over Christmas and we started the usual post Christmas conversation. It always starts with ranting about eating too much(see cat) of my mother inlaw’s Louisiana cooking and an action plan to work it off. Inevitably our retrospective conversation inspires other home improvement topics like organizing clutter and managing the continuous flow of laundry demand.

In our house the laundry saga is always in a constant state of disarray. For years my wife and I have tried countless experiments to keep up with our laundry demand. We tried the single-ringable neck approach(PO), a schedule, and we even a kanban board with WIP limits. None have worked long term!

As my wife and I were discussing our past failures and current laundry dilemma, I started to think about how Lean principles might help expose some solutions. So I got my geek on and started consulting with my wife. As I started peppering her with situational questions a severe pain point emerged! Unbeknownst to me(probably why I’m not allowed to do laundry anymore ;-), we have six different types of work as it relates to our laundry. Before washing, the laundry must be sorted appropriately. The six different types of work are: LaundryPile

Light delicates
Dark delicates
White regular
Dark regular
Light colored towels
Dark colored towels

My wife mentioned that she spends a lot of time sorting. Of course, like any good root cause analyzer, I asked WHY. And she says…wait for it Lean enthusiasts…because she has to sort through the whole batch at one time! Boy was I relieved. I can handle large batch sizes. 😉

Laundry Buffers

Large batch sorting was such a pain that we began to do it less often. This led to piles of laundry overflowing from the baskets. Like any wise management initiative, we solved that problem by throwing more resources at it and getting another laundry basket. Of course that quickly filled up and we began finding other nooks and crannies in our house to establish laundry buffers. We were on the verge going to Laundry Anonymous!

The Solution

The answer was staring us in the face. We needed shallow queues(laundry backlog) and eliminate our laundry buffers. So we made a trip to the store and bought four small laundry baskets that do not exceed the capacity of our washing machine. One for each of the following: delicates, darks, lights, and towels(gets us most of the sorting as work enters the laundry queue). We also have a policy in place that as soon as one fills up, we throw it in the washing machine.

The shallow baskets have dramatically decreased the wait time for my favorite dress shirts and believe it or not, the throughput has picked up! What scientific data do I have to prove that??? A happy wife who spends less time stressing over trying to keep up with the laundry demand!

In Lean

Merry Christmas

December 24, 2012 — Leave a comment

Santa’s workshop is almost finished!

Merry Christmas from LeanOrange!

In Agile, Kanban, Lean, Lean Agile, Scaled Agile, Scrum

Batch Size Solutions in…the Agile Zone

December 20, 2012 — Leave a comment

SolutionsImminentTwilightZone

In the previous post in the Twilight Zone series we outlined some pretty serious issues in product development when Batch Sizes increase. Since we aren’t bomb thrower consultants we hope to provide some practical advice to help reduce batch size. Of course many of these ideas come from Don Reinertsen’s book, Principles of Product Development Flow, which YOU should read!

We also will showcase the connection between reducing batch size and business areas beyond development. Our aim is to highlight the need for Lean|Agile thinking to bring agility to the whole organization.

Reduce Batch Size

Large batch sizes have a lot of bad stuff associated with them. Some of them include: project slippage due to higher utilization; long feedback loops; high rates of shelfware; and redundant defects.
So what combats this?
- Collocation – Batch sizes are proportional to physical proximity. Close proximity communication among teams encourages smaller batches of information sharing. You may need to engage Facilities Support to make this happen.
- Infrastructure – Faster compile, build, integration, and test cycles encourage work in smaller batches. Think about it, if it takes 30 minutes for a developer to get feedback on his/her most recent committed change, they are likely to batch more changes per commit. We will probably need to engage Ops for infrastructure support and possibly Architecture to help create more modularized designs.
- Limit Work in Process(WIP) – WIP is shelfware and any work not delivered to production. In manufacturing this is equivalent to inventory that clutters the factory floor. In software, this is equivalent to designs, code, …etc that clutters our minds. To get rid of this we need Management to understand the cause and effect of limiting WIP. We also need upstream buyin, because when we Limit WIP downstream, you will cause traffic jams upstream, which will cause Executives, Requirements, Architects, …etc heartburn.
- Continuous Flow of Value Discovery – Many defects in product development can be attributed to poor value discovery. Large batches create significant time delays between value discovery and actual development. The accuracy of the assumptions or information captured during the discovery of value tends to decay over time. So this time delay introduces bad information into the development process, which leads to defects. Worse yet, an assumption or piece of information may be redundant across many design decisions which causes a widespread defect. Therefore, the upstream participants involved with discovering value, typically the Customer, Requirements, Executives, Marketing, Sales, and Product Management, must do this on an ongoing basis to provide as much value information to the development teams.
  - This requires a standardized set of business practices to take in, analyze, prioritize, decompose, sequence and validate work.

So far we’ve identified several business areas beyond Development that influences batch size and ultimately the business agility of the whole organization. They include:

Facilities, Ops, Architecture, Management, Executives
Requirements, Customers, Marketing, Sales, Product Management

While Batch Size is just one of many principles that influences enterprise agility, we hope the Twilight Blog series has showcased how an entire organization influences enterprise agility. So next time someone suggests that “Agile” only concerns Development…point them to this blog series.

Cheers!

In Enterprise Agility, House of Lean, Lean, Lean Agile