Tuesday, November 18, 2014

It is all X or Y management - and why Agile people should read Mintberg

In the last few years it has become increasingly common to hear Agile supporters talking about Beyond Budgeting, indeed, I was instrumental in inviting Bjarte Bogsnes to deliver at keynotes at Agile on the Beach this year.

Agile and Beyond Budgeting are very different, one is mainly about developing software and other is concerned with budgeting, strategic management and personnel management (I cannot call it human resources.) Agile and Beyond Budgeting are not the same thing but they fit together very nicely - indeed they may share some common roots, I think of them as fellow travellers.

Similarly Lean and Agile fit together nicely, but then many of us - although not all - see them as different versions of the same thing.

Then there is John Seddon and the Systems Thinking crowd, they pop up at Agile conferences regularly but System Thinking is not Agile, nor is it Beyond Budgeting, but again, they do all promote a similar view of the world. Again, fellow travellers. (Although John Seddon will probably object to that, he seems make a point of rubbishing Agile.)

Underlying many of these ideas is organizational learning - something I wrote about myself in Changing Sofware Development - and something which seems to be experiencing renaissance in Agile circles.

And I’ve heard talk of Agile HR. I’m not sure what it is but I guess its also a fellow traveller.

And I’ve been told that some forms of marketing fall into this camp too. Another fellow traveller?

I increasingly see lots of ideas and models which cluster around a similar philosophy, they may not always agree but they generally fit together.

And this philosophy is in contrast with a lot of ideas in that are more generally accepted. For example: budgeting as planning, command and control management, hierarchical organizations, managers as task master and so on. You get the idea? This is another group of fellow travellers.

Some of you might have guessed where this is heading: McGregor.

Back in 1960 an academic by the name of Douglas McGregory published an article entitled “The human side of enterprise”. In it he laid out theories of how organizations work, Theory X and Theory Y. (I just checked and I am amazed to discover this 1961 book is still in print!)

Theory X is predicated on idea that people inherently dislike work - after all, wouldn’t you rather be watching TV? Therefore employees must be controlled and directed, they want security and all but a small elite have little ambition and shun responsibility.

From this theory we get the idea that annual budgets control spending, that bonuses incentivise people, managers control work, responsibility goes with authority and if managers don’t keep an eye on people they will slack off. Project planning and theories like Michael Porter’s view of business strategy all fall under this banner. These are the Theory X fellow travellers of traditional, or at least 20th century management and business.

Theory Y on the other hand is predicated on the belief that work leads to satisfaction and through work people can be more fulfilled and happier. People are naturally motivated and can exercise self-direction - indeed the more autonomy people have the more satisfied and motivated they can be. As a result people seek responsibility, want to feel valued and can be very committed to objectives.

Clearly theory Y would encompass Agile, Beyond Budgeting, self organization, team based working and amoeba management, systems thinking and possibly new forms of “Agile HR” and marketing.

I would like to think that these Theory Y fellow travellers represent the model of business and management in the 21st century. But I can’t prove it.

(By the way, I missed Lean out of that last list, while I argue that Agile is Lean, and Lean does embody much of the same Theory Y philosophy I have reservations about Lean. These concentrate on some overwork practice that have occurred in Lean, particularly Karōshi, death by overwork.

Most definitely I do NOT include 6 Sigma, ever, that is X.)

Little of this will be a new to those who have hung around “agile” for a few years but there is something else, something we’ve missed before….

Business strategy.

Theory X has business strategy sorted. Its about big men with big brains setting out strategies for competitive advantage. Michael Porter is the hero.

In Agile we haven’t really got our thinking sorted here so let me make a suggestion.

Henry Mintzberg

In Mintzberg’s world management, business and strategy are messy. Strategy is part pre-planned (Porter-esque) but it is also about what has happened before. The stories we tell ourselves, our understanding of what happened. Sometimes strategy is backward looking, sense making. Often strategy is messy because it is emergent, it comes from what we have done, what we have learned before. The firm may start off with a destination in mind but it will actually reach a different place. The distinction between strategy and tactics may not clear until long after the event.

