Lean Metrics & Time Tracking

Lean MetricsAt this month’s Agile Brisbane meetup, Ben Starr presented on Lean Metrics. His talk was based on metrics that they tracked at his previous company on an operational support team. A couple of points from the talk:

  • used Kanban – work item types to allocate capacity and 3 levels of service (standard, coordinated, expedite)
  • JIRA was the tool but was not the most ideal choice and not really up to the task
  • reported by type on backlog, work in progress, throughput (number of work items not size), velocity (throughput and velocity were similar which showed average size), cycle time, class of service mix, due date performance, estimation accuracy, cancelled WIP (started and then cancelled work) and demand balancing (clearing out the backlog)
  • flow efficiency – percentage of time you work on an item versus in progress, also referred to as touch time – using time tracking in JIRA to do this
  • time allocation – value add, failure load (defects), transaction cost (overheads of planning and releasing), coordination cost (management), used percentage of time spent rather than actual hours

The one things that got me thinking during this presentation was the flow efficiency report.

Early on my journey of being an Iteration Manager, my teams used to track times per card. We used to use XPlanner which had some reasoanbly easy functionality for tracking time (one of the good features was as the Iteration Manager I could enter time for my team if needed, tools like JIRA require the developer to record that data if you want it assigned to that developer). We used to use thee metrics for comparing estimates to actuals but over time I came to the conclusion that we would be much better off just making sure that the cards were completing on time (an average of 3 times) and splitting cards out if they appeared to big.

