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.

Related posts:

1. I am presenting at Agile 2010 I am really excited to have two sessions accepted...
2. XPToronto Talk – Understanding and Dealing with Technical Debt by Amr Elssamadisy Tonight Amr Elssamadisy from GembaSystems presented at the XPToronto/Agile User...
3. Strategies for Effectively Managing Legacy Systems Derek Longmuir presented ThoughtWorks QTB on working with legacy systems....

Related posts brought to you by Yet Another Related Posts Plugin.

For me organizational change is a hot topic since I keep running into it when adopting Agile practices.

Schneider Model for understanding Culture

Israel introduced the Schneider model for understanding company culture. The idea is to use survey questions to categorize the dominant culture into one of four categories (see below).

Many companies we work with are a control culture while Agile is all about Collaboration and Cultivation and (sadly) to a lesser extent about Competence.

You Can’t Change Culture

“Culture is singularly persistent” – Drucker. It is estimated that it can take 10 years for the culture to change in a large company.

Consider the chart in the middle of the diagram below. If we want to be successful in adopting Agile (or anything else) it is essential to focus on harmony with the existing culture. Pushing for different culture will lead to conflict.

Agile adoption leads to conflict

This is an observation rather than a pejorative. With the best intentions Agile will accidentally lead to conflict within the organization. The example given was of different cultural biases within different departments.

For example, Competence in Engineering and Control in Operations. In addition to differing departmental objectives, us vs. them thinking will also create tension. Israel talked about the Outmodel that describes perceptual bias that we create when we have limited information about a situation. The idea being that by design of our organization, there will be conflict between the groups and Agile adoption only makes this worse by perturbing the system.

One idea proposed by Israel is to create a boundary object between different groups. In the case of Development (Engineering) and Operations, one could use Technical debt as a way of measuring the quality of the code to satisfy ops that the code was production worthy. So a  boundary object that has a quantitative measure is very helpful. IMHO, there is much more than this required to ensure that code is production-worthy, but that’s another story.

What I learned about myself

In one exercise we broke into the four groups to explore the different cultures. I went to Control because I have struggled with a few organizations with this culture. What I discovered is that I personally have strong control tendencies. I also discovered that control can save a lot of time by decisive action. The trick is knowing when to apply it. I experimented with my workshop later in the conference and was happy to see that very strong direction around group logistics and exercise structure can make a session more coherent and valuable.

And now for something completely different

Clarke Ching shared a great 6 min animated video on organizational change by Eli Goldratt. It is related so, I’ll throw it in here…

Related posts:

1. Coaching Self-Organizing Teams Joseph Pelrine gave a really interesting session on “Coaching Self-Organizing...
2. Agile 2010 Keynote by Dave Thomas Dave Thomas talked about a lot stuff so I pulled...
3. Rapid reliable releases I recently attended a ThoughtWorks QTB – Rapid, Reliable Releases...

Related posts brought to you by Yet Another Related Posts Plugin.

It is interesting to watch oneself after some time has passed. I would definitely keep the energy and the passion. For sure I would speak S L O W E R (Man, I was like a gerbil on speed). I would also drop most of the text as you can see in my more recent zen-like presentations. A lot of the message is very good – I reminded myself of a few things. Enjoy.

Related posts:

1. Agile Tour Toronto Presentation #2 – Agile Executive Briefing Below are the slides from my first presentation at AgileTourToronto. This is...
2. Agile Tour Toronto 2009 Blasts off! Agile Tour Toronto 2009 is over and it was an...
3. Ways to start with Agile – books, training, or coaching? I wrote this to help explain to the different types...

Related posts brought to you by Yet Another Related Posts Plugin.

The contents of this post are my summary of THE BOOK on this subject: Managing to Learn: Using the A3 Management Process to solve problems, gain agreement, mentor and lead – by John Shook. Available via Lean Enterprise Institute and Ocapt (in Canada).

Why A3?

Over the last year, I have used A3 to solve serious problems myself as well as with clients that I am coaching. I am blown away by how effective it is. I think of it as the howitzer (big gun) of problem solving and use it for complex problems.

Root cause analysis tools are very helpful, however, do not provided a context for resolving problems. A3 is a complete process. If you are not familiar with root cause analysis, see my related blog post.

