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:

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.

I am spending most of my time as of late providing management consulting services to my clients.  Most of them have made, or are making, the transition to Agile and often facing the same set of issues.  While I think there is no replacement for a good Management Consultant/Agile Coach, a close second is reading as much as you can from those who have successfully made the transition to Agile.  With that, I would like to present a select list of my favorites:

I was recently asked: “What mentoring techniques have you used to help engineers make the move into management?”  Great question!

While there are many tools that can be used here, I think it’s important to start with some key factors in making this jump:

1. Engineers thrive on building things and the resulting sense of accomplishment when it’s built.
2. To improve yourself, the must be an awareness of the improvement area.

Starting with the first point, I’ve seen (and personally experienced) a sense of floundering when engineers are asked to manage others.  Being used to writing code all day they often feel like they aren’t accomplishing anything day after day.  As far as I can tell, there is no way around this and represents the first half of the chasm.  Tool #1, Patience.  We must remind our manager in training that what they are experiencing is perfectly normal and that things take time.  Additionally remind them that the sense of accomplishment will return if they are willing to be patient. In John Baldoni’s book, Lead by Example, an entire lesson (#7) is devoted to this topic alone.  Tool #2, Communicate…then communicate some more.  In the realm of engineering it is common practice to communicate things only once and expect that they are understood, in reality this is rarely the case.  Give people direction, set clear expectations, talk about team goals, discuss the vision of the company…rinse and repeat.  Your team must understand what you expect from them and start including these expectations in their decision making process, this takes time and repetition.  Tool #3, Watch for changes.  As our management in training begins to use the first two tools, have them watch for changes in behavior on the team, however subtle, that may be a result of their leadership.  This tool is the preface to regaining that sense of accomplishment.  As the team begins to respond to our manager in training’s leadership there will be changes to team dynamics.  These changes may be positive or negative depending on the many factors, but awareness of the change is important.  The ability to detect changes in the team based on decisions made by our manager in training represents the second half of the chasm.

On the second point, we need instill in our manager in training (and remind ourselves) that having an awareness of an improvement area is the first step in making changes.  For out manager in training to use the tools above, they must be able to see how certain aspects of their experience, education, personality and management style impacts what they do.  It is the job of the mentor to make them aware of this. (albeit tactfully)  If there is no awareness it is unlikely to be improved upon.

This is far from a complete list but instead represents some of the basics. I hope that it’s helpful and, as always, I welcome your comments.

I’m spending quite a bit of time these days helping organizations implement Agile methodologies.  As such I hear the same set of questions and see the same set of issues over and over again.  One of the issues I see quite often is the “long sprint.”  To explain what I mean by this I’ll use a hypothetical conversation with a Team Lead new to Agile.

Team Lead: “How do you deal with the fact sprint planning and reviews take so long?”

Me: “How long is long?”

Team Lead: “Sometimes a week!”

Me: “How long are your sprints?”

Team Lead: “Usually 3-6 weeks.”

Me: “How did you determine that 3-6 weeks was a good length?”

Team Lead: “Because we couldn’t spend 2 weeks out of every month not coding!  We use longer Sprints to avoid spending so much time in review and planning.”

For those of you that are experienced in Agile, you should see a few problems here.  For now, let’s just focus on the “long sprint” concept.  The “long sprint” seems to manifest in organizations that are always sprinting.  First off, this is in direct conflict with the name sprint.  Sprints should be just that, a focused exertion of energy over a short period of time…2-3 weeks max.  So how do we solve our Team Lead’s issue with spending too much time in review and planning and not enough time writing code?  Enter the “Release.”

A Release is a means of building larger blocks of functionality in multiple Sprints. (usually 4-6)  Some Agile methodologies (XP) implement this concept directly, others do not. (Scrum)  There are many reasons to use the concept of a Release, a select few are:

• Some features just might not fit into a two week Sprint.
• Allow team to perform work in parallel to development.  In general team members can do work other than sitting in sprint review and planning sessions.  This is because these sessions are lighter weight and involve fewer people.  You simply review implemented sprint functionality ensuring it meets the needs of the stakeholder and grab the next chunk of the prioritized Product Backlog. (ok, a bit more than that, but you get the point) These two sessions should not take more than 3 days.
• Reduce the overhead of delivering software to production every 2 weeks.
• Reduce the information overload caused by releasing every 2 weeks.
• Define a delivery pace more inline with that of the organization. (the rope in the Drum-Buffer-Rope of Throughput Accounting)

