Becoming agile

Agile, through the storms

Archive for the tag “learning”

CoachRetreat – There is such a thing!

Imagine you are in an important meeting with someone, say a frustrated team member, and as soon as the meeting is over you think to yourself: “DOH! That was not how I meant it to be. I wish I could do it all over again”. Sounds familiar?

Well, sometimes you can!

It is called a CoachRetreat, and it allows you to try out the same situation multiple times, in several coaching techniques.


If have been very fortunate to co-facilitate with Yves Hanoulle such an event at the end of January, the third of its kind and the first in Israel.

More about this event, and also where do you need to do to attend one later in this post. If this is what you’re after just scroll down to Upcoming Coach Retreats – I will not take any offense 😉

First – what is it?

The idea came about from Oana Juncu and Yves Hanoulle, and is derived from combining two ideas Code Retreat and Coaching Dojo.

What’s a Code Retreat? It is a day-long event, during which participants work in pairs to solve the same kata, a programming problem, in several techniques and constraints. The solution to the problem is known, so participants focus on learning and excelling their engineering skills, and having fun at that.

What’s a Coaching Dojo? It is a short session, during which participants work in a small team to solve a kata, a coaching situation, they choose. One person or more are the Seekers (e.g. person or team seeking a solution to their problem), one person or more are the coaches, and the rest are observers. At the end the debrief together. So it’s taking a normally frustrating situation, and practicing it in a fun environment and getting timely feedback from peers.

Add 1 to 1 and now you have a Coach Retreat: It is a day long event, during which participants choose a kata, a coaching situation, and practice it in small groups multiple times during the day in various techniques.

How does it work?

The day begins with a short introduction and check-in (“Sad, Mad, Glad, Afraid“)

The group then chooses a kata.

The group then repeats five times:

  • Explain a technique in the large group
  • Split to small groups
  • Repeat 4 times:
    • Simulate the situation of the chosen kata in the learned technique
    • Debrief
  • Debrief in the large group

During the event participants are encouraged to contribute to a A-Ha wall – sharing and posting on it those insightful moments they have had during the day.


A-ha wall. Find more photos at http://www.flickr.com/photos/yveshanoulle/8437662905/in/set-72157632673041156

At the closing of the day there is a general debrief in a Circle of Questions.

The following coaching techniques were tried out during the event in Israel:

  • Solution Focused (or Futurespective, or History of the Future, if you like)
  • Yes And
  • Appreciative Inquiry
  • Pair Coaching
  • Click Rewind
  • Crucial Confrontations

You may read more about these techniques, including links to more details and proposals to additional ideas in the CoachRetreat website here.

At the recent event in Israel we managed to do more – something I personally feel very happy about: the Coach Retreat was sponsored and participated by three competing agile consulting organizations: Agile Sparks, Agile Planet, and our company Practical Agile. So participants could benefit from the knowledge and advise of six professional agile experts, working together in the same event. Following the success of this event, I hope to see more collaborations like this between us.

The CoachRetreat was great fun. I truly believe that fun at work is significant enough to mention it first – when we feel fun we work better and learn better. Certainly it helped this event become successful. During the day and afterwards I received feedback that the day is very meaningful for them – indicating that the format is generally good.

Sounds interesting? Do you feel you should attend one?

Upcoming Coach Retreats:

London on March 16thhttp://skillsmatter.com/event/agile-scrum/coach-retreat. The event takes place at Skills Matter eXchange, and facilitated by Oana Juncu and Marcin Floryan.

Belgium on May 11thhttp://www.co-learning.be/CoachRetreat/11052013. Exact location to be defined. The event will be faciliated by Yves Hanoulle.

If you are interested in organizing a Coach Retreat in your community, please do not hesitate to contact either:

Oana: @ojuncu

or Yves: @YvesHanoulle

or me: @kirschi_


Advertisements

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…

That’s the Waze, a-ha, a-ha

