Heresy: My warped, crazy, wrong version of Agile

I increasingly feel that the way I interpret Agile, the practices and the processes, if different to the rest of the world. Perhaps this is just self doubt, perhaps because I started doing Agile-like-things before reading about XP or Scrum, perhaps this is because my version has always been more informed by Lean, perhaps this is because I have never achieved Certified Scrum anything status, perhaps because I’ve never worked for ThoughtWorks, perhaps because I hold and MBA (and thus have an over inflated opinion of myself) or perhaps I’m just wrong.

Yet clients of mine report some success (I even have a couple of case studies). Perhaps this was despite me rather than because of me. In the past I’ve described two of my own Agile systems - Blue-White-Red and Xanpan, these are my attempts to describe how I see the development working without being constrained by other systems (sometimes I think of own-brand-cola methods.)

Here is where I feel I differ from the Agile mainstream, or perhaps, just Scrum:

• I don’t it is wrong to carry work from one sprint/iteration to the next
• I don’t believe in Scrum Masters; where Scrum Masters exists I think they are a kind-of Project Manager; and I believe Scrum Master Certification is a con (but I would, wouldn’t I?) that is potentially damaging the industry and Agile
• I don’t believe team Commitment works, its too open to gaming
• I don’t think Agile has cracked the requirements side of the business, we’re working on it, things are getting better
• I don’t believe Agile has cracked relational database management system; but I think much of the problem lies with the DBMS vendors
• I don’t believe Agile Coaching is different enough from Agile Consulting to justify the name
• I don’t really believe in offshore-outsourcing; OK, it can work but the companies that use it seem to be those who shouldn’t and those who are equipped to use it don’t need to
• I don’t believe you can tell how long a piece of work will take (or how much it will cost) until you start doing it. And I believe it is wrong to pretend you can.
• I don’t believe Scrum (specifically) really understands the requirements side; and I believe the Scrum Product Owner is a pale shadow of Product Manager role which is (often) needed
• I don’t believe in One Product Owner to Rule them all; on a large development effort the Product Owner role needs to be refactored (damn, I need to blog more about that)
• I don’t believe all companies can, or will, make the transition to Agile; but that many of these companies will stagger on for years while more Agile competitors take their market
• I don’t believe Agile will ever work in Cobol teams, or not Agile-as-we-know it; anyway, Cobol teams which still exists are highly adapted to their environment.
• I believe Agile is a dirty word in some circles and has been used and abused; but I don’t believe there is an alternative (at least not right now)
• I don’t believe the Dreyfus model of learning is the right model for Agile, I think it makes work for consultants and creates Learned Dependency, I prefer the Constructivism model

Its not all bad, there are some things I believe:

• I believe Agile means “Better”
• I believe the Agile Manifesto is a historic document like the US Constitution, and like the constitution we can read all sorts of meaning into it, depending on who you are you read different things. But there is no Supreme Court to arbitrate on whats-what. So Agile is “what I say it is” - or maybe, like “art is what artists do”, “Agile is what Agile advocates say it is”
• I believe Agile is, and always has been about flow, some people might not get it, and the some in the Kanban crowd might have come to it late but its always been there
• I believe in breaking User Stories down - I mean, I’d love it if teams didn’t have to break them down and I aim to take them there one day, but its a long journey
• I believe the Product Owner role is far more important than the Scrum Master
• I believe “Project” is an accountancy term that has wrongly become attached to development work
• I believe in the Planning Fallacy
• I believe Developers are the centre of the process, ‘Work Flows Inward’ as the Pattern says
• I still believe in Story Points, or rather, the things I call Abstract Points
• And I believe Abstract Points should be assigned to task; I don’t believe in using different currencies for tasks and stories (i.e. don’t use hours for tasks and story points for stories)
• I believe planning meetings, work break down and assigning points is as much about design as it is about work scheduling
• I believe engineering quality is essential to achieving Agility
• I believe in Software Craftsmanship and don’t think Agile will ever work if quality isn’t fixed
• I believe every organisation has to define its own version of “Agile” - you can’t take Scrum (or any other method) off the shelf
• I believe too much advice and consultancy can stifle an organisation, I believe in light-touch consulting to help companies find their own path
• I believe that in many companies - corporate IT departments specifically - the right approach is to “do things right, then do the right thing”
• I believe when you apply Agile thinking outside of IT it is Lean
• I believe speaking out against Scrum is bad for the reputation and the Scrum Mafia will come after you in a dark alley

