Blog

Blogger, Blog move & Comments

Frank_Sinatra_Hollywood_star-2017-08-7-15-15.jpg

“And now, the end is near
And so I face the final curtain
My friend, I’ll say it clear
I’ll state my case, of which I’m certain”
My Way, Paul Anka/Frank Sinantra
(public domain picture from WikiCommons)

Don’t panic!

I’m not going away, this blog is not finishing.

But it is changing. And with the change there will be some loss.

Blog entry 1 appeared in April 2005, and after 12 years on Blogger this blog is moving and that move has a downside.

I’ve always been happy on Blogger but in the last few years I’ve been operating three website: the blog on Blogger, allankelly.net – a static site written in RapidWeaver and my commercial site, Software Strategy (www.softwarestrategy.co.uk).

This means my efforts have been split between three sites, and Google has seen me as three sites. Given that my web presence is part of marketing my training and consultancy that might not have been the smartest move.

So last month I decided to merge the three sites and adopt a new corporate identity. Most of the move has been done, Software Strategy is now doing to allankellyassociates.co.uk, the blog is mostly moved – thanks to the great work of the folks at CMS2CMS, highly recommended – and here in lies the problem….

CMS2CMS have done a great job of moving the blog posts, images and comments. But they can’t move all the comments. That is because around October 2014 I switch the comments from Blogger to Google+. The comments on Blogger, before October 2014, can, and have, been moved across, but the comments on Google+ can’t – so all comments left since October 2014 are lost. I regret the decisions to switch to Google+ comments massively.

So many of the comments over the few years (I’m not sure exactly how many!) are about to be lost when the Blogger blog is set to redirect to allankellyassociates.co.uk.

In order that the comments are not lost entirely here are some of my “greatest hits” as PDF files with comments and the view count according to Blogger:

I could go on, I’m sorry I can’t save more comments, it is sad looking now at all the comments, far more than I thought there were. I’m also amazon by how the blog has grown, from early posts with, maybe, a hundred views to a regular audience of thousands and sometimes tens of thousands.

And I completely blame Google and G+ for this, on Blogger Google are quite supportive of blog exports but there is nothing equivalent on Google+.

O, the third site, allankelly.net, this is mostly an archive of my writing down the years and it too will disappear inside www.allankellyassociates.co.uk in the very near future – most of the content is already moved.

Programmer’s Rorschach test

The picture above, I recently added this picture to Continuous Digital for a discussion of teams. When you look at it what do you see:

An old style structure chart, or an organization chart?

It could be either and anyone who knows of Conway’s Law shouldn’t be surprised.

When I was taught Modula-2 at college these sort of structure charts were considered superior to the older flow charts. This is functional decomposition, take a problem, break it down to smaller parts and implement them.

And that is the same idea behind traditional hierarchical organizational structure. An executive heads a division, he has a number of managers under him who manage work, each one of these manage several people who actually do the work (or perhaps manage more manager who manage the people who do the work!)

Most organizations are still set up this way. It is probably unsurprising that 50 years ago computer programmers copied this model when designing their systems – Conway’s Law, the system is a copy of the organization.

Fast forward to today, we use object oriented languages and design but most of our organizations are still constrained by hierarchical structure, that creates a conflict. The company is structurally decomposed but our code is object oriented.

The result is conflict and in many cases the organization wins – who hasn’t seen an object oriented system that is designed in layers?

While the conflict exists both system and organization under perform because time and energy are spent living the conflict, managing the conflict, overcoming the conflict.

What would the object-oriented company look like?

If we accept that object oriented design and programming are superior to procedural programming (and in general I do although I miss Modula-2) then it becomes necessary to change the organization to match the software design – reverse Conway’s Law or Yawnoc. That means we need teams which look and behave like objects:

  • Teams are highly cohesive (staffed with various skills) and lightly coupled (dependencies are minimised and the team take responsibility)
  • Teams are responsible for a discrete part of the system end-to-end
  • Teams add value in their own right
  • Teams are free to vary organizational implementation behind well defined interface
  • Teams are tested, debugged and maintained: they have been through the storming phase, are now performing and are kept together

There are probably some more attributes I could add here, please make your own suggestions in the comments below.