The Agile community should be reading more Mintzberg. Fortunately he recently started blogging, http://www.mintzberg.org/blog.

One of his shorter strategy books would make a good start. But if you want a real read the Rise and Fall of Strategic Planning is brilliant. The parallels with software development, the rise and fall of waterfall, are striking. Indeed, only by understanding how the corporate world fell for strategic planning can one understand where waterfall really came from (hint: it isn’t Royce.)

Rise and Fall is a great book that is work reading but it isn’t a quick read and it requires thought. Try Strategy Bites Back if you want a shorter read.

More recently, and more relevantly for Agile folk are his recent works on management.

Managing (2009) - or the shorter version Simply Managing - should be required reading for anyone who wants to argue that Agile teams don’t need managers - and equally they should be required reading for anyone who blindly believes managers are needed. To have or not to have managers: it is not an easy question and both sides should be better informed.

(After reading both Managing and Simply Managing I thought I would write a article, or at least a blog, setting out the case for managers but its a lot to take on. Better to just read someone else’s book.)

Our world is complex, sometime the Theory X people may be right, and sometimes the Theory Y people. In the part of the world I live in Theory Y is the one I find most useful.

Thursday, November 06, 2014

Does Agile require cultural change?

If Wood Allen was an Agile Coach Consultant he might say:

“#Agile without culture change is an empty experience; but as empty experience go its one of the best”

I sit in Agile conferences (and I include Lean and Kanban here) and I hear people say “To really become Agile you need culture change.” And I agree with them.

Yes, if you really want to be Agile, and get the greatest benefit from Agile you need to change the culture of the organization to embrace the Agile way. I agree.

And I also know that every speaker on this topic - and myself - warn again “doing Agile” without being Agile in culture and mindset. Heck, I kind of wrote a book about this once upon a time. For me “Agile culture” is a “Learning Organization Culture.”

But…

But Agile is a toolkit, you can pick out and use many of those tool without adopting others and without adopting an Agile mindset. For example, you can do Test Driven Development without the need to adopt an Agile culture in your organization. And even without culture change Test Driven Development (TDD) will make you better.

True, if you have to force march your programmers through TDD it isn’t going to be as beneficial as it will be if your programmers embrace TDD and want to do it and make it part of their life.

Given this we - and I include myself - build an argument for undertaking cultural change.

But, big BUT….

TDD is not alone, there are lots of tools in the Agile toolkit that you can pick up and use individually, or with a couple of others, which will help you improve. But if you want the full benefit, well, you are going to have to pick up more tools and change that culture!

Culture change is a far bigger effort than introducing any Agile tool - or even an Agile method.

And most of the people who go by the title “Agile coach” or “Agile consultant” or similar are - in my opinion - drawn from the technology side and aren’t necessarily equipped to undertake culture change initiatives. To be fair, I don’t think many people are equipped (training, experience, knowledge, etc) to undertake culture change.

Please don’t take offence Agile consultants/coaches, I include myself here. On paper I have more qualification to change culture than the vast majority of Agile consultants/coaches I meet and I’m wary of trying to change culture.

Certainly, if we believe folk-law (or the updated version “wisdom of crowds”) culture change is hard and often fails.

Let me say something some people will disagree with:

Culture Change is not necessary to introduce Agile. Culture change is not an enabler.

Rather culture change may be the result of adopting Agile.

I hope it is the result but I also recognise that organizations have the cultures they have and we mess with it at our peril, culture may look bad but embedded in there is a lot of knowledge and norms. Company culture is makes a company what it is, change it and you risk destroying the company. Messing with culture is likely to bring out the corporate antibodies.

