Becoming agile

Agile, through the storms

Archive for the category “Agile”

18 Feb 2013

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 16th – http://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 11th – http://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_


Posted in Agile, Human Relations and tagged , , , , , , , , , , , , | Leave a comment
02 Feb 2013

#AP13 – A Big Thank You

Agile Practitioners 2013 conference is now over, and what a success is has turned out to be. And it is so tempting to think that this is about Practical Agile arranging this conference – well, it’s not.

On the other hand, in the “mania-depression” journey towards this conference, there are lows such as: “why would Boris Gloger, Dan North, Yves Hanoulle, Marcin Floryan and Markus Gärtner come to a conference organised by a tiny organisation in tiny Israel?”

Well, they did, as did eleven additional local speakers – and this is what it is about.

About 200 people came to see these magnificent experts talk, share their learning and expertise on agile, and influence the Israeli agile community.

Of course, this event would not be possible without help, financial and otherwise, and we are very grateful for the sponsors of this event: HP, Scrum Alliance, Experis, Kanbanize, ESL, and Bor!s Gloger. Also Technologies.co.il who produced this event.

We have received great feedback on the conference, some insightful and some overwhelmingly positive. Presentations of all the talks will be uploaded to the conference website in the coming days.

Some of the speakers have already started talking about their talks, so follow their blogs to find out what they thought. Here are three posts I found by Markus Gärtner,  Eilon Reshef and by Gil Zilberfeld

And finally a Big Thank You for all of you who took one or two days off work to be in the conference. Your participation is what makes it work. We will begin working on #AP14 pretty soon – if you have ideas on what will make it more relevant for you; if you didn’t come because something was missing from the program; if you had a A-Ha! moment on what you would like to see next – please let me/us know. This event was a success because of You – as will the next one be.

Posted in Agile and tagged , , , , , , , , , | Leave a comment
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 , , , , , , , , , , ,
25 Dec 2012

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.

Posted in Agile, Human Relations and tagged , , , , , , , , , , , , , , | Leave a comment
18 Dec 2012
5 Comments

The Agile Man-ifesto

I have observed recently that of the signatories of the Agile Manifesto, 17 are men, and the rest are women. This made me think about the relevance of the manifesto, in terms of the intellectual, emotional, and cultural diversity that led to its creation.

I searched if someone else has published articles or works on this interesting fact, that all the signatories are male, and did not find anything about it. I did find, however, and the article Empower Gender Diversity with Agile Software Development by Prof. Orit Hazzan The paper shows that teams with mixed genders present better communication skills and better relationships. Furthermore, gender diversity in teams and in pairs resulted in members significantly reporting on more collaborative work. Did anyone mention Individuals and Interactions?

The Agile Manifesto source: http://agilemanifesto.org

The paper refers to additional work, and lays ground for future empirical work on the contribution of gender diversity on trust within teams, enhancing cross-functional teamwork and other aspects. This all suggests that encouraging women leadership and involving women in development teams enhances organizations’ ability to produce more and better quality software for their customers.

This got me intrigued. I browsed renowned agile books written be women: Johanna Rothman, Esther Derby, Diana Larsen, Lyssa Adkins – all books I found were published during or after 2001! (Admittedly this was not an extensive research only browsing in online bookshops)

Even the references in Prof. Hazzan’s article above – all referenced papers by herself were published after 2001.

I then contacted Prof. Hazzan and asked her if she has noticed this, and whether she knows of work done in this respect.

The answer came quickly: Read more…

Posted in Agile, Human Relations and tagged , , , , , , , , , ,
06 Dec 2012
8 Comments

A piece of cake. A huge piece of NIH cake

This is so tempting to start something afresh, something that only we will use, so it fits our needs like a glove.

It is so tempting because it seems so easy to develop exactly what we need – it must be a piece of cake to custom build it for us.

And of course what exists out there does not serve the purpose well enough, simply because it was NIH – Not Invented Here.

Image by http://www.flickr.com/photos/rabanito/

So here are ten reasons NOT to develop internally what exists off the shelf:

1. It is already tested by more customers

2. You enjoy from features you didn’t think of; you will enjoy future features you cannot imagine today

3. You are good at what you do business wise. So why try to become proficient in something other organizations are already experts in?

4. Conversely, by investing in existing tools you produce less of what you are uniquely good at

5. Once you deploy your tool you will need to maintain it, making even less of what you are good at

6. When you or the market evolve you will need to expand also the tool – what tool providers do anyway for their own survival

7. Changing the tool becomes much harder. For starters, the tool will be someone’s “baby”. You might also find that you need to lay off really good people to replace it, turning decision making harder still.

8. People always blame tools. Always. It is easier to defend a Rolls Royce or a Chevy than it is to defend a home made cart

9. Some tools (not yours!) are crap for real. It is easier for someone to admit that they’ve bought a piece of crap than to admit that they are making crap.

10. Think twice and thrice before you reinvent the wheel. If you are already making the Rolls Royce of your business, why service it with second grade tools?

What is your view? Are you developing tools that are commercially available?

Posted in Agile, Quality 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 , , , , ,
13 Nov 2012

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…

Posted in Agile and tagged , , , , , , , , , , , , , | Leave a comment
24 Sep 2012

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.

 

Posted in Agile and tagged , , , , , , | Leave a comment

Post Navigation

← Older Entries
Newer Entries →