Gee, this starts to sound like Allan’s manifesto! Anyone want to sign? :)
- OK, the last point was a bit of a joke :)

I’ve linked to some blogs and such where I have previously discussed these items, and I might expand on some in future. Many of the issues raised here are complex and I really don’t have the time to explain them right now, so next time you see me ask me to discuss.

Now out: Business Patterns

Business Patterns for Software Developers is now out!
Early too!

See for yourself:


Some frequently asked questions:
Q: How long did it take to write?
A: Eight years end to end, although the first patterns aren’t in the book, in fact I didn’t realise I was writing a book until about 2008. Years 6 and 8 were the busy ones.

Q: What is a business patterns?
A: Its like a software pattern, or an architecture pattern, but concerns itself with business and business strategy.

Q: Is it available on Kindle?
A: Not immediately but it will be in a few weeks

Q: Where can I read more about the book?
A: Early versions of most of the pattern are available for free on my website - follow links for business strategy design patterns

Q: What are the buildings on the cover?
A: The Three Graces on Liverpool pier head, a UNESCO World Heritage site. I prefer the daylight pictures but the evening picture on the cover works well in the design.

The Meter: Tom Giib's greatest invention

If you’ve ever found the time to read Tom Gilb’s work - and I’m thinking specifically of Competitive Engineering here - you’ll know that his work is packed full of good ideas. So many god ideas in fact that it can be hard to read his book - something I think he admits himself in the opening pages of Competitive Engineering.

One of his ideas is that of a Meter. This alway confuses me a little, still now...

You: A Metre you say?
Me: No, not a metric unit of distance, a Meter, as in a Gas Meter
You: What, how can a Gas Meter help software teams?
Me: No, the idea of measuring things, scrum that, say a Ruler
You: A ruler? Centimeters and inches?
Me: No, A yard stick
You: Distance again?
Me: No, A unit of measurement and a tool for measuring
You: Measuring what?
Me: Yes, Measuring what, that’s Tom’s great invention, we need to define measuring systems

Tom’s great invention is: define a mechanism for measuring the thing which is important to you.

OK, Tom takes the idea further with Plangauge he says we should define the meter, the starting value and the desired value. But forget values, its the measurement unit itself which I think is too frequently overlooked and worth more attention.

The thing is, the unit of measurement, and the means of measuring it is implicit in a lot of work: its in Kaplan & Norton’s Balanced Scorecard, its in Beyond Budgeting, its in Lean Start-Up and elsewhere.

But, as far as I know, only Tom calls the Meter out as an idea in its own right. In fact, I suspect Tom might not have realised the significance of this.

Once you know what the right Meter is it becomes - relatively - easy to measure things. So you can measure the starting point, you can set a target, and you can measure how far you have got.

We are surrounded my measurement units and meters which already exist

• Currency: Pounds, Dollars, Euros, etc. etc. - and the associated profit, revenue, costs, etc. etc.
• Accounts: Profit, revenue, costs
• Website hits: visitors, unique hits, conversions, etc. etc.
• Time: second, minutes, days....
• Distance: inches, miles, centimetres, meters and kilometres
• Location: Latitude and Longitude
• Weight:.....

And we tend to use these measuring units again and their associated meters again and again.

New meters are not so common but they occur, e.g. Eric Ries in Lean Start-Up introduces a new meter: Cohort Analysis.

But - big but - if we use inappropriate measuring units and meters it gets hard, and it potentially gets wrong. (Another on of Eric’s points.)

Again, as far as I know, Tom is the only authority who says: define your own unit and define your own way of measuring it.