The next logical question is “Do we create a Release Backlog?”  I agree with Mike Cohn in this case and would say no.  I do however, use the concept of a Release Plan or Release Roadmap.  According to Mike a Release Plan contains:

• Graph showing historical velocity.
• Prioritized Product Backlog. (including some big user stories, "epics")
• A predicted range of where we will finish. This should be either a date-range for a fixed-scope project or a functionality-range.
• Personnel assumptions. (Team members and availability)
• Velocity assumptions. ("we’ll go about half speed during December because of holidays and time off")

I would also add the following:

• A Vision Statement.  (“We want to add the shopping cart functionality and connect it to PayPal”)
• Estimated Release Value as I discuss here.

Using the concept of a Release in Agile organizations can be an extremely effective way to increase efficiency through the elimination of waste.  I will try to post more on this topic in the future.  As always, let me know your thoughts.

Further Reading:

Extreme Programming Release Planning:

http://www.extremeprogramming.org/rules/planninggame.html

Mike Cohn on Release Planning:

http://blog.mountaingoatsoftware.com/why-do-release-planning

Mike Cohn on why there should not be a release backlog:

http://blog.mountaingoatsoftware.com/why-there-should-not-be-a-release-backlog

Kelly Waters on Release Planning:

http://www.agile-software-development.com/2008/02/agile-release-planning.html

Glen B. Alleman has a great post on teams trying to use technology to solve their issues.  First tenant of the Agile Manifesto:

Individuals and interactions over processes and tools

I see supposed Agile teams doing the direct opposite over and over again.   I’ve seen really well run projects using nothing more than email and an Excel spreadsheet…and lots and lots of leadership and communication.  :)

The more software development teams I work with, the more I’m convinced that it’s often nearly impossible for said teams to see where there are issues.  From the managers of these teams I hear:  “If people would just follow the process we would be in great shape!” or “We really don’t have many issues.”   From the team members I hear “We’ve tried following our process and it just creates more work for us!”  or “Management doesn’t get it!”  If these statements sound familiar to you, you’re not alone. 

Improving your organization’s ability to deliver software in a streamlined way can be a daunting task.  I liken it to having issues with your golf swing.  You can make corrections that you hope will have a positive effect, but often they morph one problem into another.  In most cases it is better to have someone else examine your swing.  A coach or consultant looking in from the outside typically has a much clearer view of what is going wrong.  If this consultant has the experience and a keen eye, he can make suggestions that will have a greater impact in a shorter amount of time than you could on your own.

The point here is that if you are looking to improve a management area in your organization, give a reputable consultant a try.  They just might see the real issues and allow you to be under par on every hole! :)

Another book to add to the list:

Pascal Van Cauwenberghe has a review here.

I have founded or co-founded a number of startups, worked as a consultant for Fortune 100 companies, and been an executive in large corporations.  What I’ve come to hold true is that as a company grows it experiences what Dr. Larry E. Greiner calls “growth phases.”  Dr. Greiner postulated the existence of these phases in a 1972 paper titled “Evolutions and Revolutions as Organizations Grow.” These growth phases are characterized by certain periods of growth ending in a crisis.  The duration of the crisis period can lead to what I call “growth plateaus” resulting in stalled or declining revenues.  The phases and associated crisis are as follows:

From the above, can you fit the company you are working for into any of the phases?  Are you in a crisis?  The funny thing is that employees usually seem to know if they are in a growth phase or experiencing a crisis.  Depending on the quality of the management team the crisis may be temporary or may last for years.  If you are stuck in a crisis for years, you will usually see a high volume of management turnover and hear phrases like “This has worked for us before.  It will work for us now!”  Then the revenue begins to slide. If senior management sticks to their guns, this is the beginning of the end.

What does the flipside look like?  Good leaders embrace the ability to change processes and practices if they are no longer working. (Agile Management)  Some, feeling they are only an effective as a Phase 2 manager, may choose to remove themselves from the organization completely.  According to Dr. Greiner, organizations should not attempt to bypass phases or their associated crises. Instead he recommends a few tools to managers to help them move to the next step.

1. Know where you are in the development sequence.
2. Recognize the limited range of solutions.
3. Realize that solutions breed new problems.

Here are a few good books that discuss Dr. Greiner’s concepts as well as strategies to deal with each crisis.

Managing Technology and Innovation: An Introduction

Dynamic Strategy-Making: A Real-Time Approach for the 21st Century Leader

Evolution and Revolution as Organizations Grow

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.

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

