Tuesday, September 29, 2015

Little Book of User Stories anyone?

If you follow me on Twitter you will probably have noticed I’ve been writing a series of pieces for The Agile Connection on User Stories. This series began by accident, until recently I didn’t know I knew so much about user stories!

Actually, although the series is based around user stories it is probably better to say its about requirements in an agile setting. (There is a full list of the pieces so far on my website.)

I can now see the end of this series, a few more pieces to go and I’m thinking of rolling all the pieces, plus some offcuts and one or two extras into a LeanPub book. This is tentatively entitled “The Little Book of User Stories.”

Its on LeanPub now and if your interested please register your interest. And tell me how much you think I should charge.

If it looks like more than a few people are interested I’ll put the work in an publish it. If not, well, MVPs should be able to fail.

Friday, September 25, 2015

New website - feedback please?

For reasons which don’t always make sense to me I run three websites.

The most active is this blog - which is hosted on Blogger, I suppose I could, should, move it but I’ve yet to find a compelling reason.

The second is allankelly.net which is classic static site created with RapidWeaver - a great but far from perfect tool. allankelly.net is a dumping ground for me, allan, its contains or links to almost everything I’ve written or recorded.

The third - and the reason for writing this post - is my commercial site, Software Strategy, this is where I list my commercial offerings - the training courses and consulting work offer. Over the summer we launched a new version of SoftwareStrategy.co.uk, the most expensive version yet! I’d be really grateful for feedback from anyone - please!

(And links to it would be even better, thank!)

The real test of the Software Strategy website is whether it brings in more paying work for me - yes I’d love to blog blog blog but I need to pay the mortgage too.

What do you think of SoftwareStrategy.co.uk?

Until a couple of years ago Software Strategy was all my own work, again with RapidWeaver and static. Then I decided to improve the website and paid someone to rebuild it on WordPress. The site never performed as well as the previous one - i.e. it didn’t bring in as much work - and eventually I decided to rebuild again.

So now I have a new fancy WordPress website.

And I hate WordPress more than ever.

I expect that in a couple of years I’ll be ready for another rebuild. When that time comes I would love to move it back to a static configuration. I see WordPress costs me more but I can’t see any benefit.

Anyone out there want to correct me?

Tuesday, September 22, 2015

Stop empowering people - End disempowerment!

In the last two posts I’ve discussed some problems with of self-organizing teams and highlighted the need to be clearer about what is actually meant when talking of, that is naming, self-organizing teams. At a minimum the labels need clear definition (I suggested some definitions and I hope someone knows some better ones.)

I went further and I called for individuals and teams to be given authority so that timely decisions can be made with maximum knowledge. I’m sure everyone agreed with me up until that point and then I said we should stop “empowering” people, I said I hated the term empowerment and that probably confused a lot of people.

Now I’d better explain myself.

Actually my thinking comes directly from Henry Mintzberg so I’ll let him explain:

“empowerment [does] not change that [participation] because the term itself indicate[s] that the power remain[s] with the manager” Mintzberg, Managing, 2009

Mintzberg argues that the practice of empowerment leaves real authority, real power with the manager, when a manager “empowers” a worker he is offering him a gift, or rather a loan. It is the manager who chooses to empower the worker, by implication the manager may choose not to empower the worker or to remove the power at a later date. The very act of empowering a worker actually emphasises the lack of worker power.

Elsewhere in the same book Mintzberg makes a good point:

“Truly empowered workers, such as doctors in a hospital, even bees in the hive, do not await gifts from their managerial gods; they know what they are there to do and just do it. … people who have a job to do shouldn’t need to be empowered by their managers”

A little later Mintzberg offers a key insight:

“a good deal of what is today called ‘empowerment’ is really just getting rid of years of disempowerment.”

Its not about empowering software engineers to improve the build system, or testers to automate scripts, or analysts to do stakeholder mapping; its about trusting them to do their job right and letting them do it. These are the experts in their field, let them do what they know to be right, indeed, go further: insist they do the right thing.

So if you are a manager stop empowering people and teams, instead stop disempowering them. Give them the trust, authority and support to do their work.

