Showing posts with label pattern. Show all posts
Showing posts with label pattern. Show all posts

Sunday, December 13, 2015

The next big thing...

... probably won't save your project.

If you have seen the Gartner hype cycle model you are probably familiar with the terms “Peak of Inflated Expectation” and “Trough of Disillusionment”

Hype Cycle
Gartner Hype Cycle Model

While the hype cycle model itself is heavily debated and criticized, I for one see that a lot of “new things” follow this kind of adoption curve.

But why is that? And why is it so common around things as diverse as programming languages (e.g. Java), Infrastructure (e.g. Build Servers), Methods (e.g. eXtreme Programming) and techniques (e.g. test driven development, TDD) to name a few?

What works for Early Adopters doesn't have to work for everybody

One reason I have seen for this is the simple fact that tools in the hands of experts can become menaces in the hands of laymen. This is not only true for things like the beautiful Katana (a Japanese sword) a friend of mine inadvertently used to cut an artery in his arm. No worries: he got treated real soon and has no lasting injuries. And the tatami (floor mats) got cleaned as well by now.
But back to the question at hand – other tools are also often quite dangerous in the hands of the “non-expert.” While it is hard to injure yourself on the sharp edge of the Java programming language, it still is quite possible to use it in a harmful way – for example by over-using mechanisms like reflection, a powerful feature that makes it possible to change the program from within while it is running or change the accessibility of parts of the software.

In my experience this is what happens when the tool reaches the “Trough of disillusionment” – badly trained people start cutting themselves too often and the effectiveness of this tool for the masses becomes a subject of discussion.

In Iado (an art of moving the Japanese sword) there are several ways to avoid the self-injury of the novice swordsmen. They either use a Bokken – a wooden sword look-alike – or a Katana-like thing with a blunt edge, the so called Iaito.

This, to me, seems to be what happens, when these tools reach the “plateau of productivity” – they get blunted down to make it harder to injure oneself.

And of course it works. In a way. With their blunted down instruments, it is much easier to let more people with less training do jobs similar to the ones that the early adopters did. Those early adopters whose efficiency with these tools made the tools so compelling.

But there is a drawback – with a Katana you can easily slice through a steel plate (for example). You just can not do that with a Iaito.

So please – if you use the blunted down version of a tool – don't expect it to still work like the real thing.

Adjust your expectations and always take into account who is wielding the tool.

till next time
  Michael Mahlberg

Sunday, October 04, 2015

Scrum Master or Zen Master?

Another Scrum-Master Anti-Pattern

Well – of course there is not one Scrum-Master anti-pattern. There are dozens.

Let's look at a special one today: The Scrum-Master as the Ruler, the Projectmanager, the Sovereign of the project.

To cut it short – Scrum-Masters are not.
Originally weren't meant to be at least.
Maybe sometimes they actually are – but they should not.

It is about the verb ‘master’

Here is what the dictionary on my computer has to say about the verb master:

2 it took ages to master the technique:
learn, become proficient in, know inside out, know (frontward and) backwards; pick up, grasp, understand; informal get the hang of.

If you look at it that way, a scrum master becomes to scrum what a zen master is to zen: someone who has mastered scrum and now is able to help others – at their request - to become more proficient in what they do.

Of course he also has a lot of other duties as well, but the fundamental idea of ‘mastering the process framework‘ in contrast to being the 'Master of the team' is really a big difference in the attitude.

The Scrum Guide explicitly states that ‘The Scrum Master is a servant-leader for the Scrum Team’, perhaps this is worth taking into consideration from time to time.

till next time
  Michael Mahlberg

Sunday, December 15, 2013

Yes you can (because I think so)

a.k.a. “works on my machine” or “works in my world”

The Situation

Developers declare function after function ‘ready’ and the customer still complains that “nothing ever gets ready” - unhappiness ensues.

Example

This little exchange really happened…

Consultant: “Has the issue #whatever been resolved?”

