Becoming agile

Agile, through the storms

17 May 2013

My name is Acme.com, and I have ADHD

I attended a conference on ADHD recently, and, while I discovered that probably I, too, suffer from some form of ADHD, it occurred to me that many organizations I work with, and worked at, also suffer from organizational ADHD.

What follows in this blog post is describing what is ADHD and some of its symptoms of ADHD in humans, their manifestation in organizations, and how agility may serve as a treatment.

To begin with, ADHD is not something you cure. It is something you learn to live with, sometimes to the extent that the well-being of the individual (or the organization) is not impacted by ADHD. At others, it is something one must be aware of, and accept its limitations and drawbacks. What more, there are some qualities that significantly define the population of individuals with ADHD – they are pleasers, keen to succeed, tend to be artistic and creative, and more. I wish to hypothesize the organizations with ADHD also have such collective qualities – but this will remain for further analysis.

A disclaimer

This blog post is what it is – a blog post. By no means does this even attempt to be a scientific work, nor is it based on extensive empirical data. It is based on my own experience, with my own subjective analysis, and lame insights.

The reader’s initial response is likely to be ‘surely not our organization’. And yet, let me share some of my thoughts following the conference. Please revisit your original thoughts after reading the entire post.

ADHD in Organizations and Potential Treatment

In this post I discuss Scrum as a potential treatment. If you like, Scrum to organizations is like Ritalin to humans. (I actually intended to have this as the title, and opted eventually to the existing one).


Photo by unfolded, source: http://www.flickr.com/photos/unfolded/3698543176/

ADHD is transparent

Transparent in humans

First and foremost, people (and children) suffering from ADHD do not know that they suffer from something. Anything. It is transparent. And by that I mean in several forms:

It is transparent in the sense that individuals suffering from ADHD commonly looks like any other person. Yes, they have some subjective difficulties that they try very hard to hide, so others will not think they are different or lesser than others. They try very hard to stay within boundaries – something they find incredibly hard. They do so because they want so badly to be good – and they are considered good children or person.

Transparent in organizations

Now let’s talk about organizations: If you think that your organization is potentially really good, and that you are trying very hard to keep it a good one, and you are convinced that other organizations are also the same – please read on. What comes next might also be relevant for you.

Note that I am not trying to say that something is wrong with your organization. It is transparent, remember? It is seen as a problem neither from the inside nor from the outside.

Scrum and Transparency

Scrum is about transparency. It is about taking empirical data relevant to your own organization, and using it to find out what your organization is really like.

Take, for example, this video (watch until about 16:00): http://youtu.be/IyNPeTn8fpo?t=13m33s

ADHD is about Attention Deficit

Attention deficit in humans

Individuals suffering from ADHD find it hard to stay focused – to maintain attention for long periods. That is, a child with ADHD can sit on the chair for hours on end doing homework. But in practice, within the first minute they run off the subject, moving to other things. Any disturbance – either external or internal will get them out of focus.

When reading a book, they will get stuck on the same line and read it again, and again, and again. If there’s a fly in the room, they will have to read the line again, because the noise distracts them. If they just recalled something that happened at school, they will need to read that line again.

Attention deficit in organizations

Take support for example: What do you do in your organization when a P1 support call comes in? Can the team still focus on existing requirement? Or do you turn to the P1? How about P2? How about a medium priority bug? How about when someone has a question to ask the team?

Often teams will work on multiple concurrent requirements, increasing the spread of effort and reducing the focus.

If this hits a chord, you might have organizational ADHD.

Scrum and attention deficit

Scrum provides a prescription of practices, aimed, among others, to focus the team frequently and effectively.

The team works in short sprints – preferably one week long, starting with a planning session – what will we do this week, and ending with a review – what have we accomplished.

In between the team will meet daily to plan together the daily tasks.

Scrum training and coaching also advocates focusing on few things during each day. Virtually every Scrum training graduate can quote the proverb “Stop Starting Start Finishing”.

ADHD interferes with organizing things

Organizing difficulty in individuals

Next, individuals suffering from ADHD find it very hard to organize themselves. They find it hard to maintain sequence of things, to make order of information, to focus on a single solution. Some individuals just can’t organize, and struggle with it frequently. Others find it helpful to organize meticulously, making sure, for example, that everything is prepared to the last detail in the evening to get it right in the morning. (For this reason, some individuals are wrongly diagnosed as suffering from OCD [Obsessive Compulsive Disorder] or only from OCD, while their obsession is secondary to the underlying ADHD). Treat the ADHD and the OCD will reduce or disappear altogether.

