Agile

A few days ago I pushed out a couple of Tweets which got quite a reaction:

“I am fed up hearing developers complain of Technical Debt as if it has nothing to do with them. Who writes this stuff?”

and

“Devs say ‘look technical debt’ like ‘look its snowing’. As if it has nothing to do with them”

It was that second one that got a hail of re-tweets.

So I thought I should add a few words of explanation here.

First it is important to say that the these tweets were not aimed at, or about, anyone in particular. I’ve visited a bunch of companies and delivered a lot of training in the last few months and the topic of technical debt comes up a lot. If I had anyone in mind about these comments in particular it was a developer I worked with four or five years ago but his sentiments are common.

Second, I’m not sounding off about developers. I love developers, I used to be one. I’ve had the same feelings myself at times, speak to people who managed me way back when and I probably moaned about the same things. (Over 10 years ago I wrote High Church C++ where I agonised about the right way to write code.)

What I am taking aim at is an attitude which says: “There is this thing called Technical Debt, we have it, it makes our lives hard, we want it to go away, but we have nothing to do with creating the problem and we need a special solution.”

It sometimes seems to me that having labeled the phenomenon developers are too keen to use the label. Steve Freeman and Chris Matts have tried to recast the debate in terms of real options “Bad code isn’t Technical Debt, it’s an unhedged Call Option”. Intellectually I agree with them but I find that the explanation required to explain an “Unhedged Call Option” is greater than the explanation to explain the original problem so I’m not sure what the metaphor adds to the debate.

The other problem with switching to an “unhedged call option” metaphor is that it perpetuates the Quick and Dirty Myth – the idea that doing a bodge-job now will pay back in shorter delivery time. In reality the reverse is just the case, I gave some statistics on this in my blogs last year about Capers Jones book Applied Software Measurement.

Common reasons given for the existence of technical debt are:

• It was the developers who where here before us
• We don’t have the time to fix it
• The managers made us do it, or The business demands this
• Its the Architects

(Notice the current developers are never to blame – and as much as I don’t want blame thrown around thats the debate is too often framed.)

Anyway, none of these reasons really stand up to analysis, except perhaps the last one.

Regardless of what the developers who were here before did the current developers should be addressing the issues. It is the current developers who need to live in this code, if they don’t like it they should do something about it.

Sure there may not be time to stop the world and fix everything but you don’t need to. You just need to fix a little bit every time. As Uncle Bob Martin says in Clean Code, follow the Boy Scouts Rule “Leave the code slightly better than you found it.” Then let the Power Law work its magic.

Secondly, there is more time if you do it right. Building quality, bug free, systems is faster than the alternative. Forget the Quick and Dirty Myth, its Slow and Dirty or Quick and Right.

(Sometimes I meet developers who want to “stop the world” and re-write the system. I’ve also on occasion met managers who have bought into this argument and stopped the world. This is a seriously bad idea, its why Netscape no longer exists: developers were allowed to re-write Navigator, as they were doing so Microsoft attacked.

I keep meaning to blog about “version 2” now I must, just watch this space.

Twice I’ve come across Managers who told the team they could re-write. In the first case the managers were lying. The developers, well one specifically, held a gun to their head and said “I’m resigning on 14 February if you don’t let me rewrite”. In that situation you should let them resign, these managers were scared of the developer. As far as I can tell things didn’t work out, the developer left the company not long after and the company was sold.

In the second case the Managers were either stupid or desperate. In either case within days of starting the “Technical Improvement Programme” (TIP) they found it wasn’t that easy and things started to revert to usual.)

Getting back on topic…

Unless Project Managers and Business Analysts sneak into the building at night and change code when developers aren’t looking then managers do not write code. Nor does the nebulous unit called “the business”. It is developers hands on the keyboard, “I was only following orders” is not an acceptable defence.

There is a professionalism issue here. Software Engineers need to take their work seriously and create code they are proud of. This is not to say they should start gold plating things but being an professional engineer means you don’t do shoddy work.

Architects may be the only defence I might accept: however this defence is only applicable when the organisation and architects are committing an even bigger sin, namely Architects who Don’t code, or Architects who don’t understand the system – usually these two go hand in hand.

If the architect(s) code then they are part of the development team, they see the same problem, they have the same complaints. Now it is just possible that the architect does code and they aren’t very good. Or rather, the Architects understanding is different to that of the developers, which might point to issues of recruitment, the architects style or bad team dynamics.

