Slides from my “Falling off a log theory of software development” talk to Software East are online for download.
These slides only give a small part of the talk, it was a real talk with the slides for illustration only. If you want to get a flavour of what I talked about see these past blog entries:
'In search of mediocracy' - The falling off a log theory of business
and
The lining up your ducks theory of software development
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!
Friday, May 21, 2010
Monday, May 17, 2010
Cambridge, Nottingham and Business Analysts
My talk at the first meeting of the IIBA in Nottingham last week went well - don’t just take my word for it Alex Papworth says so too.
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.
What has become clear to me is: a lot of Business Analysts are wondering where they fit in the Agile world. To help with this I’ve collected some resources together about the role of BAs, and Product Owners generally, in Agile projects.
I hope thats helpful. If you are a BA, and you have this question then think about attending one of the two courses I’m running later this year. The first is in August and is specifically for BAs, Agile Foundations for Business Analysts. The second is in October and focuses more on specific Agile techniques, Agile Development and Requirements with Scrum and User Stories.
Anyone who followed my last set of links on A3 report templates may have noticed my website has sprung a new tab “Resources”. The intention is to make material more accessible. So far there are Resources for BAs, Resources for Lean and Resources for Patterns (writers).
Before then, I’m off to Cambridge on Thursday to speak to Software East, The Falling off a Log Theory. So still time to book.
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.
What has become clear to me is: a lot of Business Analysts are wondering where they fit in the Agile world. To help with this I’ve collected some resources together about the role of BAs, and Product Owners generally, in Agile projects.
I hope thats helpful. If you are a BA, and you have this question then think about attending one of the two courses I’m running later this year. The first is in August and is specifically for BAs, Agile Foundations for Business Analysts. The second is in October and focuses more on specific Agile techniques, Agile Development and Requirements with Scrum and User Stories.
Anyone who followed my last set of links on A3 report templates may have noticed my website has sprung a new tab “Resources”. The intention is to make material more accessible. So far there are Resources for BAs, Resources for Lean and Resources for Patterns (writers).
Before then, I’m off to Cambridge on Thursday to speak to Software East, The Falling off a Log Theory. So still time to book.
A3 reports: templates and observations
As I mentioned last time, I recently delivered a course on Lean software development in Oslo. One of the exercises I set people was to produce an A3 report.
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.
Put it another way, as Peter Senge says in The FIfth Discipline, “tomorrows problems come from todays solutions.”
Anyway, the purpose of writing about this is to share my A3 report templates with anyone who is interested. There are actually two templates:
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.
If you want to know more about A3 reports John Shook’s book “Managing to Learn” is good, although you have to order it from the Lean Enterprise Institute, its not at your local online bookshop. For a shorter version check out Shook’s article in the MIT Sloan Management review, “Toyota’s Secret: The A3 report”.
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.
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.
Put it another way, as Peter Senge says in The FIfth Discipline, “tomorrows problems come from todays solutions.”
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.
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.
If you want to know more about A3 reports John Shook’s book “Managing to Learn” is good, although you have to order it from the Lean Enterprise Institute, its not at your local online bookshop. For a shorter version check out Shook’s article in the MIT Sloan Management review, “Toyota’s Secret: The A3 report”.
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.
Thursday, May 13, 2010
How do you make Lean Practical ?
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.
And since building a Lean organization really means building a Learning Organization my own Changing Software Development was the course book.
If your interested, it looks likely that the course will run again in Oslo in November.
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.
And since building a Lean organization really means building a Learning Organization my own Changing Software Development was the course book.
If your interested, it looks likely that the course will run again in Oslo in November.
Wednesday, May 05, 2010
What Is Software Design?
This link has been in my blog backlog for a couple of months, waiting to work its way into a blog post. But I’m fed up waiting so here it is raw.
What Is Software Design? by Jack W. Reeves on Developer Dot Star
Originally published in 1992, before Java, before C#, before Agile, when Lean was just breaking out of Toyota and before the web (almost) this is a classic piece about software design.
Reeves argues that all coding is design. His specifics might refer to C++ but this could be any language.
Just in case you are in any doubt: I completely agree.
What Is Software Design? by Jack W. Reeves on Developer Dot Star
Originally published in 1992, before Java, before C#, before Agile, when Lean was just breaking out of Toyota and before the web (almost) this is a classic piece about software design.
Reeves argues that all coding is design. His specifics might refer to C++ but this could be any language.
Just in case you are in any doubt: I completely agree.
Tuesday, May 04, 2010
Falling off a Log live!
Bookings are now open for my talk to Software East in Cambridge later this month (20th to be exact.)
There is a £10 charge but you do get buffet, I’m told places are limited and there are quite a few bookings aleady.
The talk is entitled “The Falling off a Log theory and other observations on the software industry”. Think of it as the road-show version of Falling off a Log.
There is a £10 charge but you do get buffet, I’m told places are limited and there are quite a few bookings aleady.
The talk is entitled “The Falling off a Log theory and other observations on the software industry”. Think of it as the road-show version of Falling off a Log.
Saturday, May 01, 2010
Brain dump on team boards
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.
Subscribe to:
Posts (Atom)