As some of you will recall, I was one of the Chairs for the European Patterns conference in 2008 and 2009. One of my responsibilities for the 2009 conference was to produce the conference proceedings. Well I’ve done it!
2009 represents a change for EuroPLoP. Until now we have published our proceedings in a physical book, a large book I should mention. This cost the conference organisers money (because it sold almost no copies), the money pushed up fees, and the proceedings were almost completely inaccessible unless you actually went to the conference. While some authors (like myself) put their papers online not everybody did.
For 2009 this has all changed, we’ve gone electronic. Thanks to CEUR EuroPLoP 2009 proceedings are available for free to anyone who want them. You can download individual papers or everything as one 30Mb PDF file.
So roll up, roll up, get your EuroPLoP 2009 conference proceedings here!
Thursday, March 25, 2010
Sunday, March 21, 2010
Change models: Shook, Schein, Dreyfus and Constructivism
Continuing on from my opening comments in the last entry, “Why forecasts fail: simple ones are better ”...
The other article which was good in the latest MIT Sloan Management Review was John Shook’s piece on change. His change model complements my own ideas well.
Shook’s model is shown below. He sees change starting with specific practices, e.g. just-in-time inventory, and as teams improve their practices and deepen their understanding they move to more thinking for themselves.
I’ve written before about my Agile triangle (or maybe pyramid is a better term). In the last few months I’ve added another insight into this model. Team which start by just “doing Scrum” or “XP” and want to advance, improve their process and practices further, deepen their understanding and application, take the next step, call it what you will, well, they need to advance by moving down the triangle.
You might start doing XP but over time you want to look outside XP and see what else is out there in the Agile toolkit. Deeper still is going back to Lean and picking up the Lean tools (value stream mapping, A3s, focusing on flow, etc.) And deeper still is a learning organization, a team or unit that is continually learning and changing.
While this goes some way validating my ideas its not the end of the story. Shook goes further and suggests his model parallels Edgar Schein’s writing - Schein is an MIT Management professor who has written extensively on culture and organisations.
Schein argues that organisational culture cannot be changed directly, indeed, to start with a desire culture in mind is a mistake. Better to start with the issues in hand and set about changing the cultural artefacts. Shook gives the model below (similar but inverted to the one on Wikipedia.)
It hadn’t dawned on me before, although heaven knows I once read plenty of Schein, that this isn’t far from my model. XP and Scrum, and other Agile methods, really start by changing the culture artefacts of an organisation.
Out go Gantt charts, in come burn-down charts.
Out go status meetings, in come stand-up meetings.
Out go moving deadlines, in come fixed iterations.
And so on.
Only later, are teams expected to reflect and modify their models - moving down the triangle/pyramid, moving from XP to Agile, to Lean, to a Learning Organization.
This also fits well with the Dreyfus model of skill acquisition which is so well liked by many in the Agile community. In this model a Master teach the pupils, when the pupils have mastered the skills they are allowed to think for themselves.
I’ve always disliked the Dreyfus model, and I believe it has failure built in. This is because the learner spends a long time looking to the teacher for the answers, they are not encouraged to find their own, indeed they are discouraged from trying anything different to accepted norm. Consequently someone may have mastered the skill they set out to, but they are no better at learning or problem solving. Faced with a new problem, or a need to deepen their understanding, and without a Master teach and ready made answer they are lost.
Maybe I over worry about this danger, as usual the truth is probably somewhere in between the two extremes. Rather than the Dreyfus model I look to the Constructivism model of learning. Under this understanding it is peoples understanding, derived from their experience which constitute learning. The teacher is not there to teach so much as to help individuals experience something different, the individuals sense making process then takes over.
Still, as I’ve said before: my interpretation Agile comes from Lean and the underlying idea of organisational learning. (Indeed, I think I wrote a book about that!)
As a result when I’m trying to make teams more Agile, I’m really trying to make them better learners, and make the organisation as a whole a better learner. While publicly we might be working down the Agile pyramid secretly I’m trying to work up.
The other article which was good in the latest MIT Sloan Management Review was John Shook’s piece on change. His change model complements my own ideas well.
Shook’s model is shown below. He sees change starting with specific practices, e.g. just-in-time inventory, and as teams improve their practices and deepen their understanding they move to more thinking for themselves.
I’ve written before about my Agile triangle (or maybe pyramid is a better term). In the last few months I’ve added another insight into this model. Team which start by just “doing Scrum” or “XP” and want to advance, improve their process and practices further, deepen their understanding and application, take the next step, call it what you will, well, they need to advance by moving down the triangle.
You might start doing XP but over time you want to look outside XP and see what else is out there in the Agile toolkit. Deeper still is going back to Lean and picking up the Lean tools (value stream mapping, A3s, focusing on flow, etc.) And deeper still is a learning organization, a team or unit that is continually learning and changing.
While this goes some way validating my ideas its not the end of the story. Shook goes further and suggests his model parallels Edgar Schein’s writing - Schein is an MIT Management professor who has written extensively on culture and organisations.
Schein argues that organisational culture cannot be changed directly, indeed, to start with a desire culture in mind is a mistake. Better to start with the issues in hand and set about changing the cultural artefacts. Shook gives the model below (similar but inverted to the one on Wikipedia.)
It hadn’t dawned on me before, although heaven knows I once read plenty of Schein, that this isn’t far from my model. XP and Scrum, and other Agile methods, really start by changing the culture artefacts of an organisation.
Out go Gantt charts, in come burn-down charts.
Out go status meetings, in come stand-up meetings.
Out go moving deadlines, in come fixed iterations.
And so on.
Only later, are teams expected to reflect and modify their models - moving down the triangle/pyramid, moving from XP to Agile, to Lean, to a Learning Organization.
This also fits well with the Dreyfus model of skill acquisition which is so well liked by many in the Agile community. In this model a Master teach the pupils, when the pupils have mastered the skills they are allowed to think for themselves.
I’ve always disliked the Dreyfus model, and I believe it has failure built in. This is because the learner spends a long time looking to the teacher for the answers, they are not encouraged to find their own, indeed they are discouraged from trying anything different to accepted norm. Consequently someone may have mastered the skill they set out to, but they are no better at learning or problem solving. Faced with a new problem, or a need to deepen their understanding, and without a Master teach and ready made answer they are lost.
Maybe I over worry about this danger, as usual the truth is probably somewhere in between the two extremes. Rather than the Dreyfus model I look to the Constructivism model of learning. Under this understanding it is peoples understanding, derived from their experience which constitute learning. The teacher is not there to teach so much as to help individuals experience something different, the individuals sense making process then takes over.
Still, as I’ve said before: my interpretation Agile comes from Lean and the underlying idea of organisational learning. (Indeed, I think I wrote a book about that!)
As a result when I’m trying to make teams more Agile, I’m really trying to make them better learners, and make the organisation as a whole a better learner. While publicly we might be working down the Agile pyramid secretly I’m trying to work up.
Monday, March 15, 2010
Why forecasts fail: simple ones are better
As regular readers may recall (one of my favourite expressions!)... I regularly ponder my subscription to the MIT Sloan Management Review. After a few dull issues - which leave me wondering if it is worth the money - it has once again come up with an issue with a couple of articles which justify the price for the whole year.
One of these is “Why Forecasts fail. What to do instead.”
The insights I find illuminating here are:
This fits in well with what I tell teams when I’m coaching and training in Agile methods. The simple estimation and velocity measures I advocate are better than the complex models which are too often preferred.
And it is no use asking a system expert (architect, senior developer, what-ever) how long it will take, their estimate is no better than anyone else. But, getting several different estimates (e.g. using planning poker or similar) is.
One technique suggested by the article is something I’ve tried in “future-spectives.” You say to the team, or individual, “Imagine we are at the end of the project, we have finished on time, in budget, everyone is very happy, what did we do right?” and the opposite: “Another failed project, what did we do wrong?” Imagining yourself in that situation can produce useful insights.
One of these is “Why Forecasts fail. What to do instead.”
The insights I find illuminating here are:
- Sophisticated, complex, models are good at fitting past data (“forecasting wit hindsight”) but they only not very accurate in predicting what will happen in the future (they tend to extrapolate)
- Simple models are not so good at explaining past data but are better at forecasting the future
- Human judgement is worse than statistical models at predicting the future
- Experts don’t predict any better than the average person
- Averaging the predictions of several independent individuals is more accurate
This fits in well with what I tell teams when I’m coaching and training in Agile methods. The simple estimation and velocity measures I advocate are better than the complex models which are too often preferred.
And it is no use asking a system expert (architect, senior developer, what-ever) how long it will take, their estimate is no better than anyone else. But, getting several different estimates (e.g. using planning poker or similar) is.
One technique suggested by the article is something I’ve tried in “future-spectives.” You say to the team, or individual, “Imagine we are at the end of the project, we have finished on time, in budget, everyone is very happy, what did we do right?” and the opposite: “Another failed project, what did we do wrong?” Imagining yourself in that situation can produce useful insights.
Sunday, March 07, 2010
The Scrum Hegemony & the Kanban Insurrection
One of the ideas I talked about in my Jax London presentation is something I call the Scrum hegemony and it deserves a few notes.
In the early days of Agile there was a tendency to equate Agile with XP, that changed a few years ago and Agile become (almost) synonymous with Scrum. I’m not saying Agile was XP or Agile is Scrum, just that to the uninitiated it can seem that way. (I blogged about this nearly 2 years ago now, see “Scrum is the new XP”.)
In many ways the Scrum people did a fantastic job of making Agile acceptable to the corporation. They had data and Harvard Business Review articles to cite, they didn’t ask the corporation to get into technical details (like TDD) and they had a friendly (English) name which avoided the word EXTREME! And most of all they had Certifications. O, don’t forget a pretty good marketing machine.
All this had the effect of making Agile acceptable to suited corporate types who didn’t know the first thing about software development but knew projects were always late. Ironically Scrum isn’t much more than XP, indeed, it is less than XP.
Consider XP: you can basically divide it in two. The bits about engineering (continuos integration, test driven development, refactoring, etc.) and the bits about managing the work (iterations, stand-ups, stories, etc.). Scrum, as documented concerns itself with the management side.
Granted Scrum expands on roles, Scrum adds some concepts like self-organising teams, adds some terms like backlogs and renames others (iterations to sprints) and adds burn-down charts but the management side of XP is basically Scrum, and Scrum is XP.
Purists might like to argue about which stole from which but the point remains: they are the same.
Scrum is devoid of the engineering practices, but as I’ve noted before in this blog: Scrum without the engineering practices is heading for trouble.
XP’s success, and the even bigger success of Scrum had the unfortunate side effect killing off most of the other Agile methods: FDD, ASD, Crystal, etc. Pockets still exists (especially with DSDM) but that is all they are, pockets. That was good for understanding but bad for experimentation and learning.
That’s now changing. The Scrum hegemony is now ending. Kanban, and perhaps other methods, are now offering alternatives. David Anderson’s Kanban insurrection is again offering an alternative. Kanban is again allowing the experimentation and variation in process that the Scrum hegemony has been stifling.
Don’t get me wrong, I don’t think for one moment Scrum is going to roll over and disappear, or that Kanban will dominate. Scrum will continue to be the Agile method of choice for corporations, it will be the 800 pound gorilla to use a phrase. But it will no longer be the only show in town.
Kanban is on the rise and drawing more attention to Lean, Software Craftmanship is on the rise and Tom Gilb’s work is being re-examined. There has long been a divide in Scrum between those who believe in “one and only one Scrum” and those who see “Scrum A, B and C” (I was going to post a link here to Jeff Sutherland’s blog but it appears he’s removed the post). Now there is a schism in Scrum: there are two bodies awarding Scrum certification, Scrum Alliance who’ve been around for a while and a Scrum.org backed by Microsoft and Ken Schwaber.
One of the good things about Scrum was that it was clear about what it was and was not - unlike Agile. This increasingly looks in doubt. As Scrum has grown more popular variations have set in, differences in certification and types of Scrum only add to those differences. The danger for Scrum is that it goes the way of the word Agile and becomes all things to all men.
That risk is echoed in the wider Agile family now. I welcome the rise of Kanban, not just because I think its a good system but because I think it is offering opportunities to think again about how we do things. But the end of the Scrum hegemony could leave the Agile as a whole fractured and incoherent, and decidedly not the type of thing corporations should be involved with.
Worst of all, it could see a new methodology war. There would be no winners here, only looses. Scrum and Kanban, and all the other methods, shouldn’t be rivals just alternatives. Unfortunately between the method zealots and in the commercial market I fear that message will be lost.
In the early days of Agile there was a tendency to equate Agile with XP, that changed a few years ago and Agile become (almost) synonymous with Scrum. I’m not saying Agile was XP or Agile is Scrum, just that to the uninitiated it can seem that way. (I blogged about this nearly 2 years ago now, see “Scrum is the new XP”.)
In many ways the Scrum people did a fantastic job of making Agile acceptable to the corporation. They had data and Harvard Business Review articles to cite, they didn’t ask the corporation to get into technical details (like TDD) and they had a friendly (English) name which avoided the word EXTREME! And most of all they had Certifications. O, don’t forget a pretty good marketing machine.
All this had the effect of making Agile acceptable to suited corporate types who didn’t know the first thing about software development but knew projects were always late. Ironically Scrum isn’t much more than XP, indeed, it is less than XP.
Consider XP: you can basically divide it in two. The bits about engineering (continuos integration, test driven development, refactoring, etc.) and the bits about managing the work (iterations, stand-ups, stories, etc.). Scrum, as documented concerns itself with the management side.
Granted Scrum expands on roles, Scrum adds some concepts like self-organising teams, adds some terms like backlogs and renames others (iterations to sprints) and adds burn-down charts but the management side of XP is basically Scrum, and Scrum is XP.
Purists might like to argue about which stole from which but the point remains: they are the same.
Scrum is devoid of the engineering practices, but as I’ve noted before in this blog: Scrum without the engineering practices is heading for trouble.
XP’s success, and the even bigger success of Scrum had the unfortunate side effect killing off most of the other Agile methods: FDD, ASD, Crystal, etc. Pockets still exists (especially with DSDM) but that is all they are, pockets. That was good for understanding but bad for experimentation and learning.
That’s now changing. The Scrum hegemony is now ending. Kanban, and perhaps other methods, are now offering alternatives. David Anderson’s Kanban insurrection is again offering an alternative. Kanban is again allowing the experimentation and variation in process that the Scrum hegemony has been stifling.
Don’t get me wrong, I don’t think for one moment Scrum is going to roll over and disappear, or that Kanban will dominate. Scrum will continue to be the Agile method of choice for corporations, it will be the 800 pound gorilla to use a phrase. But it will no longer be the only show in town.
Kanban is on the rise and drawing more attention to Lean, Software Craftmanship is on the rise and Tom Gilb’s work is being re-examined. There has long been a divide in Scrum between those who believe in “one and only one Scrum” and those who see “Scrum A, B and C” (I was going to post a link here to Jeff Sutherland’s blog but it appears he’s removed the post). Now there is a schism in Scrum: there are two bodies awarding Scrum certification, Scrum Alliance who’ve been around for a while and a Scrum.org backed by Microsoft and Ken Schwaber.
One of the good things about Scrum was that it was clear about what it was and was not - unlike Agile. This increasingly looks in doubt. As Scrum has grown more popular variations have set in, differences in certification and types of Scrum only add to those differences. The danger for Scrum is that it goes the way of the word Agile and becomes all things to all men.
That risk is echoed in the wider Agile family now. I welcome the rise of Kanban, not just because I think its a good system but because I think it is offering opportunities to think again about how we do things. But the end of the Scrum hegemony could leave the Agile as a whole fractured and incoherent, and decidedly not the type of thing corporations should be involved with.
Worst of all, it could see a new methodology war. There would be no winners here, only looses. Scrum and Kanban, and all the other methods, shouldn’t be rivals just alternatives. Unfortunately between the method zealots and in the commercial market I fear that message will be lost.
Tuesday, March 02, 2010
Jax slides
The slides from my Future of Agile presentation to this weeks Jax conference in London are now online. Although this talk started as a revision of last year’s Future of Agile (at ACCU and BCS Bristol) it ended up as a rewrite. The essential message is largely the same (key message: The future is lean) it brings out some new themes (e.g. software craftsmanship).
Later this month I’m presenting longer version of this talk to the BCS PROMS-G group in London as part of their Agile spring school, itself a repeat of the Bristol BCS Spring School last year. The longer version will include more on how to go about changing from where you are today to where you want to be.
Later this month I’m presenting longer version of this talk to the BCS PROMS-G group in London as part of their Agile spring school, itself a repeat of the Bristol BCS Spring School last year. The longer version will include more on how to go about changing from where you are today to where you want to be.
Monday, March 01, 2010
Last words on architects
Time to bring this mini series to an end. I’ve talked about
As a quick rule of thumb consider:
As a quick rule of thumb consider:
- The Product Owner (Produce Manager/BA): is concerned with the What
- The Project Manager: is concerned with the When
- The (your type of) Architect: is concerned with the How
- When you have a software system to design or fix, look to an architecture team not an individual. The team can share the vision in creating and exploitation.
- Never, ever, give someone the title Architect: give them the role yes, but never the title. Once you give them the title it is difficult to remove. And since you don’t know how their ego will respond you risk creating an problem. Architect is a role, not a title. Give people architect responsibilities but make sure they are still defined as a Software Engineer or whatever term you use were you work.
- The moment an “Architect” asks for an expensive tool to draw UML in then its time to let them go. UML can have a role but it isn’t worth spending money on. Expensive tools allow people to hide, architects shouldn’t hide. A cheap tool might be acceptable but don’t let them hide behind it.