Organizing difficulty in organizations

Let’s get back to your organization. We already know that it is a very good one, and that you are trying very hard to keep it that way, despite the difficulties.

Do you find that your organization has difficulties to focus on things? To order the requirements correctly? To make sense of the right sequence to do things?

On the other hand, do you find that your organization is obsessed with planning, to get it absolutely right? Maybe even yourself? Maybe someone you work with? And do you, or colleagues, find it traumatic that things don’t go according to plans? And then you are disappointed that you did not plan well enough in advance?

Do you frequently find that integrations are hard? That deciding when to do the integrations is tough?

Have you experienced that prioritizing is particularly difficult? If you are working in a development team, did you ever find that deciding when to start testing your code is challenging? That in your team it is ‘easier’ to assign individuals work on one thing, and in practice everyone, or most, get eventually involved in everything, and that things then just don’t finish? Oh, oh, hold on to that thought – I am jumping ahead of myself. First let’s look back at Scrum.

Organizing difficulty and Scrum

Scrum prescribes two backlogs: The product backlog, and the sprint backlog.

Product backlog is intended for the upcoming 2-4 sprints, maybe the upcoming quarter.

Sprint backlog is intended for the upcoming sprint.

In both cases, Scrum prescribes to prioritize the backlog in ascending order. There will be no two items with the same priority.

This is hard to do, to begin with. And it is critical to having things organized such that the organization can focus better on what to do now and next.

ADHD and procrastination

Procrastination and individuals

Now that’s a real killer. A small confession: I mentioned that I recently attended a conference on ADHD. That was back in March. To be precise, it was on March 1st. The idea for this blog post was born that day. 77 days later I am finishing it up, with 76 days of zero progress on it.

As it turns, individuals that suffer from ADHD tend to procrastinate more than those who don’t. As a result, these individuals find themselves in a situation that they must start many things late. As a result of that, they find that they do not finish things.

For example, a person having ADHD condition might start to read several books in parallel, finishing only some, or none of them. Sometimes this person will only read the first few pages, and, although he or she really wants to read the book until the end, they cannot bring themselves to it.

Coming to the first point, that people with ADHD try very hard to be good, this puts them in an impossible situation: they simply cannot finish that book, and then they think that they are lazy and incompetent. Often, others will ‘helpfully’ tell them that they are lazy. Or incompetent. Or both.

Procrastination and organizations

Can you spot procrastination in your organization? Can you find that things are started and never get finished? That many things are being done in parallel, and few, or none, get really Done (and here’s a hint towards the Scrum treatment)?

And how do you feel about that? How do others make you feel about that? Do you think that, despite trying very hard to be really good, you feel that collectively you are lousy because you never or rarely finish things?

It is common to procrastinate in organizations – at the individual level, at the team level and at the greater circles as well.

Procrastination and Scrum

Scrum recommends defining a good Definition of Done, one that gets revisited now and again to reflect the changing maturity of the team. Done may mean finishing coding, or it may mean finishing coding and unit testing, or it may mean that Done is accepted by the customer.

Whatever the definition, the notion of Definition of Done provides the opportunity to realize whether collectively you are accumulating technical debt (that is, procrastinating), or not. Conversely, whether you are really finishing things off before moving on to the next ones.

ADHD and self-esteem

Self-esteem and individuals

As you may notice, there is a build-up of a vicious cycle that characterizes people suffering from ADHD. A person that has ADHD tends to be very critical of him/herself. Boys tend not to cry, and instead to come raging from school, and act it out instead of talk about it. Girls tend to cry it out in what seems to be hysteria.

It so emerges that these people tend to be more suicidal than others. Both in thoughts and in action.

Self-esteem and organizations

Back to your organization: Have you ever thought, or talked to someone that this place is going nowhere? That we are doomed? Does your organization tend to let-go of key individuals?

When things don’t go as you expected (and they never do) – do they get discussed? Or do they, instead, manifest in shouting, fighting, and other aggressive behaviors (a “boyish” organization)? Or do they manifest in whining about it, without actually talking about the real problems (a “girlish” organization)?

Self-esteem and Scrum

There are very few measurements I advocate. I can most likely make you discard any measurement you come up with by proving how it can be gamed, either consciously or not.

One indication that does help indirectly is a “fun-o-meter” – how good does it feel to be a member of your team?

