Becoming agile

Agile, through the storms

Don’t insult me; I’m too good at it myself, thank you!

I was introduced to the three insults by Yossi Triest during my studies, when he first introduced us to Freud.

He started off with the three insults that the human kind suffered in history, namely the Copernical revolution, the Darwinistic revolution, and the discovery of the Unconscious – the Freudian revolution.

The latter, in its own right, insults us multiple times. It was hard enough if it was all about me, but it strikes us at the organization level as well. Here’s how.


The first insult: There is an unconscious

To begin with, there is an unconscious. So what, big deal, everyone knows that, you might say. But is knowing enough? The fact of the matter is, that everyone you interact with has an unconscious, that doesn’t want to be known, yet does havoc to the individual. As members of organizations we have a desire that everything will work according to logic and structure. If not everything, then most. How many times have you heard: “It is acceptable to make a mistake – as long as you do not repeat the same mistake twice”. That statement inherently assumes that once we made a mistake, we can consciously learn the lesson, and assimilate the new desired behavior.

So why is it that people keep ‘forgetting’ to check-in? Or let people ‘push their button’ and they lose their temper? Or they do a lousy job just when they prepare a demo to the CEO, although normally they are top-performers?

More often than not, the reason is that unconsciously some internal process brings this behavior about:

They ‘forget’ to check-in because they didn’t get a pay-rise, they are frustrated, and as much as they try to act reasonably, the unconsciously try to get-back at the organization.

When you talk to them you unconsciously remind them of their mother, and the anger that they do not afford themselves to let out on her, comes out on you

Because they work relentlessly to satisfy customers, and deep inside the fact that the demo for the CEO is really important for you, does not impress their unconscious, the little monster within that cares about their own TLC. If you need TLC of your own, says Mr Id, prepare the demo yourself!

But that is part of the story. Because as much as we think of ourselves, the experienced, rational, as in control of our own mind, the fact of the matter is that…

The second insult: I too have an unconscious

It does not help that you know about the unconscious, you have read all the writings of Freud, Klein, Bion, Winnicott, Kohler, Piaget, and you can read them backwards by heart, you too have an unconscious. So do I – and I don’t need to read 0.01% of the available materials to know it.

I too sometimes forget the most important task, or delay things forever. Some of it I can understand, some of it I don’t, and some of it I am not even aware of. It all happens unconsciously, without me, Ilan the person that I am, knowing that I am doing it.

This is not only frightening – this is insulting! I might, and I will sometimes make the same mistake more than once, despite that I have a strong desire never to repeat that mistake again.

I will sometimes forget to mention the person that made the biggest effort in the last sprint – maybe because I am jealous of him or her and their achievements.

I will sometimes be unkind to my own manager – maybe because he or she pissed me off, and I didn’t do anything about it

And if only it was an excuse for me to feel better with myself. Hell no, I will feel guilt; I will feel shame; I will feel diminished. And why? Because my unconscious makes me feel that way. Damn, is there a way out of this?

Yes there is. But you will not like it because…

The third insult: In order to be made aware of my own unconscious, I need others

The unconscious works overtime, but it is invisible to the individual. For example:

Here’s a hypothetical scenario:

My manager really pissed me off in the last appraisals. Since I think the appraisal process is, pardon me, oxen-dung, I decide not to respond. But it was two months ago, so who remembers? (Guess who!)

  • My manager: “Can you send me the presentation on this and that? I must have it for the management review at 14:00 today”
  • Me (abruptly): “Look, I’m really busy – ask someone else”
  • My manager: “Well, someone’s got a chip on their shoulder! Anything I did to upset you?”
    (Actually, yes, but who remembers? Same guess!)

Without the interaction with my manager, I would not realize that, unconsciously, I still hold grudge. Moreover, it is easy for me to ‘deposit’ the feelings of aggressiveness and selflessness with my manager, not realizing that I am doing it myself.

In this simplistic scenario above, I describe the concept of projective identification, a mechanism that helps individuals not to deal with the negative aspects of their own by finding their expressions in others. Conversely, finding desired behaviors we wish for ourselves in others.

