Rant on.

In software terms quality does not mean walnut dashboards, it does not mean gold plating, it does not mean polishing to perfection. These things may happen in a development team but they should not.

However you define quality for a piece of software I bet it has no place for “bugs.” In fact, I bet anyone who has actually written a definition of “what is software quality” included something like “Few or no bugs.”

What ever else “software quality” means it does mean producing largely bug-free code. The best performing teams can deliver on this. They may not be entirely bug free but they can be largely bug free.

When bugs are present, when quality is compromised, bugs appear. Customers are unhappy – they may loose money or terminate contracts. Or they may keep calling your support desk.

Bugs destroy predictability because they can appear at anytime and demand fixing.

Bugs destroy productivity because they disrupt work and take time to fix for little apparent gain.

Bugs destroy any hope of meeting schedules because nobody knows when the bug finding and fixing will be done.

Bugs and poor code quality hinder future work because developers find themselves battling past problems.

Compare this with developers who always work on new code, those who start with a new sheet each time, those who carry none of yesterday’s baggage. Developers who work on fresh prototypes will always look better than those who work on a legacy.

Bugs make it difficult, if not impossible, to have a rational conversation about “what to build next” because there are bugs to fix. Bugs discussions don’t add value because bugs don’t add value. The only value fixing a bug adds is putting value back that was missing in the first place.

Bugs make it difficult – no, impossible! – to have a rational conversation about delivery dates too because nobody believes the dates will be met.

And when you have lots of bugs developer, testers, requirements engineers and, most of all, managers, forget how to do their real jobs because so much of their time is taken up with bug conversations.

Yet techniques for combatting bugs do exist and are used by the best companies.

Code reviews are one of the most powerful techniques for removing bugs but when used in a low trust environment with confrontation they can descend into school yard bullying.

Test Driven Development (TDD) is an extremely powerful technique, one team at Microsoft recorded a 91% reduction in bugs. While many developers are now aware of TDD few actually practice it, and many of those who do practices it erratically or without real understanding.

To embed TDD in the culture required support: specifically technical coaching. This approach also helps address hidden skills deficiencies, e.g. poor use of object-oriented techniques. Technical coaching is expensive simply because it is one-on-one with developers.

Look, I happen to think TDD – and by extension cousin BDD – work. I know not everyone agrees with this, that is your right. I just ask: if you don’t believe TDD will help, what do you suggest? – just add your suggestion in the comments below.

A third technique is pair programming, while controversial and instinctively disliked by many programmers but can be highly productive.

These are not the only techniques. There are other, often complementary, techniques available – see my old “Things to do to improve code quality” blog.

I hate bugs but there is something I hate more than bugs: the attitude that tolerates bugs as “a fact of life, something that will always be, something we can’t do anything about.”

I don’t hate people who think they can create software quicker by tolerating bugs. I don’t hate them because they aren’t worth hating. They shouldn’t be in the industry. Quality software, few bugs, makes for shorter delivery cycles, lower costs and happier customers.

The attitude “Low quality is faster and cheaper” has no place in our industry. Anyone who believes this doesn’t deserve to work in the software industry.

One of the big problems I see with the software industry is that so many people have stopped aspiring to do anything better. The philosopher Aristotle is reported to have said: “Our problem is not that we aim to high and miss, but that we aim too low and hit”.

Most of all I hate the attitude that aims low with bugs and code quality.

Rant off.

(If you want a longer, more rational, discussion on how to deal with bugs have a look at the draft “Bug Management Strategies” chapter (PDF) for Xanpan book 2 which is available from my website. See also the appendix in Xanpan book 1.)

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?

A “execution of thousand Story Points” – wow, thats erh… big? small? (What is the Right Size for a Story)

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

Wow!

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.”)

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.

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.

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.

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.

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.

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

I’m looking for some guinea pigs….

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

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

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

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

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

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

Interested?

Call me or mail me – contact details here.