I find that there is a strong correlation between self-organization and a working Scrum to the feel-good factor of a team. This comes both from what people are reporting and from my own subjective experience of working with a team. My own humble experience consists of probably a few dozens of teams. And I hear the same from others who witness successful Agile implementations.

Other ADHD symptoms

ADHD has other symptoms, and this post is already getting too long to detail others. At this point I wish to discuss the “treatment” part, in particular the contribution of Agile frameworks.

This post is not a comprehensive detail of ADHD symptoms, nor is it a comprehensive description of Scrum.

A dose of Scrum for Organizational ADHD

I will begin with some reservations. If the first part of the post appeals to you, you should be aware that not all organizations have all symptoms. Some organizations have some of the symptoms, but not all; some (probably not many) have none.

Note also, that Agile is not a ‘magic pill’. Neither is Ritalin. Sometimes it helps, sometimes it doesn’t, and at others it should be combined with other types of treatment.

The important things to remember are (and this applies both to Agile and to Ritalin…):

  • A lot of patience is required. Adopting agile is a frustrating experience. It might take a while before results show. It might take longer before the original goals are met – maybe even never.
  • Not all practices will work for you. The right ones need to be tried out and tested based on empirical data – what, in the middle and long term, does this do to your organization. TDD might be the right thing to do, it might not. It might not be relevant now, and might become necessary later on.
  • Collecting empirical data is hard! It requires focus, discipline, stamina, order, following sequences – the very things that are hard to do with ADHD. You will need responsible adults (parents or managers) to make it sustainable. If you are in management, this clause is intended for you!
  • In this post I have used the most popular Agile framework, Scrum, to exemplify how this treatment makes sense. Other agile frameworks may work better for you. Maybe non-agile frameworks are right for your organization. TOC (Theory of Constraints) is one such example.
  • Agile is not the only ‘cure’. I am a great believer in Agile – and you are welcome to take everything I say with a pinch of salt. I stand corrected – I encourage you to challenge me.

    How many Scrum pills a day should I take to get cured?

    I hope that this post is indicative enough to suggest that if done properly enough, Scrum may be a treatment to alleviate the ADHD symptoms of the organization.

    It is important to understand that’ like ADHD in individuals, there is no cure. Sorry to be the baddy on this. People don’t get cured from ADHD – they learn how to use the right treatment to live with it adequately. Organizations cannot be cured from Organizational ADHD – they either die, or use a treatment, such as Scrum, to avoid their dysfunctions resulting from their ADHD.

    Going back to transparency, Scrum doesn’t solve your problems; it makes them visible. Just like ADHD is transparent until you get diagnosed. Once you start doing Scrum, problems emerge, ones that you didn’t know they existed before. Quite often we hear that Scrum is creating problems in the process. This is like saying: “Until I started using Ritalin everything was great! Since I started it seems that I am crap in math. I’d rather not use the medicine, and not know about it”.

    Many of the Scrum practices sound counter intuitive initially. Try explaining to a child that watching TV is not going to help him/her do their homework, or that reading five book concurrently is not good for their book report.

    Similarly, explaining that feature-teams and cross-functional-teams are good is no easy task. This is a result of not seeing the problem – the same as a person that resents taking Ritalin because he/she does not accept the ADHD condition (in denial).

    We have completed our Scrum dosage. Are we done now?

    It is quite self-explanatory that if you don’t see the problem, and you don’t think you have one, you also don’t want to get help. Moreover, if, for example, there is an expert in the picture that tells you that you are procrastinating – when you are convinced that you are not, you will resent hearing about it. The contribution of Scrum (and Agile in general) is that by retrospecting frequently, there is a good chance that by reflecting with supporting empirical evidence, at some point, hopefully sooner than later, the team will accept that treatment is required.

    Retrospectives can become boring, and it is a good practice to play around with retrospective practices in order to get the team engaged.

    To analogize with ADHD in individuals, sometimes Ritalin works well, then Concerta may work better, and at others you may try out CBT like Attengo.

    Scrum beyond the organization

    It is worth mentioning that the Scrum practices are helpful not only in organizations – also in families. The book Agile Kids is a good example.

    Other thoughts

    I already mentioned that I wish to explore the relatedness between “Organizational ADHD” and creativity. If you have any information or input I will be happy to hear about it.

    I also mentioned that this post is not based on scientific evidence. It will be interesting to turn this hypothetical article into a research topic.

    Finally, if you are interested to learn more on this, or on other topics, feel free to contact me either by commenting on this work, or through the contact-me page.

