Becoming agile

Agile, through the storms

Archive for the tag “Retrospection”

Got lost? Try stopping

One of the anxiety provoking situations working in organizations is getting lost; not knowing what to do next.

Let’s face it, imagine your manager entering the team’s room, when none of you really know what to do next? Not a pleasant moment.


Photo by brewbooks, at http://www.flickr.com/photos/brewbooks/6032820148/

Reflecting on the famous verse from Psalms 121: “A song of ascents.
I lift up my eyes to the hills– where does my help come from?” and the answer immediately follows: “My help comes from the LORD, …

This text is translated literally from Hebrew:

שִׁיר, לַמַּעֲלוֹת:
אֶשָּׂא עֵינַי, אֶל-הֶהָרִים– מֵאַיִן, יָבֹא עֶזְרִי.

(תהילים קכא פסוק א’)

But it could be translated differently. Those of you, who are not Hebrew speakers, may find this strange. I encourage you to check it out, if you sense any doubt:

A song, for ascents:

I lift my eyes, lord of the mountains– From void, comes my help.

Now there is no question. So the next verse is not an answer for the above, it is the next statement: “My help comes from the LORD, …“; maybe the LORD will help me find my way through the void.

Ok, so the manager enters the room, and you are lost. You have no idea what to do next. What do you do?

There is a tendency to come up with a solution, any solution, as long as we are making progress.

Further in the psalm we learn that:

“…indeed, he who watches over Israel
will neither slumber nor sleep.

Once again, the original suggests an alternative:

הִנֵּה לֹא-יָנוּם, וְלֹא יִישָׁן– שׁוֹמֵר, יִשְׂרָאֵל

This interpretations suggests: “…indeed, Israel will neither slumber nor sleep, watching over”

There is, of course, the option of getting help from the manager, from books, from an expert, from The LORD. Those options are always there.

But, hey, from time to time allow yourselves to just Get Lost, watching over yourselves from whatever lies outside.

A few more words on the context: Psalms 121 is about Jacob (aka Israel) running away from his bigger and stronger twin brother Esau. In despair he lifts his eyes to the mountains. Instinctively we imagine what he might think: from where do I get help?!

I guess this is more for you, managers, than it is for teammates. Your team is lost, facing a problem that seems as big as mountains for them, maybe even for you. Yes, they do need your help, but possibly not the kind you are used to. Sometimes they need the space to get lost and build their own help from void, from nothing; to learn from their own mistakes and from their own experience.

There is learning without teaching, and there is teaching without learning. If you notice that you teach your team the same things time and again – try another way. For example, let them learn their own way. In the process you will also learn to contain the team’s anxiety and refrain from automatically offering your help.

Many thanks to my mentor at my studies, Haim Deutsch, staff member in the program, for turning my attention to this notion

Spot the Differences

Everyone’s talking about agile. This is the hype in software development process – the fashion, the Mode. It is so much in the Mode that we sometimes forget that our purpose in life is to produce quality, endurable, appealing software. Scrum, or any other agile framework for this matter, is a means, not a goal in its own right.

A friend gave me permission to share this image with you: Can you spot the differences?

Let’s hypothesize what has happened here:

  • Two error messages were displayed in a very different fashion. Why?
  • Because they were introduced by two separate developers. Why?
  • Because one is technical and the other is more business oriented. Why does this matter?
  • Because there was no one shared mechanism for messages for the user. Why?
  • Because it had to be finished within the same iteration. Why does this matter?
  • Because in agile there is no time to build such infrastructures.

Is that really so?

Scrum is no excuse for technical mediocrity. On the contrary – it is an opportunity to improve, based on two major features of agile:

  1. Scrum does not introduce problems. It exposed them. In this example, this is an opportunity to deal with such a scenario now rather than later. In a traditional project, such a failure can also occur. An iterative-incremental process helps here on two ends:
    – The feedback loop is much shorter
    – A sustainable solution, such as a framework to display messages, can be introduced in the next sprint, rather than the too-well-known “We will deal with it in the next version” (also known as “It will never happen”)
  2. When the team encounters similar tasks, they should identify that they fall into the DRY – Don’t Repeat Yourself, category. When you find you are doing something repetitively, such as forming a message box time and again, this is a good time to make it happen in one place. It may cost an extra hour in the current iteration, but it will save dozens of them in maintaining those messages, should you make general changes to them.

If you are one of the agile-skeptics, I strongly recommend you take a course to learn what it really is about. Especially if you are working in an organization that practices agile – you might be doing damage not only to the organization, but also to yourself. So next time you encounter such an agile-makes-things-worse moment, think maybe it is not agile who is not up to scratch, but your knowledge of it

Post Navigation