Now, as far as I can tell Tom is a master of this, the rest of us... well most people don’t get it and try and use pre-defined measurements and Meters, even those of us who “get it” struggle with it.

So, we need to start inventing new units of measurement and new ways of measuring things. We need to get good at both inventing these things and sharing them. History shows many of these measuring units are useful to other people.

Second, as more of these units are recognised then we will have more mechanisms - and language - with which to implement both our own tools and the tools like Balanced Score Card and Lean Startup.

Corporate Psychopathy

The Oxford Dictionary of English on my Kindle defines:

Psychopathy n. mental illness or disorder.

Psychopathic is more interesting:

Psychopathic adj. suffering from or constituting a chronic mental disorder with abnormal or violent social behaviour

There is a reoccurring pattern of behaviour I have observed in corporate environments which I have taken to calling Corporate Psychopathy, maybe you’ll recognise it if I describe it.

• A company brings together a team to do some work. At some date they decide the work is “done” and disband the team. They often call this work “a project” - projects by their definition have a start date and an end date, and involve a temporary organisation unit; i.e. a team is brought together at the start, they do some work, then the team is disbanded.

I think this state of affairs is crazy. So crazy I believe it is abnormal social behaviour.

A team is a social unit. When was the last time you dumped all your friends and started to forma a new group?

Think of the high performing teams you know: sports teams or successful political parties. They may change players from time to time, even key players, but the winning team usually stays together from one victory to the next.

By contrast think of the teams who are less successful. How often to do they change personnel How often do they work together?

Anyone who has studies team dynamics will probably have come across Buckman’s “Storming, Forming, Norming and Performing” model. The idea is that when you bring a team together they pass through each phase as they learn to work effectively together.

If you have an effective team - one that has passed through storming, forming and norming and is now performing - why would you break them up? Let alone break up one team and create a new team which has to pass through three phases to get to the productive fourth?

It doesn’t make sense.

Just to make it worse when corporations break up teams many of the people leave for ever. Companies which use contract staff release the contractors who will go and work somewhere else. Even permanent staff may well find themselves release to a pool, or to previous roles and the same people are unlikely to work together again. Knowledge evaporates in the process.

If that isn’t enough think of the admin overhead in managing all this.

It also makes the start of a work incredibly difficult because you don’t know how effective a team will be or when they will break through into Performing. And if you are following a development method where you measure capacity (velocity) and benchmark against past performance you can’t use this method for the first few weeks.

Its psychopathic: anti-social, performance reducing, expensive, undermines forecasting and increases risk.

Put it another way: It is plain stupid.

My solution is keep the performing team together as much as possible and bring the work to the team. Have the team move from one piece of work to another together.

This parallels the way we timebox work. In timeboxing we fit the work to the time allowed - a two week sprint or a quarterly release. Similarly we should bring the work to the team.

Of course teams might not have very clear cut switch over dates. Perhaps they have to ramp-down one stream of work while ramping up another. More complex to manage.

Or perhaps a performing team splits into two - like cell division. One part continues working on the first piece of work while the second part starts something new. This way the team can carry the culture from one piece of work to another.

To do this is might be necessary to let the team grow organically, split the team, then grow both sides organically.

The point is: there are ways of managing this. You don’t have to split teams up and form them all anew.

Dialogue Sheets on show at Skills Matter - 13 February

Quick follow up to the last entry about Dialogue Sheets. I’ll be doing a evening session at Skills Matter on the sheets next month - 13 February, “Dialogue Sheets a New Tool for Retrospectives”. The event is free but registration is required.

Retrospective Dialogue Sheets in InfoQ

Happy new year! - my opening missive for the new year is elsewhere...

I’ve written more about Retrospective Dialogue Sheets for this weeks InfoQ - “Dialogue Sheets: A new tool for retrospectives.”

This piece summarises many of the findings I discussed a few weeks ago in Dialogue Sheets feedback #1 and Dialogue Sheets feedback #2 blog entries.

A footnote to a footnote, I discussed dialog sheet print-on-demand a few weeks ago. After that I was able to reduce the price of printed sheets. As I suspected at the time the price reduction has made no difference to the number of people using the service. I therefore conclude that it is not the price of the sheets but rather the fact that there is a charge at all the creates the block.

