Ballot Debris

Thoughts on Agile Management, Leadership and Software Engineering

Agile and the Boom/Bust Cycle

clock March 26, 2012 05:29 by author Chad Albrecht

I spend a fair amount of time these days working with senior business leaders on some of the challenges they face.  One of the things that both they and I are seeing is the impact of shorter business cycles on planning.  While the use of the word “cycle” implies that these changes occur with some predictability, it is also clear from observation that they do not.  In fact, many economist choose to use the term “fluctuation” over “cycle” to denote its chaotic nature.   Many factors go into making our economy behave this way, globalization, decreasing consumer attention span, less brand affinity, increasing technology and government intervention to name a few.  The real question many leaders face as it relates to these cycles is “How long do I have to get my product or service offering to market?”  They want to understand how quickly they can take and idea to market without having the ground shift from underneath them.  When I started in the technology space in the early nineties, project lengths of many years were not uncommon.  For many companies, releasing a piece of software once a year was a challenge.  If you had hardware to go with the software (think game console, cell phones, etc.) you could pretty much kiss the once a year thing goodbye.  This was the way it was.  Consumers didn’t expect more, competitors probably couldn’t do better and our detailed design specifications were as much work as the product itself.  Over the last 20 years, this has all changed.  Consumers demand the latest and greatest, our economy is wildly unpredictable, startup competition can build products from start to finish in months and many companies are now releasing software “continually.”

Many leaders are looking at these new conditions and realizing that the ways of the past are no longer suitable.  These leaders look at their companies, consumers and competition and make thoughtful choices about where to go and what to do.  They are not surprised by changes as this is now the norm.  An example of this if Flickr which started as an online gaming company but quickly realized there was more of a demand for their photo sharing feature.  This change in direction, also known as a “pivot,” is becoming a key piece of modern business practices.  Making a significant change in the direction of an organization requires software development techniques that can readily deal with it.  Enter Agile.

Agile development is a general term for many different techniques but the piece that is common to most of them is a focus on delivering done software frequently.  In Scrum we do this every Sprint. In XP this is done every Iteration. With Continuous Delivery this is done…well continuously.  When leaders have the confidence and understanding that the product they are building is always in a done state, they can “pivot” more readily and cost-effectively.  It’s clear from the state of the market that and organization that can most readily respond to change is going to prevail.  If you are leading an organization that produces a product, have you asked yourself “How able are we to respond to change?”  An honest answer to that question will likely indicate the future success of your organization.



Analyze your Value Stream, A Quick How To Guide

clock February 2, 2010 07:16 by author Chad Albrecht

Inspired by Michael Dubakov's article Flow. Discover Problems and Waste in Kanban, I thought I’d spend some time looking at Value Stream Analysis.

We talk a lot these days about delivering value to our clients, but many of us don’t understand the details of how that is accomplished.  Sure we understand that raw ones and zeros couldn’t be sold for the same amount as the aggregated application, but let’s take a more concise look at a couple questions?  1) How do we define value.  and 2) How do we analyze the process by which we deliver value? (Value Stream)

The first question we seek to better understand is the definition of value.  Without diving head first into an economics discussion, we can simply look at value as our client’s perceived worth of the product or service we provide.  This has a dollar figure attached to it.  While one can argue that value is also inclusive of the qualitative aspects of our product or service, it is not easily measured, so for purposes of this discussion can be ignored.  I defined a method of assigning a dollar value to SaaS features in one of my previous posts.  This method can also be used to determine the dollar value of a release, iteration, feature or task on either products or services.  With a dollar value in hand we can begin to look at answering question #2.

As we begin to examine our Value Stream, I would be remiss without mentioning the work of all the people that have contributed work in this area, Eliyahu M. Goldratt, Taiichi Ohno, James Womak, Kent Beck, Mary Poppendieck and Tom Poppendieck, to name just a few.  In Tom and Mary’s book Lean Software Development, they present Tool #2 - Value Stream Mapping which gives us a good way to visually represent our Value Stream:

 

image

 

If we look at the figure above, we see the typical steps that an Agile team may follow transforming an idea into reality.  There is active work that is done on the idea/feature (above the line, value add) and time when the idea/feature sits dormant. (below the line, waste)  Examining the timing of the above hypothetical flow, we can see that the overall process took 18 weeks with 11 weeks (61%) delivering value and 7 weeks (39%) of waste.  This example is a bit far fetched but is meant to provide a simple means of showing how the map works.  You may find it more useful to use days as a unit-of measure or even hours.  The point here being that you may be able to reduce your feature time to market to only 11 weeks if you could only avoid wait time.  If we assume that the feature we are developing will provide $5000 of value in the market, (to our clients) then at 18 weeks we are only delivering $278 of value a week, whereas we hit $455 a week when we do it in 11 weeks.