Lately, a number of people in my Agile classes have been arguing that time track is beneficial. My usual response to this (like for all metrics) that it is OK if it adds value, but my recommendation is not to waste your time. Even more so, this opens up the estimation debate that I also believe that a lot of time should not be wasted on (#noestimates), but that is a discussion for another post. My main reasoning is often we need to track for other sources (like timesheets) in different systems, and the overhead does not justify the effort. If teams need time metrics (often to see if time is being wasted away from the core work of the team, say on production support or corporate meetings), I suggest they are done at a team level and rounded to the nearest hour, and collected as time not spent not on project work.

In the graph above, flow efficiency is a good way for showing waste in the system (in this example, the team could potentially be way more effcient), but it relied on the team tracking time (in this case using the time tracking feature in JIRA against each card). I really like it as a graph, I am just not sure the effort to produce it is justified.

Some discussion in the Q&A revolved around recording time tracking (or similar metrics) is OK if the team understands it is an incentive for better metrics, and I can’t disagree with that thought. Just in my experience as an Iteration Manager, getting reliable and timely time and effort metrics ha been painful and the reward outweighed the effort.

Episode 79: Vomit Value with Jim Benson

The Agile Revolution's avatarThe Agile Revolution Podcast

14491375311_22bf182a39_zAt Agile Australia 2014 in Melbourne, Jim Benson of Personal Kanban fame takes some time to talk with Craig, Renee, Tony and (a very silent) Kim Ballestrin and along the way they talk about:

  • early work implementing David J. Anderson’s Agile Management which resulted in Jim focussing on the person (Personal Kanban) and David focussing on the organisation (Kanban method) – two different viewpoints on the same solution set
  • XP, Scrum, Kanban method and Personal Kanban exemplify the people who created them
  • The Oath of Non Allegiance
  • Scrum vs Kanban
  • Why Limit WIP and Why Plans Fail books out now and working on an upcoming book about meetings
  • Individuals and interactions is redundant – relevant in 2001 to shake people out of complacency
  • Agile is anti-manager
  • Agile in knowledge work
  • WIP limits and avoiding “death flow”
  • Vomit Value – user stories with spurious and arbitrary value in a…

View original post 63 more words

Episode 78: Renee-Renee-Renee

The Agile Revolution's avatarThe Agile Revolution Podcast

ReneeYes they’re at it again ! The revolutionists bring forth their innermost thoughts on the life the universe and most importantly Agile . Oh yeah and Craig and Tony ask the question repeatedly ….Renee,Renee……Renee

 TheAgileRevolution-78  (61 minutes)

View original post

Episode 73: What Made You An Agile Coach?

The Agile Revolution's avatarThe Agile Revolution Podcast

AgileCoachTony asks a philisophical question , whilst Renee harnesses her nineties pop star – Ice Ice Baby and Craig marvels at Tony’s  cool intro – probably the coolest intro he’s done since the eighties.

The Agile Revolution – 73 (54.21)

View original post

Episode 70: Hello Is This Thing On?

The Agile Revolution's avatarThe Agile Revolution Podcast

IsThisThingOnCraig, Renee and Tony catch up again and discuss the wonderfully diverse world of Agile :

The Agile Revolution – 70  (65 minutes)

View original post

Meals Per Hour

A great video demonstrating how Lean principles can be applied to everyday life, such as disaster relief or non-profits.

And kudos to Toyota for sharing their knowledge for charity.

Episode 63: The Lean-Agile Project with Al Shalloway

The Agile Revolution's avatarThe Agile Revolution Podcast

alan_shallowayAt Agile 2013 in Nashville, TN, Craig talks to Al Shalloway from Net Objectives in the open space area (ironically in front of a waterfall) about his current areas of interest in the Lean Agile community. Al has been a leading voice in the Agile community for many years, is the author of many software development and Agile related books and is a SAFe Program Consultant as well as a co-founder of the Lean Software & Systems Consortium. The topics discussed include:

TheAgileRevolution-63 (26 minutes)

View original post

Agile Australia 2013 Review

Agile Australia 2013Agile Australia 2013 was recently held in Sydney with over 850 attendees and 3 days. Between running a pre-conference workshop, recording interviews for InfoQ, presenting a session and being a MC for a number of sessions, it was a fairly busy time but I did get to sit in on a couple of sessions.

I was once again one of the conference advisors, although this year we introduced the role of Stream Chairs and Reviewers who took the bulk of the review of the 240 plus submissions and, I think, went some way to making the whole selection process more transparent and community driven.

Pre-Conference Workshop – Introduction to Agile

There were a number of pre-conference workshops running on the day before the conference, and on behalf of Software Education I ran an Introduction to Agile workshop for a small but engaged group of people new to Agile. According to the course overview:

This course provides an independent one-day introduction and overview of Agile Software Development. We look at the underlying philosophy and motivation for this trend in software development and examine the core values, principles, practices and techniques that fall under the broad “Agile” umbrella. Independent of any single brand, this course looks at the key factors that are needed to apply Agile effectively and provides an experiential introduction to working this way.

InfoQ Interviews

InfoQ was a media sponsor for Agile Australia this year, and being the Australian based Agile Editor for InfoQ, I undertook the organisation iof the recording of sessions and interviews. I recorded a number of interviews throughout day 1 of the conference and I look forward to seeing them available on InfoQ in the coming months.

Visual Management: Leading With What You Can See

The session I presented with Renee Troughton had a great turnout and plenty of questions afterwards.  The slides are available in a separate post.

In relation to the sessions that I attended, here are my notes.

Keynote: The Lean Mindset

Mary Poppendieck delivered the opening keynote, her slides are available here.

  • going beyond software
  • Thinking Fast and Slow by Daniel Kahneman – two types of thinking – system 1 (fast, instinctive and emotional) and system 2 (slower, more deliberative and logical)
  • need to see the waves and learn how to surf them, rather than trying to control the waves
  • cognitive biases – confirmation biases (align with people with same thinking), anchoring (hang on first piece of information), loss aversion (careful not to lose what we already have rather than gain)
  • dealing with options – teenage decision making (either/or or whether or not), widen the frame (what about both or none of the above), multiple options, patterns
  • speed and quality are compatible, you learn that you can’t go fast without high quality
  • Continuous Delivery by Jez Humble and Dave Farley has become the bible, supersedes iterations and Kanban because it’s too fast, whole feedback loop from customers to the development team
  • Ericsson – the past is not good enough for the future, stop projects because they are big batches
  • accept uncertainty and learn how to live with it – range estimates over point estimates and manage flow
  • managing complexity – probe, observe and adjust; dealing with it – flow, obstacle, adjust
  • wisdom of the crowd, widen the perspective, zoom in/it, look at base rates (probability of success in your market and what makes you different)
  • why do companies fail – they focus too much on success, take what they have and make it better, forget to look at the big picture and see what the world is doing – Garmin and Magellan lost 70% of their market overnight due to Google Maps on the iPhone
  • Carol Dweck on the Growth Mindset – fixed mindset versus growth mindset
  • perfection paradox – learn to fail and learn to prevent rather than striving for perfection, resilience is learning to fail
  • flow depends on your engagement – deeply engaged, no distractions, time evaporates – otherwise you drift between anxiety and boredom depending on your expertise

Keynote: Managing for Serendipity

I was quite looking forward to seeing Dave Snowden and hoping his talk would cement in my mind the Cynefin Framework. His slides are available here.

  • it is better to have a partial view of the whole, than a complete view of the parts
  • theory deals better with uncertainity than practice
  • exaptation (taking something that exists and enable it to a different purpose, usually two unrelated things)
  • agile manifesto swung too much towards customers and away from how we can educate them
  • you absorb complexity, don’t delude yourself into thinking you can eliminate it
  • outliers are where opportunity and threat manifest themselves first – most research and search eliminate them
  • only way you can understand a complex system is via experimentation.
  • evidence supports competing hypotheses
  • Dave’s Harvard Business Review article

  • you want to cycle between complicated and complex, stuff that goes to simple usually becomes complacent and dies
  • cynics care about your organisation – they are the only ones making noise
  • meetings should not be used to resolve problems – you get dominant players – you want to to do 5-7 parallel safe to fail experiments
  • interventions should be coherent, safe to fail, finely grained, tangible – tackle problems oblique (plant different ideas, like managing a teenager), naive (anthropology experts in the Holiday inn), a few high risk high return options
  • process is what you need to change people (sorry mainfesto), naive if you think you an change one person at a time
  • complex domain action form – if it doesn’t fit in top 4 boxes it is not safe to fail
  • micro narratives are what we want (stories developed in workshops are not the same as the discussions around the water cooler)

Keynote: Beyond Budgeting

The highlight of the conference for me was to meet and hear from Bjarte Bogsnes, as I have long been a fan of his Beyond Budgeting work. His slides are available here.

  • the purpose is not to get rid of budgets, need to change traditional management and the budgeting mindset to make organisations more agile
  • written into The Statoil Book, but has not reached all corners of the organisation
  • transparency is a great social control mechanism and good for learning
  • management recipes – someone has done all the thinking for you, beyond budgeting is not that
  • Beyond Budgeting principles
  • we budget for targets, focussing and resource allocation – inefficient and in one number – separate the numbers and be event driven not calendar driven
  • change the mindset from do I have budget to is this really necessary and how much value it is creating
  • Statoil abolished annual budgets, but they still have project budgets but can get money at any time (the bank is always open)
  • need good information to make decisions – current status as well as capacity
  • use a burn rate rather than a budget, with some variance
  • use a unit cost, keep exploring as well as you stay within a unit cost
  • bottom line – good costs create value, eliminate the bad ones
  • express cost in words rather than dollars as strategic actions and objectives
  • need to start trusting our people
  • “the way we deliver is as important as what we deliver”
  • objective > measure > actions > goals
  • KPIs – perfects KPIs do not exist, make them ambitions to action
  • dynamic forecasting – don’t put everybody into the same limited time buckets – some people need small time frames, some people need years
  • apply pressure to the KPIs – were they ambitious, did you stretch versus low balling, were there outside influences
  • mechanical link and no judgement between KPIs and performance bonus is dangerous

The Guessing Game: Alternatives to Agile Estimation

Neil Killick has become the voice of the #noestimates discussion in Australia (whether he likes it or not). His slides are available here.

  • estimation – what am I going to get and when
  • estimates set an expectation level
  • in 12 moths time if estimates come true – either by good guessing or by adjusting for over runs
  • we have known unknowns – can’t predict them and can’t ignore them
  • use real constraints – what can we build for this money, budgets create a real deadline and bring out creativity
  • create mini constraints and iterate and learn, come up with a mini solution for what we can do, small iterations to keep options open and diversify our risk
  • need an a-team that can build solutions continuously
  • iterative pricing – allows the customer to cut the cord early, possible even with traditional contracts
  • present customers with expectations of of what they are going to get and when – flexible options
  • slice things to the same size, avoid story points, count cards – price per feature
  • story points will be gamed – people will make the burn chart look good

In Conversation with Patrick Eltridge

I was the MC for this session that was a coffee table conversation between Beverley Head and Patrick Eltridge, the CIO of Telstra. When I introduced this session, I made the comment that it was interesting to see how Telstra was progressing on their Agile journey and Patrick was at the conference for his third year now; in the first year we didn’t really believe they would be able to make an Agile transformation and in the second year we weren’t sure how much was fact and fiction. In 2013, they are certainly making their presence felt with over 70 people at the conference, a title sponsorship and a number of sessions being presented.

I did not get to hear all of the session, but hear are some snippets I picked up

  • IT strategy needs to be driven by the corporate strategy, then creating an environment that can change and people being the best they can be
  • huge “opportunity” when he joined Telstra
  • celebrate successes as much as possible – stiffens the spine for the naysayers
  • reverse mentoring – mentor older staff with younger ones to pass on new thinking and ideas, both sides learn
  • nations can benefit if agile leadership is successful
  • simplified scorecards and KPIs – single number of financial performance (EBIT), engagements with stakeholders, employee engagement plus project outcomes
  • Scaled Agile Framework and weighted first has allowed Telstra to have acute business control and adapt as required

This discussion also spawned some news articles around graduates mentoring CEO’s and five day interviews.

Lean Quest: Establishing A Problem Solving Culture

Last year, I attended a 5 day intensive lean course led by the folks at Lean Quest. The course helped cement a lot of my understanding around Lean and here are some of my takeaways from the course:

Culture

  • the way we execute is the culture we have
  • culture is how we go about solving problems, the way we do our work every day
  • organisations tend to fix problems by: avoiding and defelcting blame, adding resources, calling in external resources, organisation restructures, adding new technology and adding a new layer of management
  • the foundations are our core values and principles as well as our beliefs and assumptions. We can see and observe the norms and behaviours and artifacts. You need to focus on the bottom and the top will take care of itself
  • “you can only see what you can see, you can’t see what’s inside”
  • leaders doing things different will change the culture, need to create an environment where everyone can be successful
  • catastrophes are made up of little problems that are allowed to slide by – it takes 7 problems to happen simultaneously for a plane to crash
  • lean has 3 core values – customer first (start with the customer and optimise the process for the next process), respect for people (engage and enable people, value people over process) and continuous improvement (a thirst for perfection, fix your own work / area)
  • true north – don’t need to get to perfection, but continually heading there
  • lean principles – standardised work, just in time, problem solving, built in quality, visual techniques, culture
  • break the process – by increasing the measure, will expose more problems

Capability 1: Design and Operate Work to Reveal Problems

  • every problem is an opportunity
  • failure is word that people feel uncomfortable with
  • fail quick and often versus do it right the first time
  • reveal problems for the level you control – need to be able to measure this
  • quality starts with the customer (ask them)
  • add quality to the discussion, add value to the conversation
  • quality check at the end, adds no value to the customer
  • pathways break down with the connections between them
  • cycle time – how long it takes
  • takt time – how quickly the customer demands it
  • S5 – sort, straighten, shine, standardise, sustain (also safety)
  • use visual queues, they are all over the place – red line to get to emergency in a hospital, lines in a carpark
  • work is three categories – value added work (something a customer is prepared to pay for – 3% – 4% on average, if you changing fit, form or function you are adding value), incidental work (needs to be done but the customer does not care) and waste (unnecessary activities in the process)
  • continuous improvement to reduce waste and incidental work in a process
  • 7 wastes – inventory, motion (of the person), material movement (of the product), rework, over processing, waiting, over-production (the worst waste because it hides the other wastes)
  • we want problems to surface so we can see them and fix them

Capability 2: Contain and Solve Problems Close in Person, Place and Time

  • if you reward fire fighters, you get arsonists…
  • we don’t teach people how to solve problems very well
  • everytime you problem solve you are making a little more time for yourself
  • a problem is a gap between the expectation and the current state, the key is to set the standard , if you don’t have a standard you don’t have a gap
  • keep lowering the water level and/or raising the standard
  • start with where you are today and measure variation to the standard
  • PDCA – Plan, Do, Check, Act (Deming wheel)
  • 7 step problem solving process (1. define the problem, 2. grasp the situation, 3. plan, 4. do, 5. check, 6. act, 7. conclusions and lessons learned)
  • A3 – used to document the journey in the most concise form possible
  • project charter – an improvement project that is a break from operations
  • SIPOC+M – process level summary (Supplier, Input, Process, Output, Customer + Metrics)
  • COPIS – business level summary (multiple processes)
  • a lag indicator could be a lead indicator for another process
  • fishbone – cause and effect diagram – 4M’s (Man, Method,Machine, Material)
  • pareto chart – line / bar chart that distinguishes in descending order the relative importance of problems
  • “say it with charts” – Edward Tufte
  • 5 Why’s – peel away the layers of a problem and reveal the symptoms that often lead to the root cause
  • 3 why’s in sales is considered interrogative
  • SMART targets – Specific, Measurable, Achievable, Relevant, Time-Based

Capability 3: Accumulate and Share Knowledge

  • knowledge is an asset
  • use a SIPOC+M to grasp the situation or to assess the future state, want to create a SIPOC+M for the repeatable steps (there should not be 100’s of these)
  • SOP – Standard Operating Procedure – leverage SIPOC+M and process flow diagrams
  • use a standard A3 format for reading and reviewing efficiency
  • leaders need to understand the job – need to study it and be able to improve it

Capability 4: Leaders Coach and Develop the Previous Capabilities

  • traditional organisations manage people and results, high performing organisations manage processes

AWS Lean Startup Event 2012

AWS Lean CloudThe planets aligned this week which meant that I was in Sydney for the Amazon Web Services Regional Premier Lean Startup Event, with the highlight being able to hear from Eric Ries, author of The Lean Startup. A huge thanks to my friends at Slattery IT who got me registered for this event. Here are my notes from the event.

Eric Ries – The Lean Startup

I am a huge fan of the Lean Startup movement, so it was a thrill to hear directly from Eric Ries. His talk mirrored others of his that can be found all over the web and the content followed much of what is available in the book, but it was inspiring and awesome nonetheless.

From Miscellaneous

This is a copy of a similar presentation from another conference.

Here are some of my notes from the talk.

  • you can now rent the means of production and compete with big players
  • join the global conversation at #leanstartup
  • this is the boring part of entrepreneurship
  • Ghostbusters is the original movie on entrepreneurship
  • startup = experiment
  • we live in a time where we can build anything we can imagine – need to ask not can it be built but should it be built…
  • entrepreneurship is management
  • most products Eric has built have failed!
  • Frederick Winslow Taylor stated things that are obvious now yet had to be invented then – work needs to be done as efficiently as possible and breaking work into tasks
  • all of the tools of general management are based on planning and forecasting – but making an accurate forecast relies on a long operating history – need a new entrepreneurial toolkit because the world is filled with uncertainty
  • the pivot – successful entrepreneurs did not have a better idea, they take the leanings and change the direction without changing the vision
  • runway should not be amount of money remaining but amount of pivots remaining
  • achieving failure is successfully executing a bad plan – this is like getting good fuel mileage when driving a car off a cliff
  • the lean revolution was led by W. Edwards Deming and Taiichi Ohno
  • Agile only works well if you know who the customer is
  • failure is the great equaliser of quality
  • “we learned something important” is an excuse, need to learn early
  • ask what experiment am I trying to run, and what learning can I take from that
  • build > measure > learn loop – minimise time through the loop
  • measurement will slow you down but optimise the part to optimise the whole
  • drive down the batch size to one day – continuous deployment – many features take longer to prioritise than to build
  • The Toyota Way says foundation is long term thinking, the startup way says foundation is accountability
  • brink of success is indistinguishable from goofing off – need innovation accounting
  • business plans are rarely achieved – achieving failure – leap of faith assumptions need to called out
  • build a minimum viable product, iterate experiments and look for upward trends, pivot when returns are diminishing
  • better to have bad news that’s true than good news that’s made up
  • pivot meeting should be a milestone in its own right, need good information to make a good decision – micro scale experiments that help make future decisions
  • lean startup is still early adopter stage

Dr Werner Vogels – The Lean Cloud

Dr. Werner Vogels is the CTO of Amazon.com and opened the startup event. Here are some notes from his session.

From Miscellaneous
  • Animoto – upload images and music, analyses the music and creates a movie around the mood – went from 15 to 5000 servers in a number of days
  • web services is now called cloud…
  • Australia is not yet an Amazon Web Servixes (AWS) region – soon? – Asia Pacific region is based in Singapore
  • the number of objects in S3 has increased by 250% per annum consistently over the last 5 years, currently 762 billion
  • cloud is defined by its benefits not its technology
  • scaling is as much about using the Cloud to scale down as it is to scaling up
  • lowers cost – eliminate CAPEX, reduce OPEX
  • increase agility – not constrained by resources(eg. waiting for or buying servers), reduce time to market
  • remove heavy lifting – like scalability, security, reliability
  • foundation for next generation architecture, infrastructure cost should grow with your income
  • resource models changing due to competition, limited capital, power of customers, faster time to market
  • lean manufacturing – the machine that changed the world, lean startup
  • remove waste that does lead to direct value for the customer
  • an elastic and pay-per-use infrastructure – follow their demands to eliminate waste for peaks in traffic
  • AWS makes deployment, testing and staging trivial – tools for red-green deployment for example
  • need to build security in from the ground up when building a cloud application – lots of tools available
  • advantage of AWS is you are on a continuous innovation curve
  • DynamoDB – uses low latency SSD, predictable performance, zero administration NoSQL – database is no longer the bottleneck
  • no need to have your own transcoding anymore, it all sits on the cloud

8 Securities /  Q&A Panel

8 Securities gave an overview of their use of AWS ahead of a short lean cloud panel.

From Miscellaneous
  • are all the lessons US lessons? No, early on some cultures said this would not work, particularly admitting failure, the grass is not greener in Silicon Valley, understand the underlying principles, figure out how to translate strengths and build on the Lean startup principles
  • there is a new book by Jeffrey Liker who wrote The Toyota Way (The Toyota Way to Lean Leadership) – Toyota  has translated the approach to as many plants in the USA
  • need to communicate and connect with your employees – we are still solving simple problems
  • good thing about having a small amount of customers is that when you screw up you can apologise… personally
From Miscellaneous