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.
My lecture for students in SWEN302 Agile Methods at Victoria University of Wellington called “Going All XP On Your Business” is available on Slideshare.
My presentation from Fusion 2012 called “Going All XP On Your Business” is available on Slideshare.
When XP and Scrum were devised over 10 years ago, they were created to improve the delivery of software development projects. As many enterprises have matured in the Agile adoption, many of the business users on IT projects are now attempting to use Agile approaches on their own non-IT projects.
In this session we will cover using Agile in a non-IT environment and demonstrate how the original XP practices map extremely well over to business processes. And how those in SD can help your business counterparts.
Throughout the talk I will be referencing back to specific examples and case studies that we have experienced
in our organisation as we have rolled out agile processes across the enterprise. We’ll look at:
- Agile values for non-software development, including an updated look at the agile manifesto.
- Agile principles and why they make good business sense.
- Agile practices (such as TDD, standups, retrospectives, storycard elaboration and acceptance criteria
and planning approaches) and how to adapt them effectively into a business process (using case
studies as specific examples).
- Mapping the XP, Scrum and Kanban practices to work in a business context.
- Agile vs Kanban and how to decide when which is most appropriate.
- What a business storycard looks like and why the elaboration and acceptance criteria are important.
- Project delivery and how iterative delivery applies (and what delivery looks like in a non-software development project).
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:
- 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
The 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.
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.
- 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.
- 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
I was cleaning up some old files, and came across my notes from a workshop I attended with Mary and Tom Poppendieck entitled Lean Software Development – Leaders Workshop at the YOW! 2010 Australia Developer Conference in Brisbane. Obviously the slides and commentary have a wealth of information, but here are some of the key takeaways I had.
- stop doing stuff that does not deliver value, not laying people off
- spend time doing the right stuff, not the wrong stuff
- think systems, not software – Southwest think employees, customers and then shareholders
- optimise the whole system (software is just a layer) – Amazon is structured around it services (2 pizza teams of 8-10 people)
- a separate testing team is silly – just handoff / afterthought, need to build quality into your product
- need to understand value before you deliver value – understand what your customers value, not what they want and build the right thing before building the thing right
- setting up a new product is a set of learning loops
- watch for what is making people uncomfortable
- understand your customers not by bringing an idea but by taking the team to understand the problem
- there is always demand in a service company – fix issues as fast as possible, but that is not the game
- consumability – how much effort does the customer need to go through to get value?
- customers decide value… and therefore decide waste
- measure productivity on value delivered, not features
- work in progress is waste – customers are not interested in your long list of things to do
- good Agile teams have a low number of defects
- map end-to-end flow to find the biggest opportunity in your end-to-end process
- 40-90% of the cost is maintenance not delivery, the cost of quality is way higher than the cost of building quality in, don’t put defects on a list (track them, fix them immediately), root cause every escaped defect, determine why every one happened
- problem with readable specifications is that the text is not refactorable – any text page will have hundreds of ambiguities
- every organisation that calls itself professional should be doing TDD
- legacy code is code without unit tests, use Martin Fowler’s strangler pattern or the Mikado method to refactor
- expertise takes 10 years / 10,000 hours of deliberate practice, need a teacher to challenge, feedback and dedication (The Road to Excellence)
- marketing leader – for a successful product you should be able to name this person
- technical leader – keep two top engineers free to roam around and give guidance
- Empire State Building – on time and under budget, had to manage the flow of materials not tasks, had two alternating mills to keep up schedule and remove failure point
- people who have dome something before should know how to deliver within the constraints
- when managing an organisation you need to manage the capacity, you need to have a stable flow
- kanban – reduce work in progress to expose problems (don’t crash your boat on the first day, keep your limits high then lower your limits and remove your problems one at a time
- kanban board – every column is handover to the next column, the next column (downstream process) gets to define done
- 5 why’s – the cause of the cause of the cause of the cause…, The Team Handbook has good process improvement practices, as do the Six Sigma tools
- delivering value – read Competitive Engineering by Tom Glib and Value Driven Development
- product-centric development – 54% of Fortune 500 companies are heading in this direction
Here is a picture of an exercise we did to map the cycle time of a particular company (it highlighted some of the issues they are having around approvals).
Finally, a huge thank you to Nick Muldoon from Atlassian who helped me out with a space on this course. Also to one of my colleagues who reminded me that we should ask forgiveness not permission when I was dealing with some competing priorities!