This can be a very useful tool for improving the productivity of your development organization but we need one more piece to make it effective.  Since we are not developing one feature at a time we need to understand the effects of multiple features flowing through our value stream.  If we only seek to optimize the flow of one feature’s flow we may do that at the expense of others.  We must look at the system as a whole and try to optimize elements that will reduce our wait time for all ideas/features currently in progress.  This is not an easy task.  You should look at the steps that are costly first and try to identify the pain points in those steps.  For instance, if there are days lost because team members are unaware of a status change, seek to implement a tool that sends automated emails on status change.

In summary, here are the steps to analyze your value stream:

  1. Create a map of the steps that an idea takes from concept to delivery.
  2. Measure the value-add and wait time of a number of ideas as they flow through this map.
  3. Assign a dollar value to your ideas and measure your current weekly value and share this with the team.
  4. If changes were already made to try to increase the flow of value, did they work? By how much?
  5. As a team, come up with changes that will increase the flow of ALL ideas through the system.
  6. Implement these new changes and go back to #2.


SLKK - A New Agile Toolset

clock July 19, 2009 11:06 by author Chad Albrecht

In much the same way Michael Kunze coined the acronym LAMP, I propose the use of a new industry acronym for Agile. Scrum, Lean, Kanban & Kaizen. (SLKK, pronounced slick)  I have successfully used this process which incorporates techniques from all of these areas and felt it needed a name.  I also feel that it will be very useful to many of you that are already using or just beginning to use Agile.

 

Scrum – Describes the artifacts, meetings, backlog and iteration terms, etc. A good intro here. (Hat tip Ken Schwaber and Jeff Sutherland

Lean – Describes mechanisms for the elimination of waste, systems thinking and pull concepts. Wikipedia description here. (Hat tip Tom and Mary Poppendieck)

Kanban – Introduces the card wall, reduction of work-in-progress(WIP) and resource workflows.  Personal Kanban also useful. A great description by Kenji Hiranabe here. (Hat tip Taiichi Ohno)

Kaizen – Company and culture. Also speaks to elimination of waste using the scientific method. Using actionable items found in Scrum retrospectives, teams perform “kaizen blitzes” to improve processes and performance. Personal Kaizen also useful. (Hat tip TPS, W. Edwards Deming and Joseph M. Juran)

 

I have read numerous articles and blog posts discussing one technique vs. another and have found it amazing that very few discuss the how they compliment one another. This is what I hope to begin to do in this post.  If you would like to learn more about any of the four pieces, click on some of the links above or books below. First a picture to graphically show my thoughts.

 

image

Figure 1 – Scrum, Lean, Kanban, Kaizen Relationship

In a nutshell, here is what the process looks like:

  1. Initial Backlog prioritized by business value.  Value drawn from market (client) needs.  This is the pull in Lean.
  2. Map your value stream.  Make sure you understand how you will measure partially done work, task switching, defects, etc.
  3. High level estimates.
  4. Build release roadmap based on value and estimates.  Refactor if necessary.
  5. Release planning session for release.  Make sure everyone is clear on the vision of the release.
  6. Sprint planning session.  Limit Work-in-progress (WIP) as much as possible.  Prioritized by business value.  Make sure work is buffered and balanced. 16 hour SBI’s.  Make sure everyone is clear on the vision of the Sprint.
  7. Commitment on Sprint Backlog.
  8. If not already done, automated build and test environment setup.
  9. Kanban card wall goes up for Sprint.  An electronic version of this on a 60” LCD works well!  :)
  10. Daily Scrums review the card wall deltas.  If electronic, task cards added to personal Kanban walls.  If manual, use resource swim lanes.  How have we improved on our Kaizen item?
  11. Sprint Review.  Demo new value features. What was the Throughput in dollars? Review PBI’s contained in the next sprint and verify correct priority order.  Sprint Review minutes published via email to all stakeholders.
  12. Sprint Retrospective.  What are we doing well?  What could we do better?  Pick and actionable item for improvement during the next Sprint. How will we measure our improvement?  How did we do on our last item?
  13. Ready for Release?  If yes, go to #14, if not go back to #6.
  14. Software released to production.  Release notes sent to all stakeholders including version number, release CVE, de-scoped features, added features, impediments and any open discussion items.
  15. Is the dollar value (revenue potential) for the next release greater than the cost?  If not, the project is ended or put on hold.
  16. Does this project have the highest IRR of all the potential projects for this team?  If not, change projects.
  17. Begin next release, go to #5.

 

While I hope to go into more detail on this technique in future posts, but for now, here are some great primer books to get you started:

Agile Software Development with Scrum (Series in Agile Software Development)
Agile Estimating and Planning (Robert C. Martin Series)
Lean Software Development: An Agile Toolkit (Agile Software Development Series)
Scrumban - Essays on Kanban Systems for Lean Software Development
Agile Retrospectives: Making Good Teams Great
Kaizen and the Art of Creative Thinking - The Scientific Thinking Mechanism
The Kaizen Pocket Handbook


