Thursday, April 16, 2015

Managers are not homogenous

(If you are not a coder please bear with me…. we’ll get to the business point in a moment.)

When a programmer finds a class named Manager in a code base they know - or at least should know - that it is probably a smell. It might be innocent but until proven so it should be considered guilty.

For example…




I’ve written a few of these myself in my time, and I may even write some more in future. But that does not make them good.

The problem with “manager objects” is that they are usually a vaguely connected set of functionality which either deserves a better name (SecurityValidator, Logging, or some such) or they are worth breaking up into multiple classes each of which has its own clearer purpose (DatabaseUser, DatabaseConnection, DatabaseFinder….). And sometimes, some of those functions would be better off as a stand alone function not bundled into a class because it happens to share part of a name.

Now let me suggest the same is true of job titles and roles which include Manager in the title.

For example: I am writing this on a train, my ticket has just been checked by the “Train Manager”. This is a position that used to be called “Train Guard.” I must assume that the Train Manager’s job entails more than just checking tickets, similarly the Guards job entailed more than just loading the guard van with good.

Does the Train Manager have the authority to order the train driver to pass a red signal? - I don’t know but I assume (and hope) not.

Does a Train Manager have the authority to order the catering crew to reduce prices? - I don’t know but would expect prices to be decided centrally or for catering staff to have the authority - perhaps under standing orders - to reduce prices under some circumstances.

Personally I prefer the old title “Guard” but perhaps there is some reason - other than presentation - why the position is is no longer called a guard. But since I have no deep insights into exactly what actions this person undertakes or what their responsibilities are I can’t really comment.

In the same way that I don’t really know your code base so shouldn’t really comment on your class naming. However, I can say, that given my limited knowledge I detect a smell.

Now there are a lot of people in the Agile community who are very anti-manager. They see self-organizing teams etc. as a way of removing managers. While I have understand their position and think maybe some “managers” would be better removed and the teams allowed to “get on with it” I don’t think its that simple.

But I also think when developing software, when doing many other activities too, and in an organization, be it big or small there are often many vaguely related things what need to be looked after. Big organizations tend to have more of these than small because of their nature. Some of these things that need doing are the result of people inside the team and some from outside. Resolving many of these things requires being in possession of information, it requires a degree of authority and more importantly competence. What do we call someone who deals with all this? Well, a Manager.

For a few years I’ve been trying to find the time and energy to write a comprehensive blog series on the topic of managers in software development but I can’t. I see another land mine, if I weigh in on this debate I expect both sides will attack me and neither will really appreciate my position. So you may have to wait a bit longer but I think the above discussion illustrates an important point…

The formal title of “Manager” (and even the informal use of “Manager”) hides a lot. Some of those roles, like Product Manager or Build Manager, can be quite focused and specific. But many of those roles are catch all roles with mixed responsibilities which may, or may not, be better filled by a specialists or by devolving authority to do the work to others.

Some of these tasks - like checking tickets on a train - should not be needed and should not exist, everyone should buy a ticket and pay the fare! Much of the train manager role is because we don’t live in a utopian socialist society. (Although history shows managers were just more to running of socialist societies as capitalist ones.)

So please, before anyone tries to remove a manager please examine what they actually do, and whether the role would benefit from a better, specific title. Or whether it actually makes sense to have a someone catching all the other stuff in a vaguely defined role.

Saturday, April 11, 2015

Agile on the Beach voting procedure

Nothing exciting but to save me from explaining this again and again….

Yesterday the Agile on the Beach conference committee finalised the speaker lineup. I’ve just this morning sent the acceptances and the “Sorry” e-mails. Since there were about 150 submissions and only 41 slots to speak in we cold only accept less than a third of the submissions - even fewer actually because some sessions are doubles.

Here is how we came to our decisions.

We have five committee members - you can see who on the website. Each of these was given electronic copies of all the submissions - including long and short synopsis, speaker bio, travel origin (implying how expensive it might be for us to bring someone in) and other details.

Each committee member independently scored each submission on a scale from -2 (I don’t think this should be at the conference) to +2 (I really want to see this myself.) By making Zero the default any reviewer who didn’t review a session or felt they did not have the knowledge to pass judgement didn’t bias the results. Sometimes reviewers made a comment as to why they had given this score but not always.

I took these scores and added them together. In the first review meeting (two weeks ago) we reviewed the total scores, debated a few sessions and the top scoring sessions were short listed.

In the product track 17 were shortlisted, business 13 and for the team track 27 made the shortlist. Again each reviewer independently reviewed the shortlist. Software was slightly different because we again decided to make extra space to keep our technical side, more to follow. Since Product expanded from one day to two days this year it means the conference has grown again.

But this time instead of scoring the sessions reviewers ranked them. Each track has 9 sessions (if all are single) and each reviewer ranked the sessions knowing this.

For the second meeting I took these rankings and averaged them for each session then in each tack ordered the track. At this point we had some clear accepts. At the 9 mark things became fuzzy, in one track we had a double in position 9, in another track one person had three slots in the top 9 and so on. So some manual adjustments were made. We also made a call on some things we thought should be in the conference or developed mini-themes.

In the end a lot of sessions didn’t make the cut simply because they were out competed. Everything that made the shortlist was strong, a lot that didn’t make the shortlist was strong too. We just don’t have space for everything we would like and can’t expand the conference every time, sorry.

Anyway, I hope that explanations helps.

Wednesday, April 08, 2015

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

Monday, March 30, 2015

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!

Saturday, March 28, 2015

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.

Sunday, March 15, 2015

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.

Sunday, March 01, 2015

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.

Sunday, February 22, 2015

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.

Tuesday, February 17, 2015

Xanpan book 2: The means of production

Today I start unveiling Xanpan book 2: The Means of Production - Managing team centric Agile Software Development.

Many regular readers will have read about Xanpan - my own blend of XP (Extreme Programming) and Kanban - and the most regular readers won’t need telling that the message behind Xanpan is…. Create your own development method!

But I’m not sure every reader has yet bought a copy of Xanpan. Xanpan is available in electronic form from LeanPub and in hard copy Xanpan is on Lulu. There are also some reviews of Xanpan on Lulu - and plenty of space for more.

Now its time to announce Xanpan book 2.

Xanpan book 2 is much further developed than I like to admit. In fact what I’m publishing today has been ready since before Christmas. But like so many others the desire to unveil a more complete product has held me back. The desire to do a more complete job has detered me. I’m just the same as everyone one else!

So, I’m taking a chance. I’m pushing some of it out there and let see what happens.

As with any LeanPub project lets see what the feedback says and then we’ll do some more.

Right now Xanpan2 contains the introduction and the first chapter “Teams Heuristics”. It also contains the chapter headings for the chapters I think will be in the book as it develops.

If you like Xanpan 2 please send me some feedback, and if you don’t like it please please send me some feedback. As always, the best feedback is money!

My intention is to polish and publish more of the chapters over the next few weeks and months, and try to complete the unfinished chapters too. As I do this I might push the price up!

I’ve got an idea where this book will end, when I get there and I’m happy I may decide to have it professionally copy edited. That is a batch process so much wait. And again I’ll push the price up.

Now: go get Xanpan book 2.