Thoughts on 6-Sigma and Agile

Question that comes up from time to time:

“Does anyone have Agile project which is Six Sigma? How these two things Six Sigma and Agile complement each other on software product development project? “

My answer:

In theory Agile and 6-Sigma should fit, they both have their roots in the quality movement.

A cursory glance at the 6-Sigma toolset reveals similarities to the Lean toolkit – continuous improvement, root course analysis, statistical methods, so at first it looks good but…

While there are a few stories of Agile and 6-Sigma working successfully together my own experience, and the majority of the stories I hear are that they are contrary.

Let me briefly share my experience….

I did some work with a financial services company which was a big believer in 6-Sigma. Any change had to be set up as a 6-Sigma change, with a business objective, current status measurement, target, approach, etc. Its difficult to argue with such a rational position but it was hard to pull all these bits together.

The change then needed to be signed off by more senior managers as a 6-Sigma effort. And it was hard to get the necessary managers in the same room at the same time. Which meant efforts didn’t get signed off.

And with all this effort you needed to put a lot of effort into any change which meant even thinking about change was expensive.

The net effect was to freeze the status quo. Six-Sigma had the effect of preventing change not supporting it.

On a day to day level the attention paid to variance was highly detrimental. Teams adopted behaviours designed to minimize variance (e.g. differences between estimated effort and actual effort) which both made measurements unreliable and made people wary of any change, experimentation or risk. (They had bonuses related to variance reduction.)

It seems there are some big difference between 6-Sigma and Agile, if not in intent then in implementation:

  • 6-Sigma is very top down, Agile is traditionally bottom up (although this is changing)
  • 6-Sigma is process and plan driven, 6-Sigma demands evidence; Agile is more “experiment and see what happens”, in other words Agile is happier with failed experiments
  • 6-Sigma demands study from its devotees (all those belts!) while Agile benefits from study it is a free-for-all when it comes to what to do (this may well be a disadvantage)
  • 6-Sigma anoints experts (black belts) while Agile is much more egalitarian (or at least should be)

So while Agile and 6-Sigma may have somethings in common they are culturally incompatible.

And as for the newer mutant form of 6-Sigma known as “Lean 6-Sigma”, well let me quote something I heard Dave Snowden say at a conference a couple of years back:

“Lean 6-Sigma is about removing all the waste that 6-Sigma introduces.”

Requirements, Customers and a new Dialogue Sheet

I’ve written many many times in this blog about Dialogue Sheets. On the whole I offer dialogue sheets as a retrospective technique. However they have other applications, for example:

  • The Agile Discussion sheet serves to help teams decide what Agile practices they wish to adopt. I use this to close training sessions and I’ve seen teams move straight from training into using some of these practices. I credit this sheet with some of this success (Oh, and my brilliant training course of course, plug plug.)
  • The Planning Meeting sheet helps guide teams new to Agile planning meeting through the planning process.

I’ve long believed Dialogue Sheets can help on the requirements side too but until recently I’ve not had a chance to try this. Now I have.

Last month the Victoria Wiggins and Rosie Curran at offered one of their teams as guinea pigs to try a new sheet. The session went well, the team had about 2 hours of discussion and they even provided lunch. Thank you very much!

After observing the team discussion around this sheet I’ve made a number of modifications. Primarily I decided to focus the sheet on the customer question, i.e. who are you customers? and what are their problems?

I now offer this sheet for free download. The Customers sheet is available on the Dialogue Sheets pages.

Now the catch: I still consider this sheet to be in beta test. I really really really would appreciate some feedback on the sheet – please please please. If you try the sheet please let me know how it goes – for better or worse.

Until recently I had all the sheets behind a registration page. This allowed me to known who was downloading the sheets and in the past I occasionally e-mailed people to find out about their experiences. I got feedback.

But I also got feedback from people who said they didn’t like putting their e-mail address into a system. So I removed the registration process. Now I have no feedback.

I find it very ironic that despite all the talk of the importance of getting feedback (particularly in Agile circles) very few people offer feedback without prompting. Consider this your prompt.

Please, try the sheet, and please please, tell me what you think!

Common Agile objections

Last time (“Waterfall works when…”) I promised to discuss some of those common objections to “Agile.” (Actually, reading back this this post I’m struck by how like my “12 Myths of Agile Development” which was originally a blog post 2 years ago called “11 Agile Myths of 2 Truths”.)

(Apologies by the way, “Waterfall works when…” was misposted the first time, I’ve just fixed that.)

“Waterfall is most appropriate because our requirements are known and stable”