Anyone who wants to change an organization, particularly anyone wanting to change tools, methods of working and culture in an organization is well advised to go and study the history of Business Process Re-engineering (BPR). BPR was an 1990’s attempt to change the ways companies work, through the use of technology, or make them more efficient. Agile has a lot in common with BPR but BPR is an example of how not to do it.

I am prepared to take people through Agile tools, practices, methods, I encourage them to adopt these approaches, and I don’t really work, directly, to change culture. I believe that if people start to live and Agile lifestyle then the culture will follow. I believe that Agile-Lean is good, I believe that if we pick tools which will make peoples work better in a way they appreciate it then I believe that in time the culture will change.

In short, I believe culture follows tools, the tools we choose to use - whether that be stand-up meetings, Jira, Rally or paper and pen - influence our culture and lead somewhere. Its not a one way street, its not that simple, but tools are a lot easier to change than culture.

Change come first, culture follows.

Saturday, October 25, 2014

#NoProjects/#BeyondProjects - a developer footnote

Last Friday I delivered a revised version of my “The End of Projects and What to do Next” presentation - otherwise known as #NoProjects / #BeyondProjects. The presentation is on Slideshare if you missed it - or better still see it next week at Lean Kanban UK 2014 (use the code LK14SPK for 15% discount).

In the post conference drinks was chatting with a developer - Matt from New Zealand if my memory serves - and he came out with what some might think was a surprising comment. He said: “I’d never thought of a project like that before.”

Specifically he meant he’d never thought of “a project” in sense “project” is used by APM/PRINCE2 and PMI, which is:

  • The PRINCE2 definition: “A temporary organization that is needed to produce a unique and predefined outcome or result at a pre-specified time using predetermined resources.”
  • The PMI definition: "PMI defines a project by its two key characteristics: it is temporary and undertaken to create a product, service, or result that is unique."

He went on to say that he believed “a project” was “a collection of features.” I can’t say I’m surprised by this, I think many people regard a project as “a collection of features.”

In fact I’ve long suspected that many developers don’t even get that far. To many developers a project isn’t any of these things, a project is “A collection of source code files that build an application.” Back when I was coding C++ this was exemplified by Microsoft Visual Studio where .prj files (i.e. .project files) listed the source code files and “make” instructions to build an executable.

I have a lot of sympathy with this - and other - developers who take this attitude. One might say they have moved to an Beyond Projects mindset already.

The term Project is being used, it is the language of the team but it is being used to mean different things. When this happens the people are using the same words but are not talking about the same thing. Goals, objectives, aims, deadlines, and everything else is missed up.

Its just another example if what I call “False Projects” - using the word “project” without really meaning it.

Friday, October 24, 2014

Dialgue Sheets (2 of 2): Searching for Guinea Pigs

This post follow directly on from my previous one, Dialogue Sheets and Update.

I’m looking for some guinea pigs….

Are there any teams out there who would like to try a dialogue sheet focused on requirements?

I’ve long thought that Dialogue Sheets would be a good way of discussing software needs, requirements, customers, problems and such. I’ve started designing some sheets to address this - the first one is a high level Products and Customers sheet. In intend to produce a more day-to-day product sheet and a sheet of internal IT.

Now I’d really like some teams to step up and say: We’d like to try one of these sheets.

There is no charge for this and I’ll supply the sheet. I need a teams which are willing to give me half a day.

I’ll give you the sheet, I’ll observe as you complete it, we’ll debrief and thats that.

Preferably I’d like my guinea pigs in the Greater London area (because that is easy and cheap for me) but I’m happy to come wherever you are. (OK I might have a problem is you are a few thousand kilometres away but lets talk.)

Interested?

Call me or mail me - contact details here.

Thursday, October 23, 2014

Dialogue Sheets update (1 of 2)

It has been a while since I’ve written about Dialogue Sheets here - or indeed anywhere else. So here is a quick update and a request for some guinea pigs - I have ideas for new sheets but I need some teams to try them out. (If you want to be a guinea pig for a new sheet skip to the end of this blog.)

