I am very grateful to New England Agile (and Ron Verge in particular) for videotaping my presentation. For those of you who haven’t heard me speak about culture and adoption, I believe this is a crucial message for anyone acting as an Agile change agent. Enjoy.
P.S. I am actively working on an eBook for those who prefer print. Drop me an email if you want to help review it before it comes out.
P.P.S Slides are here.
Martin Fowler is among other things the Chief Scientist for ThoughtWorks. He gave an interesting keynote that consisted of 3 mini-talks. I thought it was very effective since it was accessible to those new to Agile as well as interesting for folks like me.
Here are my notes containing the juicy bits:
One problem Agile suffers from is Semantic Diffusion where the meaning of Agile is getting diluted. As we grow, there is increased miscommunication and less understanding. I see this struggle on mailing lists where well-intentioned people sometimes mis-explain things.
Martin then made the case that Agile requires Evolutionary Design. It goes like this: requirements change, so you need adaptive planning and hence evolutionary design. Play the Marshmallow Challenge to experience how this can work.
The next topic (middle of diagram) was about people. He touched on Taylor’s anti-pattern of process-centric view where people are replaceable parts and contrasted this with the research of Alistair Cockburn who classified people as non-linear and variable. Martin suggests that each team must own it’s process and evolution. Not sure how he reconciles this with the enterprise view.
The final topic was on code branching strategies and how continuous integration is the best of all strategies. Heed his call or suffer the despair of code decay in your feature branches.
Dave Thomas talked about a lot stuff so I pulled out the bits that resonated with me and bear emphasis.
Starting with the top right and going clockwise, I’ll make a few comments…
There is no Agile toothfairy to make all the problems go away. A lot of companies only look to Agile when things are really broken. It took your company a long time to create the mess that it is in and it is going to take a while to get out of it. Agile will help and provides a direction and it is going to take hard work. Sorry.
When you have no automated tests in place, acceptance tests add much more value than unit tests. So, consider starting here before learning about JUnit, refactoring and working with Legacy Code.
TDD (Test Driven Design) is a huge technical contribution to the community that stands independent of Agile. It is an amazingly powerful design practice.
We were reminded that a flat org structure with a technical career ladder is essential in a well-functioning organization. It is important to keep your top technical people in technical roles.
Dave has seen the rise of what he calls blue collar programming. So many environments are filled with legacy code. Programmers have to sweat out meaningless design-dead code just to make things work.
One of the workshops I run is to help team members understand root cause analysis. I use it with operations teams as well as product development teams. My workshop goal is to have people leave with a basic understanding and some practice.
I created the diagram below to situate this workshop in a larger context of Kaizen (Continuous improvement).
One starting point is with a team using a Scrum board or Kanban to create BIG visible information. This supports teams in identifying problems or waste to stop the production line and investigate the problem using root cause analysis tools. I introduce two tools and have the participants practice with each:
- Ask Why five times – powerful technique for drilling down into problems.
- Fishbone (Ishikawa) Diagram – looks at the big picture around the problem.
Both of these improve quality to help teams go fast. 5S (sort, straighten, shine, standardize, sustain) is also totally applicable for software – it’s called clean code: coding standard, refactoring, etc.
Finally, the foundations for Kaizen and root cause analysis are:
- NO BLAME. Most problems are related to the system, not individuals.
- Team work and trust. If 100 people each help find 1% improvement, this will be sustainable.
- Genchi Genbustsu – Go and See. When you work on a problem, go to the source and get the facts for yourself. Root cause is about investigation and problem solving – see and think for yourself.
If you want to learn more, check out Implementing Lean Software Development: From Concept to Cash or Toyota Production System: Beyond Large-Scale Production.
Here is a slide deck I have used in training. It’s from last year, and would benefit from a refresh to cut down on the text – still very usable. As usual, you are welcome to use this as well as the diagram under Creative Commons license.