To regular readers this should all sound familiar, I’ve been exposing these ideas for a while, they draw on software design and Amoeba management, I discuss them at greater length Xanpan, The Xanpan Appendix and now Continuous Digital – actually, Continuous Digital directly updates some chapters from the Appendix.

And like so many programmers have found over the years, classes which are named “Manager” are more than likely poorly named and poorly designed. Manager is a catch all name, the class might well be doing something very useful but it can be named better. If it isn’t doing anything useful, then maybe it should be refactored into something that is. Most likely the ManagerClass is doing a lot of useful stuff but it is far from clear that it all belongs together. (See the management mini-series.)

Sometimes managers or manager classes  make sense, however both deserve closer examination. Are they vestige from the hierarchal world? Do they perform specialist functions which could be packaged and named better? Perhaps they are necessary, perhaps they are necessary for smoothing the conflict between the hierarchal organization and object oriented world.

Transaction costs can explain both managers and manager classes. There are various tasks which require knowledge of other tasks, or access to the same data. It is cheaper, and perhaps simpler, to put these diverse things together rather than pay the cost of spreading access out.

Of course if you accept the symbiosis of organization and code design then one should ask: what should the organization look like when the code is functional? What does the Lisp, Clojure or F# organization look like?

And, for that matter, what does the organization look like when you program in Prolog? What does a declarative organization look like?

Finally, I was about to ask about SQL, what does the relational organization look like, but I think you’ve already guessed the answer to this one: a matrix, probably a dysfunctional matrix.

Exciting: Something different for those Leading & Managing Agile

“Some readers have found it curious that The Mythical Man Month devotes most of the essays to the managerial aspects of software engineering, rather than the many technical issues. This bias … sprang from [my] conviction that the quality of the people on a project, and their organization and management, are much more important factors in the success than are the tools they use or the technical approaches they take.” Frederick P. Brooks, The Mythical Man Month – Anniversary Edition (1995a, p.276)

This is one of my favourite quotes about software development.

Those of you who followed my management mini-series last year might remember some of my conclusions, specifically:

  • Management is still needed in most software teams
  • Even if you don’t have dedicated managers there is still management work to do; and without dedicated management that management work gets spread around so in a self-organizing team more people need to do management work

I can’t remember if I said it in that series or in another post: the quality of management in software development is often poor.

So now I’m going to do something about it.

Part of the problem is that very very few software engineers ever take time to learn about management. Sure they learn about Java, BDD, AWS, CSS etc. etc. but most people learn “managing” by watching the people who had the job before them. Unfortunately that tends to propagate poor management.

Why don’t people take the time to learn management skills the way they do technical skills?

A few days in the classroom learning about Java is great, why not spend a little time learning about management?

Now most readers probably know that I provide training, usually agile training to teams, but I have long felt that simply offering a two day training course for current and future managers wouldn’t be enough. I’ve long dreamt of offering a course that ran over a series of weeks, that allowed people to mix classroom learning and discussion of topics with hands on practice and, perhaps more importantly, reflection and group discussion.

Now I’m partnering up with Learning Connexions to offer just this course – I’m more excited about this than anything I have been in a while!

It’s going to run this autumn, September to December, half a day every two weeks.

In each session I’ll present some material but more importantly we’ll have discussions between people doing work. We’ll try and apply the material to real work. I expect group discussions will go beyond the stated subjects and allow everyone – me included! – to learn from one another.

Not only is this a new course it is a new way of approaching learning in work. Since it is new the course we are going to keep the price down. We’re running it on Friday afternoons so hopefully it won’t interfere with the usual work week too much.

Here are the hypothesis I’m testing:

  • Software development can be improved if software management can be improved: current software managers, aspiring software managers and software engineers will all do a better job if they take time to pro-actively learn about key issues in the software industry.
  • People will learn more and deeper if it is organised as a little and often.
  • Encouraging self reflection and group discussion about topics and real life problems will enhance learning.

The hypothesis you would be testing by coming along are:

  • I will learn more by discussing key topics with a cross section of my peers
  • An investment of six-half says and a little less than £1000 will pay back in increased effectiveness, productivity, organization, focus….

More information on the workshops on the training pages. (Yes, this is the new website.)