And if you are a worker just reach out and take authority. One of MIntzberg’s better known peers, Tom Peters, like to quote the American soap star Rossanne Barr:

“Nobody gives you power, You just take it” Rossanne Barr quoted in Re:Imagine! by Tom Peters

Let me leave you with a classic pattern from Joe Begin, Do The Right Thing:

Things are bad. Really bad.

        •        When things are bad it is really tough and bad things happen.

        •        When things get better the bad stuff doesn't happen any more and you feel good. Really good.

Therefore: Do the right thing. Make the bad thing better.

The result: Things are good. Really good.

Known Uses:

        •        When you were small your father would make the Monsters Under the Bed go away just by sticking his head in your room. He did the right thing.

        •        When you are really sick, eat your Mom's chicken soup. Only your Mom's. Only she knows how to do the right thing.

Don’t wait for someone to give you authority or empower you, do the right thing.

Sunday, September 20, 2015

Self-organizing, self-directing, self-managing and authority

Quick as a flash Eben Halford on Twitter pointed out the mistake with my last blog (Question for self-organizing teams). I was mixing up self-organizing teams with self-directing teams. Well maybe I was… much of my post still stands either way, and as Eben himself pointed out, we might be trying to split a hair here.

Frankly, I suspect many people think the whole “self-organizing team” thing is one-size. The idea that there are actually “self-organizing” and “self-directed” and possibly “self-managing” hasn’t occurred to most people and, if they have noticed, they don’t know the difference. In fact, I’m not sure I know the difference!

If you take time to look at some of the literature on self-organizing/directing teams you find that very little of the pre-agile stuff talks about self-organizing teams, rather the common term in management literature is self-managing teams, most of the serious research relates to this rather than the (to my mind) weaker idea of self-organization.

To untangle this mess lets define a hierarchy here:

  • A self-organizing team is a team where team members get to decide among themselves who does what, the team gets to work on problems and have some power to remove their own blockages. Clearly there are teams who are more self-organizing than others and teams which have more authority than others.
  • In a self-managing team there is no active day-to-day management of the team. The team are effectively left to manage their own work. To my mind this is a stronger form of self-organizing.
  • A self-directed team is a team which sets its own goals, decides its own objectives and determines its own priorities.

Does anyone know of any serious literature (i.e. research led) which defines these terms better? I’d love to have some better, clear, more well defined, separation.

Clearly some, but not all, of the questions I posed in my last blog relate to self-directed teams rather than mere self-organizing teams.

But while I have, belatedly, made this distinction it seems to me that not everyone does. It seems to me that making this distinction would help by removing a lot of the confusion that sounds self-organizing teams. And making this distinction would actually help with the questions I posed in the last blog post because teams and their managers would be able to draw lines and discuss where authority and responsibilities lie.

You see, one of the problems with labels, especially labels like self-organanizing teams, is that they mean different things to different people. Indeed different authors define them differently.

It is because of this confusion that I prefer to avoid using these labels and prefer to leave the idea of self-organizing teams alone.

Instead I prefer to talk about authority, I want team members and teams, however they are organized and managed, to be given authority. Sometimes authority is vested in the team members equally, so for example each member has the authority to make a decision. In other case authority is vested in the collective team, in that case as long as the team can agree a decision they can make it,

In other cases authority is vested in specific individual team members. This usually occurs where specialist skills or knowledge are needed. The Product Owner role is a great example here: product owners need to have the authority to make decisions on prioritisation, they need authority to make trade-offs and make compromises. The more authority you give the product owner the better they can do their job.

I want teams and individuals to have authority for two reasons. I believe the soft, fuzzy, reason that is usually sighted: people get more satisfaction from work when they have autonomy (i.e. they can make their own decisions) and thus are more motivated and more engaged as workers.

The second reason is very hard, not fuzzy: when developing software there are thousands of decisions that need to be made. Many of the decisions require specialist knowledge and the people with the greatest knowledge, both of the technology and the situation in hand right now, are the people doing the work. The testers and programmers at the code face have more information about what needs to be decided than anyone else.

