Friday, June 16, 2017

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

Monday, June 12, 2017

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.

Tuesday, June 06, 2017

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.