I hope, I very much hope we can make this work…. – please get over to Learning Connexions and book Leading & Managing Agile today. Even if you cannot attend I’d love to know your thoughts on this, please give me feedback – comment here or mail me direct, allan@allankelly.net.

And apologies, I’m going to be talking more about this in the next few weeks as I put material together and get more and more excited!

Exciting: Something different for those Leading & Managing Agile

HeadacheiStock_000014496990SmallLeft-2017-07-20-10-29.jpg

“Some readers have found it curious that The Mythical Man Month devotes most of the essays to the managerial aspects of software engineering, rather than the many technical issues. This bias … sprang from [my] conviction that the quality of the people on a project, and their organization and management, are much more important factors in the success than are the tools they use or the technical approaches they take.” Frederick P. Brooks, The Mythical Man Month – Anniversary Edition (1995a, p.276)

This is one of my favourite quotes about software development.

Those of you who followed my management mini-series last year might remember some of my conclusions, specifically:

  • Management is still needed in most software teams
  • Even if you don’t have dedicated managers there is still management work to do; and without dedicated management that management work gets spread around so in a self-organizing team more people need to do management work

I can’t remember if I said it in that series or in another post: the quality of management in software development is often poor.

So now I’m going to do something about it.

Part of the problem is that very very few software engineers ever take time to learn about management. Sure they learn about Java, BDD, AWS, CSS etc. etc. but most people learn “managing” by watching the people who had the job before them. Unfortunately that tends to propagate poor management.

Why don’t people take the time to learn management skills the way they do technical skills?

A few days in the classroom learning about Java is great, why not spend a little time learning about management?

Now most readers probably know that I provide training, usually agile training to teams, but I have long felt that simply offering a two day training course for current and future managers wouldn’t be enough. I’ve long dreamt of offering a course that ran over a series of weeks, that allowed people to mix classroom learning and discussion of topics with hands on practice and, perhaps more importantly, reflection and group discussion.

Now I’m partnering up with Learning Connexions to offer just this course – I’m more excited about this than anything I have been in a while!

It’s going to run this autumn, September to December, half a day every two weeks.

In each session I’ll present some material but more importantly we’ll have discussions between people doing work. We’ll try and apply the material to real work. I expect group discussions will go beyond the stated subjects and allow everyone – me included! – to learn from one another.

Not only is this a new course it is a new way of approaching learning in work. Since it is new the course we are going to keep the price down. We’re running it on Friday afternoons so hopefully it won’t interfere with the usual work week too much.

Here are the hypothesis I’m testing:

  • Software development can be improved if software management can be improved: current software managers, aspiring software managers and software engineers will all do a better job if they take time to pro-actively learn about key issues in the software industry.
  • People will learn more and deeper if it is organised as a little and often.
  • Encouraging self reflection and group discussion about topics and real life problems will enhance learning.

The hypothesis you would be testing by coming along are:

  • I will learn more by discussing key topics with a cross section of my peers
  • An investment of six-half says and a little less than £1000 will pay back in increased effectiveness, productivity, organization, focus….

I hope, I very much hope we can make this work…. – please get over to Learning Connexions and book Leading & Managing Agile today. Even if you cannot attend I’d love to know your thoughts on this, please give me feedback – comment here or mail me direct, allan@allankelly.net.

And apologies, I’m going to be talking more about this in the next few weeks as I put material together and get more and more excited!

A new blog home

After over 10 years blogging on Blogger I’m moving.

Actually, for the last 10 years I’ve been running three websites. The blog, AllanKelly.net and my company, commercial, site, SoftwareStrategy.co.uk. This kind of made sense once upon a time but it has increasingly meant that all three sites were a little neglected.

My plan is to merge all three sites into this one eventually. Hopefully that will also benefit my Google rankings but, it also means I need to keep all those inbound links!

This is going to be a gradual process…

Medium range capacity planning

iStock_000012937008XSmall-2017-07-5-13-13.jpg

My last blog, “Creating Beautiful Roadmaps – NOT!”, highlighted how the term “roadmap” is used and abused. While I’m probably in the minority in seeing a roadmap as long range scenario planning exercises to enhance learning there isn’t really a consensus on what a roadmap is…

