This is the second of two blog entries about the use of dialogue sheets. The first entry contain some simple statistics and findings from recent experiences and feedback from users. This entries discusses a few findings which deserve longer comment.
Those who use the sheets consistently report that they engage more team members (everyone gets to speak). Several people report that quieter team members are more likely to contribute in a dialogue retrospective than in a regular retrospective.
Another common finding is that energy levels are higher, there is more discussion and removing the facilitator changes the focus of the retrospective.
These are the results I hoped for when I created the sheets. Yet, to some degree I think these findings are simply the result of changing the format - doing something different. Perhaps a team that uses dialogue sheets for every retrospective will find that in time some of the energy is lost.
Right now I don’t know, I don’t have enough not enough data. However, I have always said these are one technique and I encourage you to use them as one for several retrospective approaches.
A few people report that they don’t like the idea of removing the facilitator. This dislike has stopped them from trying the dialogue sheet. While I understand this fear I hope they will try them all the same. After all, it is the nature of Agile to experiment.
My advice: try a dialogue retrospectives and see what happens, then decide if you want to try again.
One person did report that they felt that without a facilitator some issues were not explored as they might be. I fully understand this finding although it does cause me to ask: were some areas explored which might not have been explored? Again this could be a argument for having some facilitator-less retrospectives and some with.
There is a strange case reported from a company I will not name. Here the management vetoed facilitator-less retrospective. My correspondent doesn’t understand why and I am a little baffled. This gets curious when you know the name of the company concerned. Someone else from the same company replied independently (different country) and has had success with the sheets. I’ve put them in touch and hope this will be resolved.
Interesting, a previous correspondent told me that they kept a facilitator even when using the retrospective dialogue sheet. This hybrid could address both management concerns and the fear of missing topics. I think there is more experimentation to be done here, perhaps using the dialogue sheet to start the retrospectives and then having a facilitator follow up. Or using a dialogue sheet retrospective to identify issues and in following retrospectives deal with them in detail.
Finally, two unexpected findings which carry lessons for those doing regular retrospectives.
All the retrospective sheets include Norm Kerth’s Prime Directive:
“Regardless of what we discover, we must understand and truly believe that everyone did the best job he or she could, given what was known at the time, his or her skills and abilities, the resources available, and the situation at hand.”
To retrospective facilitators this is a holy commandment, something we hold close to our hearts. Yet left alone it is interesting to see how groups react to it.
While one corespondent reported “Kerth's prime directive is also in our company's culture, therefore there is no need to remind people of it, it comes natural for us.” Another reported:
“One group poked fun at the "prime directive", but the other didn’t”.
My own experience is similar. Some teams - usually those who are familiar with the directive - just accept it. One team commented that although they knew it they tended to forget it and it was a good reminder. However, several teams have agonised about the directive, they stall at what should be a routine reminder. Sometimes it is obvious that team members implicitly do blame individuals for problems they face.
I think this behaviour says something about the company, the culture and the teams familiarity with conducting retrospectives. It is, perhaps, the one place where I would like a facilitator on hand. However intervening at such an early stage in the sheet would compromise the approach.
Perhaps the lesson here is that the dialogue sheets work best when teams have trust, and accept the Prime Directive. But then, isn’t that true for all retrospectives?
The other lesson is: while retrospective facilitators hold Kerth’s directive close to their heart the same isn’t true for many others.
The second unexpected finding came at a company in the North West of England. I visited and observed a retrospective using dialogue sheets. There were over a dozen people so we divided into two groups each with a retrospective dialogue sheet.
Unusually the two teams used different sheets - I think one had a T1 and one had a T3, so a similar format but slightly different questions. The first, finding here was that using different dialogue sheets not only does work but can help add insights.
The second, much more significant and unexpected finding was a result of who joined each group. I thought I had divided the groups randomly but as it happens the majority in one group were developers and the majority in the other group were Business Analysts.
At the end of the exercise one of the Business Analysts commented: In a normal retrospective the developers dominate (there are more of them) and so the retrospective usually talks about issues of concern to developers, the issues of concern to BAs are not usually discussed.
It sounds obvious once you see it: the largest group will tend to dominate a retrospective.
However, separate them out, as we did here, gives both groups an opportunity to talk about their concerns. Now the really interesting bit.
The two groups were retrospecting the same time period, however they approached it from different points of view. Some of their conclusions were different but some were the same. To my thinking, when different people, coming from different starting points come to the same conclusions, then those conclusions have added weight.
Overall then: Retrospective Dialogue Sheets are a success.
This blog is now at: https://www.allankelly.net/blog/ You should be redirected shortly. If you have any problems with it please let me know.
Monday, November 28, 2011
Retrospective Dialogue Sheets: feedback & updates 1 of 2
Every couple of months I e-mail everyone who has downloaded one or more of my Dialogue Sheets to get some feedback. Getting feedback is why I make people register to download a Dialogue Sheet - sorry, I know some people don’t like doing this, and I know some people fake their e-mail addresses but unless I do this I get very little feedback.
I’ve blogged about my Retrospective Dialogue Sheets before but I thought this would be a good opportunity to update readers with some feedback and findings. This is the first of two posts on this subject, the second post will examine a few findings in more depth.
First simple facts and comments:
I’ve also been asked if it is possible to customise the sheets. The short answer is No, because they are PDFs its kind of difficult - although I’m sure you could with the right tools. Still there is no reason why not to create your own - a few correspondents say they are thinking of this. (Anyone thinking of creating their own sheets might find this guide for teachers creating dialogue sheets useful.)
Finally for this entry, I’m also hoping to provide translations of the sheets shortly. I have offers of translations into Spanish, German and Finnish - plus I hope to persuade a friendly Russian to help. Main problem at the moment is getting the raw files out of OmniGraffle into Visio.
I’ve blogged about my Retrospective Dialogue Sheets before but I thought this would be a good opportunity to update readers with some feedback and findings. This is the first of two posts on this subject, the second post will examine a few findings in more depth.
First simple facts and comments:
- 40% of people who download Retrospective Dialogue Sheets do retrospectives rarely or at best every six months.
- Many who download them and reply to my requests for feedback say “Sorry we haven’t used them” and I guess that many of those who don’t reply haven’t used them either. Given that I expect those who are interested in retrospectives will download, and given that downloaders are measured in hundreds, not thousands, this indicates that actually doing retrospectives is rare.
- 46% of downloaders do them once a month or more frequently, while 15% of downloaders classify themselves as Retrospective Facilitators and perform any retrospectives.
- 25% of downloaders are in the USA, 9.5% in the UK, just ahead of Germany (9.09%). Otherwise only India (5.79%) tops 5%. Though Holland, Canada and France all score 4.5%. I don’t find this surprising given the spread of software development internationally and the spread of dialogue sheet publicity.
- A few people find the sheets too complicated, a few people find them too simple. I had hoped that a variety of sheets would address both ends of the spectrum: the lesson for me is to create some even simpler sheets.
- A couple of people have reported that they don’t feel their team is open enough to use the sheets. My guess is this will present difficulties for any type of retrospective.
- A few people say the sheets are too expensive to print: the print on demand services charges about $40 dollars, the expense is in the postage rather than the printing, if you order a lot the price per sheet is a lot lower. (I must find a European print on demand provider.). However 40% of people say that they have a suitable printer, this surprises me a bit, I never expected large printers were so common.
- To my surprise a couple of people have said there is not enough space to write on the sheets! I will create some new sheets with fewer questions and more space.
- A few replies say that the teams are now using the sheets regularly, and in some cases they have spread from Agile to non-Agile teams.
I’ve also been asked if it is possible to customise the sheets. The short answer is No, because they are PDFs its kind of difficult - although I’m sure you could with the right tools. Still there is no reason why not to create your own - a few correspondents say they are thinking of this. (Anyone thinking of creating their own sheets might find this guide for teachers creating dialogue sheets useful.)
Finally for this entry, I’m also hoping to provide translations of the sheets shortly. I have offers of translations into Spanish, German and Finnish - plus I hope to persuade a friendly Russian to help. Main problem at the moment is getting the raw files out of OmniGraffle into Visio.
Friday, November 18, 2011
You are not Steve Jobs (and don't try to be him)
Many people better than I have commented on the passing of Steve Jobs a few weeks ago, I too was sorry to see him go. He touched my life (indirectly): I’m writing this on a Mac, we have an iPad in the house, I might not like iPhones but my new Android phone clearly owes a lot to Jobs vision (i.e. it is a copy).
Reading, watching and listening to the many obituaries about Jobs I started to get worried. My concern is simply that Jobs was not a good role model. His phenomenal success guarantees that more than a few people will attempt to emulate him, in so doing they will sow the seeds of their own failure and make the lives of their employees miserable in doing so.
Here are a few examples.
Jobs was a perfectionist: products didn’t get launched unless he approved of them. However, being a perfectionist is something of a luxury, Apple existed, had revenue, had a brand. If you are a start-up perfection is just too expense.
Jobs started the MacIntosh project because he had Lisa taken from him: MacIntosh and Lisa could only exist because Apple had revenue from the Apple II line.
The first Macs were far from perfect; the team undoubtedly learned from Lisa - what we might call a pivot in Lean Start-Up terms but not quite that clean cut.
Jobs demanded the first Macs would work in 64k, the team knew it needed 128k and Jobs, late in the day gave in. Secretly the team engineered the Mac to accept 512k which is what it really needed.
The moral of the story: there is more to it than being a perfectionist. Even perfectionists need to compromise sometimes. Surrounding yourself with good people helps.
More recently the original iPhone was launched as a 2G GSM phone, without features like cut and paste. It seems incredible now. Apple launched an under-spec phone and refined it in the market. Which leads us to....
Jobs would spurn products/employees who he didn’t think were up to scratch: if employees are loyal to the company and to you, and if you have a deep talent pool, and (perhaps) the stock-options are worth a lot you might get away with this. Otherwise its a sure fire route to staff turn-over.
Jobs may have been a perfectionist but, it seems to me, he wasn’t a perfectionist about quantity of features, quite the opposite. Apple products are simple because they lack so much, once launched they are refined and elaborated in the market.
Jobs didn’t use customer understanding or focus groups to tell him what the public needed. He was a visionary who just knew. This is perhaps my greatest fear: to read some of the obituaries is to condemn the whole discipline of Product Management to the dustbin in favour of senior managers who know what is right for customers - a disease too many companies suffer from.
This argument doesn’t stand up. Jobs was an, perhaps unique, visionary who did understand what customers wanted. He had an ability to see what technology could do and how people could use it. Few of us are blessed with this ability. Thus we have the discipline of Product Management to help us.
Jobs may have shunned market and customer research but his Product teams didn’t. In some cases Apple conducted internal, closed, demonstrations of new products; they used their own staff for research. And, as I just said: Apple launched products and rapidly refined them in the market.
Apple also had many products which were not hits, with and without Jobs: Apple III, Lisa, Newton, Mac portable, Pippin, Apple TV, A/UX, Pink, MobileMe - the iPod took several years to break through and even the Mac came close to failure on several occasions - and iTunes is probably the worst piece of Mac software on the market.
OK, Jobs was not even at the company when several of these products launched but he sowed the seeds and above all it was his company, a culture he had created. And while he wasn’t at Apple he founded NeXT which wasn’t exactly a success either.
But look again: Apple and Jobs were prepared to try things. Some worked, some didn’t. Some took a long time to come to success. Some failed but somewhere, in Jobs head, deep in the bowls of Apple, lessons were learned for future products. We will never know just how much the Mac team learned from Lisa, or how much MacOS X learned from Pink, or even how much the iPad learned from Newton.
Apple and Jobs could do this because they had deep pockets, they had revenue.
Lets put this simply: as much as you might like to think you can emulate Steve Jobs you probably can’t. What worked for Jobs worked for him because he was unique in vision, timing and experience. Just because Jobs could ignore volumes of business advice, armies of experts and accepted wisdom doesn’t mean you can.
The lesson I would take from Jobs and Apple is not about perfectionism, design, arrogance, or the super-CEOs but about the willingness to try something simple, iterate and refine in the market.
Reading, watching and listening to the many obituaries about Jobs I started to get worried. My concern is simply that Jobs was not a good role model. His phenomenal success guarantees that more than a few people will attempt to emulate him, in so doing they will sow the seeds of their own failure and make the lives of their employees miserable in doing so.
Here are a few examples.
Jobs was a perfectionist: products didn’t get launched unless he approved of them. However, being a perfectionist is something of a luxury, Apple existed, had revenue, had a brand. If you are a start-up perfection is just too expense.
Jobs started the MacIntosh project because he had Lisa taken from him: MacIntosh and Lisa could only exist because Apple had revenue from the Apple II line.
The first Macs were far from perfect; the team undoubtedly learned from Lisa - what we might call a pivot in Lean Start-Up terms but not quite that clean cut.
Jobs demanded the first Macs would work in 64k, the team knew it needed 128k and Jobs, late in the day gave in. Secretly the team engineered the Mac to accept 512k which is what it really needed.
The moral of the story: there is more to it than being a perfectionist. Even perfectionists need to compromise sometimes. Surrounding yourself with good people helps.
More recently the original iPhone was launched as a 2G GSM phone, without features like cut and paste. It seems incredible now. Apple launched an under-spec phone and refined it in the market. Which leads us to....
Jobs would spurn products/employees who he didn’t think were up to scratch: if employees are loyal to the company and to you, and if you have a deep talent pool, and (perhaps) the stock-options are worth a lot you might get away with this. Otherwise its a sure fire route to staff turn-over.
Jobs may have been a perfectionist but, it seems to me, he wasn’t a perfectionist about quantity of features, quite the opposite. Apple products are simple because they lack so much, once launched they are refined and elaborated in the market.
Jobs didn’t use customer understanding or focus groups to tell him what the public needed. He was a visionary who just knew. This is perhaps my greatest fear: to read some of the obituaries is to condemn the whole discipline of Product Management to the dustbin in favour of senior managers who know what is right for customers - a disease too many companies suffer from.
This argument doesn’t stand up. Jobs was an, perhaps unique, visionary who did understand what customers wanted. He had an ability to see what technology could do and how people could use it. Few of us are blessed with this ability. Thus we have the discipline of Product Management to help us.
Jobs may have shunned market and customer research but his Product teams didn’t. In some cases Apple conducted internal, closed, demonstrations of new products; they used their own staff for research. And, as I just said: Apple launched products and rapidly refined them in the market.
Apple also had many products which were not hits, with and without Jobs: Apple III, Lisa, Newton, Mac portable, Pippin, Apple TV, A/UX, Pink, MobileMe - the iPod took several years to break through and even the Mac came close to failure on several occasions - and iTunes is probably the worst piece of Mac software on the market.
OK, Jobs was not even at the company when several of these products launched but he sowed the seeds and above all it was his company, a culture he had created. And while he wasn’t at Apple he founded NeXT which wasn’t exactly a success either.
But look again: Apple and Jobs were prepared to try things. Some worked, some didn’t. Some took a long time to come to success. Some failed but somewhere, in Jobs head, deep in the bowls of Apple, lessons were learned for future products. We will never know just how much the Mac team learned from Lisa, or how much MacOS X learned from Pink, or even how much the iPad learned from Newton.
Apple and Jobs could do this because they had deep pockets, they had revenue.
Lets put this simply: as much as you might like to think you can emulate Steve Jobs you probably can’t. What worked for Jobs worked for him because he was unique in vision, timing and experience. Just because Jobs could ignore volumes of business advice, armies of experts and accepted wisdom doesn’t mean you can.
The lesson I would take from Jobs and Apple is not about perfectionism, design, arrogance, or the super-CEOs but about the willingness to try something simple, iterate and refine in the market.
Sunday, November 13, 2011
Me @ Agile on the Beach
Many of the sessions at Agile on the Beach were recorded and are now available online.
You can find my “Objective Agility” presentation here.
I have a bit part in the The Agile Cornwall case study which is also online. Actually, this video, or rather these videos, are the best version of the Agile Cornwall case study. Although myself and Mike Barritt have given versions of this presentation elsewhere (and probably will do again in time) this version is the best for two reasons.
First, these videos include people on the receiving end of the programme - Research Instruments and Sullivan Cuff Software. They tell about their experiences moving to Agile and the results they have achieved. Second, this version of the case study goes into more depth of about the nature of the programme and how it worked.
Personally I’ve come to see three audiences for the Agile Cornwall case study: anyone who wants to adopt Agile, those who want to know the lessons of our Cornish Agile Laboratory (the Cornish Software Mines), and third, Government agencies who want to see how Government support can help companies adopt Agile.
Finally, I was also part of the panel discussion which is online too - this include Mary and Tom Poppendieck, Toby Parkins and Jason Gorman.
You can find my “Objective Agility” presentation here.
I have a bit part in the The Agile Cornwall case study which is also online. Actually, this video, or rather these videos, are the best version of the Agile Cornwall case study. Although myself and Mike Barritt have given versions of this presentation elsewhere (and probably will do again in time) this version is the best for two reasons.
First, these videos include people on the receiving end of the programme - Research Instruments and Sullivan Cuff Software. They tell about their experiences moving to Agile and the results they have achieved. Second, this version of the case study goes into more depth of about the nature of the programme and how it worked.
Personally I’ve come to see three audiences for the Agile Cornwall case study: anyone who wants to adopt Agile, those who want to know the lessons of our Cornish Agile Laboratory (the Cornish Software Mines), and third, Government agencies who want to see how Government support can help companies adopt Agile.
Finally, I was also part of the panel discussion which is online too - this include Mary and Tom Poppendieck, Toby Parkins and Jason Gorman.