The impetus for writing this blog is a new French translation of the T1 Retrospective sheet. I am most grateful to Nicolas Umiastowski for this translation which is now available with the other sheets.

Nicolas has blogged (“Retrospective dialogue sheet in use”) - with photos - about using the sheet this week with a team. The post is well worth reading, everyone was involved and it sounds like there was a lot of energy in the room.

More generally, the sheets continue to be used by teams, lots of downloads still happen from the Dialogue Sheets website. Unfortunately I don’t get much feedback on what happens after the download. If you have download a sheet and have tried them then I’d love to hear how it went and what you think.

Now some statistics.

There have been over 3000 downloads since 1 January 2012 from 94 countries.

(A word of warning here. I’ve made no attempt to cleanse the data. I know it contains some duplicates and some fake e-mail address (e.g. a@b.com) so I assume some of the downloads are fake. Given there are now over 3000 downloads I think (hope?) this doesn’t make a big difference.)

Unsurprisingly the USA leads the world with 20% of downloads, then the UK (15%) after which numbers quickly tail away: Germany (6.5%), France (5.5%), Sweden (4.75%), Norway (3.9%), Australia (3.8%), Netherlands (3.5%), India (2.8%) and Canada (2.75%).

I am sure one of the reasons France scores so highly is Laurent Carbonnaux’s translation of the Sprint sheet. Nicolas’ translation could see France overtake Germany. (I hope we’ll get some more translations and have added some notes on translation to the website.)

The most interesting story I’ve heard this year about Dialogue Sheets is from Sweden - the country where they were originally invented. I am told that there is a childrens’ nursery school (kindergarten) where the teachers hold a fortnightly retrospective using the sprint retrospective sheet! Wonderful.

The statistic I still find most interesting the retrospective frequency question.

I ask all downloaders “How frequently do you hold a retrospective (at the moment) ?”

Nearly 8% of downloaders say they are retrospective facilitators. Excluding these people, 47% of downloaders claim to hold a retrospective regularly (every two weeks or once a month.) But 44% say they never or rarely hold a retrospective.

Now I think it is fair to say we can expect those who hold retrospectives regularly to be more interested in these sheets therefore I expect these figures to be biased towards such people. In other words, if 44% of people interested in retrospective dialogue sheets say they rarely hold a retrospective I expect the true number of software professionals who hold a retrospective rarely to be a lot higher. Sad.

Moving on from numbers, some other changes.

About 18 months ago I introduced an Iteration Planning sheet, this doesn’t have so many downloads (over 200 in total). I’ve also written a description of how to use this sheet (same page). I know my style of planning is slightly different from everyone else’s - heck no two teams are ever the same! (Since I published Xanpan it have wondered if maybe I should rename this sheet as a “Xanpan planning sheet.”)

When I do training sessions I leave the teams copies of both the Sprint Retrospective sheet and the Planning sheet to help get them started. By all reports they help a lot.

The print on demand service is still there, it is little used and I was recently able to reduce the prices there. But if I’m being honest I don’t think the price of a Dialogue Sheet is a bit issue for two reasons. Firstly unless you are buying a lot of sheets, and unless you live in the USA, you will probably find the cost of postage greater than the sheets themselves. Hence I think most teams get these sheets printed locally.

Second, I think teams that have to ask for money have as much trouble getting $50 as $500. So it is the fact that the sheets cost rather than how much they cost which is the problem.

Now to the innovations….

I continue to use the Agile Thinking sheet at the end of Agile training courses to help teams talk about how they will put the training into action. This has proved very very successful. Steve Smith has recently adopted a similar sheet on his continuous delivery courses.

While I’m writing this I should mention some other changes that happened a while back, I retired the T2 sheet - it was not different enough from the T1, T3 and Sprint versions. And I updated the T1 and Sprint sheets - the Sprint sheet now has time boxes on it to aid with keeping the retrospectives to schedule.