On virtually any trip I make by car, I open my GPS APP, Waze. I do this for a number of reasons: It’s social, it’s a learning experience, it is a good investment and, yes, it also helps me get there effectively and on time.

Such investments and learning opportunities are relevant for organization life as well. If you don’t make these opportunities, they will not happen on their own. Just the same way that if you don’t open Waze on every trip (longer than driving to the corner shop) you will not know if you are getting into heavy traffic or heavenly clear roads.

For those of you who are not familiar with Waze, it is a GPS mobile application that provides near-real-time data on traffic. The way it works, is that is collects data from active Wazers on the road, and uses it to calculate traffic speed. It also enables users to report on important events, such as obstacles on or near the road, weather alerts, police presence, and more.

So it is quite clear why it is social. It is also clear why it helps me get to places. The question remains what makes it a learning experience, and what makes it a good investment.

The learning comes from improving my ability to plan things ahead. I learn what routes are better at what days of the week and times of the day. Yes, I can also do it by recording the data myself. But by having some preliminary data at the start of the trip, and validating it as the trip unfolds, helps me make better judgments on the same trip and on subsequent trips. It also helps me realize ahead of time whether I need to make a decision – for example to call a client that I am going to be late or early.

The investment is in contributing continually to improving this near-real-time data. When I open-up Waze I provide this data to others, not only to myself. Likewise, other Wazers help me by merely using the service. In fact, one of the main reasons that I acquired a smart phone in the first place, is to be able to use Waze. That was an investment too.

As it turns out, not surprisingly, the closer I am to the target, the better the accuracy becomes. As someone once told me about product development: The longer it is, the harder it gets.

A long trip is not quite as predictable as a long trip:

Different routes have different speed characteristics and different slowdowns:

Indeed, these kinds of investments are true for other aspects of life, not only for using your smartphones.

It takes a lot of learning to understand that planning is not a one-off activity per release or per product version. It is something that takes place continually. The more planning you do, the more you understand whether you are going to meet your interim milestones (call them iterations, if you like).

It requires making investments in order to build the framework to gather data as you go in order to be able to do your planning: the short, and medium, and the long term.

When driving somewhere, it does not make much sense to look at the map, divide it leg by leg, and extrapolate how long it is going to take based on logic and common sense alone. It requires hard data, even inaccurate, but hard data, to do that.

In order to be able to create such a framework, you will need to learn how to start the project in the first place. How to create a contract with the customer that is not stifling into rigid plans. Such are agile contracts – a framework that helps two companies inspire one another, and not bind into unchangeable scope.

Alongside the contract with the client, you will need to learn which walls that exist within your own organization divert you from increasing the pace of making software. Where do you have ‘traffic jams’ that could be avoided by using another, simpler, route?

In order to do planning continually and effectively you want to be able to collect data about what the road looks like ahead? Where are the technical ‘traffic jams’ that you will meet along the way, and that maybe you can resolve before you get there? How do you measure them? Collecting data about your application’s complexity, and testing it continually provides such data, and provides early feedback, and to fix them before they become complete roadblocks.

The way you architect your product may also need to change. By looking at the map and guessing which parts will be slower you don’t get real data to make good decisions. You have to be out on the road in order to figure out whether your car can make it or not; whether the road is good enough or not. Good architectures are unfolding as you get more data collaboratively, and not by hoping for the best and then starting the journey too late.

And finally, I am sorry to break this to you – it is all about you. If you change, your organization will also change. If you provide others with tools that you can use on your own, maybe they will also change. Ultimately, whatever your role is, developer, tester, architect or CEO, you are responsible to make the change.

Are you the kind of person who waits for other to make all the changes on your behalf? Or are you holding the wheel of the car which is your own professional or personal life?

Agile Practitioners 2013 is a great opportunity to make such investments. Join us for the fantastic star cast we have gathered to make this investment a real learning experience for you and your organization.

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.

Post Navigation