In the previous post we mentioned that Time to Feedback is measured by Lead Time.  Little’s Law gives us insight into lead time that can help use manage time to feedback…aka shorten or length lead time.  Little’s Law states that the average Lead Time(LT) is equal to the work in process(WIP) multiplied by the the average delivery rate or throughput.  That’s simple enough.

For example if you got in line at Starbucks and with the line 10 people deep and the average throughput was 1 customer/minute, you could expect a 10 minute wait

• (10 customers) x (1 minute/customer) = 10 minutes

Say they opened a second register and doubled throughput to 30 seconds per customer

• (10 customers) x (0.5 minute/customer) = 5 minutes

Now that we know what influences Lead Time, WIP and throughput, we can manage those two areas to decrease lead times.  We can do this by decreasing our WIP and/or increasing our throughput.  The latter is often a convoluted and context specific answer best viewed through the lens of system delays.  We’ll save system delays for another post.  However decreasing our WIP throughout the lifecycle of software development is a more straightforward task.  It also tends to cause less heartburn than tackling system delays. 🙂

Take a look at the “ready for” queues you have built up in your development system(ready for – analysis, development, test, ready to deploy, …etc), and see where you can reduce your queue sizes to decrease your overall WIP.

Now the wrap up.  What are we striving for?  A way to measure agility at the team level.  We can do this by measuring Time to Feedback, better known as Lead Time.  We do this so that we can learn faster, which brings certainty to the uncertain world of software development.  Little’s Law shows us that to decrease Lead Time we need to reduce work in process(WIP) and/or increase throughput.  Reducing WIP is a simpler, more straightforward approach than dissecting the variables of throughput.

So go crack the WIP and get your on Lead Time!

As stated in the previous post, Agile rightly puts emphasis on delivering valuable software.  But how do you measure what’s valuable?  After all, some features that seemed valuable at one moment in time turned out to be bad ideas.  This is the nature of product development.  Different metrics have more value at different levels within the organization.  But is there one metric that applies applies to all areas within an organization?

AT TechEd 2012 Steven Borg proposed just that – Time to Feedback…aka Lead Time.  While there are many different metrics to be measured, I largely agree with Borg’s assertion that Time to Feedback is the best metric to measure across an organization.

The Agile Manifesto states that “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”  The main thrust behind “early and continuous delivery” is to secure feedback.  Why?  Because as Eric Ries describes in the book, The Lean Startup, validated learning is the unit of progress in work that has a high degree of uncertainty, like software development.  The faster we get feedback, the faster we can learn, which allows us to bring certainty to the uncertain environment.

To understand why Time to Feedback is vital, it is important to have a deep understanding of the metrics that make up Time to Feed.  In the next post we’ll take a look at Little’s Law to determine the value of Time to Feedback.

So you want some metrics to measure the progress of your Agile team.  Where do you start?  To answer that question we need to set a foundation of understanding in place to showcase why certain metrics are more important than others.

First off, it’s also important to note that some metrics are more valuable than others based on your responsibility area.  If you operate within the business portfolio area, you may be most concerned the portfolio team’s ability to discover high value business increments that impact the organization’s ROI.  A technical delivery manager may be most concerned with the speed of delivery.  And a program manager may be focused on delivery predictability so that he/she can provide more accurate forecasts when doing mid range planning.

The second point is, there is no silver bullet.  Many Agile metrics are often more subjective than objective.  Therefore, precision is difficult to come.  For instance, Agile rightly puts emphasis on delivering valuable software.  But how do you measure what’s valuable?  After all, some features that seemed valuable at one moment in time turned out to be bad ideas.  This is the nature of product development.  ROI seems like an obvious answer, however often times its hard to directly attribute an increment of value to an ROI metric, like revenue.  Therefore measuring business value is subjective at best and often hard to connect ROI measures.

In the following posts we will take a look at the optimal metrics for three different areas of responsibility within an enterprise – Portfolio, Program, and Team.