News from the Cornish Software Mines

My work in Cornwall, helping companies adopt Agile approaches to software development, is set to continue into the new year - so more jokey tweets about the Cornish Software Mines. I hope to write more about this work - the benefits and what we’re learning in future.

Right now there are two pieces of news I’d like to share:

• At the start of December the author of PHPUnit, Sebastian Bergmann, joined in me in Cornwall to provide training and coaching to teams using PHP. Oxford Innovation (who run the Grow Cornwall programme) have put out a press release about this.
• Oxford Innovation have also produced a Video Case Study of our work with Research Instruments in Falmouth. RI are a great success story and the case study is worth the two and a half minutes it takes to watch.

I first met the team at RI in October 2010 when I provided Agile foundations training to development team. Since then I’ve been in many times to provide follow up coaching.

About six month after the Agile foundations course Jon Jagger delivered a Test Driven Development (TDD) in C# course for the team and has also been visiting to provide follow up coaching. All in all a great success, as the video shows.

Xanpan, ToC, Guilt, plagiarism and sorry

When I was doing my Masters degree I had it hammered into me: credit your sources, don’t plagiarise. To this day I take pride in trying to credit the source of my thoughts, back-up my ideas with research and apportion credit. I won’t always succeed but I think I do a reasonable job. Heck, I’ll go further, I think I do a better job than most.

So image how I felt after my last blog post, about Xanpan, when Benjamin Mitchell tweeted:

“@allankellynet I'm unclear why you don't mention Theory of Constraints 5 Focussing Steps. What's your thinking on this?”

I was mortified because, well, he was right. My blog post discussing how to improve throughput on a Xanpan board was pretty much a Theory of Constraints description.

I had plagiarised. I had failed to credit. And I had written something that other people have written before - probably better than me.

I apologise, I give due credit: these ideas are inspired by the Theory of Constraints - or ToC for short.

So how did I come to make this mistake?

Well, I think the answer is in two parts:

First, I have ToC thinking to heart and it now seems so obvious I’d forgotten it needed crediting

Second, the blog entry was written a day after I’d had a similar conversation with a client. ToC hadn’t been mentioned in that conversation so it wasn’t mentioned here.

So maybe the plagiarism occurred in my conversation with the client. Well yes, but.... my first point still applied and second I tend to avoid crediting with clients. Now I’d better explain that second point some more.

In conversation with clients I tend to avoid saying things like “This comes from....” or “I suggest you go and read....”. Yes I do say those things but every time I say it I believe there are two ways for a client to take it: they may take it as “good, Allan is giving me the original source” or they may take it as “Hmmm, this consultant is name dropping, doesn’t have ideas himself and is very academic.” (Plus, they are paying for my time so perhaps I should just explain things to them.)

In short I don’t think it always helps.

I also remember all those Professors at Business School who uttered “Smith Smith & Smith, 1904” (or whatever) at the end of every sentence. And those turgid academic journal articles where every paragraph was credited and thus become very very boring to read.

I could go on but you get the message.

Now, one more thing, this blog entry is really really defensive. I feel a little attacked by Benjamin - I’m sure he didn’t mean to attack me, its just in 140 characters people come to the point. Maybe he feels attacked by this, don’t know we could get deeper and deeper.

For anyone still reading, I’m sorry for droning on. However I think this does raise an interesting point: in trying to explain things, in writing and in conversation making things accessible and easy to understand is - in my humble opinion - at odds with academic integrity and full disclosure.

As someone who makes a living doing this I need to be more aware of it than most.

Xanpan: refining the process

In my last blog entry I discussed a Xanpan board layout which allows for planned and unplanned work to co-exist in one workflow. Here is a picture of the board I had just put together with a team in Cornwall:



This might be the perfect board layout for the team for ever. More likely it can be improved over time - in the words of Kevlin Henney, it is a Stable Intermediary Form.

