When I say changes, I’m not saying anything about changes to the sheets themselves. I mean I’ve been thinking about how I make the sheets available and I’m going to make two changes.
Firstly, I’m going to remove the print-on-demand service for the sheets. Second, I’m going to remove the need to register before downloading a sheet. You can still find all the sheets at DialogueSheets.com just now they will be a little harder to get and a little easier to get.
Now I’d like to explain why I’m making these changes.
I’ve always felt I needed to offer people the option to get printed sheets, hence the print on demand service. However, not many people use the service. I might have once thought I could make a little money off the service but I long ago gave up any dreams, it doesn’t get used enough to make me rich!
It seems most people either have large printers or get the sheets printed by their local print shop – I use Kall-Kwik myself.
To complicate matters, when it does make me a little money, the company which provides the service (Mimeo) send me a cheque. Or rather a check, against a US bank in US dollars. Since the sums are small the cheques cost more to cash then they are worth. This is a shame because when Lulu or LeanPub send me money – in dollars – they use PayPal which I can access easily.
Add to this the complexities of keeping the print-on-demand shop up to date and its just not worth it.
Second, the need to register.
When I first made the sheets available I really wanted feedback on who was using them, how they found them and so on. In the early days I would e-mail people and ask “What was your experience?”
That was like getting blood out of a stone. Very few people replied. Those who did gave me very useful feedback which allowed me to adjust the sheets and made me feel good.
Since then there have been too many downloads to go ask for feedback – O, I could mail a few people but that requires work. Right now there have been over 1,300 registration in the last two years, and I known there were several thousand before then.
In the meantime a few people considered my request to register an imposition, I’ve had a couple of people tell me to my face. All I wanted was feedback but this put people off. I have on occasions given dialogue sheets away – they are part of the package when you buy a course of me but I also regularly give spare sheets away after conference presentations. When I do so I ask – no beg – people to send me feedback, but they rarely – no never – do.
I remember a man from the BBC who took a spare sheet at Agile Cambridge. He promised to send me feedback on what his team thought. I never heard from him again. I guess it went in the bin.
Maybe I’m a little bitter but actually, the point I’m trying to make is: its hard to get feedback!
I once planned to send a newsletter to everyone. But I never got around to it.
As most readers will have worked out, I’m not a fan of Scrum Masters. Partly this is because I find it a very mixed up role to start with (see my “Hard Core Scrum” post), partly because the way individuals and organizations choose to interpret the role is so variable the title is meaningless but mostly because the Scrum Master certificate is not, despite its name, adequate to prepare people to be a Scrum Master. The certificate itself has problems, these problems infect the role.
Still, more and more people are getting jobs as Scrum Masters. And this doesn’t look good to me.
A few weeks before Christmas, out of the blue, an e-mail from a recruitment agency appeared in my mailbox. This Reading based company used to have a good reputation, then it got bought, the main man jumped and the company changed its name to something exceedingly stupid.
In the e-mail the recruiter – whom I don’t know and have never met – extolled the virtues of Dr R. An exceptional Scrum Master, and whose CV was attached to the e-mail. What kind of agent is this who spams people someones CV? Anyway, its an insight into what Scrum Masters feel they need to put on their CV to get a job.
(Dr R, if your reading, this isn’t about you. Given recruitment system you are within you did your best, it’s the employees and agents that made you do this. Except I recommend you choose your agents with more care next time.)
Lets look at some excepts from the CV:
“I am a highly motivated and experienced techno-functional Lead Scrum Master. I am responsible for the deployment of Agile methodology in four different multi-site projects.”
What is “techno-functional” ?
What is a “Lead Scrum Master” ?
And what has happened to the self-organization and servant leadership we read about in Scrum books? This guy is responsible, not the team, him.
Move on to his last job – in a notorious *Staines office:
“Agile Release and Sprint planning and execution of thousand (sic) Story Points (SP) involving ten developers, five testers, project manager, product owner, business analyst and test manager.”
Sounds like the Scrum Master did the planning, shouldn’t he have facilitated the planning?
10 devs and 5 test, that sounds like a quality problem, maybe he’ll say something about how he managed that – erh… no he doesn’t!
And obviously as a Scrum Master he failed to remove management, he’s got a project manager and a test manager. Sounds awful.
“Deployment of Agile methodology from the basic to remote Scrum team management. Established Mingle Agile tool and trained Scrum teams to use Mingle. Integrated Scrum Board and Mingle in a single view. Implemented best Agile practices including Avatar and Scrum Weather Report. Working along with release and delivery team, I delivered many E2E solutions.”
“Deployed Agile Methodology” ??? How does one deploy Agile? And what about “Scrum is not a methodology, Scrum is a framework” ?
I’ve never heard of “Avatar” or “Scrum Weather Report” – anyone know what these are? – maybe I’m at fault here.
And again, “I delivered many E2E solutions” – no servant leader here!
“Conducted retrospectives and implemented many improvements e.g. accountability and visibility of Scrum activities. Early risk identification and solutions: shortage of resources, technical complexity (merge and migration, BI), test environment (time travel) and release bus alignment.”
Time travel? Does he really say “Time Travel?” – hire this guy now! Our schedule slippages are over!
So much of that bullet would fit in well on a Project Manager CV.
“Implementing Continues [sic] Integration and Testing, and prototyping Test Driven Development (TDD) and Test Automation.
How does one prototype TDD? If he only prototypes it what was achieved? And did he solve the quality problem?
“Successfully implemented an unplanned Change Request (35 SP) as a part of final sprint.”
Right, now, this gets serious. Sounds like he doesn’t approve of unplanned change requests, or at least they were a big deal (35 story points – yoh!) but if you really have CI, TDD and Test automation in place this is easy. Isn’t the whole point of Agile to embrace change?
Now the funny bit:
“Maintained an average Velocity of hundred (sic) over eight Sprints.”
Go team Staines! – that is fantastic, did they pay you in Roubles too?
What happened to Scrum Commitment? Velocity is so XP.
And how long are your Sprints?
I wonder how long this guy will take to travel from Staines to say, Edinburgh? Thats what, 400 miles.
“Member and contributing to Scrum of Scrums, Agile Community of Practice, and Agile Centre of Excellence.”
Gee, if he is in the Agile Centre of Excellence they have real problems.
There is more but its drivel, lets look at some claims from earlier in his career.
As a Senior Scrum Master he:
“Defined Sprint Zero Definition of Done and implemented it across eight different Agile product developments”
Leave aside the fact that many think Sprint Zero is a defective working practice all by itself should it be defined by one man? Maybe he is taking credit for a team, where is the servant-leadership there?
Later on he states:
“Interface with venders, Business Process Owners and off-shore development teams, followed though the Service Level Agreement to maintain the software quality and acceptance criteria as a part of product management”
I’m sure he did, and I’m sure he was good. But is this what a Scrum Master should be doing? This sounds like Project Management while he says he was part of Product Management. Proof – if it was needed – that the Scrum Master role is confused.
There is more like this. It’s not the best CV I’ve ever seen but what interests me more is two things.
Firstly it shows what he believe employees want from a Scrum Master. There is nothing in this CV about servant leadership, self-organizing teams, facilitation, talking to team members and other soft skills. There is a lot about managing and administering. Clearly from his experience when an employee hires a Scrum Master they expect a project manager. In other words, it shows how completely messed up the Scrum Master role is.
Second this CV shows how some agile techniques have become tick list items. Story points. Sprint Zero, Definition of Done.
Finally, let me say, if I had to write a CV today I’d probably make just as many mistakes and offer just as many hostages to fortune. Really this is a comment on just how bad recruitment practices in IT are and how bad the CV is at communicating what you do.
(*According to the London rumour mill, a few years ago Thoughtworks pulled out of a project at this company because they couldn’t see any possibility of success. Another Agile Coach/Scrum Master was told at their 3 month review “You are unusual, most people are depressed after 3 months here.”)
This morning I drove past the Philips UK head office, thats Philips the Dutch medical devices company with a sideline in consumer electrics. Because it is January it is dark outside, and the lights were on in the Philips office. (I guess hard working, committed, staff were already at their desks.) This combination of lighting meant that as I sat in the slow moving A3 traffic I could see inside the office and I could see the big banner draped across the inside saying:
“We can do it!”
Now I honestly don’t know what the story is with that banner, it could be a charity fund raising event or anything but my mind immediately invented a story – thats what minds do.
This looked like an exhortation. Management – who sincerely believe in the power of individuals were endeavouring to enthuse the staff to do something – build a new product, turn the division around, deliver on schedule or some such.
“Eliminate slogans, exhortations, and targets for the work force asking for zero defects and new levels of productivity. Such exhortations only create adversarial relationships, as the bulk of the causes of low quality and low productivity belong to the system and thus lie beyond the power of the work force.”
Here we have managers who like me believe that people, the quality, enthusiasm and energy of individuals – and teams! – make all the difference. So why not enthuse them?
But I, and perhaps these managers also believe Demming: the system is 98% of performance.
Its a contradiction I’ve blogged about before (People or the System?) but seeing that banner really made it seem real. Perhaps its because I recently heard that Philips was installing SAFe throughout the company, they have even told their Agile Coaches that they can only continue working with Philips if they are SAFe accredited.
So which is it? – The people, or the system?
Will SAFe save you?
Or will a “Yes we can!” style banner?
So while I agree with most of what Demming has written, and while I think the design of the system contributes an awful lot to the performance of people in the system I’ve come to the conclusion: its complicated, and saying “98% of performance is the system” is a vast generalisation. It may be true in some environments, but it only makes sense if the people in the system have no control over the system. In software development the works have a lot of control over the system, whether they believe it or not.
Still, I find it hard to believe any of the problems Philips faces will be solved with a Bob the Builder style banner. Rather, if this banner is the work of managers who think such a exhortations might have a positive effect then I suspect Philips has problems far more serious than any banner could ever solve.
Of course, I actually nothing about this banner or why Philips have it hanging in the office, but I do have an active imagination.
(Plus some local/user group events, I count them separately.)
So, if you are a conference organiser/producer and you would like me to speak at your conference the best way of getting me is: ask me directly. Part of the reason for cutting down on conferences is to cut down on the time it takes to complete call for paper submissions.
(Organisers of local groups and user groups always ask directly and I almost always say yes. In fact I often prefer these events to conferences.)
Right: now I’ve gone public with this “not a resolution” I hope I’ll have a better chance of keeping it.
I’m signing off from 2014 with a rather personal blog post, perhaps my most personal ever, that also means it is a little long, sorry about this, Happy Christmas, please leave all the comments you wish…
Have you ever read, or seen, Macbeth? Towards the end of the play he is battling MacDuff, but Macbeth is convinced he will win because the witches told him “No man born of woman can harm Macbeth” and obviously MacDuff is a man born of woman isn’t he?
Except, MacDuff was torn from his mothers womb, what we call a caesarian birth these days. MacDuff is not like other men, not necessarily better or worse, just different, and that difference means he can kill Macbeth, which he does.
I feel like that about my dyslexia. OK, when I’m feeling arrogant I might actually feel it makes me superior but most of the time just different.
(Regular readers won’t be surprised to learn this, they’ve put up with my misspellings, poor grammar and abusive treatment of the English language for years!)
I’m not a professional dyslexic, I rarely mention it, I’m just a professional who happens to be dyslexic. Beth Anders-Beck widely circulated post earlier this year got me thinking about this again. And a few weeks ago I attended a meeting at my son’s schools about dyslexia that me reminded of the advantages I think dyslexia has given me. (I was probably the only parent in the room hoping his child had dyslexia.)
Dyslexia does mean I learned things differently. Like MacDuff, my difference might not be obvious but it is there.
I spent four years outside of mainstream schools, mostly in two different special schools.
I learned to read three times. Really, I had to learn to read English three times in three different ways.
But I think all of this made me stronger.
Depending on who you read dyslexics think more holistically, what we might call “systems thinking”, dyslexics are more creative, dyslexics are more lateral thinkers, dyslexics are more visual. Not everyone – there are different forms of dyslexia – but some people in some ways.
So what has this to do with Agile?
Well, it strikes me that many of the things we do in Agile software development parallel the way I was taught by specialist teachers and the ways I found to overcome my dyslexia.
For example: Dyslexics are usually more visual thinkers than average. In Agile we use the “visual management techniques” such as task boards, physical cards and progress graphs to track our work. In my special schools we used lots of illustrations, I remember constructing a giant “bed” to help me remember b and d.
When I was learning to spell one of my teachers gave us difficult spellings “Blue Meanies” and “Green Meanies” (yes, she was a Beatles fan) on pieces of card. And now I colour code work on team boards – see my full description in Blue-White-Red or Xanpan.
Dyslexics aren’t do good with the written word – although I’m not one of those who see the letters swirling around – and so we prefer verbal and visual communication. Doesn’t that sound familiar? – stand up meetings and “placeholders for a conversation.”
Dyslexics have learning problems centred on symbols there are some who think that before the written word, before the printing press, dyslexics gave their communities and advantage. Sure writing a program involves manipulating symbols but its more about thinking, perhaps abstractly, perhaps holistically, when I’m programming objects I see the objects in my mind, I see them fitting together.
I could go on but I think you get the point.
Here is my first point: many of the techniques which help dyslexics have parallels in the way we do Agile software development.
In the same way that I approach learning – specifically reading and writing – differently to most of the population I increasingly see my approach to organizing and managing software development differently to most of the population. After all, as I have long argued, software development is a learning exercise.
Which brings us to point two.
What is good for dyslexics is usually good for non-dyslexics too. Techniques and changes which help dyslexics actually help non-dyslexics too. Dyslexics have difficulty when presented with teaching techniques that work for the majority of the population but the reverse is not true. Teaching techniques which are good for dyslexics are good – perhaps better – for the majority of the population.
When I first encountered the techniques which are now called “Agile” it was on challenged development efforts. Those of us undertaking the work found a better ways of working, the standard approaches weren’t effective; but the techniques we found happen to work well for the vast majority of development work.
To be clear: Techniques which help troubled development work happen more effectively actually help all development work – troubled or not.
I think one of the ways these techniques work is by lowering the cognitive load we all experience. When the load is lowered we can focus more clearly. A physical task board needs very little mental processing. Traditional status reports are pretty meaningless to me.
With a Blue Meanie spelling there was no question about what word you had to learn. It was written on a small piece of card. Cognitive load was lowered.
One of the ways dyslexics learn to cope is by developing their own learning strategies.
When a non-dyslexic person goes to school they learn like everyone else. They learn the same techniques as everyone else. They are given the learning strategies.
Most of these strategies don’t work for dyslexics. When a dyslexic person goes to school they need to learn how to learn. They need to find and invent their own learning strategies and they need to learn to improve their own learning experience. Unfortunately many dyslexics fail at this step and have reading and writing problems throughout their life. But those who master these issues can be very successful.
Think about this in a work context: if you work somewhere where everything works then great, it works.
But if you work somewhere where things are difficult and you need to come up with a new strategy, a new approach, well, how much practice have you had?
I’ve been practicing since I was six.
In fact dyslexic people can be so good at this that they over compensate. For example many of my closest friends and family consider me a very organised person. I don’t. I think I am a very disorganised person – my form of dyslexia means I have a poor short term memory. In addressing this problem I over compensate, the strategies I have come up with for overcoming my disorganisation make me far more organised than many others. (One way is to over use my long term memory).
The thing is: software development and dyslexia are all about learning.
Software development is all about learning – we learn about technology, we learn about the domain we are working in and we learn about the process. Software development is best done when done in a learning organization environment. (Remember, I wrote a book on this).
If you believe writers like Arie de Geus this is true of all business: “We understand that the only competitive advantage the company of the future will have is its managers’ ability to learn faster than then their competitors.”
In my experience, most organizations are poor at learning. I have heard it said that: “Companies suffer from dyslexia.” Only someone who doesn’t appreciate the advantages of dyslexic might say that. Companies may well have from a collection of learning approaches which kind of work most of the time for most of the people, techniques that have been handed down without much thought. But those learning techniques are the problem.
Many companies do suffer from learning disabilities but they don’t suffer from dyslexia. What these companies need is a good dose of dyslexia to help them get better. They need to learn to learn. They need new learning strategies.
Right now the closest thing we have to dyslexia and new learning strategies for companies are some Theory-Y ideas of which Agile and Beyond Budgeting are the most prominent.
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.