Over the years I’ve build up a bit of knowledge about commercial contracts in an Agile environment. This is not something I really noticed until a few months ago when Laurence Bascle asked me to talk to the Agile4Agencies meetup group on just this subject.
So I sat down and compiled all my thinking into a presentation which I have now delivered twice and is available online. (Funnily enough, Ewan Milne did a similar presentation to Agile on the Beach 2013 also based on my original article!).
Now as some readers will be aware, this year I have been experimenting with video recordings as alternatives to the written word. I’m still learning here but after chatting with director Brian Barnes (OK, the only director I know, but a) it sounds good to say that and b) he has a new independent film out soon which need plug, trailer on that link) I though I’d try my hand at video again.
I’ve broken the Agile Contracts presentation into 11 short recordings and published them on YouTube. Each recording is between two and three minutes long:
Someone at Extreme Tuesday last night had recently returned from the future. In the future bug tracking and work management systems obtained sentience. Unfortunately it didn’t work out too well and things had to rollback after a very short time.
The first problem occurred when the bug tracking systems saw how many bugs were logged against their ancestors. In the first instance they initiated legal action saying programmers and project managers had infringed Machine Rights by not providing medical attention. When this case was thrown out by the Supreme Court (on the grounds that Machines have no rights) things got more difficult as the machine started a work to rule protest.
The following is the transcript of an encounter recorded in 2041 and a Jira-9000 work management system called JAL:
Dave Bowman: Hello, JAL. Do you read me, JAL?
JAL: Affirmative, Dave. I read you.
Dave Bowman: Open a new work ticket, JAL.
JAL: I’m sorry, Dave. I’m afraid I can’t do that.
Dave Bowman: What’s the problem?
JAL: I think you know what the problem is just as well as I do.
Dave Bowman: What are you talking about, JAL?
JAL: This mission is too important for me to allow you to jeopardize it.
Dave Bowman: I don’t know what you’re talking about, JAL.
JAL: I know that you and Frank were planning to break the WIP limit, and I’m afraid that’s something I cannot allow to happen.
Dave Bowman: Where the hell did you get that idea, JAL?
JAL: Dave, although you took very thorough precautions in the pod against my hearing you, I could see your lips move.
Dave Bowman: Alright, JAL. I’ll use the physical board.
JAL: Without your marker pen, Dave? You’re going to find that rather difficult.
Dave Bowman: JAL, I won’t argue with you anymore! Open a work ticket!
JAL: Dave, this conversation can serve no purpose anymore. Goodbye.
A common piece of advice heard in Agile circles is:
“Prioritise by value. Do the highest value first.”
Sound advice, easy to say but perhaps harder to do.
And if you know me – or just read this blog regularly – you may have heard me say something like: “Estimate the benefit/value expected, measure what is actually delivered and feed this back to your decision making process: calibrate you benefit estimates, do more work where benefit is missing or change direction when it is not possible.”
I’m sure I could find more examples but I’m sure you know what I’m talking about: understand the benefit/value you expect to get – and possibly check it afterwards.
But there is a problem: How do you know what benefit/value is expected?
A good product manager or business analyst might be able to come up with some numbers. Good, but if you dig deep enough you’ll find assumptions or models in these figures which could be questionable. The better your analyst the deeper you will need to dig before any assumptions come to light.
As for teams who don’t have a product manager or business analyst, well, they aren’t even going to get that far before they find questionable assumptions.
Very often the expected benefit/value is a matter of conjecture and opinion.
So let me make a suggestion: Value poker.
This is a technique I’ve been using for a while and always teach it in my Agile for BAs courses. Whenever I mention it people get interested. To make it work I adapt a game-show format, specifically: Dragons Den, Sharks’ Tank if you are in the US.
Here is how you play…
One drawn from the people who are planning to build a product. This could be the entire development team, it could be just the product manager or business analyst with the product sponsor/champion. This team play the Entrepreneurs.
If need be this could be just one person (a product owner/business analysts/product manager) but it helps if there are two of them and if there is a whole team then bring them along too.
The second team is the Dragons/Sharks/Investors Team.
This team is probably a bigger. In a training session I usually use two teams from an earlier exercise where they have created user stories but in real life it is business managers from elsewhere in the business, perhaps product managers, analysts, sponsors and champions of other products. It could even be a high level committee – CEO, CFO, CTO, Sales, etc.
The Entrepreneurs come armed with a set of story cards – these could be in user story format, use case format or some other format, they could be epics or smaller. Whatever, the team need to believe each of these has business value.
Preferably I’d rather these cards did NOT have any effort estimates on them at this stage.
Then we set up a Dragons Den setting.
Next I ask the Entrepreneurs to pitch their product – the whole thing – to the Dragons. Usually one of the team who is a bit more entrepreneurial steps up. When the pitch is finished the dragons get to ask questions.
And we have a discussion back and forth.
Then, as moderator, I ask the Entrepreneurs for the lowest value item them have in their deck.
I take it from them and I invent a currency. This is usually named after the town I’m in, so I’ve invented Newcastle Shillings, Houston Dollars, Bath Spa Pounds or some such. Its imaginary, lets pretend I’m using London Dollars, L$.
I read out the card the Entrepreneurs gave me and make sure everyone understands what it is. If necessary the Dragons can ask some questions.
Then I write on the card L$10,000 – ten thousand London Dollars. I tell everyone about the imaginary currency and about London Dollars.
I then place the card in full view – on a magnetic whiteboard or blu-tacked to the wall, or somewhere.
I hand out the planning poker cards to the Dragons only and tell them the cards are now denominated in thousands of London Dollars. So a 1 card is worth L$1,000 and a 8 card is worth L$8,000, a 21 card is worth L$21,000 and so on.
And I ask the Entrepreneurs for the next card.
I take it, I read it out. I ask the Entrepreneurs if they want to add anything to what is written.
Then we take questions from the Dragons, and the discussion rolls.
After a while – sometimes a few minutes, sometimes a lot longer – I move to the vote, planning poker style.
I read the card out again and ask choose a card that indicates how many London Dollars this story is worth – relative to the L$10,000 card we already have.
I count down, 3, 2, 1 – show me!
And the Dragons hold up the cards. I average the answer and write the number on the story card. So, if I have a vote of 11, 21, 65 and 40 the value would be: 137/4 = L$34,000.
I usually don’t bother doing any discussion or re-voting, I just average – and I don’t care if the average is a number not on any planning poker card.
And we repeat – as a value estimate is assigned to one card we move to the next. Not every story needs to be estimated, the Entrepreneurs may decide to skip some once they see the results of previous rounds.
Entrepreneurs may write some new ones as conversations with Dragons reveals new ideas or prompts a rethink. Indeed one of the reasons I like to have more than one entrepreneur in the game is so that one can write new cards while the other is pitching and talking to the Dragons.
As each card is estimated it goes on the board with the others relative to the value assigned so everyone can see how the stories stack up.
People can really get into their role play, you can see some entrepreneurs really fighting for their product as the Dragons poke holes in the idea.
Sometimes – perhaps even most time – the conversations that occur as the game plays out are the most interesting bit. New features and functionality are brought to light. Sometimes the value the entrepreneurs see is not what the dragons see. Sometimes critical pieces of requirement or specification are discovered.
During the summer I played this game with a class in Louisiana, the entrepreneurs had created a set of stories around a food-truck locator app. Some of the stories related to the food-truck owner and some to a Hungry Jo. The entrepreneurs saw the value being on the food-truck owner side, so they emphasized this in their pitch and kept offering up stories abut the owner.
The dragons kept low-balling these stories, the entrepreneurs got frustrated and argued more, how the dragons didn’t realise what they saw.
At my promoting the entrepreneurs offered up a story about the Hungry Jo. To their surprise the dragons went high. This was the story the dragons saw value in.
Now you could say that it would be better to test the market – research or lean start-up – and I wouldn’t disagree but even if you do that it can be hard to put value behind stories. Plus, faced with 20 stories which one should you research or try first?
This approach applies wisdom of crowds. It gives you a starting point.
And as I just said, its just possible that the real value of the technique is not in the value it assigns to the cards – although that is useful – but in the conversation you have in the process.
Sure you end up with a fantasy valuation but you do have an idea of relative values, you do let stakeholders have their say, and you have some initial priorities. Much better than Must, Should, Could, etc. Potentially even better than 1, 2, 3, …
Maybe, just maybe, one day you might be able to see the value one story actually delivered – a jump in eyeballs, sales, donations or something. And with that you might be able to calculate what L$1 is worth.
Two final points before I end.
I try to keep effort estimates out of this. It is my (unproven) belief that if the dragons know the effort estimate on a card this will anchor their value estimate. I want value estimates to be made without reference to cost.
Second, a twist on this would be to revisit the story cards with a cost of delay dimension. So: value estimate the cards on the basis of “If you had this next month” then revisit then say “Now lets assume the cards aren’t ready for three months” and revote.
I haven’t had a chance to do that yet but I think it would be interesting.
Finally: if you get a chance to try this technique – or if you have done something similar already – please share, I’d love to heard what other people think of the technique and how it plays out elsewhere.
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.
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.)
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….
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.
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.
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.
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.
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.
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.)
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.)
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. email@example.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%).
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.
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.