I think of Xanpan boards like the Pompido centre in Paris, they externalise the plumbing. In this case the workflow and work in progress. You can see the stuff that is normally hidden inside.

My rules are quite straight forward for Xanpan boards:

Stage 1:

1. Model the current workflow on the board: avoid changing it too much to “how it should be” but you will probably need to modify the workflow a little in order to be able to model it.
2. Make sure you talk through various scenarios for work to make sure you have a workflow that will, well, work. As I said in the original Xanpan blog post columns normally come in pairs: queue then work.
3. Operate the board for at least one iteration (several weeks) and learn from it.
4. Reflect and refine the board: in doing so you will modify the workflow, this should be an improvement.
5. Operate the board some more an start gathering data, qualitative and quantitative about the flow of work.

This alone might improve your teams performance: you have visibility of the work in progress, you can reason about it, people are better informed, you will make better decisions. But, this will not solve or your problems, nor is it the end state, it is just the beginning.

Stage 2: (Assuming you want to improve the throughput)

• Think of the board as a pipeline: there are two ways to improve throughput, make the pipe bigger or make things move through the pipe faster.

First seek to move things through the pipe faster:

1. Look at the blocks: why are they blocking or impeding? What can you do about removing them, not just on this occasion but permanently
2. Where are the queues building up? Can you rebalance the board, or rather how your people (and possibly other resources) are deployed to even this out

Continuing reviewing the board and looking for improvements for ever. But if the time comes when you want a bigger pipe:

• Add people to the team gradually over time: adding people slows down the existing team, the bigger the team the smaller the proportional slow down, above all else: avoid foie gras recruitment. Again this is likely to be a long term activity.

Finally:

1. Look to level workflow: reduce the peaks and move work to the lows.
2. Look to increase the value of the items moving through the pipeline - more and better business analysis and product management

Those are the rules of thumb. Of course there are exceptions, of course there are other issues, of course they don’t cover every eventuality.

Xanpan: planned and unplanned work

I’m on my way back from another visit to the Cornish Software Mines. I’ve been with four different companies this week, laid the first plans for Agile on the Beach 2012 conference and got to know Sebastian Bergmann who has been visiting the mines this week working with the PHP teams.

One of these companies is new to the Agile programme, we did training for the entire company last month and this week I was there to get them started for real. This meant we had to design their board layout and talk about workflow. Once again I found myself advocating Xanpan, the cross between Extreme Programming and Kanban.

The board layout - effectively workflow - is on which reoccurs in Xanpan systems and I would like to discuss here. (I’ll explain the layout here and in a second blog entry I’ll post a picture and talk about the future.)

The problem companies/teams face is: they have planned and unplanned work to do. Typically this is some project they are working to deliver but they need to work on support issues - bug fixes - too. I say that, but it is not just support issues, sometimes it is clients who shouts very loud, or managers who can’t say no, or customers who refuse to wait a few days - indeed sometimes to do so would be the wrong thing to do.

The Scrum answer to this is to stamp on the unplanned work. The team are locked - remember commitment and Sprint-goal. This unplanned work is a problem the Scrum Master should stop - or declare Abnormal Termination of Sprint. Particularly in small companies this isn’t a very useful answer, the truth is, things are more complicated than that, planet-Scrum is too simple.

The ultimate solution is to look at the reason these unplanned items are arising and try to address the root course. In time it might well be possible to do that but right now we don’t want to block the team’s transition. Even in the long term this might be the way of the world for such a team.

The Kanban answer would be to go in the other direction: run all work as “unplanned” and just restock the to-do queue as needed. However this robs the team of the rhythmic certainty of a Sprint. Many of the teams I see need to move away from seat-of-the-pants decision making and knee-jerk reactions. Adopting regular iterations builds in decision making points and helps individuals understand their roles.

So: Xanpan, keep iterations/sprints but allow for unplanned work. To do this we design a board which begins with the three columns:

• Planned
• Unplanned
• Prioritised (usually this queue is limited)

The next column is usually something like:

• WIP: In development (usually WIP limited)