To some a roadmap is a plan of how a product will evolve in the next few years. To others a roadmap is a set of promises with dates made to customers, higher management and others. Most of the roadmaps I see are little more than bucket lists with dates, fantasy dates at that.

Increasingly “roadmap” is used to describe a “release plan”, that is, a list of release dates and for each date a list of features that will be included in that release. Since these are usually based on estimates they are doomed to failure because very few teams can produce meaningful estimates.

Release plans made sense when releases were occasional, say every quarter but once they became fortnightly they loose logic. What is the point of planning releases if you release when the feature is ready? Many times a day?

So imaging how my heart sank a few weeks ago when a client said: “And I’d like you to run a road mapping session for the team next week.”

Worse still, there was no escape, I was visiting a client in Australia, I suddenly wondered if I’d done the right thing flying around the world!

So although I smiled and nodded inside I thought “Bugger!”

A day or two later I enquired about expectations, what did they hope to get from this exercise? Fortunately the answer was “An understanding of what the team will be doing in the next six months.”

OK, this wasn’t a full blown scenario planning exercise it was a mid-range scheduling plan. Normally I see little point in scheduling more than three months in advance – at most! Since this team was changing their work processes, personnel had been in a state of flux and there was no historical data this was going to be difficult.

My next stop was the Product Owner. He had a long list of things the customers – internal and external – wanted. Most of these were little more than headlines and they were all a long way from stories or epics so there was little to go on. The sheer quantity of ideas was so long that saying “No” and deciding what ideas not to work on was clearly going to be essential.

Given the vagueness and unreliability of inputs one could be forgiven for despairing but instead I saw opportunity. The problem was not so much one of road mapping or scheduling but deciding how the team were to divide their time up for the next six months. This was more big ticket prioritisation.

The vagueness of the requirements and specifications meant that once the time was divided up the team would mostly have a free hand in deciding what needed to be done and what they could do in the time allowed.

Without performance data there was no way estimation could be a reliable guide so there was no point in even thinking about it. But if one was to try estimation one would need something to estimate, which means the requirements would need fleshing out and with so many possible options that would be a lot of work. Not only did we not have the time to do such work but since we knew some items would not make the cut fleshing them out, let alone estimating them, was work which would be wasted.

Just as this was looking like mission impossible I remembered Chris Matts Capacity Planning approach. The roadmap request was actually a capacity planning exercise. Chris’ approach would need a few tweaks but it might just work…

In Chris’ version the product owners estimated the work. At first this sounds awful, product people estimating how long technical work will take! Help!

While Chris says this I’ve never seen these “estimates” as real effort estimates. I’ve always viewed them as “bids.” Each product owner wants to get as much time as they can for their chosen work. But they also know that the higher their bid the less likely they are to get what they ask for. So in “estimating” they are both bidding and self-limiting. Once they have a work allocation they will have to adjust what they ask for to get it into the time.

Rather than ask the product folk to estimate or bid I decided to ask them how many nominal days they would like to allot to each item. How would they divide the capacity between competing requests?

Secondly I decided to ask them to order request items. Thus, a line item could have a very high allocation of time but be late in the scheduling order; conversely a small effort item could be high up the priority list.

So…

The first task was to knock the wish list into shape as a series of line items.

For each line item we gave a short description and statement of anticipated benefits in a spreadsheet. Each item had a box for “days” and “order.”

Next we took a stab at calculating how many days team P had: six months for 10 people equated to approximately 1280 working days.

My plan was to have each manager allocate 1280 between the line items and assign each item a priority position. Then we would average the numbers and use the combined result as the basis of a discussion before finalising the allocations. Finally we would turn the allocated days into percentages and hand them to the team together with the priority order.

So far, so good. The meeting commenced: three managers, three techies, one team product owner and me. (Only the managers got to vote.)

To my surprise the managers readily accepted the approach: I had feared they would want detail on the line items and effort estimates.

While I had intended to hand out the printed spreadsheet, collect the numbers and average them someone decided we should put them on screen. So the whole spreadsheet was projected on screen and it became a collective exercise.

Very quickly about half the items were dismissed and allocated zero time. They were all good ideas but given capacity constrains they clearly weren’t going to win any time.

