On reflection I think I probably tried to cover too many ideas in the talk. As well as my trade mark Agile Pyramid and Alignment Trap (which make it into just about every presentation) I took in a bunch of other stuff. I probably need to refactor this as two or three talks!
The slides for the talk are now online “The role of the Business Analyst in Agile”. If you saw my presentation to the IIBA BA conference last September you will recognise the presentation, only minor changes. I’m giving another repeat in July, this time privately to a big British airline near Heathrow.
A3 reports, for those unfamiliar with them are a mechanism used at Toyota to analyse issues and suggest solutions, or rather “counter measures” . The term “counter measures” is preferred over solution because no “solution” is ever the end of the story. One day there will be a better solution, er, I mean better counter measure.
Anyway, the purpose of writing about this is to share my A3 report templates with anyone who is interested. There are actually two templates:
A3 training: An important part of A3 writing is to “go and see” the actual work happening, and talk to the actual people who do it. In a classroom you can’t actually go and see the issue, you can’t talk to the people performing the task or check the company data. Therefore I allowed students to make assumptions as long as they noted them on the report. Afterwards we could talk about how the assumptions could be validated to prove, or disprove them.
A3 report: this is the same report template without the extra space for assumptions and notes. This is the template to use for real outside the classroom.
Strictly speaking there isn’t a specified A3 format. This confused me when I first started digging into the A3 method: I was looking for templates. It turns out that you can just start with an blank sheet of A3 paper, but it also seems there are some standard elements and structures people use when writing an A3. My templates are what I think are the key elements.
But the actual A3 report, the thing you can see is only half the story. The A3 report is not just a thing, it is a process. The process of creating the report, the observation, investigation and mentoring, is probably more important than the end result.
One thing that struct me while reading Shook’s description of A3 is their similarity to patterns: both involve a context, a problem, the things that make the problem hard (forces or analysis), both propose a better way (solution or counter measures), both value brevity and both allow the authors to change the format to suit the problem.
More importantly, a key element of A3 reports is the mentoring of A3 writers that occurs during the creation process. This sounds just like the shepherding process that any pattern paper being present at a conference goes through. Having shepherded many pattern papers – and won a couple of awards for it, I might say – the A3 mentoring process seems exactly the same.
Back in the Oslo classroom I learned: allow plenty of time for the A3 report writing. Its not something to be rushed.
I recently experimented with A3 formats on a coaching assignment with a client. I asked several manager to complete one. Most of the time, if you are going to ask someone to do an A3 you need some position of respect, or at least authority. They look odd to manager schooled in long report and PowerPoint reports, they require a depth of thinking they are not accustomed to and they look funny.
If anyone tries using these reports please let me know what you think and what your results are. And if anyone wants to do an A3 with me, I will be running the Lean course again in Oslo in November. This course was two days, I’m planning to increase it to three days next time so allow more time for this and other exercises.
I was Oslo recently teaching a course on Lean Software Development. When we were organizing this course on of our goals was: Make it practical. As I was preparing the course material this was at the front of my mind. But, there is a but.
Step back a minute and have another look at my Agile Pyramid:
(By the way I’ve decided to start calling this the Agile Pyramid, I’ve sometimes called it this and sometimes called it the Agile Triangle. Well in the interests of consistency I’ve decided to stick with one, since Agile Triangle tends to be used to refer to project management type stuff Agile Pyramid wins. Besides, Google for Agile Pyramid and I’m on the first page.)
For practical things you look to the top: Scrum and XP are very practical, and prescriptive, Organisational Learning is more of an academic concept than a practical recipe. Lean sits between the two.
Also consider than many writers on Lean (take Like and Morgan for example) caution against seeing Lean as a toolkit you can dip into and select bits to use. They tend towards an “all or nothing” approach which needs change from the top down.
Most of the people I expected to have on the course were software engineers and architects looking to improve their processes and practices, not CEOs looking to reinvent their companies.
Nor do I think I’m unusual in having this problem. One of the reasons the course mandate was “Make it practical” was because some other Lean courses have a reputation for being less than practical.
So what do I do? How do you make something which is largely a philosophy practical?
One of my first decisions was to include Kanban software development. Kanban is a ready made, practical, Lean based approach to software development.
Next: you can’t have a Lean course without talking about Toyota, some of the things they do and some of the thinking behind the Lean approach. However, the objective here needs to be change the way people think about product development; or at least show that other approaches are possible.
The thing about Lean is that its not so much a toolkit of solutions (like Agile) but a systems thinking model to help you devise your own solutions and tools to tackle your own problems. So, having outlined the thinking behind Lean, and one example of how it is done in software I turned my attention to tools to help thinking. Things like: Value Streams and Value Stream Mapping, 5 Whys, Fishbone diagrams, A3 reports and reflection.
Two days was not enough, I might increase it to three next time, but then, you can never give too much time to Lean because to really understand it means doing it. Summarising it in a short course tends to remove the practicality.
One decision I made which might surprise some people was not to start from the Poppendieck’s books for the course. Yes I referenced them, yes I advised my students to read them but I used Morgan and Liker’s Toyota Product Development as a guide.
I was helping a team set up their board (white board, Kanban board, Scrum board, call it what you will) for Agile working the other day and it dawned on me I use a whole bunch of heuristics I’ve never seen written down. So here goes:
I like magnetic white boards best myself but I’ve seen teams use walls, cupboards and flip charts too. The important points are: big, visible things you can stick other-things on it.
I prefer to use index cards but many teams use Post-It type stickies. If you use index cards you need a means of sticking them to the board which is where the magnets come in.
You can divide the columns: classically this is To do, In Progress and Done. Of course Kanban teams use many more columns.
At first I used the same dry market pens to mark the columns as to make notes on the board. The trouble is these lines tend to disappear. This is a particular problem with Kanban teams who have more columns and so more movements to make. So now I use coloured electrical insulation tape to mark the columns. This is much easier to see and lasts a lot longer.
Leave space on the board to include Team or Project name and the end date of the iteration. You might also find space to keep a burn-down/up or cumulative flow diagram.
You don’t need a very big board: I normally use 120cm x 90cm, again Kanban teams tend to need bigger boards because they have more columns.
You can buy a suitable board from most stationary suppliers for less than £100. If your company can’t afford this (or won’t pay) you have problems which Agile isn’t going to fix.
Remember to buy magnets, dry wipe pens and something to remove the permanent market someone is going to put on there eventually.
Coloured magnets are fun but so far I’ve not found using the colour of a magnet to convey information hasn’t been worth the extra effort
Boards are usually mounted on the wall or a stand but, I prefer them to be free standing because you can carry them around. If you have a meeting in another room you just pick the board up and carry it there. And its a team exercise to move it.
We had an accident with a board once: it was hit from behind at the start of the planning meeting and everything came off. But that turned out to be good, we looked at everything in more detail. Sometimes I now remove everything at the start or during the course of the planning meeting and only replace it if I need to.
Don’t put designed on your board: there isn’t enough space. By all means have another board for designs.