What is an A3 anyway?

As shown in the middle of the diagram below, A3 is the name for a large sheet of paper (17″ x 11″). With the A3 technique, it is filled up with useful information. Space is intentionally limited to make sure only the most relevant information is shared. At Toyota, the A3 report is used to drive company decisions from shop floor to senior management.

Let’s walk through the sections:

1. Problem – What is the problem that is causing problems? Also, give attention to the title as the summary.
2. Background – How did you decide to work on this problem? What is business problem?
3. Current Conditions – Describe the current conditions with visuals and numerical data that you have analyzed.
4. Goals/Targets – What is the desired target state? This is the place to use SMART goals.
5. Root Cause Analysis – What are the underlying causes? Use ask why five times and fishbone diagram.
6. Countermeasures – How will you reach goal state? What activities can be identified that will address root causes and how were the best ones selected?
7. Plan – What is the plan for getting there? When will the countermeasures be implemented?
8. Followup – What were the results of deploying the countermeasures? Now that there is new information, it is time to revisit the A3.

You may have noticed that this is an elaborated version of PDCA – Plan Do Check Act. This is the heartbeat of a learning organization.

It takes time and effort to complete an A3. Weeks not days. Use when appropriate.

Tips: Experts strongly recommend using real paper. Yes, you will need to re-write; editing is a good thing. A wiki is great for details, but not for thinking and summarizing.

A3 to gain agreement, mentor and lead

In this section, I want to share how the A3 technique is a powerful management tool.  Consider the following diagram:

A3 is about people working together to solve problems. The Japanese word Nemawashi is about going to the roots to reach consensus and alignment in a deep way. An A3 changes the way we work and communicate with each other. When meetings start by reviewing the parts of the A3 that have been completed, there is great focus on the remaining work. I have also seen new project participants brought up to speed very rapidly.

At Toyota, the A3 is used to do work. It is used to solve problems, make (set-based) decisions and execute plans.

Lean is famous for using pull to deliver the right part at the right time at the right place. With A3, the person driving the change effort can pull authority by working with other people and demonstrating leadership. It is chilling to see this work. I was coaching a junior analyst to put together an A3 on a production problem. When the issue escalated, the VP recognized the analyst as the expert and asked him to tell people what to do to fix the problem even though he had no formal or informal leadership role.

Finally, the A3 can be used to build a learning organization. One key aspect is to celebrate mistakes. This is also common with building an innovation culture through Improv or theatre techniques. At Toyota, it is used to develop people by helping them think for themselves to solve problems. A manager’s job is to build people and mentoring people on the A3 is a great way to do it. (Like a self-organizing team, but on an individual scale.)

I wish I had a real A3 to share, but the better ones I have are client confidential.

If you want to learn more, I urge you to buy the book or check out webinar on Managing to Learn.

Related posts:

1. Go Faster with Root Cause Analysis One of the workshops I run is to help team...
2. Use Value Stream Mapping for Current State Assessment This post is about how I run a value stream...
3. Approaches to Organizational Change Mary Poppendieck gave her usual well-researched and convincing tour-de-force presenation...

Related posts brought to you by Yet Another Related Posts Plugin.

In Scrum (and some Agile), we have the notion of cross-functional teams and place value on generalists who can go where the work is. Cross-training charts can help get you there.

Technology and Domain skills

When helping teams assess themselves, I separate technology skills (who knows a library or tool) from domain skills (who know the frazzit module). Once teams do this, the lightbulb goes off – “Oh that’s why it takes so long when we need to do work on the frazzit – only Bill knows it and he is busy with other stuff”.