So what? Agile works brilliantly with stable requirements, it also works pretty well with changing requirements.

“Scope cannot be flexed”

See above.

If scope can’t be flexed than so be it, you will do it all. Scope is flexed all the time on traditional projects. No matter how much traditional projects say “scope is fixed” once they get near the end and no more money, people or time is available scope always flexes.

“We work on multiple projects at the same time”

And? Its all work to do. If you want a full discussion see Xanpan.

I think some of the Scrum texts talk about “dedicated” or “ring fenced” teams. I’ve never yet met a team that doesn’t have some baggage. As John Lennon might have said: “None project work is what happens to us while we are making plans.”

“The thing that is being built cannot be decomposed into smaller pieces”

Well have you tried to decompose it? – many teams jump to this assumption without trying to decompose it. Decomposing work is a skill, just because you tried once and it didn’t magically happen doesn’t mean it can’t be decomposed.

If you couldn’t did you ask for help? Did you ask someone (like myself!) to help? – breaking things down isn’t always easy, it might help to have some help.

What if you can’t break it down but your competitor does?

I believe almost everything can be broken down if you approach it right. And if you can’t break it down then perhaps it isn’t something that can be implemented in software.

“Agile works on greenfield projects but we have a legacy system.”


“Agile works on legacy systems but we are building something new.”

(Now I really am repeating myself – see “11 Agile Myths of 2 Truths”)

They both can’t be right? I’ve seen Agile work on both new and legacy development and I’ve heard both sides say “It won’t work because…”.

The grass is always greener on the other side.

“Our project finance model does not allow Agile”

So what? There is plenty you can do which has not finance implications.

Stop pointing at other people who stop you, do what you can and take one problem at a time.


Waterfall works when….

I frequently find myself in situations where someone says something like: “Waterfall is appropriate when…”

Some people out there think there are occasions when an Agile (mainly iterative) approach is “best’ and other occasions when “Waterfall” is “best”. Most of the time I let this line of argument go because its boring, I can’t be bothered arguing. (I’ll look at some of these common objections next time). Right now lets get something out in the open:

  • Before you make any decision on Waterfall or Agile define what you mean by “Agile” and “Waterfall”.
  • The decision to work Agile or Waterfall should not be based on which is more appropriate.
  • The decision on whether to work Agile or Waterfall should be a based on an examination of the business benefits.

Briefly, let me define “Agile” as working and delivering in short iterations and “Waterfall” as delivering in a single pre-planned event.

In cold hard cash the benefits to the business are:

  1. Agile working produces a far higher return on investment because benefits are delivered sooner.
  2. Agile reduces risk because risk is spread across many independent (consecutive) deliveries.
  3. Agile further reduces risk because failure can be identified sooner thereby saving money and time (Fail fast, fail cheap).

Without any other changes I can prove those improvements: they are objective. Using just mathematics without reference to any subjective opinion I can prove those three claims.

There are some other business benefits which are I can show logically although this opens the possibility that some will see these are subjective:

  1. Agile creates options for businesses and options have value (see Black-Scholes)
  2. Agile creates opportunities to incorporate feedback and incorporating feedback leads to better products
  3. Agile (when done properly) improves quality (fewer defects) and fewer software defects leads to short schedules (reduced time) in software development, shorter schedules leads to reduced costs

The question of “appropriateness” is an engineering concept based on the idea that one approach is better for the problem in hand than another. If instead we examine the problem from a business perspective it can be rephrased as:

“How can I maximise the return on investment from this work?”

Given that Agile delivers a greater return on investment than Waterfall surely Agile is the most appropriate method every-time?

Of course “which is better Agile or Waterfall?” has never been about cold rational arguments because as individuals, and as businesses, decisions are very rarely made in such rational terms, despite what one might hope or event claim.

Code and other reviews (a small piece of advice)

Many teams have some sort of very regular reviews. I’m not thinking personnel reviews or budget reviews, I’m thinking code reviews specifically but it could be test reviews, documentation reviews or some other. Reviews that need to happen every day but which frequently get delayed.

Lets stick with code reviews because they are the type I encounter most often.

Code reviews are good, by some accounts they the most effective means of removing bugs early – although I haven’t seen code reviews compared with TDD. But, code reviews loose their efficacy when they are not conducted promptly. The longer the period between the review being requested and the review being conducted (and by extension the review comments being acted on) the less effective the review.

The effect reduces because: a) the person who requested the review has moved onto something else, b) issues found in the review may be repeated until the review is conducted and c) the review will either inject a delay into the delivery process or the delivery will happen without the review in which case, what was the point?

