I recently came across the expression “The Scrum Wall”, as in the expression “Hitting the Scrum Wall”. Its akin to “the pain barrier”, or “feel the burn” in aerobics workouts of old.
Once I heard it I knew what it was, I’ve talked about this before, now I know it has a name.
The Scrum Wall is the thing Bob Martin described at the ACCU conference. And it is probably why Jeff Sutherland endorses Test Driven Development and other technical practices from XP.
You hit the Scrum wall when you adopt Scrum and everything goes well, then, after a few Sprints things don’t work any more - to use an English expression, they go pear shaped. You can’t keep your commitments, you can’t release software, your customers get annoyed and angry, it looks like Scrum is broken.
This is what happens when you adopt Scrum without technical practices such as Test Driven Development, continuous integration and refectoring. When teams adopt the Scrum process, they go faster, show progress, things look good... and then the quality becomes a problem. Now the team are fighting through quick sand.
The code quality is poor and developers are expected to continue to make progress. Maybe the Scrum Master/Project Manager reverts to past behavior and demands overtime and weekend working. Maybe the team start busting a gut to keep their commitments. Either way the team is heading for burn-out.
That’s the wall.
Tuesday, July 21, 2009
Monday, July 20, 2009
A true story about CMM
About a decade ago I worked for a major supplier of financial information in London. The company decided it wanted to improve its software development process and the answer to this problem was to adopt CMM - the Capability Maturity Model. Initially the become level 2 and then move on the level 3.
The little group I worked in interfaced to financial trading institutions in the City of London. My project in particular had to respond quickly to changes at the institutions.
The CMM roll-out was a akin to a neutron bomb in reverse. The people were left in place, but their processes and practices were replaced en-mass. Developers attended CMM training and instructed in how to develop software according to the new process.
The effect was devastating. One manager likened it to pouring quick setting concrete on the railway tracks of progress.
I went out and I bought myself a book on CMM so I could understand it. What I learned was that CMM was a way of measuring maturity. It was a meter, imaging it as a ruler. It was a way of assessing your organization. You could measure yourself as 1 CMM, or 2 CMM, up to 5 CMM. It was not a method of working.
The CMM body of knowledge also contained recommendations, “best practices” and examples of good practices but it was not itself a process. It was a meter for measuring your maturity.
From the book I learned that Watts Hymphrey advised companies to: focus on improving their processes first and let the CMM measures improve by themselves.
What I observed in practice was the destruction of working practices an processes. I never observed any attempt to involve those doing the work in process improvement. The consultants knew best. Opposition was to be overcome. Process improvement was something that was done to others.
This wasn’t the company for me and I left. The company was eventually certified as CMM Level 2 and was expected to move to level 3 in time. Time went by and I don’t think the company ever made level 3. I heard that internally CMM was recognised as a mistake and the work was quietly allowed to die. The company also announced major moves to offshore development.
Fast forward to 2009. I recently met someone who was an outside consultant to the company and advised them on CMM adoption. He told me that he, and the other consultants, had advised the company to build on the practices they had and improve them. They specifically advised them not to write new processes and impose them on people.
He also told me that when the company did its own retrospective on the CMM project it was seen as a mistake to have written and imposed new processes on developers. A far better way would have been to improve what was in place with the people who did the work.
So the moral of the story:
• There is a lot of good in CMM - and the more recent CMMI.
• CMM itself is not a process, it is a meter, it is a means of measuring yourself.
• The key is process improvement, focus on improving and the levels will come.
• Don’t replace, improve, evolve. Involve your own people.
The little group I worked in interfaced to financial trading institutions in the City of London. My project in particular had to respond quickly to changes at the institutions.
The CMM roll-out was a akin to a neutron bomb in reverse. The people were left in place, but their processes and practices were replaced en-mass. Developers attended CMM training and instructed in how to develop software according to the new process.
The effect was devastating. One manager likened it to pouring quick setting concrete on the railway tracks of progress.
I went out and I bought myself a book on CMM so I could understand it. What I learned was that CMM was a way of measuring maturity. It was a meter, imaging it as a ruler. It was a way of assessing your organization. You could measure yourself as 1 CMM, or 2 CMM, up to 5 CMM. It was not a method of working.
The CMM body of knowledge also contained recommendations, “best practices” and examples of good practices but it was not itself a process. It was a meter for measuring your maturity.
From the book I learned that Watts Hymphrey advised companies to: focus on improving their processes first and let the CMM measures improve by themselves.
What I observed in practice was the destruction of working practices an processes. I never observed any attempt to involve those doing the work in process improvement. The consultants knew best. Opposition was to be overcome. Process improvement was something that was done to others.
This wasn’t the company for me and I left. The company was eventually certified as CMM Level 2 and was expected to move to level 3 in time. Time went by and I don’t think the company ever made level 3. I heard that internally CMM was recognised as a mistake and the work was quietly allowed to die. The company also announced major moves to offshore development.
Fast forward to 2009. I recently met someone who was an outside consultant to the company and advised them on CMM adoption. He told me that he, and the other consultants, had advised the company to build on the practices they had and improve them. They specifically advised them not to write new processes and impose them on people.
He also told me that when the company did its own retrospective on the CMM project it was seen as a mistake to have written and imposed new processes on developers. A far better way would have been to improve what was in place with the people who did the work.
So the moral of the story:
• There is a lot of good in CMM - and the more recent CMMI.
• CMM itself is not a process, it is a meter, it is a means of measuring yourself.
• The key is process improvement, focus on improving and the levels will come.
• Don’t replace, improve, evolve. Involve your own people.
Tuesday, July 14, 2009
The role of the Agile Coach
I was at EuroPLoP most of last week - a great conference! And I was busy preparing for the conference for the days before that - because I was Programme Chair.
So, not much time for blogging. But I did manage to get a piece in the latest Agile Journal on the Role of the Agile Coach. Originally this was based on the “What does an Agile Coach do?” piece in this blog but the final result was a completely new article.
So, not much time for blogging. But I did manage to get a piece in the latest Agile Journal on the Role of the Agile Coach. Originally this was based on the “What does an Agile Coach do?” piece in this blog but the final result was a completely new article.
Tuesday, July 07, 2009
Agile @ DevelopMentor
I’m pleased to announce that I have entered into a partnership with DevelopMentor. For those who don’t know DevelopMentor they are one of the leading IT training companies in the USA and Europe. DevelopMentor are traditionally a tech-heavy company. Traditionally they offered hard corse courses in C++, C#, Java and so on. They have not so far offered anything for Agile development. Well thats were I come in.
The partnership is in two parts. First DevelopMentor are licensing some of my training material. The first of these is my Foundations of Agile Software Development using Scrum (a 2 day course.) This course is now available in the USA and Europe - and probably most other places if you ask nicely.
The second part of the deal is for me to deliver training to DevelopMentors clients. This will include the Foundations Course plus other courses, again in the UK, Europe, the USA and elsewhere.
For more details see DevelopMentor’s Agile courses see their website.
Initially DevelopMentor are launching with three courses: Foundations of Agile, Requirements with User Stories and Test Driven Development. The first public delivery is schedule for September when I will deliver the Foundations course plus the Requirements course over 4 days (22, 23, 24 & 25) in London.
If your are interesting in the public course get over to the DevelopMentor website quickly, within a couple of hours of them announcing the course they took the first bookings.
Actually, we expect most of the interest to come from companies wanting in house delivery of the course. I delivered the foundations course in Denmark a few weeks ago and got very good feedback from the class.
The partnership is in two parts. First DevelopMentor are licensing some of my training material. The first of these is my Foundations of Agile Software Development using Scrum (a 2 day course.) This course is now available in the USA and Europe - and probably most other places if you ask nicely.
The second part of the deal is for me to deliver training to DevelopMentors clients. This will include the Foundations Course plus other courses, again in the UK, Europe, the USA and elsewhere.
For more details see DevelopMentor’s Agile courses see their website.
Initially DevelopMentor are launching with three courses: Foundations of Agile, Requirements with User Stories and Test Driven Development. The first public delivery is schedule for September when I will deliver the Foundations course plus the Requirements course over 4 days (22, 23, 24 & 25) in London.
If your are interesting in the public course get over to the DevelopMentor website quickly, within a couple of hours of them announcing the course they took the first bookings.
Actually, we expect most of the interest to come from companies wanting in house delivery of the course. I delivered the foundations course in Denmark a few weeks ago and got very good feedback from the class.
Monday, June 29, 2009
Agile FAQ - Kicking off another Agile team
I recently gave some coaching to a big, well known, UK company get an Agile team started. Its interesting, this team have a few novelties all of their own, I’ll blog about that some other time. But they also have all the same questions and doubts that other teams have.
So here is a kind of Agile FAQ, the questions this team asked which all teams seem to ask sooner or later.
Q: What do we do about work items that are too big to fit in one iteration?
A: We will break the work down. We will break business requests into developer tasks. We will implement the minimally marketable feature the business agree to. We will talk to the business customer about what is required, we will implement the smallest thing that will work. It might be new, it might take some time to get the hang of it but it is doable.
Q: Should we have longer iterations? (Because our work items are so large)
A: No, if you have doubts you should have shorter iterations so that a) you see problems sooner, b) you get more practice at breaking work down.
Q: How will I know what to do if I don’t write a technical design?
A: Design is good but do not do more than is needed. Writing a document can be a useful learning exercise but there are other, and faster, ways to do similar things. Technical designs are best done at the white board with a colleague. If you need to document technical knowledge then document it after you have written the code/done the configuration.
There is no place for architects and software designers who are removed from the team. Design and architecture will evolve over time so needs guiding. This means experienced designers need to be involved (preferably coding) with the team daily.
Q: How will the business know what we are doing if we don’t write a functional design?
A: The business will be working with the team in planning meetings and will be seen the work as it is delivered.
Q: How do we manage dependencies between tasks?
A: Identify them and order the tasks accordingly. If need be break them down further.
Q: What if the business wants us to do A and B but not C?
A: Then do A and B but not C. The business pays the bills. If you need to do C for technical reasons - such as system quality - then do it. Don’t do C if its a feature the developers thing is worth having but the business don’t prioritise.
Q: What if the business wants us to do A then B but it would be quicker to do B then A?
A: Explain that to the business but respect their final decision. If they want B sooner then do it first.
Q: What if there is something technical which the business don’t understand and we need to do? The business won’t let us!
A: Explain it in terms the business will understand - this might require some learning and practise.
Q: Shouldn’t we have a detailed plan for future Sprints?
A: There is no point; requirements will change, your knowledge and understanding will increase and you will be better at estimating later. Only plan the next sprint in detail, you can sketch the work beyond that but don’t spend a lot of time on it.
You might sketch out what you expect to do in future sprints in “Release Roadmap|” but remember this will change as you go. Keep the roadmap under review.
Q: Should I include testing a documentation in my estimates? Won’t that make the estimates too large?
A: Yes. If that is work that needs doing it should be included. Not to include it would start to build an additional, hidden, backlog of work. Equally the customer should see the real price of the work, not the price you want them to see with more to come. And if the project manager gets a shock then so be it.
Q: Doesn’t Agile invite scope creep?
A: Yes but in general I find scope reduces on Agile projects. I call it running Scope Creep Backward.
So here is a kind of Agile FAQ, the questions this team asked which all teams seem to ask sooner or later.
Q: What do we do about work items that are too big to fit in one iteration?
A: We will break the work down. We will break business requests into developer tasks. We will implement the minimally marketable feature the business agree to. We will talk to the business customer about what is required, we will implement the smallest thing that will work. It might be new, it might take some time to get the hang of it but it is doable.
Q: Should we have longer iterations? (Because our work items are so large)
A: No, if you have doubts you should have shorter iterations so that a) you see problems sooner, b) you get more practice at breaking work down.
Q: How will I know what to do if I don’t write a technical design?
A: Design is good but do not do more than is needed. Writing a document can be a useful learning exercise but there are other, and faster, ways to do similar things. Technical designs are best done at the white board with a colleague. If you need to document technical knowledge then document it after you have written the code/done the configuration.
There is no place for architects and software designers who are removed from the team. Design and architecture will evolve over time so needs guiding. This means experienced designers need to be involved (preferably coding) with the team daily.
Q: How will the business know what we are doing if we don’t write a functional design?
A: The business will be working with the team in planning meetings and will be seen the work as it is delivered.
Q: How do we manage dependencies between tasks?
A: Identify them and order the tasks accordingly. If need be break them down further.
Q: What if the business wants us to do A and B but not C?
A: Then do A and B but not C. The business pays the bills. If you need to do C for technical reasons - such as system quality - then do it. Don’t do C if its a feature the developers thing is worth having but the business don’t prioritise.
Q: What if the business wants us to do A then B but it would be quicker to do B then A?
A: Explain that to the business but respect their final decision. If they want B sooner then do it first.
Q: What if there is something technical which the business don’t understand and we need to do? The business won’t let us!
A: Explain it in terms the business will understand - this might require some learning and practise.
Q: Shouldn’t we have a detailed plan for future Sprints?
A: There is no point; requirements will change, your knowledge and understanding will increase and you will be better at estimating later. Only plan the next sprint in detail, you can sketch the work beyond that but don’t spend a lot of time on it.
You might sketch out what you expect to do in future sprints in “Release Roadmap|” but remember this will change as you go. Keep the roadmap under review.
Q: Should I include testing a documentation in my estimates? Won’t that make the estimates too large?
A: Yes. If that is work that needs doing it should be included. Not to include it would start to build an additional, hidden, backlog of work. Equally the customer should see the real price of the work, not the price you want them to see with more to come. And if the project manager gets a shock then so be it.
Q: Doesn’t Agile invite scope creep?
A: Yes but in general I find scope reduces on Agile projects. I call it running Scope Creep Backward.
Thursday, June 25, 2009
Agile Governance model
The online Technology Management journal has published an article by me entitled “A new governance model for agile work.”
In the article I argue that Agile based software development needs a new governance model. The old model, based on defined requirements is not applicable - simply because the requirements evolve when working in an Agile fashion. Instead a governance model based on the venture capital investment cycle is more appropriate.
In the article I argue that Agile based software development needs a new governance model. The old model, based on defined requirements is not applicable - simply because the requirements evolve when working in an Agile fashion. Instead a governance model based on the venture capital investment cycle is more appropriate.
Saturday, June 20, 2009
Hitch Hikers, Dynabook, the FT and me
Anyone who bought this weekends Financial Times might enjoy my contributions to the letters page today. If you missed it, then I hope this brings a smile to your face. (The piece I was commenting on appeared last week.)
Agile Coaching from Liz Sedley and Rachel Davies
I used to regular review books on this blog, somewhere along the line I stopped doing it - too many other things to blog about I guess. Plus, while I still read a lot I find it hard to find books which say anything news.
And, I increasingly find I’m reading books before they are published. My friends Rachel Davies and Liz Sedley have been beavering away at their book on Agile Coaching for over a year now. I’ve been reviewing the drafts as they go and I’ve seen it change and improve over time.
The book, Agile Coaching is now available as a Beta download from the Pragmatic Programmers press and the print version will be out in August.
For me the book is a book of two halves. As you would expect half of it is about coaching Agile teams. In that you’ll find that it covers similar ground to my own Changing Software Development - both are about introducing change. While I cover more management and background they cover more personal stuff.
The other half of the book is a nice, modern, discussion of how Agile teams work. Its not Scrum, Kanban, XP or any other method. It describes what you find. Its one of the best introductions to current Agile practices you’ll find. Plus, it incorporates a lot of experience which earlier books couldn’t.
Anyway, the waiting is over see for yourself.
And, I increasingly find I’m reading books before they are published. My friends Rachel Davies and Liz Sedley have been beavering away at their book on Agile Coaching for over a year now. I’ve been reviewing the drafts as they go and I’ve seen it change and improve over time.
The book, Agile Coaching is now available as a Beta download from the Pragmatic Programmers press and the print version will be out in August.
For me the book is a book of two halves. As you would expect half of it is about coaching Agile teams. In that you’ll find that it covers similar ground to my own Changing Software Development - both are about introducing change. While I cover more management and background they cover more personal stuff.
The other half of the book is a nice, modern, discussion of how Agile teams work. Its not Scrum, Kanban, XP or any other method. It describes what you find. Its one of the best introductions to current Agile practices you’ll find. Plus, it incorporates a lot of experience which earlier books couldn’t.
Anyway, the waiting is over see for yourself.
Tuesday, June 16, 2009
I'm on Software Engineering Radio
For those who don’t know Software Engineering Radio is a series of pod casts about, well, software engineering. It was founded by Markus Völter and most of the team are other German software engineers. Don’t worry, its all in English!
Markus and the team are very well connected so they get access to most of the best people in the field.
So, its with a little awe that I am now joining in this collected wisdom. Yes, you can here me talking about Software Development as Learning on Software Engineering Radio. If you’ve ever wondered just what I sound like now’s your chance to find out.
The interview was recorded months ago and focuses on the material in my book (Changing Software Development).
SE-Radio is a totally not for profit organization so you might like to make a small donation if you find it useful.
Markus and the team are very well connected so they get access to most of the best people in the field.
So, its with a little awe that I am now joining in this collected wisdom. Yes, you can here me talking about Software Development as Learning on Software Engineering Radio. If you’ve ever wondered just what I sound like now’s your chance to find out.
The interview was recorded months ago and focuses on the material in my book (Changing Software Development).
SE-Radio is a totally not for profit organization so you might like to make a small donation if you find it useful.
Sunday, June 14, 2009
Hawthorne effect disproved
Interesting piece in last weeks Economist which suggests the Hawthone effect doesn’t stand up to analysis. (For good measure the Financial Times covered the same story over the weekend.)
For those who don’t know, the Hawthorne effect is named after the Chicago telephone factory were it was originally observed. The researchers suggested that the act of experimenting on people changed their behaviour.
Back in 1924 researchers changed the lighting at the Hawthone factory and observed productivity increased. Then they reduced lighting and to their surprised it increased again. The conclusion of the study is widely cited to show that when workers know they are experimented on their performance increases. Another spin on the research suggests it is when workers feel valued their performance increases.
Now it seems the original data has been re-analysed using modern econometrics techniques. What it actually shows is the workers were more productive at the start of the week (lighting changes happened on Sunday.)
(Have a look at the Economist piece or the research itself to understand the subtleties I’ve glossd over.)
Anyone who saw another Economist report from last year knows already that most published research is wrong. That study showed that most of the research published in the top journals is disproved within three years.
Which raises the question of whether less well known and influence journals are actually more reliable but lets leave that to one side for now.
Perhaps the only surprise about the Hawthone effect is that it took over 80 years to be exposed.
And what lesson are we to draw from what we now know?
Well, maybe, if workers are more productive at the start of the week then keep that first two or three days clear for core work. Push meetings such to the end of the week.
For those who don’t know, the Hawthorne effect is named after the Chicago telephone factory were it was originally observed. The researchers suggested that the act of experimenting on people changed their behaviour.
Back in 1924 researchers changed the lighting at the Hawthone factory and observed productivity increased. Then they reduced lighting and to their surprised it increased again. The conclusion of the study is widely cited to show that when workers know they are experimented on their performance increases. Another spin on the research suggests it is when workers feel valued their performance increases.
Now it seems the original data has been re-analysed using modern econometrics techniques. What it actually shows is the workers were more productive at the start of the week (lighting changes happened on Sunday.)
(Have a look at the Economist piece or the research itself to understand the subtleties I’ve glossd over.)
Anyone who saw another Economist report from last year knows already that most published research is wrong. That study showed that most of the research published in the top journals is disproved within three years.
Which raises the question of whether less well known and influence journals are actually more reliable but lets leave that to one side for now.
Perhaps the only surprise about the Hawthone effect is that it took over 80 years to be exposed.
And what lesson are we to draw from what we now know?
Well, maybe, if workers are more productive at the start of the week then keep that first two or three days clear for core work. Push meetings such to the end of the week.
Subscribe to:
Posts (Atom)