Some of the remaining items were split up and others combined. Before hand I had worried whether we had the right granularity and even the right items but the group quickly addressed such concerns without me needing to mention them.

(Anyway, I didn’t want fine granularity because that would hinder the teams ability to decide what it wanted to do.)

Next each line item was discussed and assigned an order. I had intended to order them into strict 1, 2, 3, …. but these quickly became buckets, there were several #1 items, several #2 and finally some #3.

With the “order buckets” decided we moved onto allocating nominal days. We quickly decided to simply work with 1,000 nominal days. I quickly calculated how many points equated to one developer for one sprint, how many points equalled the whole team for one sprint and a couple of other reference points to help guide the process.

The days were allocated – including an allowance for technical investment – and we were at 1300 nominal days committed, 300 over budget. Now things got hard so we stopped for lunch.

After lunch I expected a fight. But I knew that if the worst happened when we converted to percentages everything would be cut by 30%. Moving to percentages would force any cuts the meeting couldn’t make.

Maybe it was the effect of lunch but these hard decisions were taken quickly, to my immense surprise. The managers concerned could easily see the situation. Once the capacity constrain and work requests were clear the competition became clear too.

Most of all I had succeeded in preventing managers from arguing over who was doing what. There was no attempt to say “Peter will do X and Fred will do Y.” The team had a free hand to decide how to organise themselves to meet the managers’ priorities.

I was delighted with the way the whole exercise went, having tried capacity planning once I expect I’ll be doing it again – I may even build it into some of my training courses!

What do you think? Anyone else done this? – please leave me a note in the comments

Create Beautiful Roadmaps in Minutes – NOT!

Houston-2017-06-26-16-55.gif

Subject: Create Beautiful Roadmaps in Minutes

Body:

Hi << Test Name >>,

I hope you enjoyed reading our guide to product roadmaps.

If you haven’t already built a roadmap in _____, I’d encourage you sign up for a free trial.

Why did this email annoy me so? – apart from the failed name substitution that is.

This e-mail, perhaps spam or perhaps something I did sign up to, landed in my e-mail box the other day and set my blood boiling.

Roadmaps should most definitely NOT be created in minutes. Roadmap should take time, roadmaps should take lots of people’s time.

  • Roadmaps should NOT be a list of features with dates
  • Roadmaps are NOT promises
  • Roadmaps based on work effort estimates will undoubtedly fail
  • Roadmaps describe what MIGHT happen in the future to your product(s) and company
  • Roadmaps should be informed by known events (upcoming shows, purchase needs of potential customers, legislation changes, etc.)
  • Roadmaps should consider how technology changes might play out
  • Roadmaps should consider how your technology can help your (potential) customers with the problems they will have tomorrow
  • Roadmaps should be informed by company strategy and roadmaps will feedback to company strategy
  • Roadmaps should be flexible because the future will be different to any predictions you make

The value of roadmaps is not in what they say. There is a lot of value in what they don’t say – the things that the organization will not do. But the real value of the roadmap is in the creation of the roadmaps.

The act of creating the roadmap brings key people together and exposes them information about the future.

Peter Drucker once said: “We have no facts about the future” but there are probabilities: population changes is one that can be accurately predicted years ahead (e.g. we know how many 20 year olds there will be in 10 years time.) Most legal changes can be seen coming at least a few months out. There are things we can take a view on, there are things we know we don’t know, and things were we need to keep options open.

When key people are brought together they can exchange information and views. They can share their views of the future, they can talk about how they see the future, they can build a shared model and out of these can come a possible future, a possible scenario, a roadmap, which shows how your product will add value to some customers.

Because that’s what a roadmap is: a scenario plan, one or more possible descriptions of the future for your product.

Like so much planning it is the exercise of creating the plan that is the valuable bit rather than the resulting plan itself. This is especially true for roadmaps which are attempting to look far into the future. Roadmaps need to be a mix of prediction and opinion.

Roadmaps should bring people together for a discussion, to hear each others voice and opinion, creating the roadmap should be discussion.

Reducing roadmaps to a few minutes work with a tool destroys the value of the exercise. Any organization that does this has a pretty screwed up idea of collaboration.

