Stand up meetings - those short meeting that a team holds every day to update each other. Also called daily meetings, Scrum meetings and probably some other things. The basic format is well known: three questions -
• What have you achieved since we last met?
• What are you working on next?
• Do you have any blocks or impediments?
Yet despite this simple sounding format there is still a lot of subtle detail and variation possible.
Take the questions for example:
• “since we last met” as opposed to “yesterday”: if the meeting happens every day there may be little difference. But there are weekends, people have holidays and occasionally meetings are skipped
• “what have you achieved” as opposed to “what are you working on”: this makes the questions results oriented and many people find it hard to answer because while they have worked on stuff, there is nothing they can yet say they have “achieved”. (I don’t usually enforce this distinction until the team and the developers are experienced in answering the question and actually delivering stuff. To enforce it early can make people negative as everyone reports “nothing”.)
• “blocks or impediments”: blocks might limit discussion to just those things that had stopped work, including impediments means we ask about things which are slowing work down
Still asking the same three questions every day can be boring and sometimes you want to vary the questions as long as you stick to the same key elements I don’t mind.
What is less well know is that there are - at least - three different ways of running the meeting to ask the questions.
For years I asked the three questions in three rounds. With everyone circled around the whiteboard (or if you prefer Kanban board or information radiator or just task board) I would ask the first person “What have you achieved?”, then the second person, then the third person and so on.
Once I completed that round I would start over a second time with “What are you working on today?”. Again, first person, second person, etc..
And then another round of “Any blocks to report?”
One modification was to ask the third question as an open question to the whole group at once. That can speed things up a little although it might lead to one person’s block or impediment monopolising discussion.
The second way to ask the questions - and the one I think most teams use - is a single round asking all three questions at once. So the first developer reports achievements, current work and impediments in one monologue, then the next developer and so on.
I’ve recently started to favour this format simply because it is a little faster so easier to keep a meeting short. But, this week I realised it might be a false economy.
I did some Scrum training for a team in Switzerland and stayed on to do a little coaching. One of the problems the Scrum Master had identified was failure to identify impediments. I stood in their Scrum meeting and heard each monologue, within the monologue people talked about impediments but did not explicityly identify them as such. They were “hidden”.
Splitting the three questions up into three rounds encouraged team members to categorise what they are saying into Achievements, Work and Impediments. It is very clear what is Achieved, what is In Progress and what is slowing them down.
The third way of running a to do it from the team board. Rather than ask each team member in turn you point to a task card on the board and say: “Who’s working on this task? - what’s happening here?” If the task is in the done column it is (obviously) an achievement (only point to done cards that become done since the last meeting.) If the task is in the “In Progress” column then its work that is ongoing and deserves discussion.
After the card have been discussed there are two questions to ask:
• “Anyone not reported?” - which may be the case if two people are working on the same card, in which case they just say “Same as <who ever>”. If anyone has much to say at this point then maybe there should be another card on the board. Why is a team member working on something not agreed?
• “Blockers or impediments?” - which needs saying collectively.
This format works well when the whole team is split into several sub-teams who work together or when some people are remote, in which case someone locally can report for them.
I’d never thought of this approach as anything special until few weeks ago. I read something by David Anderson and he said that his Kanban teams had taken this approach. David went on to say that this format allows for bigger teams because one person can report on a group effort. This formay also deals with remote people more easily.
Finally, there is a common problem I see with team reports: lack of focus.
The cause is usually the lack of a board showing the task (the team board, the Kanban board, the information radiator - I’m repeating myself). Without a board with the task cards on it the team lacks a focus point. When someone can point to a card (i.e. piece of work) and say “I’m doing this” it is physical. Without it the team members end up saying something like “I’m working on that feature which does blah blah blah and ...” which takes more time and looses focus.
Lets be clear: a board showing current tasks brings focus to team reporting.
My Swiss team really want to use an electronic tool. I’ve suggested they look at getting a big plasm screen on the wall to show the status, I’ll be interested to know how it works out.
Saturday, April 11, 2009
Sunday, April 05, 2009
Mr Scrum - Jeff Sutherland in London
On Thursday night I was lucky enough to meet Jeff Sutherland - one of the originators of Scrum - and hear him speak. The event was organised by the Scrum Training Institute and hosted by BT. If you missed this talk I’m please to say ACCU London will be hosting another talk by Jeff in May. Details have yet to be finalised so keep en eye on this blog or join the ACCU London mailing list - although I can say it will be a different talk, so if you did go to this weeks you may well want to go again in May.
So what did Jeff say?
Well there was some drum beating for Scrum. About how Scrum can improve team performance by 200%, 600% or even 1000% in some instances. And about how one venture capital firm in Silicon Valley now only works wit companies who develop software using Scrum.
Jeff also had some notes from Scott Downey on how to get a team started with Scrum. The interesting bit here for me, was that Scott uses some of the same techniques I do when I’m coaching Agile and Scrum teams. For example, I like to run very compressed iterations at first, 1 week instead of 1 month. This helps the team get used to the routine.
Scott is also very keen in “information radiators”, also known as “Kanban boards”, or for the non-techies White Boards. And like me he avoids the use of tools to manage the tasks.
Almost every team I introduce to Scrum or Agile says: “We don’t need a white board, we have a tool”, or “Why should we use a white board when we can get a software tool.” Personally I don’t like tools but I know some people do and some people find them useful. So my answer is: Lets start by not using a tool, using a simple board, and once the team has settled down lets look at whether a tool would be better
A couple of other things Jeff said which I think worth noting.
According to Jeff, Scrum is NOT ...
• a methodology
• a defined process
• a set procedures
One of the questions that often comes up about Agile and in especially Scrum is: “What is the future of the Project Manager?” so I took the opportunity to ask Jeff directly. In summary he said:
• some Project Managers will become Scrum Masters: although the two roles are very different some Project Managers will find the Scrum Master role natural
• some Project Managers will become Product Owners: again, these are different roles but some Project Managers will find the Product Owner role a logical move
• some Project Managers - presumably on large projects - will take on a wider brief, possibly called Programme Manager which involves them less with the development team and more with the groups who are impacted by the work
Jeff was keen to point out that there are still jobs for the those who now hold Project Manager jobs but that those jobs will be different.
Finally, Jeff also named the phenomenon of customers not knowing what they want until they see it. He called it Humphrey’s Law. I’ve not heard it called this before and I can’t find a reference to it so if anyone out there knows it then please send me a link.
For me Jeff’s talk was well timed - I’m off to Switzerland today to teach a Scrum course.
So what did Jeff say?
Well there was some drum beating for Scrum. About how Scrum can improve team performance by 200%, 600% or even 1000% in some instances. And about how one venture capital firm in Silicon Valley now only works wit companies who develop software using Scrum.
Jeff also had some notes from Scott Downey on how to get a team started with Scrum. The interesting bit here for me, was that Scott uses some of the same techniques I do when I’m coaching Agile and Scrum teams. For example, I like to run very compressed iterations at first, 1 week instead of 1 month. This helps the team get used to the routine.
Scott is also very keen in “information radiators”, also known as “Kanban boards”, or for the non-techies White Boards. And like me he avoids the use of tools to manage the tasks.
Almost every team I introduce to Scrum or Agile says: “We don’t need a white board, we have a tool”, or “Why should we use a white board when we can get a software tool.” Personally I don’t like tools but I know some people do and some people find them useful. So my answer is: Lets start by not using a tool, using a simple board, and once the team has settled down lets look at whether a tool would be better
A couple of other things Jeff said which I think worth noting.
According to Jeff, Scrum is NOT ...
• a methodology
• a defined process
• a set procedures
One of the questions that often comes up about Agile and in especially Scrum is: “What is the future of the Project Manager?” so I took the opportunity to ask Jeff directly. In summary he said:
• some Project Managers will become Scrum Masters: although the two roles are very different some Project Managers will find the Scrum Master role natural
• some Project Managers will become Product Owners: again, these are different roles but some Project Managers will find the Product Owner role a logical move
• some Project Managers - presumably on large projects - will take on a wider brief, possibly called Programme Manager which involves them less with the development team and more with the groups who are impacted by the work
Jeff was keen to point out that there are still jobs for the those who now hold Project Manager jobs but that those jobs will be different.
Finally, Jeff also named the phenomenon of customers not knowing what they want until they see it. He called it Humphrey’s Law. I’ve not heard it called this before and I can’t find a reference to it so if anyone out there knows it then please send me a link.
For me Jeff’s talk was well timed - I’m off to Switzerland today to teach a Scrum course.
Sunday, March 29, 2009
Burn-down charts: The Good, Bad, advice and alternatives
I’ve never completely accepted burn-down charts. I know they are a staple of Agile development and I’ve even used them myself but I’ve never been completely happy with them.
The reason I’ve never been happy with them is that they require and initial figure to burn-down. You need an initial number - in hours, days, points or what ever - to seed the chart and then you burn off some amount and you see the line falling.
The problem is that initial figure, it has to come from somewhere. In generating that figure you need some description of the work to be done, i.e. requirements, and you need some estimation of how long it will take. Both known requirements and estimates have their problems.
Burn-down charts were popularised by Scrum where there are, strictly speaking, two types of burn-down chart: the product burn-down chart and the sprint burn-down chart. Since in Scrum the work to be done is fixed for the iteration (barring a major issue) the requirements are pretty well fixed so that isn’t s a big issue, and the estimates are the best known at the time which isn’t too much of an issue.
In a 4 week iteration, with a Sprint Goal I can see were the Sprint burn down has a place. But if the iteration is 2 weeks or 1 week I’m not sure it is worth the trouble. And if there is no Sprint Goal then what does it show? Progress against a collection of tasks?
My bigger issue lies with the Product Backlog burn-down chart. Because the items haven’t been committed to a Sprint then there is every possibility they will change. Indeed, the more Agile you are the more likely they are to change.
However, once the estimate gets out there, once it becomes known the team estimates the project at 100 points of work people start ask questions when the number changes.
There is also an inbuilt assumption that there will an end to the development work. When the thing under development is a Product or a Programme development work may continue for a long time, perhaps ever. So its wrong to talk about end dates - and also wrong to talk about projects because projects, by definition, have an end date.
Then there is the estimate: it is made when there is little information known about the requirements, the system or how much work is needed on the code. So the estimate is going to be pretty inaccurate. The best that can be said is that its a finger in the air.
But, the estimating process normally takes a lot longer than sticking a finger in the air. If you involve the whole team it takes even longer. If you don’t involve the team then its the estimate of some “leadership” which runs counter to the principle of self-organizing teams.
More detailed estimates also leads you into design decisions - because how can you estimate if you don’t know what you are going to do? However, its best to delay design (and other) decisions until the last possible moment because the information on which they are based can change.
The first Agile teams I coached skipped burn-down charts altogether. Then one day a colleague on another project (yes, you Ed), told me his Project Manager felt a lot happier now there was a burn-down chart in place for his work.
And thats where much of the value of burn-down charts. They give Project Manager types something to stare at. Burn-down charts look enough like a Gantt chart to reassure people.
All that said I use burn-down charts. Yes they are useful. They are genuinely useful when you have a piece of work with a defined end condition, i.e. a genuine project.
Of course you have to overcome the estimation problem. The trick is to accept estimates are just that, estimates, do them fast, don’t worry about them. Then do plenty of statistical tracking. How much new work is found each iteration? How much is removed? Then project forward best and worst case.
I did this with a team last year. At first we had a burn-down chart with but I refused to give a end date. After a few weeks we had data on how fast the team was working, what new work was being found and how much work was being removed. From this I could forecast a best case and an worst case end date.
That’s important: there is no definitive end date, just a range of possibilities. The more data you have the more accurate the estimate should be but its no guarantee. Giving a range of dates might not make you popular but it ensure people remember there is no certainty.
Burn-down charts are not the only tool for tracking team progress. Some people prefer burn-up charts. At first I thought this was for psychological reasons - up is more positive than down - but its also easier to add more work to the top.
So, if a team is doing 10 points a week on a 100 point project its easy add another 20 points to the chart and show the team now have to get to 120.
Taken to the extreme you get cumulative flow charts - often used by Kanban teams - shown in this diagram:
These show both the total work done and the total work to-do as constantly rising lines. If total done ever matches total to-do then its game over. This technique is open ended, the work is ongoing. And it is only necessary to estimate a little bit ahead.
So, if you do use burn-down charts:
• Consider using burn-up charts or cumulative flow diagrams
• Don’t make estimates too detailed; don’t worry about over estimating, it will all come out in the wash anyway
• Certainly don’t spend too long making detailed estimates
• Track work done, work discovered as you go along and work removed; you don’t need to put these on the charts but keep the numbers so that you can...
• Use statistics to project a range of end dates
• Don’t let anyone thing a burn-down chart is a substitute for a Gantt or Pert chart
And when people demand a done date remind them that the old method didn’t give them a done date either. Yes it gave them a date but it was never the actual date.
The reason I’ve never been happy with them is that they require and initial figure to burn-down. You need an initial number - in hours, days, points or what ever - to seed the chart and then you burn off some amount and you see the line falling.
The problem is that initial figure, it has to come from somewhere. In generating that figure you need some description of the work to be done, i.e. requirements, and you need some estimation of how long it will take. Both known requirements and estimates have their problems.
Burn-down charts were popularised by Scrum where there are, strictly speaking, two types of burn-down chart: the product burn-down chart and the sprint burn-down chart. Since in Scrum the work to be done is fixed for the iteration (barring a major issue) the requirements are pretty well fixed so that isn’t s a big issue, and the estimates are the best known at the time which isn’t too much of an issue.
In a 4 week iteration, with a Sprint Goal I can see were the Sprint burn down has a place. But if the iteration is 2 weeks or 1 week I’m not sure it is worth the trouble. And if there is no Sprint Goal then what does it show? Progress against a collection of tasks?
My bigger issue lies with the Product Backlog burn-down chart. Because the items haven’t been committed to a Sprint then there is every possibility they will change. Indeed, the more Agile you are the more likely they are to change.
However, once the estimate gets out there, once it becomes known the team estimates the project at 100 points of work people start ask questions when the number changes.
There is also an inbuilt assumption that there will an end to the development work. When the thing under development is a Product or a Programme development work may continue for a long time, perhaps ever. So its wrong to talk about end dates - and also wrong to talk about projects because projects, by definition, have an end date.
Then there is the estimate: it is made when there is little information known about the requirements, the system or how much work is needed on the code. So the estimate is going to be pretty inaccurate. The best that can be said is that its a finger in the air.
But, the estimating process normally takes a lot longer than sticking a finger in the air. If you involve the whole team it takes even longer. If you don’t involve the team then its the estimate of some “leadership” which runs counter to the principle of self-organizing teams.
More detailed estimates also leads you into design decisions - because how can you estimate if you don’t know what you are going to do? However, its best to delay design (and other) decisions until the last possible moment because the information on which they are based can change.
The first Agile teams I coached skipped burn-down charts altogether. Then one day a colleague on another project (yes, you Ed), told me his Project Manager felt a lot happier now there was a burn-down chart in place for his work.
And thats where much of the value of burn-down charts. They give Project Manager types something to stare at. Burn-down charts look enough like a Gantt chart to reassure people.
All that said I use burn-down charts. Yes they are useful. They are genuinely useful when you have a piece of work with a defined end condition, i.e. a genuine project.
Of course you have to overcome the estimation problem. The trick is to accept estimates are just that, estimates, do them fast, don’t worry about them. Then do plenty of statistical tracking. How much new work is found each iteration? How much is removed? Then project forward best and worst case.
I did this with a team last year. At first we had a burn-down chart with but I refused to give a end date. After a few weeks we had data on how fast the team was working, what new work was being found and how much work was being removed. From this I could forecast a best case and an worst case end date.
That’s important: there is no definitive end date, just a range of possibilities. The more data you have the more accurate the estimate should be but its no guarantee. Giving a range of dates might not make you popular but it ensure people remember there is no certainty.
Burn-down charts are not the only tool for tracking team progress. Some people prefer burn-up charts. At first I thought this was for psychological reasons - up is more positive than down - but its also easier to add more work to the top.
So, if a team is doing 10 points a week on a 100 point project its easy add another 20 points to the chart and show the team now have to get to 120.
Taken to the extreme you get cumulative flow charts - often used by Kanban teams - shown in this diagram:
These show both the total work done and the total work to-do as constantly rising lines. If total done ever matches total to-do then its game over. This technique is open ended, the work is ongoing. And it is only necessary to estimate a little bit ahead.
So, if you do use burn-down charts:
• Consider using burn-up charts or cumulative flow diagrams
• Don’t make estimates too detailed; don’t worry about over estimating, it will all come out in the wash anyway
• Certainly don’t spend too long making detailed estimates
• Track work done, work discovered as you go along and work removed; you don’t need to put these on the charts but keep the numbers so that you can...
• Use statistics to project a range of end dates
• Don’t let anyone thing a burn-down chart is a substitute for a Gantt or Pert chart
And when people demand a done date remind them that the old method didn’t give them a done date either. Yes it gave them a date but it was never the actual date.
Sunday, March 22, 2009
BCS Kingston & Croydon - Tuesday 24th
Back in February the snow came down and the evening talk I was due to give to BCS Kingston and Croydon was postponed. (The snow closed Kingston University which was due to host the event.)
Well it was rescheduled and is now happening this week on Tuesday 24 - Lean Constraints Action! on the BCS Kingston & Croydon site. Admission is free and there is no need for pre-registration this time.
Well it was rescheduled and is now happening this week on Tuesday 24 - Lean Constraints Action! on the BCS Kingston & Croydon site. Admission is free and there is no need for pre-registration this time.
Sunday, March 15, 2009
10 things to know about Kanban software development
1) Kanban software development originated by David Anderson. Many of the practices and heuristics have been seen on other Agile teams before but they were first described as a cohesive whole by David.
David’s innovation was to explicitly limit the work in progress. This had been done by other Agile teams before but in Kanban there is a well-known limit on the number of work items which may be worked on at one time. The limit is usually quite low, in the teams I have worked with the limit is approximately the same as the number of developers on the team or slightly less.
2) Many Agile teams use a white board to track work during an iteration. Typically this is divided in to three sections: “To do”, “In progress” and “Done.” When a physically limit to work in progress is imposed it becomes useful to split this down further. Work in progress could be: in development, in test, in analysis or in other states. Each of these may have its own limit.
Thus, the second innovation in Kanban is to split the board into many other columns. Sometimes buffers are placed between the limited columns, these may be labelled “ready”.
3) The Kanban test: In November 2008 on the Kanban mailing list, I asked: “What is the defining characteristic of Kanban that make”, in response David Anderson said:
“For me it is simple... Are you limiting work-in-progress? Are you signaling to pull work from an upstream process? If it is a WIP limited pull system, it is kanban!”
Which give a test for Kanban and is pretty much points #1 and #2 above.
4) The Kanban approach was summed up by Karl Scotland when he said (on Kanbandev again):
“a subtle difference between kanban and typical agile processes such as Scrum. Scrum focuses on being agile which may (and should) lead to improving. Kanban focuses on improving, which may lead to being agile. However, being agile itself is not important - it just happens to be the best way we (or at least I) know at the moment.”
5) The best place to learn more about Kanban is the Kanban dev Yahoo list.
6) There are currently no books on Kanban software development. There is one that comes close, Corey Ladas ScrumBan - Essays on Kanban Systems for Lean Software Development. I’ve read this book and I’m not rushing to recommend it.
7) Kanban derives more directly from Lean Thinking and Lean software development then many of the previous Agile techniques. Once you apply the innovations in 1 and 2 above just about everything else follows.
8) Kanban teams focus more on work flow, the time it takes to get work from one end of the pile to the other. In the extreme Kanban teams dispense with work estimating (which do not add value), iteration planning meeting (planning is an ongoing process), fixed release dates (they release when it is ready) and scheduled retrospectives (they have a stop-the-line approach to address a problem when it is seen).
9) Originally the Japanese word Kanban is two words kan and ban; kan means visual and ban means card. Like many people I talk about Kanban cards but strictly speaking I’m duplicating myself.
In Lean systems the cards are used to pass information, to signal when limits are reached, to signal an out-of-stock situation or some other trigger for action. Thus Kanban has come to mean more than it literal meant, and now the word is used as the name of a method it means even more.
10) Whenever I blog about Kanban I get more hits on this blog. It seems people want to know about Kanban. Actually, I just discovered that at the moment this blog appears on the first page in Google if you search for “Kanban software development.”
The lesson: Kanban is still new and still in its infancy.
For my previous description of Kanban see Making sense of Kanban (and some doubts), Agile and Lean - the same but different, Notes on a Kanban software development experience and there are some other pieces too if you search the blog.
David’s innovation was to explicitly limit the work in progress. This had been done by other Agile teams before but in Kanban there is a well-known limit on the number of work items which may be worked on at one time. The limit is usually quite low, in the teams I have worked with the limit is approximately the same as the number of developers on the team or slightly less.
2) Many Agile teams use a white board to track work during an iteration. Typically this is divided in to three sections: “To do”, “In progress” and “Done.” When a physically limit to work in progress is imposed it becomes useful to split this down further. Work in progress could be: in development, in test, in analysis or in other states. Each of these may have its own limit.
Thus, the second innovation in Kanban is to split the board into many other columns. Sometimes buffers are placed between the limited columns, these may be labelled “ready”.
3) The Kanban test: In November 2008 on the Kanban mailing list, I asked: “What is the defining characteristic of Kanban that make”, in response David Anderson said:
“For me it is simple... Are you limiting work-in-progress? Are you signaling to pull work from an upstream process? If it is a WIP limited pull system, it is kanban!”
Which give a test for Kanban and is pretty much points #1 and #2 above.
4) The Kanban approach was summed up by Karl Scotland when he said (on Kanbandev again):
“a subtle difference between kanban and typical agile processes such as Scrum. Scrum focuses on being agile which may (and should) lead to improving. Kanban focuses on improving, which may lead to being agile. However, being agile itself is not important - it just happens to be the best way we (or at least I) know at the moment.”
5) The best place to learn more about Kanban is the Kanban dev Yahoo list.
6) There are currently no books on Kanban software development. There is one that comes close, Corey Ladas ScrumBan - Essays on Kanban Systems for Lean Software Development. I’ve read this book and I’m not rushing to recommend it.
7) Kanban derives more directly from Lean Thinking and Lean software development then many of the previous Agile techniques. Once you apply the innovations in 1 and 2 above just about everything else follows.
8) Kanban teams focus more on work flow, the time it takes to get work from one end of the pile to the other. In the extreme Kanban teams dispense with work estimating (which do not add value), iteration planning meeting (planning is an ongoing process), fixed release dates (they release when it is ready) and scheduled retrospectives (they have a stop-the-line approach to address a problem when it is seen).
9) Originally the Japanese word Kanban is two words kan and ban; kan means visual and ban means card. Like many people I talk about Kanban cards but strictly speaking I’m duplicating myself.
In Lean systems the cards are used to pass information, to signal when limits are reached, to signal an out-of-stock situation or some other trigger for action. Thus Kanban has come to mean more than it literal meant, and now the word is used as the name of a method it means even more.
10) Whenever I blog about Kanban I get more hits on this blog. It seems people want to know about Kanban. Actually, I just discovered that at the moment this blog appears on the first page in Google if you search for “Kanban software development.”
The lesson: Kanban is still new and still in its infancy.
For my previous description of Kanban see Making sense of Kanban (and some doubts), Agile and Lean - the same but different, Notes on a Kanban software development experience and there are some other pieces too if you search the blog.
Monday, March 09, 2009
We're all Agile now, next stop Operational Excellence
In their keynote at XP Day last December Dan Jones and Marc Baker talked a little about the attempts to bring Lean to the National Health Service. One of the issues they mentioned was that while everyone “could talk the language”, many people had been on courses and many people agreed it was good very few people wanted to make the change.
I recognise the scenario and its one that is on the increase - and not just in the health service.
When a company asks me to help them “get Agile” I start by talking to people. At first I avoid mentioning Agile, we talk about their team, their company, the problems and opportunities they face, the frustration and the changes they want to me help make. I increasingly find that these people say something like “I’ve worked Agile before”, “I went on a course”, “We are quite Agile ... we get pulled in many different directions” or “We’re trying to be Agile... we do stand up meetings”.
There is a debate going on - its been going on for a while but its louder at the moment - about just what “being Agile” means. Lean is being talked about more, either because people want another buzzword or because the true roots of Agile are now clearer.
Few people want to stand up and say “We’re not Agile” - its like saying “I don’t like Apple Pie” or admitting to an embarrassing medical condition. While is hardly surprising it is also a defence mechanism, and it can be a resistance to change.
Increasingly I don’t want to use the word Agile. The word brings a lot of baggage - pair programming, Scrum Master certification and all the rest. Once you use the word people start to have assumptions about what you are going to do.
Sure, many of those assumptions are reasonable: I probably am going to suggets they do visual planning and tracking, I probably am going to send the developers on TDD courses, and I am probably going to organise morning “stand up” or “Scrum” meetings.
But I’m not going to force pair programming on anyone, I’m not going to dogmatically demand 30-day sprints and I’m not going to force testers to write Java.
What I’m more interesting in is creating and instilling an improvement culture grounded in learning. My aim is to improve the way people develop software and run the company today.
So what word do I use for this?
I don’t think there is one. I’m starting to talk about Operational Excellence in Software Development. While that might sound like a bunch of management speak I think it is a better description of what I am trying to achieve.
But this term too has problems.
First it is management speak and a lot of people hear the word “excellence” and think “how can we run before we can walk?” - they see their organization as such a mess that excellence has little or nothing to do with the fire-fighting they do everyday. So any manager which talks about “excellence” is clearly disconnected from the real world.
Second the keyword problem: we live in a keyword driven society, you search Google for a keyword, you SMS a single word to a service, you Twitter half a dozen words, your CV/resume is scanned by software looking for keywords. “Operational excellence in software development” is five words, and includes two expressions which will trigger a million Google hits by themselves.
(Before you ask OESD doesn’t work as a keyword, Old English Sheep Dogs for starters.)
Still, the thing I like about Operational Excellence in Software Development is describes what you want to achieve - what you want to build - not how you are going to build it. “Agile” could have done that once but it was never given the change, look at the Agile manifesto, its about how, not what. It was good at the time but the world’s moved on.
I recognise the scenario and its one that is on the increase - and not just in the health service.
When a company asks me to help them “get Agile” I start by talking to people. At first I avoid mentioning Agile, we talk about their team, their company, the problems and opportunities they face, the frustration and the changes they want to me help make. I increasingly find that these people say something like “I’ve worked Agile before”, “I went on a course”, “We are quite Agile ... we get pulled in many different directions” or “We’re trying to be Agile... we do stand up meetings”.
There is a debate going on - its been going on for a while but its louder at the moment - about just what “being Agile” means. Lean is being talked about more, either because people want another buzzword or because the true roots of Agile are now clearer.
Few people want to stand up and say “We’re not Agile” - its like saying “I don’t like Apple Pie” or admitting to an embarrassing medical condition. While is hardly surprising it is also a defence mechanism, and it can be a resistance to change.
Increasingly I don’t want to use the word Agile. The word brings a lot of baggage - pair programming, Scrum Master certification and all the rest. Once you use the word people start to have assumptions about what you are going to do.
Sure, many of those assumptions are reasonable: I probably am going to suggets they do visual planning and tracking, I probably am going to send the developers on TDD courses, and I am probably going to organise morning “stand up” or “Scrum” meetings.
But I’m not going to force pair programming on anyone, I’m not going to dogmatically demand 30-day sprints and I’m not going to force testers to write Java.
What I’m more interesting in is creating and instilling an improvement culture grounded in learning. My aim is to improve the way people develop software and run the company today.
So what word do I use for this?
I don’t think there is one. I’m starting to talk about Operational Excellence in Software Development. While that might sound like a bunch of management speak I think it is a better description of what I am trying to achieve.
But this term too has problems.
First it is management speak and a lot of people hear the word “excellence” and think “how can we run before we can walk?” - they see their organization as such a mess that excellence has little or nothing to do with the fire-fighting they do everyday. So any manager which talks about “excellence” is clearly disconnected from the real world.
Second the keyword problem: we live in a keyword driven society, you search Google for a keyword, you SMS a single word to a service, you Twitter half a dozen words, your CV/resume is scanned by software looking for keywords. “Operational excellence in software development” is five words, and includes two expressions which will trigger a million Google hits by themselves.
(Before you ask OESD doesn’t work as a keyword, Old English Sheep Dogs for starters.)
Still, the thing I like about Operational Excellence in Software Development is describes what you want to achieve - what you want to build - not how you are going to build it. “Agile” could have done that once but it was never given the change, look at the Agile manifesto, its about how, not what. It was good at the time but the world’s moved on.
Tuesday, March 03, 2009
Making sense of Kanban (and some doubts)
As regular readers will know I’m a fan of the Kanban software development process championed by David Anderson. However it has to be said that the jury is still out on Kanban.
I’ve come to the conclusion that one of the dangers with Kanban is actually one of the reasons I like it. To properly implement Kanban you need to create a learning culture, there really needs to be a drive towards learning, change and improvement. Kanban raises the importance of understanding and creating a learning organization. Let me explain...
Depending on your point of view, Kanban might be:
a. The first second generation Agile development method
b. A collection of common heuristics
c. Dangerously unAgile
d. None of the above (a-c)
e. All of above (a-c)
f. Just another marketing term
Over at the Peripatetic Axiom blog Keith Braithwaite was voicing some doubts last week.
I had lunch with a Scrum trainer recently who commented “There’s nothing really new there, its stuff people have been recommending for a while”. I’ve said some similar myself - I find Kanban as described fits better with the way I’ve been coaching and running Agile teams for five years.
But then, isn’t that where Agile itself started? - people collecting heuristics and making sence out of them?
The Kanban community is not ignorant of some of the issues, Karl Scotland has a recent blog post about not mistaking Kanban for waterfall.
I have to say, some parts of Kanban worry me. For example, I’ve been telling teams for a while to think management by routine, the drum beats you have a planning meeting, a drum beats again and you do a demo, and so on, it all happens in a predictable fashion. So dropping iterations gives me the willies.
Keith’s point about batch size is well taken. Its all very well to talk about Minimally Marketable Features (MMF) but sometimes what the business thinks of as a MMF is a pretty large project in its own right. I remember one customer who’s idea of an MMF was “Works on Mac” which was a pretty major piece of work before we started to even consider the design limitations imposed, and the ones the engineers dreamt up.
Perhaps one of the reasons so many Kanban success stories involve maintenance teams (I have one too, I promise to publish it soon) is because bug fixes make nice MMFs.
However I don’t think this problem is confined to Kanban. All the Agile process suffer with a version of it. Scrum encourages teams to focus sprints on some meaningful goal, basically an MMF at the sprint level. The work breakdown, from business feature to developer tasks is a central plank of Blue-White-Red Agile.
I’m not doubting that teams can come up with small, non-bug fix, MMFs, I just think its difficult. Some technologies make it easier than others, e.g. its easy to come up with an MMF if you are coding a Ruby on Rails website and much harder if you are coding a C++ shrink-wrap legacy app.
Its also a sign of team maturity - both the development team and business team. The more experience the development team is the more likely they are to come up with a work breakdown were each item makes a meaningful contribution to the overall goal and delivers value to the business. It helps if the teams management is good at getting the team to look at options before deciding on what to do.
The business also needs to be experienced in both identifying small deliverable elements and they need to trust the development team. Rather than ask for the World (because they expect to be delivered Luxembourg) they need to be prepared to ask for Holland (and expect to get Holland).
There is something about Kanban that has troubled me for a while and I’ve not been able to put my finger on. Oddly its related to the fact that I’ve found teams pick it up more easily than Scrum based processes. And it goes back to Karl’s point about a superficial resemblance to waterfall.
I’ve finally worked it out: Kanban needs a culture of learning and improvement. Without a relentless drive to improve teams can fall back to glorified waterfall.
With Scrum, or XP, you know you are doing it because there is a lot of information on how to do it. If you start breaking a Scrum practice (without agreeing it in a retrospective) sooner or later someone will pull you up on it. Kanban removes that safety net.
At the moment the safety net doesn’t exist for Kanban. In five years it might be different because there will be more published on it. But in a way I hope not because the need to learn and improve is what I value in Kanban and its why it maps better to my model of development. A safety net might limit the learning and improvement.
The learning culture you need for Kanban is, perhaps, the result of it drawing more directly on Lean than some other Agile methods. In the absence of a safety net teams must think through problems and find their own solutions.
I think Kanban is here, it is here to stay and it will be found useful. But like other methods it won’t work in some places. With any Agile or Lean method there is an riding consideration:
There is no reason why one method is universally applicable.
Some times one method is more appropriate and sometimes another works better - horses for courses. Scrum is best in some work, XP elsewhere and Kanban in others. And all methods need to tailoring, sometimes you need to roll your own method.
I’ve come to the conclusion that one of the dangers with Kanban is actually one of the reasons I like it. To properly implement Kanban you need to create a learning culture, there really needs to be a drive towards learning, change and improvement. Kanban raises the importance of understanding and creating a learning organization. Let me explain...
Depending on your point of view, Kanban might be:
a. The first second generation Agile development method
b. A collection of common heuristics
c. Dangerously unAgile
d. None of the above (a-c)
e. All of above (a-c)
f. Just another marketing term
Over at the Peripatetic Axiom blog Keith Braithwaite was voicing some doubts last week.
I had lunch with a Scrum trainer recently who commented “There’s nothing really new there, its stuff people have been recommending for a while”. I’ve said some similar myself - I find Kanban as described fits better with the way I’ve been coaching and running Agile teams for five years.
But then, isn’t that where Agile itself started? - people collecting heuristics and making sence out of them?
The Kanban community is not ignorant of some of the issues, Karl Scotland has a recent blog post about not mistaking Kanban for waterfall.
I have to say, some parts of Kanban worry me. For example, I’ve been telling teams for a while to think management by routine, the drum beats you have a planning meeting, a drum beats again and you do a demo, and so on, it all happens in a predictable fashion. So dropping iterations gives me the willies.
Keith’s point about batch size is well taken. Its all very well to talk about Minimally Marketable Features (MMF) but sometimes what the business thinks of as a MMF is a pretty large project in its own right. I remember one customer who’s idea of an MMF was “Works on Mac” which was a pretty major piece of work before we started to even consider the design limitations imposed, and the ones the engineers dreamt up.
Perhaps one of the reasons so many Kanban success stories involve maintenance teams (I have one too, I promise to publish it soon) is because bug fixes make nice MMFs.
However I don’t think this problem is confined to Kanban. All the Agile process suffer with a version of it. Scrum encourages teams to focus sprints on some meaningful goal, basically an MMF at the sprint level. The work breakdown, from business feature to developer tasks is a central plank of Blue-White-Red Agile.
I’m not doubting that teams can come up with small, non-bug fix, MMFs, I just think its difficult. Some technologies make it easier than others, e.g. its easy to come up with an MMF if you are coding a Ruby on Rails website and much harder if you are coding a C++ shrink-wrap legacy app.
Its also a sign of team maturity - both the development team and business team. The more experience the development team is the more likely they are to come up with a work breakdown were each item makes a meaningful contribution to the overall goal and delivers value to the business. It helps if the teams management is good at getting the team to look at options before deciding on what to do.
The business also needs to be experienced in both identifying small deliverable elements and they need to trust the development team. Rather than ask for the World (because they expect to be delivered Luxembourg) they need to be prepared to ask for Holland (and expect to get Holland).
There is something about Kanban that has troubled me for a while and I’ve not been able to put my finger on. Oddly its related to the fact that I’ve found teams pick it up more easily than Scrum based processes. And it goes back to Karl’s point about a superficial resemblance to waterfall.
I’ve finally worked it out: Kanban needs a culture of learning and improvement. Without a relentless drive to improve teams can fall back to glorified waterfall.
With Scrum, or XP, you know you are doing it because there is a lot of information on how to do it. If you start breaking a Scrum practice (without agreeing it in a retrospective) sooner or later someone will pull you up on it. Kanban removes that safety net.
At the moment the safety net doesn’t exist for Kanban. In five years it might be different because there will be more published on it. But in a way I hope not because the need to learn and improve is what I value in Kanban and its why it maps better to my model of development. A safety net might limit the learning and improvement.
The learning culture you need for Kanban is, perhaps, the result of it drawing more directly on Lean than some other Agile methods. In the absence of a safety net teams must think through problems and find their own solutions.
I think Kanban is here, it is here to stay and it will be found useful. But like other methods it won’t work in some places. With any Agile or Lean method there is an riding consideration:
There is no reason why one method is universally applicable.
Some times one method is more appropriate and sometimes another works better - horses for courses. Scrum is best in some work, XP elsewhere and Kanban in others. And all methods need to tailoring, sometimes you need to roll your own method.
Monday, March 02, 2009
Japanese translations
As if having Changing Software Development translated to Japanese isn’t enough one keen reader has translated some of my blog entries to Japanese.
Mark Nakamura has translated three of my Agile failure modes pieces
• Failures in Agile process? (original Failures in Agile process)
• More Agile failure modes (original More Agile failure modes)
• Agile failure modes - again (original Agile failure modes - again)
Mark Nakamura has translated three of my Agile failure modes pieces
• Failures in Agile process? (original Failures in Agile process)
• More Agile failure modes (original More Agile failure modes)
• Agile failure modes - again (original Agile failure modes - again)
Friday, February 27, 2009
Requirements not functionality
A footnote to the recent discussion of requirements....
In Competitive Engineering Tom Gilb argues that development groups spend a lot of time focusing on functional requirements but they should actually focus on performance and quality requirements:
“ From the point of view of understanding ‘competitiveness’, ‘levels of achievement’ and ‘associated risk’, the performance requirements are by far the most interesting requirements. Yet, traditionally, too much attention has been given to specification of functional requirements and resource requirements.” Tom Gilb, 2005
Put that in the context of an imaginary payroll software company: understanding what payroll software needs do do is fairly straight forward, most products on the market will do the same thing. But what makes the product competitive is how well it does it.
It relatively easy to list the things your software should do but listing how the software will be more competitive than the opposition, or delivery real business value - rather than a shopping list of features - is more difficult.
In Competitive Engineering Tom Gilb argues that development groups spend a lot of time focusing on functional requirements but they should actually focus on performance and quality requirements:
“ From the point of view of understanding ‘competitiveness’, ‘levels of achievement’ and ‘associated risk’, the performance requirements are by far the most interesting requirements. Yet, traditionally, too much attention has been given to specification of functional requirements and resource requirements.” Tom Gilb, 2005
Put that in the context of an imaginary payroll software company: understanding what payroll software needs do do is fairly straight forward, most products on the market will do the same thing. But what makes the product competitive is how well it does it.
It relatively easy to list the things your software should do but listing how the software will be more competitive than the opposition, or delivery real business value - rather than a shopping list of features - is more difficult.
Monday, February 23, 2009
Requirements: The next challenge for Agile
Continuing my follow up to my latest tell of the Alignment Trap in the Agile Journal and on InfoQ.
Lets get one thing straight: I’m not saying requirements don’t matter.
What I’m saying it: when the context is a broken development organization the most important thing is fixing the delivery process.
In which case, you can, and should, take liberties with the requirements process. Then, when delivery shapes up you should come back and fix the requirements issues. Because requirements is where the long term gain is.
Anyone who thinks I don’t value requirements should look at all the postings on this blog about the importance of Product Managers. The requirements is also where the long term future of Agile is.
Look again at those 4 quadrants:
• Maintenance zone: this segment explains why so many of my friends work at dysfunctional IT shops.
• Alignment trap zone: this explains the traditional approach has failed so badly; companies tie themselves in knots trying to do the right thing when they can’t actually do very much.
• Well oiled IT: this is where Agile takes you. But it leaves you there.
• IT Enabled growth: where we all want to be.
Most companies are currently stuck in the maintenance zone. There are three types of company here:
• those who are happy in the mud; i.e. those who lack the will to do something about it, those who believe IT is always like this, those who earn so much money elsewhere it doesn’t matter.
• those who are trying to move to the Alignment Trap; many will still be drinking “do the right thing” cool aid and are making it worse for themselves
• those who are trying to get to the Well Oiled IT, probably via Agile development
The downturn will finish off many of the companies in the first two groups. Those in Well Oiled will probably be OK, and those who can move quickly will hopefully survive. Still, too many companies will survive despite being stuck in the Maintenance Zone.
There is a whole Agile industry (including me!) helping companies make this shift. To be honest, I’ve come to the conclusion that this is the easy bit. (Don’t believe me? Call me.)
But, what do you do once you get to Well Oiled?
The problem is that while Agile as we know it will get you there it won’t take you any further. It runs out of ideas.
Companies could happily stay in Well Oiled, its a (relatively) nice place to be. And you will probably out compete your competitors. But some of the companies that make it - and those who are already there - will look to go further.
This is where Chris Matt’s point on the Agile Journal site are relevant. Agile as we know it, has largely ignored the Business Analyst and Product Manager roles.
The onsite-customer in XP lacks any kind of strategic view. It worked for the C3 team but they were just replacing an existing system, not inventing a new product or doing great innovation. Even so, the original customer nearly had a breakdown.
Scrum is slightly better, it has a full Product Owner role, but it says nothing about how this role is undertaken. It only speaks about the Product Owner in the Scrum process.
And Chris is right about “user stories.” They are a simple tool for communication with developers. They are not sufficient. To make matters worse most teams use them isolation, they do no adopt scenarios, actors or personas.
How do we fix the problem?
Here are three steps to get started:
1. Recognise the importance of the Product Owner role and staff it properly. You need 1 Product Owner for every 3 to 7 Developers. The newer and more innovative your product the more you need. If you have an older less innovative product you might have 7 developers to 1 Product Owner.
2. Stop looking to Project Managers to fill the Product Owner role. They are not Product Owners and their training is very different.
3. Decide whether Product Owners in your company are Business Analysts or Product Managers. If you develop software for your own internal use (or one client) then they are BAs. If you sell your software (shrink wrap or online) they are Product Managers.
If we are to move beyond Agile software development and build Agile companies it is essential we respect requirements. So far our success has all been based on shifting out the maintenance zone, the next challenge is to move on up.
Lets get one thing straight: I’m not saying requirements don’t matter.
What I’m saying it: when the context is a broken development organization the most important thing is fixing the delivery process.
In which case, you can, and should, take liberties with the requirements process. Then, when delivery shapes up you should come back and fix the requirements issues. Because requirements is where the long term gain is.
Anyone who thinks I don’t value requirements should look at all the postings on this blog about the importance of Product Managers. The requirements is also where the long term future of Agile is.
Look again at those 4 quadrants:
• Maintenance zone: this segment explains why so many of my friends work at dysfunctional IT shops.
• Alignment trap zone: this explains the traditional approach has failed so badly; companies tie themselves in knots trying to do the right thing when they can’t actually do very much.
• Well oiled IT: this is where Agile takes you. But it leaves you there.
• IT Enabled growth: where we all want to be.
Most companies are currently stuck in the maintenance zone. There are three types of company here:
• those who are happy in the mud; i.e. those who lack the will to do something about it, those who believe IT is always like this, those who earn so much money elsewhere it doesn’t matter.
• those who are trying to move to the Alignment Trap; many will still be drinking “do the right thing” cool aid and are making it worse for themselves
• those who are trying to get to the Well Oiled IT, probably via Agile development
The downturn will finish off many of the companies in the first two groups. Those in Well Oiled will probably be OK, and those who can move quickly will hopefully survive. Still, too many companies will survive despite being stuck in the Maintenance Zone.
There is a whole Agile industry (including me!) helping companies make this shift. To be honest, I’ve come to the conclusion that this is the easy bit. (Don’t believe me? Call me.)
But, what do you do once you get to Well Oiled?
The problem is that while Agile as we know it will get you there it won’t take you any further. It runs out of ideas.
Companies could happily stay in Well Oiled, its a (relatively) nice place to be. And you will probably out compete your competitors. But some of the companies that make it - and those who are already there - will look to go further.
This is where Chris Matt’s point on the Agile Journal site are relevant. Agile as we know it, has largely ignored the Business Analyst and Product Manager roles.
The onsite-customer in XP lacks any kind of strategic view. It worked for the C3 team but they were just replacing an existing system, not inventing a new product or doing great innovation. Even so, the original customer nearly had a breakdown.
Scrum is slightly better, it has a full Product Owner role, but it says nothing about how this role is undertaken. It only speaks about the Product Owner in the Scrum process.
And Chris is right about “user stories.” They are a simple tool for communication with developers. They are not sufficient. To make matters worse most teams use them isolation, they do no adopt scenarios, actors or personas.
How do we fix the problem?
Here are three steps to get started:
1. Recognise the importance of the Product Owner role and staff it properly. You need 1 Product Owner for every 3 to 7 Developers. The newer and more innovative your product the more you need. If you have an older less innovative product you might have 7 developers to 1 Product Owner.
2. Stop looking to Project Managers to fill the Product Owner role. They are not Product Owners and their training is very different.
3. Decide whether Product Owners in your company are Business Analysts or Product Managers. If you develop software for your own internal use (or one client) then they are BAs. If you sell your software (shrink wrap or online) they are Product Managers.
If we are to move beyond Agile software development and build Agile companies it is essential we respect requirements. So far our success has all been based on shifting out the maintenance zone, the next challenge is to move on up.
Subscribe to:
Posts (Atom)