The Principles of Product Development Flow

clock July 13, 2009 08:28 by author Chad Albrecht

I just ordered this book based on recommendations from Kent Beck and Eric Ries.  Anyone else read it yet?



Interview - Dr Eliyahu M. Goldratt

clock July 8, 2009 14:54 by author Chad Albrecht

A great interview with Dr. Goldratt. Many of his comments remind me of the MIT Sloan beer distribution game. What I continue to get from reading Dr. Goldratt is that people solve problems, not processes. While the Theory of Constraints, Six Sigma, Lean, are all good tools, they are implemented by people. Just think about how Bill Smith started using Six Sigma at Motorola or how Taiichi Ohno brought the Toyota Production System together. These were people using the scientific method to solve problems and ultimately improve their companies.



PMBOK, Agile & TOC: The Kaizen Culture

clock June 9, 2009 04:44 by author Chad Albrecht

Before I get to much further in this series I think it’s important to talk about the culture that this works best in.  Kaizen is a way of thinking about your organizational culture, the concept of continuous improvement and the elimination of waste.  A key element in the Toyota Production System (TPS), it seeks to humanize the workplace while increasing efficiency and revenue.  Ok, so what is it?  The Kaizen method consists of five basic elements which are:

  1. Teamwork
  2. Personal Discipline
  3. Improved Morale
  4. Quality Circles
  5. Suggestions for Improvements

You will often hear Kanban and Lean Software Development mentioned in the same body of work as Kaizen but it does not only apply to these techniques.  The Kaizen organization is one that is constantly looking to improve itself, one that is open to critique and one where its employees feel empowered to participate in improving it.  These characteristics are not common place in many organizations, but given the current state of the global economy they may well start to be.


Figure 1 depicts how I think about Kaizen as it relates to TOC and Agile.

 

Figure 1 - Kaizen, TOC, Agile relationship



PMBOK, Agile & TOC: Theory of Constraints???

clock May 20, 2009 08:57 by author Chad Albrecht

Brought forth by Dr. Eliyahu M. Goldratt in his 1984 book titled The Goal: A Process of Ongoing Improvement, the Theory of Constraints is an idea and process that seeks to optimize a system by identifying and eliminating its bottlenecks.  The process is comprised of five, fairly straightforward, steps:

  1. Indentify the constraint.  This means you will need to be able to measure a systems performance in order to identify its constraints.  I will talk more about that in later articles but for those of you who can’t wait, take a look at David Anderson’s book Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results (Coad Series)
  2. Exploit the constraint.  This means that you should do everything within your power to make sure that the constraint (equipment, people, policy) is never idle.  Again, I will talk more about this item in future articles.
  3. Subordinate all other processes to the constraint.  In Lean and Six Sigma this is known as “balancing” and is simply the act of keeping other phases in a process in-line with the constraint. This step introduces the concept of Drum-Buffer-Rope (DBR) as a mental model that can be used to explain subordination.  The Drum is the physical constraint (rate) of the team, the Buffer protects the Drum so it always has work flowing to it and the Rope is the flow of inventory into final product by way of the implemented process.  David Anderson has a good explanation here.
  4. Elevate the constraint.  This is the improvement step.  Consider ways to improve the throughput such as removing inefficient or time-wasting process, hiring more people, buying more equipment or tools.  In my opinion this is where the meat of TOC is and I will spend significant time on this topic in future articles.
  5. If the steps taken in #4 have caused the constraint to move, go to #1.

 

In future articles I will discuss how TOC can be used to improve the efficiency of your Agile teams primarily during the Planning, Executing and Monitoring phases of your Agile project.



About me...

bio_headshot

I am a leader, entrepreneur, software engineer, husband, father, pilot and athlete. Over the last 17 years of my career I have built numerous successful companies and software development teams. This amazing journey has taken me all over the world and allowed me to work in a number of diverse industries. I have had the privilege to meet and work with thousands of unique and talented people. As you will see from my blog I am a strong believer in Agile techniques and the Kaizen corporate culture. I am always looking to grow myself, my teams and the companies I am partnered with.

Contact me... View Chad Albrecht's profile on LinkedIn Follow Chad Albrecht on Twitter Subscribe to this blog

Professional Scrum Trainer

Professional Scrum Developer Professional Scrum Master I Professional Scrum Master II Professional Product Owner I Professional Product Owner II Certified ScrumMaster

MCTS

Calendar

<<  September 2014  >>
MoTuWeThFrSaSu
25262728293031
1234567
891011121314
15161718192021
22232425262728
293012345

View posts in large calendar

Blogroll

Download OPML file OPML

Sign in