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
Advertisement

Episode 2: Squeeze your revolutionist today

The Agile Revolution Podcast

SqueezeA fun filled podcast presented by Craig, Tony and Renee covering the following topics:

Quotes:

“I don’t program software anymore, I program people”

TheAgileRevolution-2 (43 minutes)

View original post

Agile Australia 2011 Day 2 Review

Agile Australia 2011Day 2 at Agile Australia 2011 and another jam packed day. Here are my notes from the sessions I attended.

Keynote – Elevating the Agile Community of Thinkers 

Jean Tabaka presented this keynote, barefoot, and her slides are available here.

From Agile Australia 2011
  • A Community of Thinkers” – drafted by Liz Keogh, Jean Tabaka and Eric Willeke
  • need to apply energy to learning rather than frustration – need to subscribe to the art of the possible
  • it is no longer acceptable in the 21st century to administer in the business, we need to create and provide innovative communities
  • fearful that in the agile community that we are in conflict mode but rather we should seeking enquiry and insights and learning from each other, such as we do in an daily standup
  • to be the best we can be every day, we need to inspire insights from the entire team – the definition of a good daily standup
  • Patrick Lencioni’s “The Five Dysfunctions of a Team” also apply to community
  • “vulnerability can create great workplaces and innovation” (Dr. Brene Brown)
  • our greatest wisdom is every insight in the room and is only as good as the quietest voice in the room – we have to lower the bar
  • in a command and control environment we lose wisdom and lower their IQs
  • in global teams you need to invite their wisdom in anyway possible – secret to distributed teams
  • Kathy Sierra – magic for Creating Passionate Users
  • drop outs give up when they believe they suck
  • amateurs learn how to do it and then become complacent
  • experts – keep pushing themselves to find a better way
  • in agile need to believe past both the “this sucks” and the “kick ass” threshold
  • we need active participants in our communities, rather than passive participants
  • Linchpin (Seth Godin) – being a genius self, being part of community means hard work
  • Principles of Product Development Flow (Donald Reinertsen) – this and Linchpin are Jean’s most dog-eared books
  • empathy mapping (gogamestorm.com) – look at your community and what are they thinking, hearing, saying, doing, seeing
  • use a wall of appreciation as well as a wall of break up letters to improve community and move past blockers
  • writing love letters to agile – interesting…
  • to be a linchpin your message needs to be accessible (charm), need to create talent around your message and have perseverance
  • “Drive” (Dan Pink) – autonomy (able to bring your genius self to work), mastery and purpose (a big hairy goal) – you will be creative
  • need to design a life and not a plan – how can we grow and be emergent in what we do, plans stagnate and stagnation kills
  • “Preferred Futuring” (Lawrence Lippitt) – create concrete wishes on where we want to be, need to bring this more into our workplaces
  • need to move – tell -> sell -> test -> consult to co-creation
  • find your mentor, or become that person
  • think like a genius – creating models of what might be true
  • example of Rally using lino to organize an open space – awesome
  • Jean not wearing shoes in this keynote is going out of your comfort zone – onedaywithoutshoes.com

Panel – Software Engineering is a Dead Craft

I was honoured to be given the opportunity to moderate this panel, consisting of Martin Fowler, Kane Mar and Paul King. My opening comments were as follows:

Software Engineering is defined by the IEEE is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software, that is, the application of engineering to software.

This led me to then get a definitive definition of engineering, which is loosely defined by a number of the leading engineering councils worldwide as being the discipline of acquiring and applying scientific knowledge, mathematics and ingenuity to design and build solutions that safely improve the lives of people.

Software engineering as a term has been around since the early 1960s, and, as Rob Thomsett pointed out in his keynote yesterday, was popularized when NATO hosted a conference to address the problems of software development. In there report, they particularly point out that the phrase software engineering was deliberately chosen to be provocative. So for the last 50 years, practitioners everywhere have been debating software engineering, from the software crisis that made developing software into a career, through to Fred Brooks coining the No Silver Bullet argument that no individual technology would make a 10 fold improvement in productivity in 10 years, through object oriented programming and the rise of XP and agile.

So what is software engineering. Is it an engineering practice that is dead? Is it a craft or an art form? Or is it both dead and a craft?

Martin Fowler is the Chief Scientist at Thoughtworks, author of many books on software development and a signatory to the agile manifesto.

Kane Mar is the President of Scrumology, and has been a developer and coach in the software industry for 20 years.

Paul King is the Director of ASERT and has been developing, training and contributing to the software development field for nearly 20 years, and is an active contributor to a number of open source projects including, most notably, Groovy.

My questions started as follows:

Martin – when you do any Google search on software engineering, every second link seems to point back to your website and any number of articles you have written on this subject over a number of years. You indicated your position is that the engineering metaphor has done our profession damage…

Kane – you listed your point of view on the topic is that the paradigm has come and gone and that perhaps software should be viewed as an ecosystem…

Paul – your viewpoint is listed as probably a little more conservative and that continuous learning is important…

The time flew by and I did not get to take anywhere near the number of questions I would have liked from the audience. The highlight was a question from the audience from Phil Abernathy who asked the panel if perhaps we should term what comes out of a number of projects as “crapmanship”.

Agile and Enterprise Architecture are not Mutually Exclusive

I had the pleasure of introducing Rebecca Parsons from ThoughtWorks, her slides (in all their Comic Sans MS glory) are available here.

From Agile Australia 2011
  • architects need to depress their ego and pair on critical stories and calm their concerns
  • some architects believe their job is to stifle any innovation in the development team, but they a disappointed that the team is not innovating
  • the IDE of enterprise architects has been PowerPoint for years
  • developers must code in a box, architects must worry about a bigger box
  • it is hard for enterprise architects to talk to every developer, so documents from high are standing operating procedure, unfortunately they get ignored because the context is hidden
  • use stories for technical requirements – architect communicates his requirements via a technical story and the development team responds with this is what it is going to take – ensures that the value is articulated
  • need architects to articulate their requirements based on acceptance tests
  • harvest components and talk in the community – ask who was the last person to integrate with this component and talk to them
  • development team should be focussed on delivery of their project, agile is the engine and architects need to use this engine

The Speed to Cool: Valuing Testing and Quality in Agile Teams

The session I presented got a good turnout, and plenty of questions afterwards as well as some follow-up emails.  The slides are available in a separate post as well as here.

From Agile Australia 2011

Rolling Out ‘Agile principles’ in a Global Organisation – A Continuous Journey

I introduced Sascha Ragtschaa from Computershare, his slides are available here.

From Agile Australia 2011

A Rogue’s Take on the 4 ‘C’s: Culture Change Costs Currency

I had the pleasure of both introducing and being a live prop (the dragon representing the (large) organisation) in this presentation by my good friend and colleague Renee Troughton from Suncorp. Her slides are available here.

From Agile Australia 2011
From Agile Australia 2011

Keynote – Software development in the 21st Century

Martin Fowler delivered his now famous 3 short keynotes.

From Agile Australia 2011

Non-Determinism and Testing

  • non-determinism – intermittent fails, we don’t know if something is going to succeed or fail – also called a useless test
  • non-deterministic tests infect the whole system – need to quarantine these tests to stop them bringing down the while suite – often caused by interference between tests
  • you can track dependencies or you can use isolation (preferred method)
  • tests should clean up after themselves and leave the world the way they found it but other tests rely on this happening (and hard to track failures when they occur) or start all tests with a clean slate (but it can take a long time)
  • asynchrony – can use a bare sleep but you never know how long to sleep for, could use a polling loop or a callback
  • remote services – don’t talk to them as part of the test, use a test double

Value of Software Design

  • this was a repeat session from last year where Martin did his famous Uncle Bob Martin rant. A highlight for me was in his example he used Nigel Dalton as good code example and me as a bad code example.

Agile Manifesto: 10 years later

  • we know the approach works and we need to use it more and find the boundaries
  • XP was the dominant strain at the time – has appeal of its values and principles as well as its practices like test driven development, etc…
  • many of the original people are unhappy – the core ideas have not moved as fast as the hype (semantic diffusion) and the rollout process is very long running
  • if you say you don’t care about agile you are saying you are happy with flipping the principles back again
  • do not treat stories as one-way traffic, the value is in conversation
  • as software developers we need to ask ourselves if we are making the world a better place
  • mundane work and the little things often make the world a better place

Conference Retrospective

I led a conference retrospective after the post-conference drinks. For those who stuck around, we had a good discussion on what was good and what we could do better next year.

What Was Great

From Agile Australia 2011
From Agile Australia 2011

How Can We Improve

From Agile Australia 2011
From Agile Australia 2011

New Ideas

From Agile Australia 2011
From Agile Australia 2011

Other Stuff

There have been some other wrap-up and retrospectives written about the conference including:

Also, a couple of mentions for some of my other friends and colleagues who presented on day 2 but due to my other commitments I could not attend their sessions.

Jonathan Coleman, Steve Jenkins and Phil Abernathy all did lightning talks which were all well received.

Nicholas Muldoon from Atlassian delivered a talk called “Be The Change You Seek”, his slides are available here.

Paul King (who I have presented with many times previously) delivered a workshop called “Leveraging Emerging Technologies in Agile Teams”, his slides are available here.