Posted in Agile, Human Relations and tagged , , , , , | Leave a comment
20 Apr 2013
4 Comments

APIL#14 – Kanban Pizza Factory

There are a number of Kanban games and simulations. Some of the better known ones are GetKanban and Kanban Frog Factory. For a while I wanted to play a game I have encountered about two years ago – Kanban Pizza Factory, which seemed more appealing to me, and I haven’t had the chance to play it yet. The game was introduced by Ralf Kruse from Agile42, and what I liked about it is that it is easy enough to play, it involves something majority of people love, and it can be easily analogized to our day to day life.


So, we have decided to dedicate our 14th Agile Practitioners meeting to a brief introduction to Kanban, followed by the game. Courtesy of Google Campus Tel Aviv, the meeting was held at the 26th floor of Electra Building with fantastic view of Tel Aviv.

The Kanban intro, as promised, was very brief, with types of waste and WIP being the areas that raised most questions. Read more…

Posted in Lean and tagged , , , , , , , , , , ,
16 Apr 2013
2 Comments

On Leadership, Humility and Independence

Today is Independence Day in Israel, and I want to share a short story on leadership. It is a story my dad told me many years ago.

My father served during and after the War of Independence under the direct command of General Sadeh, by then a highly acclaimed military officer. Following the war there was a major military exercise, and, as army exercises go, there was a recess for lunch. A temporary camp was set up; large tables were set with big vessels containing food. Soldiers queued up, mess-tin ready in their hands, and, when reached the large tables, those on duty served them.


Military Mess-tin. Credit goes to Collectors and Collections Forum in Tapuz (Hebrew)

Nearby another table was set up: chairs on either sides of the table, soldiers on duty serving the people sitting at the table. These were the officers, in charge of the exercise.

And then the command car arrived. General Sadeh, along with the rest of the people in the command car got out of the vehicle, and went, mess-tin in hand, to queue with the rest of the soldiers.

Needless to say that the rest of the officers, the ones being waited by other soldiers, did not know where to hide.

To this day I recall the sense of awe when my father told me the story. Not the kind associated with fear, rather with respect and trust.

General Sadeh did not stay with the army much longer afterwards. The story goes back to 1948, and Sadeh left the army in 1949, possibly due to some kind of political disagreement. He remained a much respected leader until and after his death in 1952.

There are many kinds of leadership, matching various conditions. It is often said that in the military a coercive, command-and-control is typically more suitable. Here’s one example of a leader that combined many styles of leadership, at times counter-intuitive, and yet has won the trust and respect of many, with unquestionable achievements. No doubt his opponents had much contribution to his retirement from the army service. Maybe even to his early demise. His legacy as a leader remains long after some of them.

This story tells me that it is not enough to sit at the officer’s table to become a respected leader. Sometimes, the opposite is true.

Posted in Human Relations and tagged , , , ,
08 Apr 2013
2 Comments

Yes, it’s hard. Yes, it’s also ok to laugh about it.

One of the things that will save you from losing yourself is a sense of humour. Even at what seems to be the worst situations; when the site is down; when angry customers are at the other end of the line.

This does not turn the situation into a funny one. But it is a great defence mechanism that can enable you to function and to endure.


Source: http://web.macam98.ac.il/~ochayo/humor/teaching/gif/bau2.jpg

Today we mark the Holocaust day in Israel. What could be worse than being there? There is an on going debate whether it is allowed to laugh and to tell jokes about the Holocaust. 

Well, take this short true story, extracted from a website on humour during the Holocaust (Hebrew)1, which tells us a lot about the benefits of humour, even during the Holocaust:

“A 10 years old boy is standing in the queue to the crematorium in Auschwitz. All the other children are crying and shouting, and this boy is laughing. The S.S officer walks over to the boy and asks: what are you laughing about? The boy responds: “You are going to kill me, and I have to queue for it?” The S.S officer let him go. The boy survived.

No matter how bad you think things are, crack a good joke about it. Let someone else crack some jokes. After all, very seldom do we face real life threatening conditions when writing software. And it could help you survive the bad times.

1The website is based on the Ph. D. work of Haya Ostrover, and is available also in the book “If not humor we would have committed suicide” by the same author.

Posted in Other and tagged
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 , , , ,

Post Navigation

← Older Entries
Newer Entries →