Next time you need to create a roadmap:

  • Gather relevant information about the future
  • Look at company cycles, look at competitor and customer cycles, what can you see?
  • Look at technology trends
  • Bring together a mix group of people: senior executives, technologists, sales people and product managers
  • Spend time building your view of the world
  • Consider how your product can help that world and help your customers solve the problems they will have

And repeat the process regularly, say every six months.

You might even build several scenarios about the future and consider the implications for your product in each. Such scenario roadmaps are there to shape peoples view of the future. Your scenarios will probably be wrong and the roadmap will play out differently in the end but allowing people to consider alternative futures challenges them to think differently. When real events happen the fact that people have considered alternatives will mean they are better prepared – even though the future will be different to all your scenarios!

(Museums of the future, future memories, retrospectives and change is a blog post about future memories from 10 years back.)

 

 

 

#NoProjects/ Continuous Digital update

ContinuousDigitalSmallLite-2017-06-16-14-19.jpg

If you are a regular reader of this blog and you’ve not had a chance to check-out Continuous Digital (aka #NoProjects) then I recommend you do! – but then I would say that wouldn’t I? 🙂

I’ve set up a discount coupon so readers can get Continuous Digital for $5 (plus any tax your Government my levy on ebooks.)

Now is a good time to start reading Continuous Digital because the content is done, my arguments are made. From here on I expect its all refinement – debugging. I need to do an end-to-end edit to make it internal consistent and then I need to get it copy edited. (Again as regular readers will know, grammar, spelling and such isn’t my strong point – and it never will be!)

I’m going to add an appreciation page – thats a page were people say nice things about the book. So I’m on the lookout for appreciations, if you have something nice to say about the book please drop me a note and I’ll include your name with your quote.

Stockholm developers & Back seat managers

SL_C20_Gamla_Stan,_Stockholm-2017-06-12-19-50.jpg

When does empathy become Stockholm syndrome?

“Stockholm syndrome is a condition that causes hostages to develop a psychological alliance with their captors as a survival strategy during captivity. These feelings, resulting from a bond formed between captor and captives during intimate time spent together, are generally considered irrational in light of the danger or risk endured by the victims. Generally speaking, Stockholm syndrome consists of ‘strong emotional ties that develop between two persons where one person intermittently harasses, beats, threatens, abuses, or intimidates the other.’” Wikipedia

It is one thing to have empathy with someone else’s outlook but sometimes empath gives way to something stronger, too much empathy not only becomes self-limiting but damaging to oneself.

Sometime when I argue the case for improving software quality – reducing defects, increasing maintainability – programmers start by telling me that their managers don’t care about quality. I talk about the cost and time implications of poor quality, and again I’m told that manager value speed above all else.

Asked who is to blame they point the finger at faceless “managers” who will not allow quality, will not allow the right design, tests, refactoring or anything else which is “good.” Ask what should be done to improve it and they will say “We don’t have time.”

Very, very, often I find myself debating with professional engineers who simultaneously despair at the lack of quality built into their code but claim that the company cannot afford quality. (See my old post The quick and dirty myth.)

Frankly, I think some programmers and testers suffer from a version of Stockholm syndrome: they simultaneously blame others but take on those views themselves.

Maybe it is not Stockholm syndrome, maybe its just a failure to take responsibility.

I actually find it easier to convince managers of the advantages of automated testing and test-first development. I find managers understand that higher quality is faster and cheaper when it is explained to them. I find managers are open to the argument that it is better to do less and do it better quality.

It seems to me that some unreformed managers do hold these opinions and they may well voice the need for speed to programmers. A few might even suggest that testing can be skipped.

But, since when was the manager the expert in the way to develop program code? Managers are managers not design experts, surely that is the programmers job? Many managers know they are not code experts, they know the programmers are.

Of course managers – and other “business” people want results faster – don’t we all? And of course they are focused on what customers want. Is there something wrong with that?

Managers are often in a worse position that programmers and testers because they are answerable to their own managers but lack the ability to do programming work. They are reduced to the position of children in the back of the car asking “Are we there yet?”

Overtime programmers come to share the same desire for speed, the same need to showing something. But since programmers control the means of production they take action, they make compromises with themselves. They cut quality. They skimp testing – after all their own code won’t contain defects. They abuse interfaces, they drop tests, increase coupling and reduce cohesion, avoid refactoring, they live with broken tests and they tell themselves “we can fix it later” even if everyone knows. (Not going back and fixing the things they meant to fix is another example of reducing quality.)

Time and time again I meet developers who do these things and claim “my manager won’t let me”. And I ask inside my head: “Does the manager sit beside them and tell them not to do these things?”

I’ve known managers who have said: “Ship bugs” but I’ve known more managers who haven’t said that.

The view that quality needs to be dropped seems to have two sources: ignorant managers and unprofessional managers who demand shoddy work, and, secondly, programmers who assume a desire for speed is a request to drop quality.

Sometimes I challenge programmers to tell me which managers have voiced the “reduce quality” argument. More often than not they cannot name such a manager. It is the programmers who interpret the managers – understandable desire – for speed as a request to cut quality.

I suspect that having cut corners and reduced quality programmers feel guilt. And that guilt leads them to make assumptions – perhaps even invent false memories – which allow them to pass these failings onto their manager.

I’m not saying managers are perfect or blameless. I am saying I think many programmers are more responsible for problems than they care to accept. (And of course, some just don’t know any better.)

In my mind programmers are engineers; engineers create solutions within constraints and professionalism should guild them to do the best job they can within those constraints.

Managers are like kids in the back seat of a car, if you keep giving them chocolate and telling them you are almost there they will expect more chocolate and to arrive soon. When you stop giving them chocolate and carry on driving is it any surprise they get upset?

Image: Gamla Stan stop in Stockholm by Kabelleger CCL on WikiCommons.

Responsabilisation, Command & Control and Jira

remote-control--SGS-800px-2017-06-6-18-33.png

A big part of Agile is about giving the workers, or rather the team, authority to do their job – putting people into control of their own work. Many people talk about self-organizing and self-managing teams, I prefer to talk about distributing and devolving authority but its all about the same thing.

I recently stumbled across an article discussing an initiative at Michelin called responsabilisation giving factories and workers more authority with responsibility. This French word, responsabilisation, deserves adopting by the Agile community.

What ever we call it, it is:

  • Giving those doing the work, as individuals and as teams, the authority to organise their own work
  • Giving the workers authority to do the right thing
  • Redefining the role of “managers” to allow, and even help, workers make their own decisions
  • And giving the same workers the responsibility for the work they do and how they do it

Again and again I find that electronic work management and tracking tools get in the way of doing this. Electronic tracking tools, of which Jira is the best known, disempower workers and give power, and control, to the tool and those who control the tool.

For example, typically in a planning meeting one person will “drive” Jira. That one person has a keyboard and mouse and controls the screen. They decide what is displayed and they get to create new items, drag existing ones around and ultimately decide what is done.

The others, the rest of the team, sit facing the screen and sometimes at the Jira driver. The driver has power, the driver becomes the manager of the meeting. Rather than interact with each other they interact with the driver and the machine.

Conversely, in a similar meeting using paper and cards someone may well have authority over the cards but they can be moved by anyone. New cards can be written by anyone. People focus on the work and on each other. The conversation isn’t moderated by the Jira driver – it moves.

The Jira driver has power, they have control.

And it is not just in the meeting.

In Jira – and similar tools – someone has to set the tool up, someone has to decide board layout, someone granters access permissions, everyone has a “role” in the software, they are defined by their role.

The Jira admin has power and control.

In the worst cases teams have little power to change Jira because the organization mandates they must set it up like other teams. Again, the organization holds power back.

And since Jira controls the workflow, Jira controls the to-do list, Jira controls the reporting… he who control Jira controls the work.

Jira is not alone in this respect. All electronic tools exhibit this problem. Jira is possibly worse than some because the interface is very complex and acts as an additional barrier to worker involvement.

Tools built on and around Jira make this worse. Supplementing Jira with additional tools makes Jira more powerful and that makes the Jira admins and drivers more powerful.

While Jira produces a mass of reports most people don’t understand or use them. Worse still are those who use the reporting mechanism to forecast delivery dates into the future, because these come from a tool they perpetuate the illusion of certainty.

Electronic tools reimpose the power structures, illusions and control that the Agile movement set out to remove.