Kaizen Camp was held in Melbourne this week, 20-21 May 2013. Kaizen Camp is an unconference held in the style of Lean Coffee with 8 sessions, 60 attendees and over 50 topics discussed. It was the first Kaizen Camp in Australia.
The great part of Kaizen Camp is the networking, learning and knowledge sharing using real world, practical experiences. The discussions were stimulating, interactive and there was a high level of collaboration among all participants. It was great to see many of the usual suspects in the local agile community as well as many new faces.
I didn’t take many notes as I was too busy engaged in many of the conversations. Lynne Cazaly created a few fantastic visual notes which I have included below.
The twitter feed was #kaizencamp
Thanks for Jim Benson (@ourfounder), Simon Bennett (@cgosimon) and Safron Bennett (@saffy1) for facilitating and hosting the event.
And a special thanks to everyone for sharing your ideas, insights and experiences!
I look forward to seeing you at the next Kaizen Camp!
Melbourne Lean Coffee
I host Lean Coffee Meetups with Jason Yip (@jchyip) and Kim Ballestrin (@kb2bkb). If you want more discussions beyond the Kaizen Camp event, join us for Melbourne Lean Coffee which are held regularly. More information can be found on the meetup site.
Last week I attended the LAST Conference (Lean, Agile, Systems Thinking) held at Swinburne University. The LAST Conference is a big departure from the Agile Australia 2012 conference I attended earlier this year. There was no fanfare, no big build up, little corporate advertising and significantly less people. It was also only $50 for the whole day but still contained lots of learning opportunities. It lived up to the advertised “low cost, grassroots mini-conference” message.
The conference schedule contained 5 parallel tracks so it was hard to attend all of it. I found myself at times wandering between sessions to get sound bites of what people where talking about. Being held at a uni one thing I definitely liked was the university lecture theatre style of some of the sessions – it felt right compared to sitting in a large conference center. Unfortunately, I couldn’t stay for the last sessions as I needed to head back into work.
I didn’t take any detailed notes, but here are my takeaways (in no particular order):
- Systems Thinking is the opposite of scientific thinking. Systems Thinking is not:
- Rocket Science
- Sea of Systems a handy guide to Systems Thinking
- Invention is the process of discovering something new or come up with an idea. Innovation is the act of of introducing that idea into the market and commercializing it
- Played some neat games that help with agile learning.
- Stages of learning:
- Unconscious incompetence
- Conscious incompetence
- Conscious competence
- Unconscious incompetence
- I had lots of fun in the Visual Collaboration session fine tuning my sketching skills. Use Wong-Baker Faces to visually represent levels of pain.
- Lots of interesting tidbits some of which I already knew but others just heard of in Edgy Agile things.
Here’s a selection of twitter posts on the conference (#LASTconf):
- @RonicaRoth: #LASTconf motto: you are not an attendee. Excited to participate!
- @lynnecazaly: Story structure: people + place + trouble …people want to know why, why this, why different #lastconf @unorder
- @hwiputra: A good storyteller uses concrete words not abstract words #LASTconf
- @hwiputra: Be comfortable with silence when getting stories out #LASTconf
- @AgileRenee: #LASTconf how to measure value? IRACIS – improved revenue, avoid costs, improved service
- @AgileRenee: #LASTconf my answer: the biggest waste in software dev today is doing the wrong work (benefits to cost don’t stack up)
- @libodyssey: culture is the product of behaviour #lastconf
- @ScrumMasterNZ: Work towards “Decision Meetings” and not “Status Meetings” #LASTConf #agile #lean
- @jodiem: Eg this guy has 3 levels of backlog – team-product , release-quarterly and sprint… #confused #lastconf
- @CEPitchford: The motivation for #offshore at REA was not cost it was talent! #win @hwiputra @frankmt #LASTconf
- @CEPitchford: Standup with #offshore team via Skype was hard. We couldn’t understand each other @hwiputra @frankmt #LASTconf
- @CEPitchford: Was hard for Chinese #offshore team to get visas to come to OZ @frankmt @hwiputra #LASTconf
- @CEPitchford: The whole local OZ dev team went to china for 3 weeks to handover to the #offshore team #LASTconf
- @AgileRenee: Find I’m mentally disagreeing with a lot said in the offshoring session in #LASTconf we have talent and should invest in building it locally
- @jodiem: Self service test environments… Where QA env is exactly the same as production env. Cool #devops #lastconf
- @antomarsh: Team rotation from Aus to China critical #LASTconf
- @gusbalbontin: Words such as “framework” and “governance” should never be in the same sentence as the word innovation. #LASTconf
- IrithWilliams: #Lastconf the real job at a standup is to ‘listen, inspect, adapt’
- @magia3e: Too many context changes slows down the #scrum team. Focus on getting to-do done #LASTconf
- @rooosterboy: How is #LASTconf different to #agileaus ? Seriously.
- @magia3e: If u don’t have some sort of continuous integration toolset/capability it will limit your velocity #LASTconf
- @c2reflexions: @AgileRenee doing a song and dance at #LASTconf
- @magia3e: Document the right stuff, but don’t waffle it out. Cut to the essence of it. communicate it with the right collaborative tools #LASTconf
- @CEPitchford: More control from management = less innovation from empowered teams #LASTconf @frankmt
- @CEPitchford: It’s not about execution anymore. It is about learning. #organizationalchange #LASTconf @frankmt
- @CEPitchford: Change programs: do we actually want to change? Or adapt, innovate and LEARN? #purpose #LASTconf @frankmt
- @CEPitchford: The way we still run companies was invented by people who lived in the last century @frankmt #LASTconf
- @CEPitchford: Project schedules and budgets are a work of fiction anyway @brown_note #LASTconf #fishbowl
- @hwiputra: All good leaders believe in their teams. #LASTconf
- @Drew_1609: Best value and most fun conference attended in a long time #lastconf
- @njhoughton: MVP … what’s the minimum thing to go-live … hold this as a meta-frame as you sprint … my examples are #foresight and #Innovation #lastconf
The visual recordings by @lynnecazaly were done using the iPad Brushes app. I have downloaded the app and now I just need to brush up (no pun intended) my skills. Thanks Lynne for the inspiration to try visually recording my notes.
Thanks to the organisers, Craig and Ed for putting together this great event. Snaps!
Nordstrom is one of USA’s leading fashion specialty retailers and is a Fortune 500 company (2011 – ranked 254). When I think of a fashion retail company, innovation isn’t the first thing that comes to mind. So how does a large retail company like Nordstrom innovate? Through the creation of a Lean Startup team, called Innovation Labs. According to their website,
The Nordstrom Innovation Lab is a new, and growing, team. We act like a startup inside of a large company: we move through ideas quickly, using whichever technologies make sense. We also walk the agile walk: the lab is a collaborative workspace with stickies and note cards everywhere, and we follow agile engineering practices like pairing and test-driven development. On the customer-facing side, we use ideas from both lean manufacturing and lean startup, and test our experiments with customers using human-centered design strategies and tactics.
The below video is a brilliant case study on how the innovation lab uses Lean UX and human centered design to build an iPad application (to help customers select a sunglass) incrementally and getting customer feedback in real-time as they work, so they were never working on anything that wasn’t valued by the customer. They were only doing things that was delivering value.
The innovation lab manager, JB Brown states:
Somebody will have an idea and we will find a way to prove that the idea will work.
We really don’t know what the features are yet. We are going to use customer feedback as we go along in order to build the best thing. Building a feature and testing it until we get to the point where we have something that is good enough.
Building the iPad application isn’t complex and the cycle time to develop a feature wouldn’t take long. But what the innovation labs team has done is cut down the feedback loop times. If this application was built in an office away from the customer, getting feedback would have been much longer. And by getting feedback directly from the end users rather than a user proxy, they have reduced the risk of developing the wrong features.
The innovation lab uses a concept called ‘flash build’, a variation of a flash mob, where a software team shows up at a surprise location to build a minimal viable product application so they can get direct customer feedback in real-time.
It is awesome to see innovation and the use of lean and agile principles and practices in action within a large company.
I first knew David Joyce, a Systems Thinker and Agile practitioner, through the local Limited WIP Society user group in Melbourne and in more recent times I have had an opportunity to know and work with him. David is one of those people who has a knack of explaining something that you can readily understand and comprehend.
David along with Peter Middleton have just published an IEEE paper, Lean Software Management: BBC Worldwide Case Study that contains anecdotal evidence over a 12-month period, lead time to deliver software improved by 37%, consistency of delivery rose by 47%, and defects reported by customers fell 24%.
These are impressive and enviable results.
David’s paper shows how the use of lean methods and thinking including visual management, team-based problem solving, smaller batch sizes, and statistical process control can improve software development.
Quote from David Joyce’s website –
I believe it will be one of the most significant papers in Software Engineering this decade.
– David Anderson
Great stuff David J !!!
I came across a case study on Facebook and how two key factors that contributed to Facebook’s success: people – in particular Mark Zuckerberg himself – and process – ‘moving fast’.
Facebook has a culture of speed and values moving fast above anything else – fast releases and fast learning through fast feedback. Everyone is responsible for quality. There are mandatory code reviews and there is an emphasis on coding conventions. There are automated tests at all levels of the stack, integrated with continuous integration systems and other tools.
There is a firm belief at Facebook that nothing should stand in the way of an engineer who wants to release a change or a new feature to production. There is no separate QA team. Engineers are responsible for the quality of their work. Changes are released daily, often multiple times a day. New features are released on a weekly basis.
Facebook doesn’t publicize that they have a process, however, Facebook’s culture of speed seem to have it’s roots in Lean, Scrum and XP. Though not explicitly stated in the article, I get the impression that concepts from Kanban are used. They have small batch sizes and measure cycle time to enable fast flexible flow from idea to development and then to release into production. Many of the ideas come from Hackathons. Facebook has a focus on human interactions, close collaboration and low ceremony to enable fast releases of working software. High communication bandwidth between the team members and product managers is important. Co-location of the team in the early days was critical from the Harvard dorm rooms to the houses they rented in Ralo Alto.
Agile software development embraces decentralized control and the benefits this brings, in particular with respect to moving fast. It should come at no surprise that Facebook is basically an agile shop, even if you won’t hear much about “Scrum at Facebook” or “XP at Facebook.” They work in small, interdisciplinary teams, and they deliver high-quality software early and often.
To ensure everyone is on the same page and not wasting effort working on the wrong thing, there is a common and shared vision at Facebook which enables the entire company to move in the same direction. Getting a shared vision is a challenge in many large enterprises – most people don’t even know what the vision is let alone share it. Facebook seems to have this nailed:
Mark Zuckerberg’s vision is deeply shared and understood not just by the management team, but by every single Facebook employee.
Reading the case study, I get the feeling that there is a tolerance of failure and mistakes. If Facebook fails, it learns, regroups, adapts, and develops some more – fail fast but recover quickly.
Albeit a several pages long, I encourage you to read the entire Facebook case study – it makes for an interesting read (even for not I.T. folks).
Be sure you read the comments by Don Reinertsen, Alistair Cockburn, Jeff Sutherland, Yishan Wong (former Director of Engineering at Facebook) towards the end of the article.
Have you been in a similar situation as the above Dilbert?
Lean and Agile is about doing more with less. Lean and Agile doesn’t focus primarily on cost reduction, but more on strategic alignment around enterprise agility – reducing waste and simplified processes which then could have an impact on cost reductions. Furthermore, for comparable cost as traditional (waterfall) methods Lean and Agile can deliver higher quality product and a greater return on investment (ROI) by working on the most important and highest valuable features first – the business gets greater value for less.
Lean Software Development which has been popularised by Mary Poppendieck is derived from Toyota’s Production System. Basically, lean is centered on adding value with less work. Lean Software Development (Poppendieck) recognizes the following 7 types of waste:
- Partially done work
- Extra processes
- Extra features
- Task switching
Some of these wastes can have a large impact on the amount of value you can deliver. Essentially, by having less of the above wastes we can deliver more. Partially done work means you have unfinished development and resources are tied up on items that provide no business value. Business value is only delivered when features are fully completed. Partially finished features result in hidden costs to projects. When it’s time to release, you have to complete an unpredictable amount of work. This destabilises release planning efforts and prevents teams from meeting commitments, often resulting in more work. Methods like Scrum deliver small increments of fully working software that are usable and tested. Scrum teams agree on a definition of done to ensure they are delivering features that are truly done, not only in terms of functionality but in terms of quality as well.
One big waste often found in waterfall approaches is doing extra steps and tasks that add no value to the actual process of developing working software. Doing extra process steps (such as necessary meetings, extra paper work, manual reports) ties up resources which can be better used on value-added tasks and on activities of producing working software.
Extra features or the overproduction of features is often a result of gold plating. Gold plating as described in Wikipedia:
Gold plating in software engineering refers to continuing to work on a project or task well past the point where the extra effort is worth the value it adds (if any). After having met the requirements, the developer works on further enhancing the product, thinking the customer would be delighted to see additional or more polished features, rather than what was asked for or expected. The customer might be disappointed in the results, and the extra effort by the developer might be futile.
On one of my past projects we had an Architect who wanted the team to build a framework for the system to cater for future needs. This future need may not be realized as things inadvertently change. The framework is a typical example of YAGNI. There was no real requirement (technical or business) for the framework and there was a simpler solution which still satisfied the immediate business needs. The framework added complexity which in return increased maintenance overheads to support it. Every extra piece of code produced will mean more time is needed to test, integrate, compile and maintain and thus increasing the overall cost of ownership. The key to avoiding gold plating is to ensure you only build the bare minimal that is necessary to deliver the greatest business value. If you don’t need it now, don’t build it. Keeping things simple is one of the Agile Manifesto Principles – Simplicity–the art of maximizing the amount of work not done–is essential.
To help avoid extra features, it is important to identify the minimal marketable features (MMFs). Minimal marketable features is the smallest set of functionality that must be realised in order for the customer to perceive value. It is the minimum viable product that has just those features and no more that is fully functional and allows you to ship the product to users so they can start using it. The goal is to build the features that are the highest priority and has the most business value and avoid building unnecessary extra features that are less useful. Agile’s approach of iterative and incremental development and focusing on delivering the most valuable business capabilities takes advantage of Pareto’s Principle which says you will get 80% of the business value from 20% of the effort. This will allow you to deliver more value with less waste.
To complete more work with less time, you should avoid multitasking or task switching. Every time you switch between tasks, you have to completely shift your thinking and gather your thoughts before you can get into the flow of the new task. Multitasking can make you lose focus as it takes you a while to get back and remember where you were. As a result there is a cost each time you change tasks or shift from one project to another. To complete more work, try single tasking.
Waiting is the result of time delays and idle time (time usually waiting for things to happen and where no value is being added). This can be waiting on people, analysis paralysis, delays in approvals, long planning times, delays in testing, and delays in integration and deployments. Lean seeks to optimise the process by reducing the cycle time, which is the time from when an idea is realised to the time it is consumed by the customer.
Agile approaches such as Scrum emphasise the need for cross-functional teams where the team has all the skills it needs to develop and deliver fully working and tested software in each iteration. The reason for this is to reduce the cost of motion and actions of people that do not add value to producing the product (such as traveling from one location to another to find an answer). Furthermore, Scrum emphasises the need for a dedicated Product Owner who can guide the team daily from a business perspective. All team members and customers are often co-located in a team room on Agile projects to reduce the amount of motion needed to find an answer. Frequent face-to-face verbal communication is also important to reduce the motion of moving artifacts and documents. Traditionally, hand-offs of documents between analysts to designers to developers to testers is fraught with waste and mis-communication.
Finally, Defects are a huge waste and takes resources away from producing business value (new business capability) to fixing defects. Instead of fixing defects, Lean principles address this point by focusing on building quality into the process and preventing defects from occurring in the first place. Agile teams deliver working, tested software every one to four weeks. They find themselves making more changes to the code, and staying focused on today’s deadlines. The development team and the code itself must become more Agile, which means it must be capable of faster change, sooner to keep up with business changes. Agile teams have found in practice that Agile code is extensible, low-defect code with the simplest robust design that will work for the features currently implemented. It is well-factored and well-protected by unit tests. Among the Agile methodologies, Extreme Programming (XP) goes into the most depth concerning how developers can keep themselves and their code agile. Such practices enable the team to do more changes and provide them with a kind of Tai Chi flexibility – a new feature, enhancement, or bug can come at the team from any angle, at any time and teams can make the change with confidence that it won’t compromise on the integrity of the system.
Agile development teams regularly reflect by inspecting and adapting their way of working through retrospectives. This enables the team to make incremental improvements regularly and tackle changes in manageable, bite-sized pieces that can be actioned immediately. These retrospectives are important in identifying and eliminating waste in processes which will allow teams to do more valuable work.
In recent times, Kanban systems are being used in software development to limit a team’s work-in-progress to a set capacity and to balance the demand on the team against the throughput of their delivered work. By doing this we can achieve a sustainable pace of development and flushes out issues that impair performance and it challenges a team to focus on resolving those issues in order to maintain a steady flow of work.
The simple act of limiting work-in-progress with kanban encourages higher quality code and greater performance. The combination of improved flow and better quality helps to shorten lead times, improve predictability and due-date performance. [Anderson 01]
Through commitment to Lean and Agile approaches of waste elimination, simplified processes and continuous process improvement teams can deliver in a continuous flow and do more with less. So next time your pointy-haired boss wants you to do more with less, look into how Lean and Agile can help you.
- [Anderson 01] David Anderson, “Kanban: Successful Evolutionary Change for Your Technology Business”, 2010, Blue Hole Press.
Despite that we are still yet to finish the current scope of work for the Agile Initiatives, we are starting to discuss future items in our backlog – distributed Agile and Agile@Scale.
There are a few projects in flight that couple of colleagues are working on that are large Agile programs of work. Large-Scale Agile by James Shore provides an insightful and thoughtful approach.
On a past project we used a similar technique mentioned in James Shore’s post to Using Bounded Contexts to Minimize Dependencies and Using Kanban to Manage Cross-Team Workflow. Though we didn’t use Kanban specifically, the outcome of the approach was similar – when the Team A is ready to work on something new, they took the next item off of the backlog, work on it until it’s done, and then delivered it to Team B that requested it. Where this feature is prioritized in Team A’s backlog is dependent on when Team B needed it.