The reason I might accept this reason is that it points to an even bigger problem for the organisation and it does imply engineers are pull in opposite directions.

Interestingly Ron Jeffries replied on Twitter, and said “Ward [Cunningham] originally defined tech debt as reflecting later learning, not available at the time of construction.”

I think its time we returned to this definition. Its not about other developer, the business, architects or others creating technical debt for poor developers. Its about developers improving their own understanding. Its about the need for refactoring. And it most definitely is the developers own responsibility and professionalism.

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.

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.

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.

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.

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.

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.

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.

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.

In the past I’ve worked for banks, as an employee, as a contractor and as a consultant. And I’ve worked for companies that supply banks in one way or another. And I have lots of friends who work for banks and tell me stories. While I’m not an expert on banks and banking I know a little….

One of the things I know is that modern banking – in all its forms – is highly dependent on IT. Banks spend a lot of money on IT and develop a lot of their own software. As a result they have a lot of software developers. And I also know that quite a few of these developers and their teams have been, and are, experimenting with Agile working in one way or another.

It seems every bank has pockets of Agile, a team here, a team there. And not very often joined up.

Some of these teams are successful, some are less so. They often find themselves battling against big company / bank culture. The banks seem to be very good at killing their Agile teams: they get disbanded, forced bank to traditional (pseudo-Waterfall) approaches by bank procedures, or constrained by “the way we do things here.”

It also seems – notice we get further and further from fact and more into conjecture as I build this argument – that many banks have cottoned on that Agile is good and can help them. To this end many banks (and this is fact) have established Agile support programmes of one form or another. There are people at many banks who are trying to make the bank Agile – at least in software development. For many of them it is an uphill struggle.

At this point we should differentiate between retail banking – what you do on the high street with your bank – and investment banking – or casino banking if you prefer. (Yes there are other divisions but lets limit ourselves to two.)

In retail banking I think there are grounds to be a little optimistic. The stories aI hear are that Agile pockets are having success and things are gradually, slowly, improving and the efforts to link things up are slowly bearing fruit.

In investment banking I’m very pessimistic. I have come to the conclusion that while individual development teams may be successful at Agile for a while inside an investment bank all such teams are ultimately doomed. Your team might be Agile for a few weeks or months or even a year or to, but it will eventually be killed by the bank antibodies.

I have come to the conclusion that investment banking culture is polar to Agile culture. My reasoning is thus:

• Investment banks are extremely hierarchical in nature; Agile is not. Agile can live with some hierarchy but not investment banking extreme.
• Short-term in outlook: investment banks are short-term in the extreme – microseconds in some instances. Agile teams can react in the short-term but only by taking a long term view of engineering and quality.
• Investment bankers are not engineers and do not understand engineering. Nobody from IT ever got to run an investment bank, you don’t get up the ladder from a support function, you get there from selling and banking. A large part of the Agile story is about returning to good engineering principles. The lack of engineering skills, thinking and culture in investment banks undermines Agile.
• Investment bankers think you can solve every problem with money. Throwing money at Agile can work in pockets (by the best team) but doesn’t last or scale.
• Investment banks are individual focused: individual bonuses, the power of the one trader to make money or break the bank (from Kweku Adoboli to Nick Leeson and before.) Agile is team focused.
• Investment bankers think applying more pressure is the way to get results; Agile people now that applying pressure breaks things. A little pressure can help but apply too much and things snap, bankers don’t get engineering so don’t get this.
• Risk aversion: yes, investment banks are highly risk averse when it comes to IT. Perhaps because they take so much “risk” directly with money they very risk averse in their operations.
• Investment banks are contradictory: they say they embrace and manage risk but actually they are risk averse (at least in operations); they say they value the team but their actions say otherwise; they call themselves “financial engineers” but they no nothing about engineering; and so on. Agile is about honesty, facing up to truth and acting on it. Investment banks recent track record shows that honesty is sometimes questionable, to say the least.

I’m sure many of you reading this will say “Rubbish, I know at team at ….”. I am sure you do. While that team might be successful for a while the investment bank culture will eventually kill the team.

So how can we help investment banks overcome this problem?

We can’t. Its the way it is. Take the money, and run, or keep you head down and hope for some more.

Eventually new financial institutions will emerge which get Agile, not just at the software level but elsewhere. These institutions – which might be banks or might take some other form – will eventually replace the investment banks.

This is going to take time. Investment banks are fundamentally a broken business model which are propped up by Government support and market failure. This means normal economic logic does not hold for these institutions.