Here's a typical role and hand-off sequence that I encounter in "waterfall" shops:
Customer -> Business Analyst -> Developer -> Tester
And then they learn about Agile so the sequence changes to this:
Customer -> Business Analyst -> Tester -> Developer -> (Business Analyst + Tester)
... which really misses the point. We're not just re-ordering hand-offs, we actually want to remove them.
What I'm looking for is a sequence that looks more like this:
(Customer + Business Analyst + Tester + Developer) -> (Tester + Developer (referencing Business Analyst and Customer as useful)) -> (Customer + Business Analyst + Tester)
If the Customer time is constrained,
Customer -> (Business Analyst + Tester + Developer) -> (Tester + Developer) -> (Business Analyst + Tester) -> Customer
I was talking to Erik yesterday and he was wary that I used the phrase "make the internal quality issues tangible" and said he preferred visible or explicit.
I suggested that explicit and visible aren't actually enough. I truly mean "tangible" because the particular situation I'm targeting is the non-technical audience that doesn't understand what is happening with the long-term health of their systems due to short-term project trade-offs.
Explicit is a number which is too abstract. Visible is better because then they can see. But I actually want people to feel, emotionally, the danger which they are putting themselves in.
Our target is tangible with visible being along the way there.
Bob Sutton is creating a Selfish Superstar Inventory based on the idea that organisations that destroy cooperation and information tend to celebrate solo, selfish superstars.
That post included a reminder of something described in Hard Facts
organizations that emphasize the differences between the very best versus the "merely" competent and reliable employees may do a better job of holding on to the stars, but often undermine overall team and organizational performance.I wonder if this observation holds true if you replace "organization" with "nation".
I've only presented at Ignite once but here are my rules:
1 concept per slide - no bullet points!
Use images or better yet hand drawn sketches
Rehearse twice... once to learn where to adjust, once more to make sure you can do it... no more, otherwise you'll become inflexible
Don't stop talking! The slide transition is simply a reminder to shift what you're talking about. If you try to match the transitions perfectly, you'll become inflexible.
Hold the mike up to your mouth and keep it there!
Sometimes people use "built-in quality" or "stop and fix" as a replacement for jidoka and I've realised that this is not accurate.
Jidoka is not just about stopping and notifying of problems immediately. It also includes the concept of separating human and machine work. Effectively the idea of using machines to free humans. The machines work for us, we don't work for them.
If we do consider the stop and notify aspect, it's not really about the automated stops and visual indicators. It's really more critically about people seeing problems and pulling andon cords. It's really more about people interpreting what is actually happening.
The most destructive thing to introduce to a team is a sense of powerlessness; the most valuable thing to introduce to a team is a sense of possibility and control.
What I've realised is that for the situations where I have seen ineffective retrospectives, there has also been a lack in a culture of fixing all the small stuff day-by-day (aka daily kaizen culture). My thought now is that the first step should be encouraging daily kaizen through problem / countermeasure boards, daily standups, and just continually fixing all the small stuff before worrying about retrospectives, quality circles, and the like.
There's a cool Lean tool that again I learned from KM&T which is called a Problem / Countermeasure board.
This is a visual management tool using an A3 or whiteboard, etc. that has headings similar to the following:
Owner | Problem | Containment | Countermeasure | Target Date | Status
The structure is simple because what we're targeting here is daily kaizen, all the little problems that happen day-to-day. Containment is about immediate workarounds. Countermeasure is about what we determine should be done after root cause analysis (e.g. 5 Whys) to fix the problem permanently. Status should follow PDCA.
The rules are also simple. When there's a problem, write it up on the board. Make the problems explicit to encourage us to deal with them.
A key point is that this is not a "whining wall". When you write up the problem, you are signing up to champion the effort. And the people signing up should be the operators (aka people doing the work), not managers.
Will be presenting at Agile Brazil at the end of June and here's my bio in Portuguese:
Jason é Consultor Líder da ThoughtWorks. Após se deparar com o Extreme Programming em 1999, ele foi motivado a entrar na ThougthWorks em 2001, onde tem aumentado o seu conhecimento e experiência em práticas Ageis de desenvolvimento de software. Jason conheceu o Lean em 2003, a partir do Desenvolvimento de Software baseados em Lean da Mary Poppendiecks. Desde então, ele se aprofundou na literatura acerca do Lean, frequentou um Lean Summit, visitou fábricas Lean, incluindo a Toyota, e fez a Lean tour no Japão, em 2008. Pode-se destacar que: a atual perspectiva de Jason sobre Agile é certamente influenciada pelo Lean.
Alan Beacham of KM&T recently clarified my understanding of how to use fishbone diagrams and I thought it was worth sharing:
