My presentations from ACCU 2009 are now online
• Keynote: 9 Principles for Successful Software Management
• The Future of Agile
These and others (including the longer version of The Future of Agile from Bristol BCS) are available on the presentations page.
Tuesday, April 28, 2009
Monday, April 27, 2009
ACCU conference: More links
As if I haven’t written enough...
Slides for the sessions are to be found at
http://accu.org/index.php/conferences/accu_conference_2009/accu2009_schedule
and
http://accu.org/index.php/conferences/accu_conference_2009/accu2009_sessions
Not all the slides are there yet, they will appear gradually. In the meantime, check out:
• Twitter: #accu_conf tag
• Bob Martin’s blog
• Olve Maudal’s blog
• Phil Nash’s blog
• Pete Goodliffe’s blog
If you have a blog about the conference please add it in the comments.
Slides for the sessions are to be found at
http://accu.org/index.php/conferences/accu_conference_2009/accu2009_schedule
and
http://accu.org/index.php/conferences/accu_conference_2009/accu2009_sessions
Not all the slides are there yet, they will appear gradually. In the meantime, check out:
• Twitter: #accu_conf tag
• Bob Martin’s blog
• Olve Maudal’s blog
• Phil Nash’s blog
• Pete Goodliffe’s blog
If you have a blog about the conference please add it in the comments.
ACCU confernece: The Future of C++
As you might expect from the ACCU conference there was plenty of C++. But the language was far from the only one in town - there were at least 8 others. This year most of the C++ sessions looked at the forthcoming C++ 200x standard. It now looks unlikely that this will be completed this year so we might want to rename is C++ 201x. As to exactly when, well, your guess is better than mind.
Some years ago I said that this standard would be “the longest suicide note in history.” I stand by this comment - indeed I found other people repeating it, either to agree or disagree.
I say this because I believe the language is now so big to be un-teachable, and possibly unusable. I don’t see how making the language so much more complicated will encourage more people to use it, indeed I see the reverse. And I believe this standard will only add to the confusion around C++.
I’ve also been saying for the last few years that we have seen the last generation of C++ programmers. A recent meeting made me rethink this position - a recent graduate who has to learn C++ for his first job. But then, at the conference and without promoting from me, Andrew Holmes said he didn’t think anyone would learn C++ after 2006 so maybe I’m not completely wrong.
Anyway, learning the new C++ will only be an academic exercise for the next decade. It will be a while before any compiler implements it and much longer before a substantial code base exists to work in.
I believe things need to be removed from language to simplify it. So I have also been suggesting for a while - to anyone who will listen - that C++ should split in two. There should be one backward compatible version with minor fixes and enhancements. A second version should break backward compatibility, remove features, fix elements of syntax and make it easier to learn.
After speaking to several people at the conference I believe this has now happening. Not officially but by defacto.
Walter Bright’s D Programming Language is gaining traction. This is the simpler C++ which I - and others - have been looking for. Unfortunately I didn’t get to talk to Walter at the conference, I hope he will return next year with more D and I will get the chance to speak to him. (Walter, if your reading this, can you please present D in 180 minutes?)
Its not a forgone conclusion yet but I hope D will succeed. Actually, I think Oracle’s purchase of Sun could help here. Oracle are quite clear why they are buying Sun: to get Java. This means things will change in the Java world - if only because Oracle want to make money out of Java.
Its too early to tell yet how this will plat out but I expect to see many people rethinking their languages choices as Oracle’s plan plays out.
Some years ago I said that this standard would be “the longest suicide note in history.” I stand by this comment - indeed I found other people repeating it, either to agree or disagree.
I say this because I believe the language is now so big to be un-teachable, and possibly unusable. I don’t see how making the language so much more complicated will encourage more people to use it, indeed I see the reverse. And I believe this standard will only add to the confusion around C++.
I’ve also been saying for the last few years that we have seen the last generation of C++ programmers. A recent meeting made me rethink this position - a recent graduate who has to learn C++ for his first job. But then, at the conference and without promoting from me, Andrew Holmes said he didn’t think anyone would learn C++ after 2006 so maybe I’m not completely wrong.
Anyway, learning the new C++ will only be an academic exercise for the next decade. It will be a while before any compiler implements it and much longer before a substantial code base exists to work in.
I believe things need to be removed from language to simplify it. So I have also been suggesting for a while - to anyone who will listen - that C++ should split in two. There should be one backward compatible version with minor fixes and enhancements. A second version should break backward compatibility, remove features, fix elements of syntax and make it easier to learn.
After speaking to several people at the conference I believe this has now happening. Not officially but by defacto.
Walter Bright’s D Programming Language is gaining traction. This is the simpler C++ which I - and others - have been looking for. Unfortunately I didn’t get to talk to Walter at the conference, I hope he will return next year with more D and I will get the chance to speak to him. (Walter, if your reading this, can you please present D in 180 minutes?)
Its not a forgone conclusion yet but I hope D will succeed. Actually, I think Oracle’s purchase of Sun could help here. Oracle are quite clear why they are buying Sun: to get Java. This means things will change in the Java world - if only because Oracle want to make money out of Java.
Its too early to tell yet how this will plat out but I expect to see many people rethinking their languages choices as Oracle’s plan plays out.
ACCU conference: attendence
Attendance was high. People came from as far away as California and Tokyo. Since the move from the Randolph to the Barcelo hotel the conference has been able to cope with 350 attendees. The last couple of years it has been sold out, this year it fell short by about 5. I believe 15 or more bookings happened in the last week.
Given that other conferences are reporting falls of 30% or 40%, and some are cancelling altogether that is remarkable. The success I believe is down to two reasons.
First the obvious: the conference had an extremely strong programme.
Second: community.
The ACCU conference is not just the best software development conference in the UK - possibly in Europe and indeed the world - but it is also the high point of the ACCU year. The ACCU has close to 1,000 members thoughout the world, it publishes 12 journals a year, runs several active mailing lists and holds numerous local events in the UK and USA.
For many members the conference is a chance to meet people face-to-face who they only meet electronically otherwise.
Given that other conferences are reporting falls of 30% or 40%, and some are cancelling altogether that is remarkable. The success I believe is down to two reasons.
First the obvious: the conference had an extremely strong programme.
Second: community.
The ACCU conference is not just the best software development conference in the UK - possibly in Europe and indeed the world - but it is also the high point of the ACCU year. The ACCU has close to 1,000 members thoughout the world, it publishes 12 journals a year, runs several active mailing lists and holds numerous local events in the UK and USA.
For many members the conference is a chance to meet people face-to-face who they only meet electronically otherwise.
ACCU conference 4 of many (Saturday)
Not a lot to report on Saturday really. I did the keynote - finally called 9 Principles of Successful Software Management - and then delivered my own regular session - The Future of Agile. (I’ll post the presentation soon.)
Lunch, ACCU AGM, goodbye’s and home.
And so I’m not sitting on the train writing up these notes. (OK I was when I wrote these, a little editing since I got home.)
I’m no longer on the conference organising committee but I know the people who are and from what I understand the conference will most likely start on 14 April. I hope the conference will return to the Barcelo Hotel in Oxford, although its outside the centre it is a good venue.
Lunch, ACCU AGM, goodbye’s and home.
And so I’m not sitting on the train writing up these notes. (OK I was when I wrote these, a little editing since I got home.)
I’m no longer on the conference organising committee but I know the people who are and from what I understand the conference will most likely start on 14 April. I hope the conference will return to the Barcelo Hotel in Oxford, although its outside the centre it is a good venue.
Sunday, April 26, 2009
ACCU conference 3 of many (Friday)
Friday opened with something completely different for an ACCU conference: Neuroscience and women. Baroness Greenfield spoke on the subject of women in science and technology. Much of her talk was given over to exampling the neurological differences between men and women and why they don’t matter. Great stuff - enough to persuade me to buy her book(s).
After that I started to slack off a bit, miss sessions and arrive late. The effects of two late nights and lots of beer. Plus a need to talk more to people outside the sessions.
Several activities this year were designed to support Bletchley Park]. A donation scheme, a raffle, challenge puzzle and a sponsored bike ride (thereby hangs a long story.) In keeping with this theme Simon Greenish from the Bletchley Park Trust and Dr Sue Black from Westminster University gave a talk at lunch time.
The history of Bletchley Park is increasingly well known. Simon and Sue focused on the future, how they trust wanted to improve the park and the difficulties that stood in the way. The key point was that the trust is now in a race against time, the buildings are decaying and need repair if they are to be preserved at all. There are still enough Blethchley Park war veterans alive to make historical projects based on the park worthwhile. Before long much of our history will be lost if we do not act now.
Certainly it was enough to persuade me to make a donation to the Park, and hopefully I’ll go and see it this summer. And....
IF YOU ARE READING THIS BLOG PLEASE SIGN THE PETITION TO SAVE BLETCHLEY PARK NOW http://petitions.number10.gov.uk/BletchleyPark/
Friday’s sessions ended with the Pattern Buffet. Anouther innovation, this time from Kevlin Henney and myself. With help from Linda Rising, Michael Feathers, Peter Sommerland, Jim Siddle and Klaus Marquardt we presented 7 patterns in 90 minutes. Each speaker had 10 minutes to tell the audience about a pattern of their choice.
Friday closed with the traditional speaker banquet dinner. As usual this saw conference attendees swapping tables between each cause. After dinner there was the now traditional ACCU Boat Race.
After that I started to slack off a bit, miss sessions and arrive late. The effects of two late nights and lots of beer. Plus a need to talk more to people outside the sessions.
Several activities this year were designed to support Bletchley Park]. A donation scheme, a raffle, challenge puzzle and a sponsored bike ride (thereby hangs a long story.) In keeping with this theme Simon Greenish from the Bletchley Park Trust and Dr Sue Black from Westminster University gave a talk at lunch time.
The history of Bletchley Park is increasingly well known. Simon and Sue focused on the future, how they trust wanted to improve the park and the difficulties that stood in the way. The key point was that the trust is now in a race against time, the buildings are decaying and need repair if they are to be preserved at all. There are still enough Blethchley Park war veterans alive to make historical projects based on the park worthwhile. Before long much of our history will be lost if we do not act now.
Certainly it was enough to persuade me to make a donation to the Park, and hopefully I’ll go and see it this summer. And....
IF YOU ARE READING THIS BLOG PLEASE SIGN THE PETITION TO SAVE BLETCHLEY PARK NOW http://petitions.number10.gov.uk/BletchleyPark/
Friday’s sessions ended with the Pattern Buffet. Anouther innovation, this time from Kevlin Henney and myself. With help from Linda Rising, Michael Feathers, Peter Sommerland, Jim Siddle and Klaus Marquardt we presented 7 patterns in 90 minutes. Each speaker had 10 minutes to tell the audience about a pattern of their choice.
Friday closed with the traditional speaker banquet dinner. As usual this saw conference attendees swapping tables between each cause. After dinner there was the now traditional ACCU Boat Race.
ACCU conference 2 of many (Thursday)
Thursday kicked off with a keynote from Linda Rising in which she described her personal journey of discover of, and with Patterns. I’m lucky enough to count Linda as a friend, and I already knew much of the patterns story she told. Still, I had fresh insights and understanding.
For many of those in the room Linda’s ideas and thoughts were completely new. She finished by presenting us with something of a challenge - albeit on originally thrown down by Christopher Alexander - What are you doing to make a better world?
Next I went along to Phil Nash’s talk on Objective-C. He tried to teach Objective-C in 90 minutes. He almost managed it too! I don’t really code anymore but I enjoyed this insight into another language and how Mac’s and iPhones are programmed.
Mark Delgarno of Software Acumen and Helen Sharp of the Open University workshop on “What motivates software developers?” provided plenty of food for thought.
Helen reported on her research which can be summarised as: “Nobody knows” - basically there are many studies, but none of them actually bothered to define what is a “software developer” so they covered project managers, coders, testers, and possibly many other people who are involved one way or another with creating software but have very different approaches, skills and motivation.
For me Thursday’s sessons finished as they had begun with Linda. The good news from this session is that we, as human beings, are hard wired to be optimistic. The bad news is that consequently that means we cannot estimate work and even when presented with evidence we make the same mistakes. I’ve mentioned our confirmation bias before in this blog, this presentation was a though examination of the issue.
A new innovation at ACCU conference this year was the introduction of lightening talks. After the main sessions on Thursday and Friday an hour was given over to short (5 minute), talks and presentation from various people. The speakers and subjects were only agree on the day and several of the talks were only written in the hours before.
I got several nuggets of information from these talks. Two in particular stick on my mind: the Google Web Toolkit as an alternative to Selenium (Paul Grenyer); and the advantages of giving specifications by example rather than by rule (Keith Braithwaite),
For many of those in the room Linda’s ideas and thoughts were completely new. She finished by presenting us with something of a challenge - albeit on originally thrown down by Christopher Alexander - What are you doing to make a better world?
Next I went along to Phil Nash’s talk on Objective-C. He tried to teach Objective-C in 90 minutes. He almost managed it too! I don’t really code anymore but I enjoyed this insight into another language and how Mac’s and iPhones are programmed.
Mark Delgarno of Software Acumen and Helen Sharp of the Open University workshop on “What motivates software developers?” provided plenty of food for thought.
Helen reported on her research which can be summarised as: “Nobody knows” - basically there are many studies, but none of them actually bothered to define what is a “software developer” so they covered project managers, coders, testers, and possibly many other people who are involved one way or another with creating software but have very different approaches, skills and motivation.
For me Thursday’s sessons finished as they had begun with Linda. The good news from this session is that we, as human beings, are hard wired to be optimistic. The bad news is that consequently that means we cannot estimate work and even when presented with evidence we make the same mistakes. I’ve mentioned our confirmation bias before in this blog, this presentation was a though examination of the issue.
A new innovation at ACCU conference this year was the introduction of lightening talks. After the main sessions on Thursday and Friday an hour was given over to short (5 minute), talks and presentation from various people. The speakers and subjects were only agree on the day and several of the talks were only written in the hours before.
I got several nuggets of information from these talks. Two in particular stick on my mind: the Google Web Toolkit as an alternative to Selenium (Paul Grenyer); and the advantages of giving specifications by example rather than by rule (Keith Braithwaite),
ACCU conference 1 of many (Wednesday)
Another year, another great ACCU conference. I counted 9 languages on the conference program, everything from Scala to C++ - yes there was more C++ that anything else but it was far from the only thing going on. Languages plus sessions on design, pattern, management, Agile and neuroscience.
Normally some of the most insightful comments come not in the scheduled sessions but in the discussions over coffee and in the bar afterwards. Sometimes you don’t know these are insightful until after the event when you’ve left and had time to think it all through.
This will always be a special ACCU conference for me because I was the keynote speaker on Saturday. My keynote was well received and the slides ....
So here is a brain dump.
The opening keynote on Wednesday was from Bob Martin - “Uncle Bob” - about software craftsmanship. (I’m watching the software craftsmanship movement with interest and will write a blog about it in future.) Bob suggested that the most successful Agile method - Scrum - was the accidental “winner” of the Snowbird summit in 2001. This was because the Agile manifesto and Agile values said nothing about technical practices.
Scrum, as is well know, does not contain any technical practices. Teams often borrow these from XP. Because of this Bob believes Scrum is a subset of XP - a subset which just deals with project management. Without the technical practices productivity falls off and teams make a “big mess faster.”
Bob’s answer is a renewed emphasis on technical practices - hence software craftsmanship.
Bob is a great showman and his talk was very entraining, if you get the chance to see him do so. Along the way made several Scrum jokes and was quite critical of Scrum Master Certification.
Someone like Bob can do this, Bob has the reputation and standing to be able to take pot shots from a safe(ish) position. This is good because someone needs act as a foil.
Jutta Eckstein’s session on transparency in Agile was interesting. It reminded me of the session I ran here a few years ago called “Exposing problems / Creating awareness.” The these was similar: “Agile as a problem detector.” The session was largely a discussion between Jutta and the various people in the room.
Keith Braithwaite presented the latest instalment of his “Measuring the effects of TDD” research project. I’ve seen Keith talk about this subject before and over time his presentation is getting more and more compelling. His sample size in increasing and its looking like a more convincing case.
If you don’t know the work have a look at Keith’s blog. To summarise it: you can measure code complexity using a measure called cyclomatic complexity. Keith’s research shows there is a correlation between complexity and automated until tests. Namely: code with a high level of automated unit tests exhibits lower complexity metrics and people comment they are “happier” with the code.
Having discovered the metric Keith is still trying to understand the cause-and-effect relationship and, perhaps, more importantly, uncover how this relationship can be used to improve matters.
Nicolai Josuttis finished the day with a second keynote. You could call it the antidote to software craftsmanship: Crappy code.
Although Nico made it jovially it had a serious point: there is a lot of bad code out there and it is likely to be around for a while to come. The economics of software development and business tend to perpetuate this situation. Therefore, we need to get used to crappy code and find ways of dealing with it.
While I agree with Nico I can’t help feeling it was a little defeatist. If we accept this poor state of affairs do we still have hope of a better tomorrow?
Between them Bob and Nico certainly set a debate raging - Good code, or Crappy code?
Wednesday finished with 40 of us in Chutney’s curry house.
Normally some of the most insightful comments come not in the scheduled sessions but in the discussions over coffee and in the bar afterwards. Sometimes you don’t know these are insightful until after the event when you’ve left and had time to think it all through.
This will always be a special ACCU conference for me because I was the keynote speaker on Saturday. My keynote was well received and the slides ....
So here is a brain dump.
The opening keynote on Wednesday was from Bob Martin - “Uncle Bob” - about software craftsmanship. (I’m watching the software craftsmanship movement with interest and will write a blog about it in future.) Bob suggested that the most successful Agile method - Scrum - was the accidental “winner” of the Snowbird summit in 2001. This was because the Agile manifesto and Agile values said nothing about technical practices.
Scrum, as is well know, does not contain any technical practices. Teams often borrow these from XP. Because of this Bob believes Scrum is a subset of XP - a subset which just deals with project management. Without the technical practices productivity falls off and teams make a “big mess faster.”
Bob’s answer is a renewed emphasis on technical practices - hence software craftsmanship.
Bob is a great showman and his talk was very entraining, if you get the chance to see him do so. Along the way made several Scrum jokes and was quite critical of Scrum Master Certification.
Someone like Bob can do this, Bob has the reputation and standing to be able to take pot shots from a safe(ish) position. This is good because someone needs act as a foil.
Jutta Eckstein’s session on transparency in Agile was interesting. It reminded me of the session I ran here a few years ago called “Exposing problems / Creating awareness.” The these was similar: “Agile as a problem detector.” The session was largely a discussion between Jutta and the various people in the room.
Keith Braithwaite presented the latest instalment of his “Measuring the effects of TDD” research project. I’ve seen Keith talk about this subject before and over time his presentation is getting more and more compelling. His sample size in increasing and its looking like a more convincing case.
If you don’t know the work have a look at Keith’s blog. To summarise it: you can measure code complexity using a measure called cyclomatic complexity. Keith’s research shows there is a correlation between complexity and automated until tests. Namely: code with a high level of automated unit tests exhibits lower complexity metrics and people comment they are “happier” with the code.
Having discovered the metric Keith is still trying to understand the cause-and-effect relationship and, perhaps, more importantly, uncover how this relationship can be used to improve matters.
Nicolai Josuttis finished the day with a second keynote. You could call it the antidote to software craftsmanship: Crappy code.
Although Nico made it jovially it had a serious point: there is a lot of bad code out there and it is likely to be around for a while to come. The economics of software development and business tend to perpetuate this situation. Therefore, we need to get used to crappy code and find ways of dealing with it.
While I agree with Nico I can’t help feeling it was a little defeatist. If we accept this poor state of affairs do we still have hope of a better tomorrow?
Between them Bob and Nico certainly set a debate raging - Good code, or Crappy code?
Wednesday finished with 40 of us in Chutney’s curry house.
Monday, April 20, 2009
Impediments - hidden or otherwise
A comment to my post on “Three ways to run a stand-up meeting” asked: “Can you give an example of the ‘hidden’ impediments?” so here goes.
First: know the difference between a block and an impediment. A block stops all work, they are seldom hidden because people can’t get on with what they are doing. A impediment is something which gets in the way, slows you down, saps your morale.
Fortunately, or maybe unfortunately, software people are very good at routing around blocks. They find ways to “get stuff done” even if it is not the best way, the fastest way, or the “right way”. So blocks often become impediments. Unless we strive to impediments our teams will not perform to their maximum.
One nasty form of impediment is the “I’m blocked so I’ll make work to look busy.” The work which is created is seldom as valuable as that you are blocked from doing and even worthless.
Anyway, examples of impediments, especially hidden one:
• Vendor is not responsive: someone is waiting on a vendor to deliver something and it isn’t happening; or you are waiting on a vendors technical support, or perhaps you need information from the vendor before deciding whether to use their product or someone elses.
• Build problems: the build is broken, or you need someone else to fix their bit, or you are waiting for access rights, or the compiler seems to have a bug, or ... the list goes on
• Waiting on another team: particularly test, source control, user interface, tech support, etc. Idealy we want each team to be vertical, that its, to be self sufficience, to contain the skills and authority to get a job done without needing action from others. But this doesn’t happen as much as it should so you need another team to do something. At this point problems occur because the other team doesn’t have the same prioirities as your team
• Upgrading compiler, OS, app server, etc: some piece of software (or perhaps hardware) needs to be upgraded. So instead of getting on with the task in hand someone is diverted to upgrade the system. And when this takes long than expected, or hits problems, then it becomes an impedimant and even a block.
• Bug - typically in a library: you can’t get on with your own work because of someone elses bug. Ideally you can just jump into their code and fix it but.... if the bug is in a third party library then it not quite so easy. And if the problem is with the compiler, or a vendor you get to one of the problems above.
• Database changes: databases teams seem to work in a completely different temporal dimension . Too often I meet teams who can’t progress because a DB schema change is needed, or the meta-data is a problem, or .... The real solution is two fold: simplify designed and reduce the need for complex databases, and ensure the team has database skills itself.
• Waiting on a management decision: all too common, management can’t make their minds up whether to do it like X or like Y. A particularly nasty version is when you’ve asked for something “Can we buy Z?” and rather than say “No” you are kept hanging on. If they just said “No because...” you could address the reason or find another way of doing it.
When team members can’t report real achievements in a Scrum meetings they usually report ”what they have done“ which includes ”why there isn’t an achievement“. Thats the point at which these kind of impediments are mentioned. A good Scrum Master / Meeting Leader / Agile Coach will spot these issues and move them to impediments.
If you have any more examples of impediments please add them as comments below.
First: know the difference between a block and an impediment. A block stops all work, they are seldom hidden because people can’t get on with what they are doing. A impediment is something which gets in the way, slows you down, saps your morale.
Fortunately, or maybe unfortunately, software people are very good at routing around blocks. They find ways to “get stuff done” even if it is not the best way, the fastest way, or the “right way”. So blocks often become impediments. Unless we strive to impediments our teams will not perform to their maximum.
One nasty form of impediment is the “I’m blocked so I’ll make work to look busy.” The work which is created is seldom as valuable as that you are blocked from doing and even worthless.
Anyway, examples of impediments, especially hidden one:
• Vendor is not responsive: someone is waiting on a vendor to deliver something and it isn’t happening; or you are waiting on a vendors technical support, or perhaps you need information from the vendor before deciding whether to use their product or someone elses.
• Build problems: the build is broken, or you need someone else to fix their bit, or you are waiting for access rights, or the compiler seems to have a bug, or ... the list goes on
• Waiting on another team: particularly test, source control, user interface, tech support, etc. Idealy we want each team to be vertical, that its, to be self sufficience, to contain the skills and authority to get a job done without needing action from others. But this doesn’t happen as much as it should so you need another team to do something. At this point problems occur because the other team doesn’t have the same prioirities as your team
• Upgrading compiler, OS, app server, etc: some piece of software (or perhaps hardware) needs to be upgraded. So instead of getting on with the task in hand someone is diverted to upgrade the system. And when this takes long than expected, or hits problems, then it becomes an impedimant and even a block.
• Bug - typically in a library: you can’t get on with your own work because of someone elses bug. Ideally you can just jump into their code and fix it but.... if the bug is in a third party library then it not quite so easy. And if the problem is with the compiler, or a vendor you get to one of the problems above.
• Database changes: databases teams seem to work in a completely different temporal dimension . Too often I meet teams who can’t progress because a DB schema change is needed, or the meta-data is a problem, or .... The real solution is two fold: simplify designed and reduce the need for complex databases, and ensure the team has database skills itself.
• Waiting on a management decision: all too common, management can’t make their minds up whether to do it like X or like Y. A particularly nasty version is when you’ve asked for something “Can we buy Z?” and rather than say “No” you are kept hanging on. If they just said “No because...” you could address the reason or find another way of doing it.
When team members can’t report real achievements in a Scrum meetings they usually report ”what they have done“ which includes ”why there isn’t an achievement“. Thats the point at which these kind of impediments are mentioned. A good Scrum Master / Meeting Leader / Agile Coach will spot these issues and move them to impediments.
If you have any more examples of impediments please add them as comments below.
Friday, April 17, 2009
Russian translations
Only a few weeks ago I was pleased Mark Nakamura translated some of my blog entries to Japanese. Now I’m being translated to Russian.
Ivan Doroshenko has translated Three ways to run a stand up meeting and Lean & Agile the same but different. Hopefully Ivan will be translating some more, so Russian speakers keep an eye on his blog.
Ivan Doroshenko has translated Three ways to run a stand up meeting and Lean & Agile the same but different. Hopefully Ivan will be translating some more, so Russian speakers keep an eye on his blog.
Wednesday, April 15, 2009
New writing and events: Downturn & Product Management
Its been a busy few weeks with presentations to BCS Bristol, BCS Kingston & Croydon, Hewlett-Packard and a trip to Switzerland to deliver some Scrum training and coaching - not to mention a family holiday.
The couple of weeks is also busy with some public events coming up:
• ACCU Conference: I’m delivering a keynote, a regular session and co-ordinating a set of pattern talks with Kevlin Henney. (This starts on Wednesday next week and I believe there are a few places remaining.)
• Brighton Agile Forum have invited me to speak on 11 May
• ACCU London is hosting Jeff Sutherland on 21 May
I’ve had some new articles published elsewhere recently:
• Agile in the Downturn is in this months Agile Journal
• ACCU Overload 90 April 2009 (whole journal download) continues my On Management series with a look at the Product Manager role (article download)
• A New Approach to Software Project Management in CEO Today: this is one of those virtual magazine formats so you have to flick through the pages. And for reasons I don’t entirely understand my company name (Software Strategy) and not my name has been used as the author. Can’t say I’m entirely happy the way this piece has worked out, its an experiment in reaching a different audience.
Actually, if anything I’ve been writing less recently but these three have been in the works for a while.
The couple of weeks is also busy with some public events coming up:
• ACCU Conference: I’m delivering a keynote, a regular session and co-ordinating a set of pattern talks with Kevlin Henney. (This starts on Wednesday next week and I believe there are a few places remaining.)
• Brighton Agile Forum have invited me to speak on 11 May
• ACCU London is hosting Jeff Sutherland on 21 May
I’ve had some new articles published elsewhere recently:
• Agile in the Downturn is in this months Agile Journal
• ACCU Overload 90 April 2009 (whole journal download) continues my On Management series with a look at the Product Manager role (article download)
• A New Approach to Software Project Management in CEO Today: this is one of those virtual magazine formats so you have to flick through the pages. And for reasons I don’t entirely understand my company name (Software Strategy) and not my name has been used as the author. Can’t say I’m entirely happy the way this piece has worked out, its an experiment in reaching a different audience.
Actually, if anything I’ve been writing less recently but these three have been in the works for a while.
Saturday, April 11, 2009
Three ways to run a stand up meeting
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.
• 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.
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.
Subscribe to:
Posts (Atom)