In organizations this takes place all the time. The Pygmalion Effect that causes individuals the way others expects them to is an indication of a gap in the organization which is hard to integrate – unless it is being made visible.

Sometimes these gaps bring tension that causes things to move in the right direction. However, frequently, it is the other way round; and then the organization veers away from the primary task into sidetracking in various ways (“if only everyone gave more attention to our velocity, everything would work so much better” – is velocity really what you are looking for?)

Reflecting that these gaps exist, and working with them towards integrating the ‘good’ me with the ‘bad’ me that I identify with others – this is something that requires intervention; especially if the organization is now in ‘defensive mode’ and is not attentive to such processes.

Now, as you reach the end of this post, seeing that, like others, I need you to acknowledge my own unconscious: What can you detect that I may have unconsciously tried to say?

Bread Scrums

There are many reasons to go SCRUM in particular or agile in general. Each organization will have their own reasons and motivations. According to the 2011 State of Agile survey, top three reasons are to increase time to market, to cope with changing priorities and to increase productivity.

The question is, how do you know that you are getting there?

The default answer for most is KPIs. Measure it, and you will know that you are there. The problem with measurements is that they are very elusive. You want to measure one thing, and ending up affecting another. Regardless of the measurement, you may impact something that you didn’t intend to.

Why is that so? This is because when you measure things, you leave a trail, and this trail is not merely the guide to go back, it is also the guide to go forward, a kind of a forecast to the next target.

In fact, a trail is more useful to going back in order to fix things, rather than to predict where to go next. Take breadcrumbs navigation: It helps you go back in the application to re-navigate; it also helps you navigate faster on successive uses of the application. But it doesn’t help you predict what you are going to do. It can help you measure what users are doing most, in order to improve the navigation. Like in Hansel and Gretel, the kids wanted a trail back home, not a guide to go forward.

Source: by koiart71

Take an example. Many teams use velocity as their planning tool. They use the amount of done stuff, in relative size, in order to plan how much they can sensibly fit into the next iteration. It is a planning tool, not a measurement.

Yet, organizations try to use this velocity to do more than planning. After all, velocity can be a good measure for productivity or even predictability, can it not?

Yes, if your organization’s main business is velocity. When were you last asked by your customers: “For the next release we would like to order 54 points and 21 epics, please”? Is this the kind of predictability you require?

Check out Smith and Jones Predictable Lighthouse sketch – are you convinced that predictability is something you welcome that much anyway?!

What kind of trail can you use that will record something deliverable, and not an artificial, game-able, number that can have collateral impact that is potentially undesirable?

Let’s examine few of the options:

  • Velocity: Dear team, please provide more story points.
    No problem, dear manager. We’ll just skip all those tests, and the number is set to increase. Given that we do not provide the support, escaping defects will be anyway handled elsewhere.
  • Predictability: Dear team, please provide a consistent number of story points.
    No problem, dear manager. We’ll just provide the same number of points. When something big comes in, we’ll just bloat the estimate, so we don’t have to deal with breaking to smaller stories.
  • Cycle time: Dear team, please provide a standard ratio between points size to the time to develop it.
    Now here’s a good one. Cycle time can actually be a rather useful trail. But only if you consider it from a systemic point of view – which makes it much harder to measure. Otherwise, it may become similar to velocity

The problem with all the above is that it mixes several concepts into one number. The trail and the measurement are not one and the same. This is why using points or velocity as a measurement is risky. It becomes goal in itself, rather than means to a goal.

A much preferred trail is executable specifications, developed and described by Gojko Adzic in Specification by Example.

In such a trail, for every story you specify, in business context, WHAT is the system expected to do. This specification is turned later to an executable sequence that will verify that the developed code does WHAT it is expected to do. Note, that specification by example is not about HOW, it is about WHAT.

This makes a trail of business rules that have been proven, and are now part of our regression suite, and upcoming trail that is what business rules are to be proven in the coming iteration. In an analogy to the breadcrumbs navigation, where have we navigated so far, and where are we navigating to now. Note that over specifying (forecasting several iterations ahead) is likely to become waste.

Recall from the top of the post, the trail helps you go back and make corrections. In this executable specification trail, it enables you to either fix business rules that got broken due to changes, or to remove redundant rules – and code, in order to navigate better in the future.

Coming back to measurements – this trail is not a measurement. It is a trail.

If you must measure, try to check, for example, how many routes you are navigating on concurrently. WIP can be a good measurement for that. Yuval Yeret has a good explanation of WIP and using CFD to measure it. Once in place, you can start measuring also cycle times, but as a supporting tool for your WIP, not as a guide to limit story duration.

Alternatively, try to use Agile Earned Value Management (EVM). You may read about it in Tamara Sulaiman’s article here. While Agile EVM is useful for planning against budget, it has some hidden assumptions, such as scoping for the entire release.

The merits of one measurement or the other is the subject for a separate post. I will just comment that I like these measurements more than others because a) they are good tools for decision making, and not merely measuring; and b) indeed they are based on the trail but not measuring it.

As long as you remember that the objective of the trail is to correct yourself – to make the right decisions, you will be ok. Don’t force measurements if you cannot effectively use them for decision making.

Otherwise, you may find that you were hoping for breadcrumbs and instead of SCRUM you we left with, well, just the crumbs and no trail.

Group Relations Conferences and Agility

My first encounter with the Group Relations model took place more than ten years ago, in an International conference in February 2002. The conference, nicknamed The Tavistock after the organization that invented the concept, was a turning point in my professional life. It was then that my career path gradually started shifting from the engineering domain to human relations.

Statue of Sigmund Freud and Tavistcok main clinic in the background. Photo by Mike Peel, Source: Wikipedia

Last week, Elad Sofer and I, two of the three partners in Practical Agile, participated in Ofek’s Group Relations Conference, which took place in the Galilee in Israel.

Although I had no idea what will happen during the conference, I had two hypotheses on our participation in such a framework:

  • Early on during the conference, Elad will engage with the model of the conferences and the Tavistockian thinking (which was already familiar for me before)
  • Both Elad and I will have a different type of influence, that will be enhanced by our participation as a pair

Both these hypotheses stem from a belief that while the models of agile software development and of group relations are very different, they have similarities on how they perceive systems, and in what they set to achieve.

In addition, for me it was a first to participate in such a conference together with participants with whom I interact regularly, and I have had ideas on how this might affect our experience.

Here are a few of my observations – Read more…

Games should be taken, well, seriously!

The 8th Agile Practitioners IL meeting took place on May 30th 2012, at SAP offices in Raanana.

Loyal to the title of the meeting, Agile Playground, we played two games highlighting agile values.

The first game was based on Alistair Cockburn’s version of James Shore’s Offing the Offsite Customer game. It is a fantastic game to experience many aspects of agility: iterative and incremental process, inspect and adapt, short feedback loops, and many more. To me, when introduced by Alistair Cockburn in the 2009 Scrum User Group, I have learned on agile requirements in less than an hour more profoundly than many other learning opportunities I have had before and after.

Judging by the discussion that followed, participants devoted themselves to the session, and I hope we succeeded to have similar influence.

In the second part, Lior Friedman facilitated several estimation techniques, including planning poker, silent sorting, and relative sorting. Not surprisingly, this exercise proved once again that absolute estimations yield vast variance between individuals and teams – up to 10 fold, compared to relative estimations that yield in majority of cases not more than one notch difference between teams.

In the video below you may see a very uncommon sight in a group of Israeli software experts: a large group of more than 30 people exercising silent sorting

We would like to thank our hosts at SAP Israel for their warm hospitality, and, of course, all participants, loyal patrons as well as newcomers for coming to the group meeting

See you in AP_IL #9


AP_IL #9 and AP_IL #10 are already planned with contributors from the community. Follow our linked in group Agile Practitioners IL to find out who is going to be there.

If you would like to share, or you would like one of our sessions to focus on a specific issue – please let us know – These meetings are all about sharing the agile culture with all of us!

What does a butterfly say at the end of the day?

Hindsight is a strange thing. In hindsight it is easy to criticize. It’s unimaginable to find someone still convinced that the world is flat. It’s easy for us to say ‘how didn’t the US see Pearl Harbor coming?’

Of course, we have something that those that didn’t see all this didn’t have: hindsight.

Photo by AntoGros

Quite naturally, there are things for which we do not have hindsight: will this release be successful in marketing terms? Will this new product live to its promise?

Within a given time period, we will be able to say whether the release was successful, or whether this new product made the impact we anticipated for it. But then it will be easy – it will have become a past event, and we will be able to do nothing about what happened prior to the event.

This is a problem that can never be solved. No one will be able to tell you with certainty what will happen in the future. On the other hand, you could get a good estimation of it.

Say that the release is scheduled for one week from now, and we have not even gone through 50% of the progress, and we have been working on it for 8 weeks already, and nothing is working. One can say, with a fair degree of certainty, that marketing success is somewhat not plausible.

If, however, we would have checked after two weeks whether the work we have done so far is working. And we will have continued every two weeks to make similar checks, we could, quite reasonably have reached 80% progress after 8 weeks. Knowing that these 80% worth of software is working according to the customer needs, we would be more comfortable to say that we might be successful in marketing terms. Right? Well we cannot be certain, but we will have a better chance.

The same with the new product; if we have a group of business users having a look at the product every two weeks, we will be better positioned to estimate whether it will live to its promise. Right?

This is not hindsight. Not even close. But it provides a better starting point at the time we need to provide such estimates.

This is what agile is about. Getting shorter feedback loops, so we can make decisions earlier, so we can prepare ourselves and gear ourselves with relevant empirical data.

Meticulously planning ahead of time provides nothing except having theoretical plans. Redefining the plans according to the future, as it changes it shape due to current event, will help us face this future more prepared.

Therefore planning is good, as long as you don’t overdo it. In contrast, Reacting to events will prepare you better for the future. This is counter intuitive for many of us. But think of butterflies – if they plan their day, it will be a disaster for them. They only need the grand plan; No details. Then observe the environment and react.

In the language of the Agile Manifesto: Responding to Change over Following a Plan

So what does a butterfly say at the end of the day?

If only I know this morning what I know now!

Suggestion Box

How do you get your team to become innovative? To generate new ideas?

Our default intuition is to ask people what they would like to improve. Well, this is good, but the real question is – is it good enough?

Take this photo, for example. How effective would it be in generating good suggestions? How sustainable will it remain over time?

Photo by Sethoscope

Our intuition tells us that if we tell others to do something, they will do it. However, we rarely apply the same intuition on ourselves. Say someone else put the suggestion box – how inclined would we be to participate and contribute new suggestions?

A learning team needs to nurture a learning culture. Think of those two words: nurture, culture. This implies that we need to cultivate it, and provide the fertile grounds for it to sustain.

Recently Mark Levison provided us one example of how to overcome technical debt and to increase the team’s evolvement and evolution into a team that learns how to learn.

He has used Michael Feathers’ brillirant book, Working Effectively With Legacy Code, to try out techniques of carving out problematic areas of our code, and refactoring them into code that is more maintainable and sustainable.

The point is one of courage. Will you be the first to lead this change? If someone is already leading such a transition, or attempting to, will you be courageous enough to join the ride? Take Derek Sivers‘ short clip about the underestimated kind of leadership – being the first follower.

Courage, as I have found out, is something you realize in the aftermath. Looking back in retrospect you say to yourself – “Where did I find the courage to do this?”

The order “Be courageous” in that sense is about the same as saying – put your suggestions in the box. If you are looking for courageous people, think whether you, as a team, are cultivating the atmosphere for such behaviors to emerge.

Not sure how to start? Make the first courageous decision, and get educated on the values, principles, and practices that will get you there.

Taking a good SCRUM course may be a good starting point. My colleague Elad Sofer is running a SCRUM course at the end of April (as do several others in Israel, and many around the world).

Register to this course at the course website at

If you feel courageous enough to improve your retrospective skills, try our one day workshop

On the merits of rituals

One moment before Passover start. This photo is probably meaningful to most of my readers. Come Passover, all food that contains, or is suspected to contain, flour and yeast is to be removed. At the workplace in many occasions it is simply covered up to avoid accidental use of such food products. At home, the religious practitioner will meticulously clean the house until all crumbs are properly removed from the house.

There are disputes as to the essence of this activity. Many seculars see this as a futile exercise. Atheists may see this as nonsense. But for the religious individual and family, this is part of the essence of being Jewish. Make no mistake, for the Jewish religious practitioner, Done is Not Done if a minute piece of Khametz, bread, cake, or even plain flour, is not taken out of the house well ahead of Passover.

As for these vending machines: Someone has to remember to take care of all the Khametz before Passover, and all the items that must be handled for this. The coffee jars, the cutlery, the bread baskets, the refrigerators, and even the vending machines.

It takes years of experience to remember to cover everything, and to develop the routine to recall and attent to everything.

And yet, when staff changes, nothing it left forgotten. Part of the routine is its craftsmanship to ensure that this is not dependent on one individual or another. Instead, it is the responsibility of the maintenance team to ensure that everything is taken care of, year after year.

Immediately after Passover, the regular coffee jars will be returned, the refrigerators will be filled with Khametz all over again, and the vending machines will also not be left unforgotten, and will be uncovered.

What are the rituals that you already do, and the ones that you wish you had, in delivering new software? What is not left forgotten even if you do it only once a year? What are the things that you tend to forget, but are important for you?

What will you do this year to get the rituals into the organizational rhythm, so you do not forget it next year?

Happy Passover, Happy Easter, Happy holiday season to all

The Economy of Scalability

It is one thing testing a standalone application, or a monolithic website. It’s quite another testing a platform capable handling millions and trillions of events per day. In the same token, it is one thing verifying the user and install guides of a mobile app. It is quite another verifying a mammoth document of a system consisting of thousands of complex operations and endless configuration options.

Indeed, with an agile mindset much of the overheads can be dramatically reduced. In similar concepts of identifying the impact of a single class on the entire build, it is possible to analyze the impact of altering one operation on the entire document repository. But such large systems rarely have anything near good coverage of the documentation to carry out such an analysis.

Welcome to the world of non-functional testing. What comes naturally to small organizations becomes a problem in its own right in larger ones. The examples above are just two of a much wider scope: Platform combinations, multiple UI channels, operational aspects (such as EOD or backup and recovery) – all become big issues in large systems.

A few compelling ideas to handle such challenges will be presented in the upcoming 7th Agile Practitioners IL meeting on April 17th at WebCollage offices in Tel Aviv.

During this meeting Karen Schlaien will share her experience as a testing director at Amdocs.

The presentation will be followed by a cool game of testing. As always, refreshments and mingling are an integrative part of the event.

Sounds interesting? Hurry up and register here.

Participation is free of cost, but tickets are limited.

Photo by Matthew Wilkinson

Agile Practitioners 2012 – Less than a week to go!

I’ve been pretty quiet lately, and for a good reason too. Together with two of my mates, Elad and Lior, we’ve been busy creating the Agile Practitioners 2012 conference.

Before I tell you more about it, I want to let you on a little secret at the end of this post, so please read on!

Read more…

What kind of software engineer do you want to be?

Software engineering is defined in Wikipedia as follows: “…is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software, and the study of these approaches;” and so on. Intrigued by ‘disciplined’ in the definition and lack of it as seen in some organizations, I wondered how is this seen in other professions. Say, an airplane pilot, for example. What are the differences between learning to ride a bicycle, for instance, and learning to fly an airplane?

Therefore, I was reading through the Airplane Flying Handbook to figure out what makes a good pilot?

Not surprisingly, the following text, extracted from the handbook, it found at introduction chapter: Read more…

Post Navigation