I had a discussion with a colleague yesterday on how to determine the priority of features on a given service. We quickly arrived at the topic of assessing business need, i.e. value, of the features. This is a conversation I've had many times, with many clients and thought it might be worthwhile to document some of my thoughts on this.

If you are building "shrink-wrap" software you can estimate the number of units sold and multiply by the price to get annual revenue. From there you can work backwards to establish your financial metrics. (ROI, NPV, IRR, PV, EV, AC,T,I,OE, etc.) But what about when you are building Software as a Service? This is not a simple question to answer. Regardless of the level of difficulty, it is one that many of us will need to answer in order to effectively grow our organizations. While I don't have a one size fits all answer here, I would like to toss out some tools, ideas and links that may help each of us answer the question for ourselves.

Know Your Value

For starters we should have a good understanding of the value proposition(VP) for the service. The VP will speak to why clients will choose your service over the competition. The VP will look something like:

"For sales teams seeking to reduce time-on-sale by as much as 25% our CRM application will provide full sales process management at half the price of the competition"

Or

"Our internal CRM application will allow our sales team to reduce time- on-sale by 25% and cost only 50% of an off-the-shelf package".

Here is some additional reading:

Developing a Compelling Value Proposition

Stop Coding, Start Marketing! Getting Your Positioning Right

Powerful Value Propositions

Bringing the Value Back Into Value Propositions

In Search of a Value Proposition

Understand the Features That Support Your Value

We add features to attract new clients, keep existing ones, or generate new sources of revenue. We should be doing this in alignment with our VP. We should not be adding features simply because we've conceived of the idea. Given that, we should start by asking ourselves "How important is this feature relative to our VP?" Let's start by using the following 5-point scale for each feature:

1. Direct VP feature.
2. Component part of a VP feature.
3. Compliments a VP feature.
4. Nice to have.
5. Optional.

When analyzing the features that support your VP, remember that only 6% of the work on software projects is value added and 64% of all software features are rarely used. (Thanks for the numbers Ryan!)

Price your Value

After you have the VP and the features to support it, you will need to work with your sales and marketing organization to understand what they feel the market will bear, in terms of price, for each unique service. They should also have an estimate on the number of users that will subscribe to the service. Jason Rothbart talks more about this here. Combine this with an innovative monetization model and you have some annual revenue numbers you can work with.

You may also be in a project that has the role of supporting the business. If this is the case, an estimate of the value to the business should still be generated. You may choose to adopt the model that if the service saves the organization 1 hour during a 40 hour week then 2.5% of the annual revenue is attributable to the project. For a $40M company this is $1M annually!!!

If there are no answers to these questions, you may be in the "build it and they will come" mode which is very difficult to generate value metrics from. Try using one of the above models to create an estimate and see how it compares to reality when everything is said and done.

Finally, you should consider what monetization models will be used by your service. Will you only generate revenue from paid subscriptions or will you adopt a freemium model? Will there be paid advertising from within the UI of your service? Are there client stakeholders that are willing to help fund the service? All these are examples of monetization models that will have an impact on revenue and need to be considered as part of the analysis.

Market Lifetime

Given the speed of today's market, including the market lifetime in your analysis is also important. Every service has a limited lifetime due to advances in technology and usefulness to the client base. Typically the market lifetime curves are bell shaped (Figure 1) since full market adoption is not gained immediately and decays slowly due to technology and market pressures.

Figure 1 - Typical Revenue Cycle

How long will your service be able to generate revenue in its current state? 6 months, 1 year, 2 years? If you assume the lifetime to be 2 years and the revenue curve to be bell shaped with the max subscribers in the middle, you can make some fairly good estimates. The answer to this question will play an important part to developing the Value Schedule.

Bringing It All Together

Let's assume that we've determined we will generate $1M over the next 2 years on our service. In order to generate this revenue, we will need to add continuous value and bear continuous cost over the next 20 months. Let's further assume that we will be on 2 month release cycles over these 20 months giving us a total of 10 releases.

Using our 10 releases and our $1M in revenue we can simply calculate the value per release to be $100K. (Ignoring any discounting)

Now if we look at the first release and assume that we have 25 features all of which we have ranked using our 5-point scale from above we can estimate the dollar value per feature. The trick is to normalize the value based on the rank. The formula is shown in Equation 1.

Equation 1 - Feature Value Equation

Using Equation 1 in our example we can now generate a Value Schedule which will give us the dollar value of each feature.

Conclusion

While not the answer for everyone and realizing I've left out some detail, I hope the tools I've presented here will be useful to you while you are analyzing your next project. I would love to hear what you think!