So: if you are going to conduct reviews you want them to happen soon.

And it is not just the code and the developer who wrote it who have problems. The designated reviewer feels the pressure to “do reviews” when they have other – important! – work to do.

One team I know came up with a simple solution to this problem. I recently recommended the solution to another team who promptly adopted it and are delighted. One developer said: “I’ve never been so relaxed about reviews before.”

The solution is….

Make reviews the first item of work after the stand-up meeting in the morning. And let people do them before the stand-up too.

Thus, as soon as the stand-up is finished everyone undertakes any reviews which are needed before they start their day’s work. Review work is prioritised before new work: after all, yesterday the thing that now requires review was the priority, it is probably still the overall priority and the only thing standing between it and “done” is a review.

Reviews don’t typically take very long so today’s work isn’t delayed. And the recipient of the reviews comments can act on the comments before they get into today’s work.

Better still, knowing that reviews will happen right after the stand-up meeting means that it also makes sense to do the reviews BEFORE the stand-up meeting. This also addresses the question of “how do I usefully use the time before the stand-up meeting when I know I’ll have to stop doing whatever I start.”

So for example, imagine on Tuesday afternoon Bob asks Alice to review the code he has just finished. If Alice is available she might just do it there and then. But if she is busy she will wait. Now if she arrives at work at 9am and the stand-up is 9.30am she can get on with the review before the stand-up, if she finishes Bob will have his feedback and can act on it before 10am. If Alice doesn’t get to Bob’s code then she will do it at 9.45am when the meeting finishes.

Either way, Bob isn’t left waiting.

In part this works simply because it keeps the review queue short. If reviews are done soon, say within 24 hours, then the queue is never allowed to become too big and thus its easy to keep the queue short.

One of the teams actually put a column on their board where tasks awaiting review could rest. In the stand-up everyone could see what was waiting for review and arrange to do it.

Simple really.

While we are on the subject of code reviews let me comment on something else.

There is often a belief that only senior developers, or only “architects” should conduct reviews. I think this approach is mistaken for two reasons.

Firstly in this model it is normal that there are far fewer reviewers than there are review requesters. This frequently results in queues for reviews because the pool of reviewers – who also have other work to do – is small.

Second this model assumes that only “architects” can make useful comments on code. I believe most, say 80%, of the efficacy of a code review is the result not of having an expert review the code but simply the result of having another person review the code.

Indeed I even go as far as to say junior people should review senior people’s code. Code reviews are a two way learning process – one of the reasons I like to see them done face-to-face. If an experienced developer is writing code that a junior cannot understand (why do I think of C++ meta-templates?) then the experienced person should know that they are writing code other people cannot maintain.

Anyway, there you go, let me know if you try this idea and what the result is.

How much does your manager need to know?

In this social media age I am often surprised by the reaction to what I say online. Usually this is not by the reaction to what I say but rather the lack of reaction. I’ve lost track of the number of times I’ve written what I think is a killer-blog post, or a super meaningful tweet, pushed it out in great anticipation and…. well…. nothing.

Just goes to show: what you think is good and what your “customers” think is good can be two completely different things.

And once in a while the reverse happens. I push out a something I think curious, of minor interest, something unobjectionable and bang!

A week or two back I put out what I thought was a slightly humorous tweet which would be agreeable to many:

“If you manager doesn’t know what technology you are using then they probably shouldn’t be your manager.”

And bang! People – techies! – took exception and rushed to defend managers – usually that is my job!

In a way I was delighted that so many people rushed to defend managers – and to say how managing wasn’t about technology. Most of the IT community damn managers without a second thought. Thanks guys!

Well I feel the need to reply and explain myself more fully. First lets clarify what I mean, then I’ll explain why I think its important.