The team start Springing as usual: they hold a planning meeting, review Blue Cards (Business requests, User Stories) and if necessary break them down to White Cards (tasks). These then populate the Planned column. These blues are probably drawn from a traditional product backlog.

At any time work can be added to the Unplanned column. The column is unlimited.

A few minutes before the morning stand-up meeting around the board the person with authority populated the Prioritised column reviews and populates it. This could be the Project Manager, Business Analyst, Team Leader or someone else, the role and title doesn’t matter, what is important is that this person has the authority to do this. On one team this was the joint responsibility of the Project Manager and Business Analyst.

This person looks at the work still in the Prioritised queue, and they review the Planned Work and Unplanned work. From these sources they decide the priorities for today. When the team gather they can see what the priorities are. For the sake of simplicity it normally makes sense for the Prioritised queue to be limited and for the priorities to be ordered: 1, 2, 3, up to the limit.

If need be priorities can be changed during the day: maybe something even more urgent arrives - or goes away, maybe the prioritised queue empties, or some such.

Effort estimates are normally assigned to planned work during the planning meeting. For unplanned work some teams don’t both adding estimates, some added a quick estimate from the person who picks up the card when they pick it up and some put an effort estimate on when it is complete.

Importantly, the original source (planned or unplanned) is recorded on the card - maybe a different colour card, maybe a dot, a word, whatever. At the end of the Spring the team can review how much planned and how much unplanned work was undertaken.

Thats it really: planned, unplanned and prioritised. The first two are effectively queues for the third. Somebody, or bodies, are responsible for balancing priorities.

It is possible that this workflow/board layout is actually a transitional layout. After running with this flow for a while there will be data on how much unplanned versus planned work actually occurs.

Dialogue sheets: more sheets & pricing

A quick follow up to my last two entries about Dialogue Sheets (Retrospective Dialogue Sheets: feedback & updates 1 of 2 and Retrospective Dialogue Sheets: feedback & updates 2 of 2).

Several people who provided feedback said they found the cost of the sheets to be off putting. Since the soft copies are fee the true cost of the sheets depends on where you live and what access you have to large printers, I have little control over that. However, I did set up a print-on-demand service for getting pre-printed sheets.

I’ve looked over the settings and I’ve managed to reduce the price on most of the sheets - while I was there I’ve also uploaded some new sheets - a general discussion sheet, a Sprint level retrospective sheet and a Kick-Off sheet.

The cheapest sheet is now priced at $13.75, or £8.74, €10.20. Since the printer is based in the US the exact price depends on your currency.

Unfortunately, shipping needs to be added to that. Within the US the cheapest sheet should total about $30 - if you order multiple sheets the shipping costs doesn’t rise proportionately so it gets cheaper per sheet.

Apologies to everyone in Europe - myself included, or Asia, or elsewhere - shipping something across the Atlantic costs more. Again, if you buy several sheets at once its cheaper - and is what I do, I have a stack in my office.

I would be interested to know from people who do find cost a barrier just how much they could pay. If I know the restraints I can look into other options.

However, the skeptic in me thinks that the actual price is not important: $13 might as well be $3, $30 or $300. It is the fact that any money needs to be spent that is the barrier.

Which is silly really because sitting half a dozen software developers in a room for an hour isn’t cheap: say $100,000 per developer per year means $50 x 6 = $300, the cost of the sheet is trivial. (This might be why so few teams do retrospectives in the first place.)

Look at it another way: A dialogue sheet costs about $30, which means you save $50 (at least) it would have cost for a facilitator.

Cost arguments always loose so look at it another way: if as a result of the exercise the team save more than one hour it has paid for itself.

As I said, if you have any information that can help me find the right answer please e-mail me.

Retrospective Dialogue Sheets: feedback & updates 2 of 2

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.

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:

• 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.

As I said, one common response is that downloaders have “not had a chance to use the sheets yet.” On the whole I assumed this was down simply not having a retrospective. However a few correspondents have hinted that their company has a prescribed retrospective process. This worries me, if the retrospective approach is prescribed in such detail I wonder how much else is prescribed and how much opportunity there is to change things.

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.

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.

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.