Becoming agile

Agile, through the storms

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…

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.

I’m feeling a little… insecure

This is an operator’s nightmare: security breach leads to information theft leads to direct or indirect damage. Someone hacked into the information systems, and stole credit card numbers or other sensitive personal information; alternatively someone hacked into the information systems, and deleted vital records.

Whereas the latter has higher chance of being revealed rather quickly, the former may be done in stealth, over a period, creating undetected damage to revenue, reputation, or even to personal security and privacy.

What a mess!


Image by elhombredenegro at http://www.flickr.com/photos/77519207@N02/

It is therefore only makes sense that operators invest considerable amounts in security systems such as firewalls, malware detection, and backup.

However, this is only part of the story. Read more…

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

Laundry

My wife went on a one week break last week, leaving me to deal with three kids and a hectic week at work. I wasn’t concerned much with the situation, apart from one thing that I dreaded: laundry.

Photo by T.M.O.F at http://www.flickr.com/photos/freebourg/2219601376/

To begin with, you must understand the laundry cycle at our humble home. Let me draw a picture for you:

Everyone in the family dispatches new laundry to the work queue. That is, my missus and I place it in agreed baskets, and the kids just happen to drop it some place around the house: bedroom, corridor, washroom (not to be confused with washing room!), backyard, kitchen table – anything goes. Occasionally kids misplace laundry and place it in the washing room itself, but I attribute it to a temporary lapse of kidsism. Read more…

To the team, and beyond!

For the second year in a row, the Agile Practitioners 2013 conference is on its way, scheduled for early next year.

For starters, save the date! On January 29-30, 2013, at Kfar Hamaccabiah near Tel Aviv

The theme of this conference is “Agile Beyond the Team”

Hyde Park Corner tube station, photo by Mike Knell

We give much focus to the team in our work. Sometimes we call it development team, and at times implementation team – to refrain from making assumptions on the team itself.

This time, during the conference we wish to explore the teams’ eco-system: what do we need to provide within and outside our organisations to get teams to thrive in an agile culture.

Do you feel you have a say? Would you like to share your expertise? Maybe you have a view on management or on leadership or on software architecture or on people skills or on complexity of human systems that you wish to share? Any other related subject is, of course, also welcome

We have opened a Call For Papers for people like yourself, who wishes to spend up to 45 minutes influencing people for make this agile world just a little better.

Got you interested? Follow the link, fill in the form, and tell us what you want to talk about!

As a speaker, should your idea make it to the programme, you will be entitled to a free admission to the conference 2nd day, and to a 50% discount on the workshops during the 1st day (Details of the workshops will follow soon).

If you wish to follow and get updates on the conference, you can register via the conference’ main page.

 

May your PSP taste like honey!

For the coming new Jewish year, celebrated this coming Monday:

May your user stories serve as fruitful dates between the product owner and the team

May your team produce and refactor small working artefacts, as many as pomegranate seeds every sprint

May your daily stand-ups live to the proverb “An Apple a Day Keeps the Doctors Away”

May your value stream continually flow like beans grow

May your team learn from failures and successes and adapt as nature does

May your PSP taste like Honey!

Happy Jewish New Year!

Becoming Agile on Becoming Agile

I am sharing a post from our LinkedIn group on how to commence your journey:

Original Question:

How to establish agile development in a very tight and constrained department

I have been studying Agile development (Scrum in particular) and wish to implement it within my team. Team is around 20 over developers, QA engineers and several key role personal (DBA, S.A,B.A and such). Problem being the team turnover rate is high. To add more complexity to the situation, lots of delivered products require CRs and bug handling while new assignments keep piling up, and the team keeps answering customer care 30%~40% of their time. 

Is agile good for this situation? Is working in “small” amount of work units the answer to better productivity? I have my management full support to move the team forward into agile development yet I find it hard to drive it given the conditions described above. Any advice from the masters?”


Photo by Schplook at http://www.flickr.com/photos/45040273@N02/5444960010/

My response:

@****, I am starting from the last part of your statement: You have full management support, which is wonderful. It means they trust you to make changes that are good for the organization. You will need to find out whether this includes also management commitment, that it, are they willing to change to accommodate your changes. If they don’t you will need to adapt in order to become agile while still answering their needs.
As for becoming agile:
The complexity you describe exists in many places, in many different manifestations. You will need to find a way that is suitable for your context. In order to do so, you will need to experiment, and find if what you do works well for you. If it doesn’t, you will need to design another experiment. If it does you will design experiments to make it even better, and to adapt to the changing reality.
The big question you must be facing now is HOW? How do I even begin to design the first experiment?
In order to design good experiments, you will need to acquire knowledge – both practical and theoretical. What makes an organization become agile, and what diverts it away from agility?
This can be done through experiences – courses and workshops. Practical Agile (my organization) runs such courses. Find out more about it here. Of course, there are others to choose from.
You can also read books. Shirly just posted in this group Agile Bench’s list of books by category.
I have recently posted Jurgen Appelo’s 100 most popular books on agile

