Becoming agile

Agile, through the storms

Archive for the tag “agile”

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.


Source: http://en.wikipedia.org/wiki/Pygmalion_(mythology)

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: http://www.flickr.com/photos/koiart66/3877752234/ 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…

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 http://www.flickr.com/photos/atony/6817452250/

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 http://www.practical-agile.com/training/scrum-training-menu/practical-scrum

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

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…

Agile Architect – What is it?

The Software Craftsmanship in Israel 9th group meeting was held today at SAP offices in Raanana. The format of the meeting was a panel, discussing the merits of the software architect.

Three thought leaders participated in the panel:

The host was Uri Lavi, who skillfully led the discussion.

There was interesting debate on what is an architect, the difference between design and architecture (no one really knows… but I share my view at the end of the post), how to identify a potent software architect, feature teams, and much more. It was educational, refreshing, thought provoking.

During the discussion it hit me – the role of the software architect. To be more precise, the role of the agile software architect.


Photo by Joone Hur, source: http://www.flickr.com/photos/joone/3050331298/

The architect is the person most suitable to translate the business/product language into engineering terms, and the one most suitable to translate engineering terms between various groups.

In contrast, the traditional architect’s role that is to author the high level design, as detailed and accurate as possible. Thinking as an agilist, this more than just waste; Such approach keeps architects on their Olympus, others having to understand what the architect meant to say. Not good.

Instead, the architect should work with the product manager, defining a solid Definition of Done, in order to create the requirements with solution in mind (thank you Eshed)

The architect should work with designers, developers and testers, to talk in their native language, in relevant engineering terms, describing the business needs of the customers, so they can produce the right software.

The architect should view the software, in various stages of being produced, in order to highlight quality issues, refine requirements, adjust the architecture – in other words, respond to feedback early.

In order to achieve the above, the software architect could be the one writing the high level design, creating solution overviews and diagrams, etc. Could be, but does not have to be. The organization might gain more if the architect assists the above mentioned to product all these documents.

One option that worked very well for me is pairing. Very similar to pair-programming, the architect sits together with the product manager to author the requirements; and with the development team to author design and testing artifacts.

In order to achieve that, the good architect will be fluent in the business lingo, as well as a highly skilled engineer.

More importantly, the architect should be a people’s person; someone who is able to work in pairs and in teams; someone who can drive and navigate (a-la pairing) without prejudice.

Regarding the difference between design and architecture – here is my view. Design is an engineering skill. In design we take a requirement and turn it into a blueprint, that will be used later to create the product.

In architecture, we use engineering terms to describe the requirements, without losing the business context.

It so emerges, that in an agile framework the span of the architecture is wider than before. Since we want to keep the business context until as late as possible – and to continue using the business notion in the development team (As a <WHO> I want to <WHAT> so that <WHY> – remember?), the architect is a key for success.

Some will say that it sounds like the product owner. I think that you will be right. A good agile architect will also be a good product owner (not always vice versa).

How do you experience the architect’s role? Do you see the agile architect different to the traditional architect? In what sense?


Post Navigation