Tester (customer): “Oh yes, that was the one where we couldn't do #some_important_thing”

Developer (supplier): “That's been handled for ages - you can do #that_important_thing"

Product manager (customer): “No, I still can't do #that_important_thing”

Manager (supplier): “It is possible to do #that_important_thing"

Tester (customer): “I wanted to try it this morning and it is still not possible to do #that_important_thing“

Developer (supplier): “I am sure! I have implemented that. You definitely CAN DO #that_important_thing”(in an aggravated tone)

[one or two more circles like that, voices getting louder]

Consultant: “Ahem...”

Tester: “What?

Developer: “What?

Consultant: “Dear Tester: _In what way_ couldn't you do #that_important_thing?”

Tester: “I don't see any menu entry related to #that_important_thing in my main screen!”

Developer: “Oh - you're trying to do it with your own account! That won't work of course …"

Tester: “There is another account?!? What's the name? Where is it mentioned?”

Developer: “Oups … we might have to work this out a little more …”

And thus both the developer and the tester learned something new about the system and its interaction with the world.

The Problem

The parties clearly communicate on different levels of abstraction – while the developer was referring to the theoretical capabilities of the system the tester was taking about the things he actually was able to do with the system at that point in time.
Abstraction differences like this oftentimes can take days or weeks to become visible, especially if the parties involved communicate intermittently and use media like e-mail or a ticketing-system for their conversations.

A Solution

Go to the real enduser (or as close to the real enduser as possible) and watch her using the newly added system-capability.

Related lean/TPS concepts

Genchi Genbutsu / Gemba Walk

Related values from the Agile Manifesto

Customer collaboration over contract negotiation
Responding to change over following a plan

Related Scrum Values

Openness
Respect

Sunday, November 24, 2013

Expectation Management: Mind the London tube notifications

A real life situation

Munich

A bright but icy winter morning in southern germany: Dozens of people stand on the platform at a local train-stop in Munich's outskirts. The display reads "train arriving". Ten minutes later the crowd is visibly unhappy, swearing and freezing. The first would-be passengers start to leave the platform in search for other means of transportation.

The whole attitude is "We [strongly disklike] those (explicit deleted) responsible for the public transport"

London

A rainy day in England. Hundreds of people walk into the tube station at tottenham court road, quickly glance at the sign that posts the current outages in the London transport system and quickly decide to use the ‘Northern Line’ and the ‘Circle Line’ to get to ‘Victoria Station’ since the ‘Central Line’ runs only at 50% and takes much longer this morning (and is probably heavily overcrowded as well)

The whole attitude is "business as usual"

The Situation (related to the software world)

In a computing environment some resource (a called service, the internet connection, memory, disk etc.) is not available or at its limit and the System just ignores it until it finally fails. (Another version could be planning meetings, where the fact that the amount of work can not be done in the available time (or that some preconditions, like known requirements etc., are not yet met) get ignored until after the deadline hits.)

Example

Almost all software that does not offer sensible graceful degradation strategies and thus shows an error message only after the user tried to access a – probably vital – function of the system. (E. g. E-Mail clients that say "Encryption Error while initiating secure connection to server" after polling the mailbox for two minutes … while the computer actually is not connected to the internet.)
The physical world example is in fact the German railway system (and even worse a lot of the public transport operators) where arrival times of trains and busses are sometimes displayed based on plans instead of the real situation.

The Problem

The user loses trust in the system and either switches to alternatives (e.g. if the system with the un-announced problem is a trouble ticket system the users might start sending mails instead of using the ticket-system, in the physical world people switch from public transport to private cars etc.)

A Solution

Communicate everything you know about probable system malfunctions as early and visible as possible. Plan your outages and be honest about them. Design software with sound graceful degradation strategies.

Related lean/TPS concepts

Andon
Heijunka

Related values from the Agile Manifesto

Responding to change over following a plan Working software over comprehensive documentation

Related Scrum Values

Openness