Pushing decisions down to the lowest level means decision making can be made more efficiently, i.e. in a more timely fashion. But in order to do that the workers need authority.

Now notice I’m saying authority, I’m deliberately avoiding the word “empowerment”. Empowerment is a horrid word and it describes a horrid concept. Don’t talk to me about empowerment, its nasty.

On that cliff hanger, if you want to know why I don’t like empowerment, well tune in next time, the post is already drafted.

Saturday, September 12, 2015

Question for self-organizing teams

Try this thought experiment.

You are a software development manager. You learn about agile and you think it is good. You adopt agile and you make all your teams into self-organizing teams. (Leave aside the question of whether you then quit in a fit of “no managers needed” - we can talk about that later.)

Most of your teams work well. Productivity goes up, people are happier. They organise their own work. Occasionally teams come to you and say they would like extra people on the team. Provided they can back this up with evidence that they are productive and add value, and that adding more members will increase the value they deliver then they are allowed to expand.

But, one team doesn’t perform as expected. They don’t achieve the productivity of the other teams, they don’t demonstrate the value other teams do.

Question: Do you intervene?

If you intervene you are not allowing them to self-organise, you are playing big bad manager.

If you intervene in one team what will the other teams think?

Perhaps its not as clear as that. Perhaps the team are performing but it becomes clear they have achieved a local optimum and are not improving like other teams.

Question: How do you nudge the team to move to a higher performance level?

And what if when you challenge them about things like pair programming, honouring deadlines, maybe predictable velocity, etc. etc. they tell you they have tried these things, or at least talked about them, and they have decided that these are not good for them.

Question: What do you do if they self-orgianise to not do the things you hoped they would? Things you think might improve performance?

(Potentially if you allow a team to self-organize they might even start requesting complete requirements documents up front, they may resist change requests.)

Now suppose that rather than play big bad manager you play facilitator, Uber-Scrum-Master, you go to the team and say: “I think this team could perform better, I’d like to help you improve.”

And someone on the team says back: “Could you please give us an example of when you think we could have performed better?”

Now you have a specific instance in your mind where the other teams (the performing teams) think this one messed up. Do you tell them? To tell them is negative, to tell them may make them defensive, to tell them really make you seem like a big bad manager.

You could hire an agile coach, scrum master or such and ask them to do pose these questions and make these changes. But isn’t that just delegating? You are still the power behind the action.

You could go to the other teams and ask them to challenge the under performing team and raise concerns with them directly but that might be seen as manipulative, and now you are interfering in multiple teams. Are you allowing them to self-organise?

Now suppose things take a turn for the worse. The company looses money and the shareholders ask for redundancies.

Do you communicate this to the teams and ask for volunteers? - you may hit employment law problems here.

Do you ask everyone (yourself included) to take a pay-cut?

What is someone crunched the figures and found it was the underperforming team that was dragging everyone down, and cutting the whole team could return you to profit. Should you ask the teams to do this themselves? Or do you do it?

If the team crunched the figures would the underperforming team decide to offer themselves up for redundancy? Would it be fair it you - or the teams themselves - decided to cut one person from each team instead?

In short: if you have an team where the performance isn’t satisfactory what do you do?

I suppose the ideal is that someone on the team, probably a product owner/analyst type person, is regularly analysing the benefit delivered by the team and the cost of the team. If the benefits fall below the cost and the team can’t come up with a plan to change it then the team members request dissolution. But has anyone ever seen that?

I pose these questions because I don’t know the answers. It is questions like this that add to my scepticism over self-organizing teams, or rather, cause me to see limits in the model.

I find it hard to image any team offering to dissolve themselves. O, there might be the odd story of teams doing it but I find it hard to image this is the norm. I find it easier to image teams getting more defensive and seeking to explain away their failings by reference to others (I’m avoiding the word blame.)

Arie de Geus in The Living Company says that companies, and by extension teams, are living beings, they exist to continue their own existence. In capitalist coiuntries markets will eventually force poor performing companies out of business. In the closed ecosystem inside a company how do we replicate that mechanism?

I see limits in self-organzing teams: One of manager’s roles is to determine these limits and act at the limits.