One more thing… but that can wait for the next blog post.

Tuesday, October 21, 2014

#NoProjects / #BeyondProjects - Agile Tour & Lean Kanban UK conference

The next few weeks sees me delivering my #NoProjects/#BeyondProjects presentation at two London conference - Agile Tour London (Friday this week) and Lean Kanban UK (3 & 4 November). In fact I spent a lot of yesterday refreshing the presentation. Problem is there is just too much to say, the more I look at it the more problems I find with the project model but at the same time I want to make the presentation more positive by emphasising the alternative, the Beyond Projects bit.

Anyway, the reason for mentioning this is… the good folk at Lean Kanban UK have sent me a discount coupon to share with my readers.

When booking on the Lean Kanban UK website use the code LK14SPK for 15% discount. Simple, really.

Thursday, October 16, 2014

Contracts for Agile

Last night I did a presentation to the Agile 4 Agencies meet up group on the topic of “Agile Contracts” - although I believe “Contracts for Agile” might have been a better title.

This was based on my InfoQ Agile Contracts piece from 4 years ago - also available as a PDF from the Software Strategy website. My thinking and experience has moved a bit since then and some of that was incorporated into the presentation.

When creating the presentation I very much set out to work from the original piece, although as anyone familiar with my writing will know, this territory touches on “Dear Customer, The Truth about IT” (Agile Connection and now the prologue to Xanpan - which is also available from the Software Strategy website - my stuff has a habit of being reused.)

Anyway, the “Agile Contracts” is now online at SlideShare. And I believe a recording of the night might appear before long…

Thursday, October 09, 2014

The Estimates Land Mine - use and misuse of estimates

After posting my last post - Estimate or #NoEstimate that is the question? - I felt a little as if I’d stepped on a land-mine. That is to say I had a few comments and a bit a mini-twitter storm. If I’m being honest I have been avoiding some of the estimates/#NoEstimates debate until now precisely because it is obvious feelings on the topic run high.

Perhaps the thing that surprised me most was that a post intended to support making human estimates was interpreted by many Tweeters as part of the #NoEstimates movement! Maybe convergence between #NoEstimates and #NoProjects is already happening in the public mind.

In the meantime it seems to me that a lot of the problem with Estimates lies in what they are, what they are not, how they are used and how they are mis-used.

As is so often the case it all depends on what we mean by the word, in this case “Estimate”.

Generally I find it useful to agree with Humpty Dumpty:

“When I use a word it means just what I choose it to mean—neither more nor less." (Through the Looking-Glass, Lewis Caroll).

After all, who can forget Bill Clinton saying:

“It depends upon what the meaning of the word 'is' is.”

While I am sometimes guilty of the use and misuse of words myself I find it helps to keep an open mind on just what someone means when they use a word or phrase. For example, if a developer says “Unit tests” I try not to jump to assumptions about what “Unit tests” actually are. The fact that such language is used is itself interesting but I also want to know what they actually mean by it.

But back to the word “Estimates.”

On occasions like this I like to check my dictionary, in this case the :

“Estimate

        1.        to form an approximate idea of (size, cost, etc.); calculate roughly

        2.        to form an opinion; judge

        3.        submit an approximate price for a job to a prospective client

        4.        an approximate calculation

        5.        a statement of the likely charge for certain work

        6.        an opinion” (Collins Paperback English Dictionary 2001)

My other usual source is Wikipedia which on this occasion gives:

“Estimation is the process of finding an estimate, or approximation, which is a value that is usable for some purpose even if input data may be incomplete, uncertain, or unstable. The value is nonetheless usable because it is derived from the best information available.”

From these definitions I define a sense that an estimate is:

  • Approximate
  • A statement of possibility
  • Is based on available data which may itself be incomplete or variable