I friend of mine recently delivered an Agile Introduction course to a client. Before the course the team leader/manager couldn’t tell him what technology the team were using. That is: which language (C#? Java? PHP? Scala?), which operating system (Windows? Linux? MacOS?) or which database (SqlLiite, MySql, SQLServer, Oracle?). Sure we could guess because we knew it was a web development but beyond that…. Anyway, not critical.

This confusion continued at the course itself. Apart from the coder (and possibly the tester) none of the others involved with the work knew which technology was being used.

My interpretation of this situation is: those who didn’t code were disconnected with the work of the technical staff. A gap existed, if they were ignorant of the central technology then what else might they be ignorant of?

(I once heard of a UK Government/BigConsultancy project where when asked “Where are the coders?” a project manager replied “I don’t know, Bangalore I think”. It later transpired they were in Newcastle-upon-Tyne.)

I also take it as a sign that those people do not have a technical (specifically coding) background. I can’t imagine a former coder who doesn’t have some interest in what technology is being used.

The situation clear?

So why is it important?

Lets point out: I’m not for one minute claiming the manager, or requirements analysts etc., need to be able to use these technologies. An appreciation of the technology can be useful, and if they can code they might be able to help, but, too much knowledge can be dangerous. It can lead to the non-coder trying to second guess the coder and tell them in too much detail what they need to do.

I once managed a C# team: as a former C++ and Java coder I could understand and join in the conversations but if I ever felt the urge to reach for the keyboard or tell them how to do their job I knew I would make a fool of myself.

The first reason I think management types should know the technology is exactly as I’ve said above: it shows they understand what is going on. One of the big problems faced today is disconnected managers. This is the reverse of micro-managing, this is what Professor Henry Mintzberg calls macro-leading: ‘people in senior position who try to manage by remote control, disconnected from everything except “the big picture”.’ (Simply Managing, 2013)

That is what I was getting at in my original tweet. If managers don’t know what technology is being used they they are simply too disconnected to be able to manage it. But I will go further….

The second reason is I think management types absolutely do need to understand programming and technology if they are to manage such efforts. I’m fond of saying: “In software development work the devil is in the detail.”

If managers don’t understand the nature of the coding process I don’t think they can manage it. And if they have never coded I find it hard to understand how they will know the nature of coding work.

If managers don’t understand how software is developed – in the real world – then they will impose models of development and management which undermine the work.

If managers don’t appreciate the difficulties that can arise in software development then they will not be in a position to use their authority to help the technical staff. Indeed they may have problems even talking to their technical staff if they lack knowledge.

I don’t believe “if you can manage you can manage anything” – it is a lie. Such advice is a recipe for the kind of mis-management we see all too often in the IT world.

The fact is: if you are developing technology you need to get your hands dirty with technology.

I’ve long been guided by the words of Fred Brooks:

“In many ways, managing a large computer programming project is like managing any other large undertaking – in more ways than most programmers believe. But in many other ways it is different – in more ways than most professional managers expect.” (Brooks, 1975)

(Indeed I chose these words to open Xanpan 2: The Means of Production.)

When I studied management I found much of the advice and good practices were highly applicable to software development. Indeed my Masters dissertation is an examination of how some management ideas map directly into Agile software development. (And yes, that dissertation opens with the same words from Brooks, “Software Development as Organizational Learning” is available to download and formed the beginnings of “Changing Software Development: Learning to be Agile”.)

There is a lot of good management practice and advice out there that many people inside IT and software development would benefit from knowing. But asking a generalist manager to manage a software development effort (always a complex effort) is going to result in problems.

Let me quote again from Henry Mintzberg:

“Managers deal with the messy stuff – the intractable problems, the complicated problems. … put together a good deal of craft along with the right touch of art alongside some use of science, and you end up with a job that is above all a practice, learned through experience and rooted in context.” (Simply Managing, Henry Mintzberg, 2013)

If you are managing a software development team I do not see how you can have the requisite experience and context if you have not programmed yourself. Managing does not exist in a context of its own, all management is rooted in the thing being managed.

Deep thoughts and irony

I’m just putting the finishing touches to a new Requirements Dialogue Sheet for a trial run this week with some guinea pigs (see my Dialogue Sheets update blog last October for more about this). And something thought provoking has come up I want to share.

If you’ve seen my dialogue sheets you will know that around edges I place quotes: some humorous, thought provoking, some (hopefully) inspiring and a few all three! As I edit this sheet two quotes have come next to each other and it is making me thing.

From Sergey Brin, of Google fame:

“It’s important not to overstate the benefits of ideas. Quite frankly, I know its kind of a romantic notion that you’re just going to have this brilliant idea and then everything is going to be great. But the fact is that coming up with an idea is the least important part of creating something great. It has to be the right idea and have good taste, but the execution and delivery are what’s key”

And from Leo Trotsky, of Russian revolution fame:

“Learning carries within itself certain dangers because out of necessity one has to learn from one’s enemies.”

Then add in another Trotsky quotes from his time as Commissar for Foreign Affairs:

“We will issue a few revolutionary proclamations to the peoples, and then shut up shop”

The interplay of the quotes interests me. (If only Trotsky had had Brin’s advice!)

For those who know a little about the history of these two men there is an added depth.

While you think about that, if anyone would like to volunteer to test one of the new requirements dialogue sheets please get in touch.

I hate bugs (A rant)

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

The state of Scrum Mastering

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


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

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