Monday, January 12, 2015

"We can do it!" - Problems at Philips?

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.

Of course I thought of W. Edwards Demming and principle 10:

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

Anyone from Philips care of offer insights?

Friday, January 02, 2015

2015 - not a new year resolution: a message for conference producers

2015 is here. Happy New Year!

I don’t really go in for new years resolutions but if I did it would be the same one I have had for the last two years: Go to fewer conferences.

In 2014 I went to 10 conference, and spoke at 9 of them.

Which is an improvement on 2013 when I attended 12 and spoke at 11 - although I ran a workshop at the twelfth.

The first call for papers of the year is already in my mailbox - BCS SPA - and I’m going to ignore it. Not because it isn’t a good conference but because I have to start somewhere.

I already have two conferences in the diary for 2015 - NorDevCon in February and DevWeek in March. And I’ll probably speak at Agile on the Beach and attend EuroPLoP so that is four already.

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

Monday, December 22, 2014

Dyslexia makes me stronger: Is Agile dyslexic?

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.

And third…

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.

Monday, December 15, 2014

Agile Contracts - a video mini-series

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.

Laurence’s interest came from a piece I published in InfoQ a few years back - Agile Contract Options - but more recently I published “Dear Customer, the truth about IT projects” in the Agile Journal (which later became Agile Connection). Dear Customer has become something of an ever-green, I use it as a prologue in Xanpan and it regularly gets rediscovered and Tweeted about.

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:

I’d love to have feedback and comments, just e-mail me as usual. Really my question is: should I try this format again?

Wednesday, December 10, 2014

Jira9000 - the future of electronic work management

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.

Monday, December 08, 2014

#NoProjects / #BeyondProjects in InfoQ

InfoQ recently published my piece entitled “No Projects / Beyond Projects”, of course regular readers will know it should be titled “#NoProjects/#BeyondProjects.”

Read it for yourself and let me know what you think.

Wednesday, December 03, 2014

Estimating business value: adding Value poker and Dragons Den to the Agile toolkit

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.

Easy really.

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…

Two teams.

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.

ValuePokerDen-2014-12-3-21-27.png

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.

ValuePokerCardLight-2014-12-3-21-27.jpg

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

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.