What’s your idea of becoming agile?

If you’ve got your own ideas of effectively becoming agile, please share them! You can either share them as responses here, or, even better, respond directly on the post in LinkedIn, to help the guy by sharing your way. If you think I am wrong, or maybe not good enough in my response, heck, you will also help me grow better Agile Practitioners

Just like riding a bike

I have heard more than a few times that games and simulations in training courses are irrelevant – specifically in Scrum and other agile courses. That doing Scrum using Lego bricks is too simplistic and does not represent real life in any way.

Similarly I have heard, and keep hearing, that the agile management tool should be selected early, even before the implementation starts. The rationale is that individuals need to learn the tool and become familiarized with it before they learn the rules; also that the tool will imply limitations that must be integrated into the process.

Photo by boegh
http://www.flickr.com/photos/boegh/5676964602/

Empirical research suggests that this is not quite the case. Actually quite the opposite may be true.

I am starting my argument with a reference to series of experiments on rats, researched and partly conducted by Edward Tolman. In Cognitive Maps In Rats And Men, Tolman describes how rats learn a map in their mind. It is an interesting read, written in an easy to understand language, even if you are not in the habit of conducting research on social science.

Tolman describes, in one set of experiments, how rats that learn a maze without being stimulated (“incentivized”) to reach a food-box, improve their performance once food is presented – at least as much as rats that were stimulated for food from the first attempt. Moreover, some rats have learned the approximate location of the food-box and jumped out of the maze, running in a straight line to their goal. That is, rather than learning only the correct maze route, they also concluded the spatial location of the food-box.

This last spatial map has also been researched and is described in the same article. Even when the maze was subsequently blocked, and the orientation of the experiment setting turned 180 degrees, most rats figured out the location of the food-box relative to the room. That is, the rats understood where they want to get to, rather than how to get there.

The term Latent Learning describes this ability of learning without having to express it immediately.

Additional research proves that squirrels remember the location of their caches, not merely using smelling as a guide. See Jacobs and Liman research as one example for this. Moreover, squirrels returned to their own caches, not to nearby caches of other squirrels.

Initially these experiments tried to refute the ‘hard core’ behaviorists that suggested that learning can only exist when sensual stimuli is present. But they brought, as Tolman’s title suggests, a deeper understanding of learning and remembering.

How is this related to the title? And why do people think that learning by simulation or that changing agile implementation tools is not productive?

I believe that this is related to a common human dysfunction, a cognitive bias, called Functional Fixedness a term coined by Karl Duncker. This is the opposite of out of the box thinking: Say you are on a phone call at the office on your Android device, and the other party asks for a phone number stored in your phone book. Some people will search for the number on their phone, having to stop the conversation momentarily. Where is the functional fixedness? Since you are at the office, you could login to your Google account on your computer and get access to the entire phone book from the Contacts application, since Google automatically synchronizes phone and Google account.

The funny thing is that we are convinced that others suffer from Functional Fixedness more than we do, and we attribute others with tendency of not being able to change from one tool to another. The fact of the matter is that we are all functionally fixated at times, just like any other person. At the same time, we all have capacity to learn cognitive maps, and are able to adapt, just like any other person (even like most rats, as it turns).

So if you are embarking on an agile journey, and considering a tool, start by using a physical board and sticky-notes. Experience shows that introducing a CR (Change Request) to the physical board has an incredibly better time-to-market response, at a fraction of the cost, compared to changing other software based tools. Yes, even if this means making configuration changes to a free tool (as someone will have to spend time making and testing these changes).
Even when distributed teams are involved, the cost of a HD camera and Skyping daily stand-ups will be much cheaper than any online collaboration tool.

Now, please don’t get me wrong – I think that tools are important; and the bigger the organization the more important they become for visibility, collaboration, continuous planning and more. But it is much easier to make mistakes on a physical board, and start afresh next iteration, than carrying the history of your mistakes for numerous iterations to come.

Similarly, the importance of simulations during training course and workshops is immense. There is huge value in practicing though games and simulations while you are in learning mode, in Beginner’s Mind or Flow. Running several Scrum sprints in a couple of hours will help you practice Scrum while you are focused on learning it. When you learn Scrum on the job, while you are busy with yesterday’s bugs, where to eat lunch and your upcoming appraisals is rarely as effective as learning during a training course.

We tend to believe that we are rationale beings, not affected by patterns; that once we tell ourselves to try out a new thing it will work right away. Evidence suggests that our minds are more complex this. Learning the principles of agile using simulations and then practicing through one tool later implementing another appears to work. Just as learning to ride on a training bicycle and gradually advancing to specialized models.

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