On the left is a legend I have used with a couple of wiki-enabled clients to track the matrix. (Excel works too and has a nice colouring feature under conditional rules but is less visible.

Consider the example cross-training matrix below for the developers. (QA, BA important too, but they have different technologies/skills). Across the top we have the names of the developers. As you can see, on the front end, they have an OK idea how to use SpringMVC and JSTL; there are no experts, though, so it may not be clear what their frame of reference is. Sometimes people don’t know what they don’t know. Very limited experience with UXD (User eXperience Design) which may be an area for attention depending on usability goals for the product.

What about the domain matrix? Well, it looks the same but with areas of the application outlined at an appropriate level of detail. You can put the whole team (not just dev) on this one.

Lottery/Truck Factor – Are you managing your risks?

Truck factor is about how many people on your team can be hit by a truck before you can no longer effectively support a piece of software.

The cross-training chart can be used to assess how well management is managing risk. Usually what I see is “not at all” and the result shows in terms of deteriorating code quality due to departures and growth.

How to spread knowledge?

There are lots of ways. My favourite is pairing. I also like to impose a limit on publicly declared learning goals – just pick one thing to learn at a time to provide focus.

My suggestion: give your team time to share knowledge and let them decide h0w they want to do it.

Footnotes

• I keep talking to people about this so I thought I had better post on it. Most recent discussion was at a session at Agile Coach Camp in Waterloo.
• See complementary practice of Timeline and Marketplace for understanding other team members.

Related posts:

1. Serious Problems? Use A3 Technique to Nail ‘em! This post shows the A3 technique and how it is...

Related posts brought to you by Yet Another Related Posts Plugin.

I’ll link to the writeup when it is posted.

Thanks to everyone who was there – it was a fun, intense and valuable session for me.

Related posts:

1. How we do things around here in order to succeed I attended Israel Gat’s session with this title at Agile...
2. Coaching Self-Organizing Teams Joseph Pelrine gave a really interesting session on “Coaching Self-Organizing...
3. Constellation, Timeline and Marketplace for Tuning Teams Lyssa Adkins ran a very practical session at DeepAgile that...

Related posts brought to you by Yet Another Related Posts Plugin.

Constellation – Understanding each other through motion

I love this exercise. It provides the team members as well as the coach important information about everyone on the team. It is called constellation since everyone arranges themselves around an object on the floor (in our case a roll of tape) depending how they feel about a statement such as “I like getting results”.  People align their bodies with the statement: standing beside the object signifies strong agreement while standing far away to signifies strong disagreement. It is very powerful since people are engaging their whole bodies. To learn more, there is a full write-up on Lyssa’s blog.

Timeline – sharing our pasts

In timeline, each participant draws a timeline of their life with peaks, valleys and major life events. In turn, each person describes their timeline to the team. Team members listen and note skills or talents (on sticky notes) that stand out. These are then posted at the bottom of the timeline and reviewed as a team. This approach is about figuring out who the person is and what special perspectives they bring to move the project forward. When we did this, it helped the demo subject feel more positive about their talents. Nice.

Marketplace – sharing our talents

In marketplace we pretend we are a vendor in an open-air market place and decide what wares we have to sell. What are our special skills and talents that pertain to this project? We even get to create a banner to attract people. Under the table are things that are true for us, but may not directly relate to the project. The debrief is the same as timeline. Usually a coach will use one or the other (in the training session half of us did marketplace and half did timeline).

Below is my marketplace as an Agile coach.

(This is part of a series on DeepAgile 2010 Games Weekend).

Related posts:

1. Coaching Self-Organizing Teams Joseph Pelrine gave a really interesting session on “Coaching Self-Organizing...
2. How to transform a hero culture Here is a very short (2 min)video where Selena Delesie...
3. Powerful Questions and Powerful Requests Finally, the last in my series of visual notes from...

Related posts brought to you by Yet Another Related Posts Plugin.

The game teaches people skills and resources to be effective coaches by practicing with peers. In the game, people take turns in one of 3 roles: Client (with a problem), Coach, and Observer.

Solve real problems

In the role of Client/Dorothy, you get to be yourself and bring up a problem that you want to work on. Over several iterations, new perspectives help you access the resources you already have. So a cool side-effect of this game is that you get fresh insights into whatever problem you want to work on.

Coach practices questions

The coach gets to practice listening and asking questions. We discovered that listening is something we need to practice since we are so used to jumping in with our expert opinion and solutions.

We also get practice with different types of questions (image by Portia Tung):

Observer provides depth

The observer roles gives you a chance to step back from the situation and really notice what is going on. Portia’s picture captures the simplicity of the task:

I was reminded that observation is a very helpful debugging technique. It is also less than easy – especially if you are like most of us and out of practice.

As the observer, I was able to get much deeper insights.

Go play this game

I am going to play this game again for myself and to help those I am coaching. The complete game instructions and presentation is available for download, so give it a go! I’m sure you will get value out of it. Even better, get Portia to come play with you so you can see some of the finer points.

(This is part of a series on DeepAgile 2010 Games Weekend).

Related posts:

1. Taking Responsibility to Learn and Grow Christopher Avery gave a very interesting talk at Agile 2009...
2. Powerful Questions and Powerful Requests Finally, the last in my series of visual notes from...
3. Team and pair games for building collaboration Tobias Mayer led a fun and effective session (Agile Playground)...

Related posts brought to you by Yet Another Related Posts Plugin.

Don Reinersten really turned me off at the start of his session (The Easy Road to FLOW Goes through a Town named LEAN) which started with what felt like Kanban bashing 101. Many of his comments seemed aimed at a literal implementation of a production-like Kanban system in software – something I have not seen in practice. Despite this misdirection, there were some very strong points that I would like to highlight. See video/slides on InfoQ.

Elimination of Variability is Toxic. Great Product Development requires creativity, taking risks and encouraging failure. No errors means no learning. This reminds me of Jared Spool’s Keynote on building great products and aligns with efforts such as Enough Kanban! Use XP for Single-piece flow.

Don also introduced the Internet (TCP/IP stack) as a very different model for work execution. Again, I was a little disappointed since a lot of teams are already  implementing similar elements. e.g. Different quality of service through urgent tracks in Kanban boards. A number of people said the talk was a quick synopsis of his new book: The Principles of Product Development Flow: Second Generation Lean Product Development and contains ideas that will shape lean software for the next five years. These are smart people so I am going to have to get the book.

Risk, Lean Development and Profit

The second keynote was by Bob Charette.  I love the quote he shared with us about assumptions and risk:

“It’s not what you know that can hurt you; it’s what you know that ain’t so” – Will Rogers

I am reminded of the damage assumptions can bring every time I train people with my Scrum-friendly version of the XPGame. Bob points out that assumptions are risks we have accepted.

Profit = Exchange of Risk. There are three types of risk:

1. Information
2. Control
3. Time

We need to choose between these to maximize profit

Related Posts

Check out blog post: Above All, Stay Open to New Ideas, Humble to the Current Limits of Our Knowledge, and Be Ready to Innovate, Absorbing Ideas from Other Bodies of Knowledge

Related posts:

1. What’s better than Kanban? I was reading Freddy Balle’s book The Gold Mine: A Novel...
2. Kanban for Video Game Production Clinton Keith gave an insightful session around designing and configuration...
3. Enough Kanban! Use XP for Single-piece flow Arlo Belshee and Jim Shore had an interesting pair presentation...

Related posts brought to you by Yet Another Related Posts Plugin.

The purpose of the whole talk is to trash Management by Objectives. See my related blog noting the damaging effects: SMART goals may not be that smart. As an alternative, Mary shares 4 effective models for organizational change.

I have heard a lot recently about the book Switch: How to Change Things When Change Is Hard by Chip Heath and Dan Heath. It uses the metaphor of the Rider and the Elephant. I like it a lot since it lines up well with my NLP tools and understanding of the unconscious mind. Anyway the change model is very clear:

1. Direct the rider – provide clear direction and objectives.
2. Motivate the Elephant – appeal to emotions to provide energy for change.
3. Shape the path – create a supportive environment that will keep things on track.

Toyota Kata: Managing People for Improvement, Adaptiveness and Superior Results by Mike Rother is a second approach for driving change. Check out the above description in the mind map. It reminds me of the A3 technique that I have been using for the last year with great success. I’ll blog on my experiments later.

Strategy and Deming’s systems analysis + PDCA + People were the two final models to round out organizational change approaches that involve people rather than measure them. Caveat: SMART is OK for projects; not people.

Related posts:

1. Fearless Change – Patterns for introducing new ideas I first read Fearless Change: Patterns for Introducing New Ideas...
2. SMART goals may not be that smart I just blogged about Daniel Pink’s case around intrinsic and...
3. Daniel Pink on Intrinsic & Extrinsic Motivation Newsflash! Incentives and rewards are harmful to tasks that involve...

Related posts brought to you by Yet Another Related Posts Plugin.