Maybe all estimates should be accompanies by a statement of probability but as Kahneman and Tversky described in the planning fallacy, and has been proved repeatedly since, not only do humans underestimate time but humans are over confident in their estimates. Thus any estimate probability statement would probably itself be an over estimate of probability.

Besides, very few of the “estimates” I’ve ever seen are accompanied by a statement of probability so I don’t think this suggest will get very far.

More importantly these definitions also help tell us determine what an estimate is not:

  • As estimate is not exact
  • An estimate is not a promise, guarantee or commitment
  • An estimate is not a target or deadline

And it is not several other things.

Now in my previous blog post I introduced the idea of “Accurate Estimates” so I was actually sneaking in the idea that an estimate could have a high probability and could be an accurate indicator of what will happen. Perhaps I was guilty of something there.

The trap I fell into is one that many fall into, that of accepting the general usage of the word “Estimate”.

In general usage - in the software community - we misuse the word estimate.

Firstly we automatically equate Estimate with “Effort Estimate”: effort (and therefore cost) estimate proliferate in software development but we overlook other estimates that might be useful, in particular Benefit Estimate.

Second the inherently approximate nature of estimation is too often ignore, estimated are endowed with a sense of promise of what will be rather than recognising their inherent approximate nature. (And as noted in the Planning Fallacy, Vierordt’s Law and Hofstadter's Law time estimates will always be under estimates.)

This also leads to too much conversation about “Why was the estimate wrong?” - sometime blame may be implied. The answer to the question is really: “The estimate is not wrong because it was an ESTIMATE” That is to say: An estimate is never wrong because an estimate is an approximation and therefore is not binary “Right” or “Wrong”.

Sure you can have a conversation about why the estimate was very different to what actually played out but the nature of that conversation is going to be different depending on what you will do with the findings of the conversation. For example, if the resulting information is used to refine future estimates it will be a very different conversation to one where the result will be punishment for someone. (Yes, people do get punished, I once saw a company where Project Managers were rewarded/punished based on the variance between estimated time spent on work and actual time spent.)

In short too often an approximate estimates based on variable information is used as some kind of exact promise to meet a deadline.

Software developers love to imagine it is evil managers who take their estimates, massage them to be politically correct, promise them to higher ups and then force poor coders to honour the number they first thought, but, big BUT, managers are not the only ones. Even in everyday life the Planning Fallacy, Vierordt’s Law and Hofstadter’s Law hold. Observe yourself next time you have to catch a bus, train, complete a tax return, hand in course work or do something (almost anything) with your kids.

I would love it if I could wave a magic wand and reset everyones’ understanding of the word Estimate but I don’t see it happening.

And I think - although Woody and Vasco might like to correct me - that a large part of the #NoEstimates movement is motivated by this problem. The way I see the logic is:

  • Estimates are seldom recognised for what they really are and honoured as such.
  • Estimates are misused and used as a stick to beat people and organizations.
  • Therefore estimates have become a problem and it is better of finding a way or working without them.

I’m not saying this is the whole #NoEstimates logic but it is part which strikes a chord with me.

Incidentally, because I believe estimates are not a promise I don’t believe in Scrum commitment and because I believe they are approximate that in Xanpan I focus their use on the near term. And because I believe benefits should dictate deadlines not effort I refuse to use estimates as deadlines.

Monday, September 29, 2014

Estimates or #NoEstimates? that is the question

To estimate or not to estimate, to join the #NoEstimates bang-wagon or not, that is the question.

Maybe it is a navel gazing exercise for agile-folk but it does seem to be the reoccurring theme. And I can’t get over this feeling that some of my peers think I’m a bit stupid for continuing to support estimates.

Complicating matters I’m finding my own work and research is starting to be cited in support of #NoEstimate - Dear Customer (PDF version), my publicity for Vierdort’s Law, Notes on Estimation and More notes on estimation. Add my own #NoProjects / #BeyondProjects logic isn’t far removed from the whole estimates discussion.

At Lean Agile Scotland a few weeks ago Seb Rose and I were discussing the subject, in the end Seb said something to the effect:

“How can you continue to believe in estimation when your own arguments show it is pointless?” (I’m sure Seb will correct me if my memory is fault.)

My reply to Seb was something along the lines:

I continue to believe that estimation can be both useful and accurate, however I increasingly believe the conditions under which this holds are beyond most organizations.

To which Seb challenged me to list those conditions. Well here is that list.

I’ve blogged about this before (well, I’ve mentioned it in lots of blogs, see this one Conclusions and Hypothesis about estimates) and I’ve devoted a large section of the Xanpan book to talking about I see estimates working but I think its worth revisiting the subject.

Before continuing I should say: I’m talking about Effort Estimates specifically. There is another discussion which needs to be had around business value/benefit estimation.

Here is, a probably incomplete, list of conditions I think are required in order for effort estimates to be accurate:

  1. The people and teams who will undertake the work need to do the estimates
  2. Estimates go off if not used: estimates only remain valid for a short period of time (days), the longer the elapsed time between making the estimate and doing the work the less accurate they will prove
  3. Estimates will only be accurate if the teams are stable
  4. Estimates much be calibrated against past performance, i.e. data is needed
  5. Together #3 and #4 imply that only teams which have been working in this fashion for a while can produce accurate estimates
  6. Teams must have a record of delivering and must be largely able to undertake the work needed, i.e. there are few dependencies on other teams and few “call outs” to elsewhere in the organization
  7. Estimates must be used as is, they cannot be adjusted
  8. Estimates cannot be used as targets (Goodharts Law will cut if they are)
  9. Estimates made in units of time (hours, days, etc.) are not reliable
  10. The tracking and measurement process must measure all work done, not just “project” work
  11. Financial bonus should not be tied to estimates or work
  12. People outside the team should not coerce the team in any way

There are probably some other conditions which need to be on this list but I haven’t realised. I’m happy to have additional suggestions.

Perhaps this list is already so long enough as to be unachievable for most teams. Perhaps meeting this conditions are unachievable for many, even most, organizations. In which case the #NoEstimate’ers are right.

So… I believe estimation can be useful, I also believe it can be accurate but I believe there are a lot of factors that can cause effort estimates to go wrong. In fact, I know one team, possibly two, who claim their estimates and planning processes is very accurate. Perhaps I cling to my belief in estimates because I know these teams.

When estimates do work I don’t believe they can work far into the future. They are primarily a tool for teams to decide how much work to take on for the next couple of weeks. I don’t expect estimates further out will prove reliable. Estimates for 2 to 12 weeks have some value but beyond the 3 month mark I don’t believe they will prove accurate. So my advice: don’t estimate anything that isn’t likely to happen in the next 3 months, and don’t plan any work based on estimates which extend more than 3 months into the future.

Which means: that even if you accept my argument that estimates work they may not tell you what you want to know, they may not have much value to you under these conditions.

And to further complicate matters I suspect that for mature teams estimation becomes pointless too.

As implied by the list above I would not expect a team new to this (agile) way of working to produce reliable estimates. With experience, and the conditions above, I think they can. One of the ways I think it works is by helping teams break down work into small pieces which flow. As a team get better I would expect the effort estimation to exhibit a very tight distribution. When this happens then simply counting the number of card (tasks, stories, whatever the thing you are estimating is) will have about the same information value for a fraction of the cost.

(For example, suppose a team normally do 45 points of work per iteration, if the teams average size estimate is 5 with a standard deviation of 0.5 then they would be expected to accept 9 pieces of work per iteration. If these statistics are stable then estimation works. But at this point simply taking in 9 pieces of work would also prove a reliable guide.)

So:

  1. Effort estimation doesn’t work for immature teams because they don’t exhibit the conditions above
  2. Effort estimation does work for mature teams but
  3. Effort estimation is pointless for very mature teams

Even given all this I think estimation is a worthwhile activity for teams of type 1 and 2 because it has other benefits.

One benefit is that is promotes discussion - or at least it should. Another is that it forms part of a design activity that helps teams make pieces of work smaller.

But there is another reason I want teams to do it: Credibility.

Estimation is so enshrined in the way many businesses work that teams and those trying to introduce change/agile risk undermining their own credibility if they remove estimation early. And I don’t just mean credibility with “the business” I think many developers also expect estimation and if asked to adopt a process without it will be skeptical.

So its just possible that estimation as we knowing - planning poker, velocity and such - is a placebo. It doesn’t actually help many teams but it helps people feel they are doing something right. In time they may find the placebo actually works or they may find they don’t need it.

Another reason why I like developers to think about “how long will the take” is that I believe it helps them set their own deadline. It helps them focus their own work.

Thus I keep advocating estimates because I think they are useful to the team, the fact that you might be able to tell when something might be “done” is a side effect. Since I find long range estimates questionable I advocate a cheap approach which might be usefulness or might just be a placebo.

However, I do believe, that given the right conditions teams can estimate accurately, and can deliver to those estimates. Increasing I believe very few organizations can provide those conditions to their teams.

Tuesday, September 23, 2014

#AOSW - Agile Outside of Software - starts here

We had the Agile on the Beach conference a couple of weeks. In a word: Brilliant - just look at the photos and see how people enjoyed themselves.

OK, I’m biased, I’m one of the organisers, but many people told me it was brilliant or they just didn’t want to hurt my feelings.

There is much I could write about Agile on the Beach but I don’t have enough time. Plus right now I want to focus on just one thing that came out of the conference:

Agile Outside of Software - #AOSW

Just before the conference I published a blog version of my talk to the conference (Agile Outside of Software the blog) and now the slides are online (Agile Outside of Software the SlideShare). Well between the post and the presentation, Agile Outside of Software turned out to be a hot topic.

And it wasn’t just me:

  • Belinda Weldlock talked about using Agile outside of software to help various Cornish companies: toy companies, florists and others. Her talk is available on YouTube.
  • Belinda also had a video made by Oxford Innovation about Agile in Cornwall: this started with the Cornish Software Mines Agile Programme that I was involved with four years ago. Oxford Innovation have built on that legacy.
  • Sabina Renshof from The Netherlands also spoke to me about how she had used Agile with various non-software teams
  • Rachel Picken gave a presentation on her use of Agile in a Public Relations company.

One of the points I made was: There is good evidence to think Agile does work outside of software but we lack case studies. I have a few:

  • I my own case study from GSMA (writing a specification document with a dispersed team)
  • The use of Agile at my client Sullivan Cuff software for everything! Software development, sales, support and well, everything!
  • I highlighted case studies from previous Agile on the Beach conferences (Kate Sullivan at Lonely Planet and Martin Rowe at Petroc college.)
  • And I discussed the 2007 case study of Shamrock Foods from MIT Sloan Management Review.

(After the conference I discovered this small book which I’ve only just started reading: “Scrum Marketing: Applying Agile Methodologies to Marketing”.)

But we need more.

So Sabina came up with the great idea that we start a collection. And I think we should.

It starts here, right now with the Twitter hashtag #AOSW - well actually, this hashtag was coined at the conference, I’m just a little late announcing it on my blog.

Right now we’ve not worked out how we are going to do this - my guess is a wiki or a LeanPub collection - but right now, if you know of a case study - documented or not - please share:

  • leave a comment on this blog
  • Tweet with the #AOSW hashtag
  • E-mail myself or Sabina

Lets get collecting.

Right now, if you want to know more I’m repeating my Agile Outside of Software talk on 3rd November I’m giving the talk again BCS Bristol “Beyond Software”.