One more thing, run this thought experiment again, but this time imagine that you (the enlightened manager) chose to dismiss yourself once you have set up the teams. The questions still stand, the problems still exist, but removing the manager removes the last person who might take action.

Monday, August 17, 2015

On programming in the summer

In the summer my training and consulting business gets quiet. That allows me to take some holiday and to pursue some stuff I don’t get much time for otherwise. This summer I’ve picked up a programming idea I started last summer, worked on over Christmas and still haven’t finished. This means I’m programming!

It is getting close to 10 years since anyone paid me to programme but I dabble a bit, I keep my hand in (a little). Right now I’d like to share some observations I’ve made. Programmers out there - please agree or disagree, just leave comment below. And if you haven’t programmed for a while then think about these points.

A bit of background, I’m working in Python (2.7) for the Google App Engine. It is about 2,300 lines of HTML and 4,000 of code and unit tests. I’ve set myself a challenge of doing this without a debugger. Just unit tests and some debug logging/printf’s if needed. I won’t have an IDE either, I’m using TextMate. Giovanni Asproni persuaded me to try PyCharm but the thought of learning another IDE stopped me installing it.


  1. Its addictive - hard to stop, when you see your code working its hard to step back, not to play with the kids, not to eat and even not to go the toilet!
  2. Sometimes it feels like your brain will explode, you are just trying to keep so many things in mind at one time and make sense of something (or somethings) new, and understand how it all hangs together and…. you just feel full.
  3. It scares me - knowing that I will be so immersed scares me, I don’t pick it up and do little bits when I can be cause I know I’ll get sucked in.
  4. It requires large chunks of time - its not like answering e-mail, its not something you can do 5 minutes here, and 20 there, you need a few hours at a time, partly because of #1 and #2 above.
  5. Them tests - TDD development makes it so much more enjoyable, yes its hard to keep yourself honest but when you see a little bit more working it feeds the addiction; it also means you spend less time with those annoying little bugs and trivialities. Once or twice I’ve strayed from writing tests for too long and ended up in a mess.
  6. Trivial tests Yes! - when I evangelise TDD I often get asked by people “But surely you don’t need to write tests for all the small, obvious stuff, getters and setters say”. (Leaving aside the “you should’t have getters and setters” argument for a moment). Its hard to argue with them. But its perhaps with the trivial stuff that I find TDD makes the biggest difference, perhaps in part because I’m in Python and not a compiled language. Its those occasions when you think “this is trivial I’ll just do it” that often catch you out. I am not thinking, I am on auto pilot, or, heaven forbid, I’ve done a bit of cut and paste.
  7. No you can’t TDD everything (particularly in the UI or a third party system) but that means I go slower there, I’m taking more risk. I wish could test that stuff. Why should “not being able to test everything” be an objection to “testing everything you can?”
  8. Bigger problems, multiple things: some of the bigger problems you face are where several things come together, and sometimes it far from obvious that they have! (This is the same as my entry in 97 Things Every Programmer Should Know, Two Wrongs Can Make a Right.)
  9. Taking a break: sometimes when you are in the middle something, particularly if your brain is about to explode (#2), and/or you are convinced you are on the edge of completing something, or accomplishing a breakthrough (particularly if something is not working like you expect it to) then… you just can’t take a break. Not so much addition but the feeling that if you let go now you will never get it all back into your head again. But, big but, a break is just what you need. Only when you come back fresh can you actually make it work. Only a break will let you step back and think without the overload.
  10. Nothing else: When I’m programming, when I’m on a roll, I don’t want to write more Xanpan, or continue the User Stories series, or chase down some leads for work. Yes I should do all these things but… programming is good. There is only so much time in the day. Wouldn’t it be nice if I had someone else to take care of those things? If I was a team I could…. all those programmers who want to do away with managers should think about this. If you do away with managers much of that management work still needs doing and now the programmers are going to have to do it!

Its easy to see what attracted me to programming all those years ago. The deep immersion and challenge, man v. machine, it soaked up so many of my teenage days - particularly summer holidays. Its perhaps fitting that it is mainly during the quieter summer months - when my training and consulting work isn’t so busy - that I get time to do a bit of programming.

Something else thats funny, when I’m programming I really like listening to old 70s and 80s music, stuff I listened too when I was a teenager immersed in programming. Guess I’m just a middle-aged man seeking his youth!

Tuesday, August 11, 2015

#NoProjects pod cast c/o Tom Cagley

During August I'm in holiday mode, so by way of a change from blogging here is a podcast.

Tom Cagley has been doing podcasts for some years now under the title SpamCast - Software Process and Management Cast. A few weeks ago he interviewed me on the subject of #NoProjects and its now up on his website.

I've not had a chance to listen to it myself but I'm sure it was good.

Thanks Tom!

Wednesday, August 05, 2015

Xanpan now on Amazon

Regular readers will certainly know about my Xanpan method, a hybrid of Extreme Programming and Kanban. (The secret is: Xanpan contains XP).

Earlier this year I decided to make Xanpan into a more respectable book, that mean a new, professional cover:


Step two was proper ISBN numbers for the electronic versions. The print version has long had the number 978-1-291-85273-8, now the Mobi (Kindle) version has become 978-0-9933250-0-7, the PDF version 978-0-9933250-1-4 and the ePub (Apple Books) is 978-0-9933250-1-4.

And I’m please to announce step 3 is now complete: Xanpan is now on Amazon.

Unfortunately due to the way Amazon works it sees the physical and electric book versions as different books, and the different Amazon’s don’t show the same reviews. So, there are lots of views on Amazon just scattered around - there are also still reviews on Lulu.

Anyway, if you don’t have a copy of Xanpan yet you can now get it at:
I’d love to have more reviews, so please please please add them! I’m happy to give a (unfinished) copy of Xanpan 2 “The Means of Production” to anyone who writes a review.

And if you live in another Amazon country (.de, .ca, ….) then I’m sure your Amazon has the book, you just need to look at the UK or USA for reviews right now.

Monday, August 03, 2015

Team Start Dialogue Sheet

I’ve updated the Team Start Dialogue Sheet. Many thanks to Marta Kolenda who used the sheet with two of her new teams and sent me some feedback. Incorporating her feedback gave me a chance to make some more changes to the sheet too.

I’m always glad to have feedback from people and teams who try any of my Dialogue Sheets - getting feedback from Agile teams can be like getting blood out of a stone!

Plus I’m always keen to sit in and observe teams using the dialogue sheets - particularly the still new Customer Discussion sheet - so please invite me!

And while you are looking at the sheets… you might notice that Software Strategy - my company - has a shiny new website. Bblogs and books don’t pay mortgages so Software Strategy is my commercial side. If you know anyone who wants some advice or training on software development or Agile then point them here!

Tuesday, July 28, 2015

Requirements, User Stories and Backlogs

User Stories, half of me hates them, that half of me wonders “What is all the fuss about?” and that half wonders “How did Mike Cohn write 200 pages about something so simple?”

The other half of me see that people find them useful. They fill a need. They contain the key elements of requirements “Who What Why.” And over the years I’ve built up a lot of advice I give to people and teams. Some of it is User Story specific, some is about requirements in general and some is about backlogs and Agile.

A couple of months ago I was flying to Dallas to see a client. Its a long flight from London so I took the opportunity to write down my standard advice. The other passengers must have thought me strange, for over half the flight I was tapping into my laptop. By the time we landed I had about 25 pages - yes 25! - of raw, unedited, material.

I’m in the process of turning this material into a series of articles for Agile Connection - and benefitting from the advice of Johanna Rothman as I do it. The first pieces are already online:

  1. User Story Heuristics: Understanding Agile Requirements
  2. Relieving Agile Tension: How to Write Small Stories That Still Have Value
  3. Know Your Customers: They Can Help You Write Better User Stories

This series will stray into requirements and backlogs.

Now as it happens, about the time of Dallas flight the nice people form Libero in Romania asked me if I could give a day seminar on, yes, Agile Requirements. So, if you are in Romania, or fancy a trip to Romania in September check it out: