Becoming agile

Agile, through the storms

Archive for the tag “Teamwork”

27 May 2013
3 Comments

There’s a lion lurking in the organization

(Or is agile just another way of hiding it away?)

Imagine the following scenario

Fred is a senior developer. The team is doing Scrum for about 10 sprints now, and the ceremonies are kind-of getting into a routine. The team is committing for work to do, and delivering more-or-less what they promised. And yet, Fred is not a happy chappy.

The team is coming to their third release, and there are talks that regression period must be on time, on track this time.

In his frustration, Fred talks to his Scrum Master, expressing his concern that developers must do regression testing yet again in the upcoming regression period. Clearly developers should do coding, and testers should do testing.

Joe, the Scrum Master reminds Fred that regression is for the entire team, not just for testers, and that they are all in the same boat, and that by coding away during regression they are merely adding more technical debt to an already potentially unstable release.

Fred walks back to his desk, muttering “right; and my testing skills are so good, that all bugs will be uncovered. Such a good tester I am”.

What just happened here?

What are Fred and Joe really talking about? What aren’t they talking about?

Given the conversation of these two individuals, what can we say about the atmosphere in this team?

Teams, Organizations and Lions

There is a lion lurking here.

A normal person reaction to seeing a lion would be: increased alertness, increased heart rate and increased perspiration – the automatic physical reaction required for survival in face of danger. This is vital for survival, yet not a pleasant experience.

Therefore, a normal person, having the knowledge that a lion is lurking would act to avoid being seen by the lion: Acting cautiously, refraining from conspicuous and sudden gestures.


Photo by cheetah100 source: http://www.flickr.com/photos/devcentre/327960789/

Let’s relate this back Fred and Joe. Fred might be trying to say: I’m a damn good programmer, and by doing testing, I will be exposing my weaknesses. This is something I am not prepared to do!

Joe, on the other hand, is hiding behind Scrum (teamwork, technical debt) in order to avoid Fred’s issues. He is using Scrum as a defense mechanism against dealing with what Fred has to say.

The thought of confronting these covert issues provokes anxiety. As if Joe is telling himself: I am afraid that if I talk to Fred directly about his subjective experience of being a tester, it may feel as if a lion is about to attack me. I am not prepared to handle such an experience.

Of course, both Fred and Joe don’t necessarily articulate these thoughts to themselves. This, in itself, is too frightening. So they both unconsciously use their survival mechanism not to wake the lion lurking in the grass:

Fred resolves to focus on developing new stuff; Joe is using Scrum to get Fred to do testing, as he thinks the entire team also should.

Dealing with Lions

Is Scrum to blame here? Is Scrum in particular, and Agile in general doomed to fail in such situations like all other organizational methodologies?

I think not. Read more…

Posted in Agile, Human Relations and tagged , , , , , , ,
01 Jan 2013
8 Comments

Don’t reorganize – Deorganize!

Organizations tend to do this every now and again: Reorganize the structure to suit a new strategy, a change in the management team, try out a new hierarchy model, and so on.

In this post I lay out some alternatives, and end with a practical first step.

One of the pitfalls of reorganizations is that they provoke a huge amount of anxiety and resentment: people’s direct and indirect managers change, their role description changes, their promotional path becomes unclear.

I would like to suggest a different approach. Instead of a reorganization, gradually deorganize. Shed away redundant structure, and replace them with loose structures. Allow your organization to grow in response to real market needs, and not according to a decision that was made a couple of years earlier based on data that may have been momentarily correct, but have become irrelevant for today’s reality.

Sounds impossible? Actually, you see such structures every day of your life. When you see ants collecting food for winter, when you see schools of fish swimming together, when you watch migrating birds practicing towards their long flights and when they embark on their fantastic and inspiring far-away journeys.

Waders in flight Roebuck Bay. Photo by Mdk572, Source: Wikipedia http://en.wikipedia.org/wiki/Bird_migration

These structures are not decided upon – they emerge according to changing needs of the group. Even ants have changing realities: when their nest is being attacked or flooded, as well as when they prosper and have food in abundance to accumulate for rough times.

In our business life we like to think that we can create strategies that can predict our organizations’ growth and needs for upcoming years. The truth is as far from this as can be. A good strategy is one that enables the organization to continually change in reaction to its present reality. Read more…

Posted in Agile and tagged , , , , , , , , , , ,
27 Nov 2012
10 Comments

Roles and Irresponsibilities

Organizations are built around structures and boundaries. When you join a new workplace you meet your new manager. Sometimes your manager has another manager, and the other manager has their manager, and so on. This is the structure – in this case a hierarchical one.

Within this structure there are boundaries. You learn pretty quickly what you should be talking to your manager about and what not to. In some organizations you should be telling your manager when you are going to buy a new piece of hardware; in other organizations you might have to ask for permissions; and in others you just buy it, no questions asked. These are examples of the boundaries.


Photo by zigazou at http://www.flickr.com/photos/zigazou76/5809274263/

Boundaries themselves are flexible – they are not a line, a Boolean definition whether you are within or beyond the boundary – rather it is a range. If you are at a customer site, and your manager is unavailable, and you must buy that piece of hardware, you will buy it – even if permission is normally required in advance.

That thing that will normally define your place within the structure and the boundaries within which you operate is your role. And with your role, quite often, come also responsibilities. It even has a nifty name: R&R (and no, it does not mean Rest and Recuperation in this context; R&R stands for Roles and Responsibilities).

This idea is derived from the contributions of Open Systems Theory to social systems, notably the work of Kurt Lewin early in the 20th century, and is still evolving today. In our context, roles and responsibilities that are defined at the organizational level impact the team dynamics – their influence originates beyond the team.

The funny thing is that if you have responsibilities, and others also have responsibilities, this also defines what you are not responsible for.

Take the following example: Read more…

Posted in Agile, Human Relations and tagged , , , , , ,
20 Nov 2012
11 Comments

Pickens and Chigs

Virtually every Scrum practitioner knows the story of the Chicken and Pig. With time you learn that some practitioners adopt a Picken and Chig behaviour. Here are some clues to find out whether such hybrids have evolved in your organisation:

You probably have Chigs if:

  • Some team members do not attend dailies
  • Some team members excuse themselves from retrospectives
  • Some team members attend dailies, but do not participate in the rounds
  • Some of the team’s work is regularly done by non team members, such as experts, that do not see themselves required in ceremonies
  • The Scrum Master is responsible for Sprint Reviews
  • The Scrum board and Burndown chart does not get updated if the Scrum Master does not update them

You probably encounter Pickens if:

  • Your Product Owner participates in effort estimations, although he/she is not knowledgeable about how to make the software or product
  • The time of the Daily Scrum depends on the availability of non team members, such as the Manager or a Quality Champion who’s not on the team
  • Experts, such as managers or architects, make decisions on behalf of the team
  • Team members feel frequently dependent on other teams, such as infra

You probably have examples of your own of such hybrids, who are neither team members nor not team members.

So, what to do?

One possibility is to map out the involved individuals according to what role they play for the team. Then let the Pigs say what they would like to do with the various hybrids. Here’s an example:

+---------+----------+-------------+
| Who     | What     |             |
+---------|----------|-------------+
| Abe     | Pig      |             |
+---------|----------|-------------+
| Sarah   | Pig      |             |
+---------|----------|-------------+
| Isaac   | Pig      |             |
+---------|----------|-------------+
| Becky   | Picken   | Into the sty|
+---------|----------|-------------+
| Jack    | Chig     | To the coop |
+---------+----------+-------------+

The rule is that anyone that enters the sty with the rest of the pigs must play with the pigs – attend the ceremonies, get their hands dirty in making products, commit with the rest. The ones that go to the coop can play with the chickens, but are asked to kindly not interfere with the pigs.

Why is this important? Because for teams to become autonomous, self organised, self learning, all the good stuff you want from a Scrum team, they need to feel safe in their sty. And chickens should be chickens.

Posted in Agile and tagged , , , , ,

Post Navigation