Becoming agile

Agile, through the storms

Archive for the tag “agile”

Ten Tips for the New Scrummer

What makes a good Scrummer? Well, if I knew an exact formula, I would be too busy selling it to Scrum-wannabees than writing tips about Scrum 😉

On a more serious note, the differences between organizations is so great, that any ten tips will never be good enough for all.

Nonetheless, I’ve gathered some of the things I found helpful in early stages of Scrum adaptations.

I hope that many will find this useful, since ‘Early’ is also organization specific – some teams I’ve encountered have become self-managed in less than 10 weeks, whereas other teams still struggled with the basic concepts after six months (and more) of doing Scrum.

So here it is – my Ten Tips for the New Scrummer:

  1. Start with a project small enough to become a success, yet important enough to attract decision makers.
    It is not uncommon to see organizations start with multiple concurrent teams going Scrum, which makes the transition effort much greater than required. Instead, generate success by building a Scrum team that will give management the ‘appetite’ for more.
  2. Celebrate small successes.
    Focus on what’s working well. Peel-off all the cynicism that we so frequently meet in IT organizations, and find that people still love when told that they are doing good.
  3. Appreciate that Scrum is a very different than traditional software development projects.
    It is unrealistic to expect people who didn’t do Scrum before, or are fairly new to Scrum, to adapt to concepts that may seem counterintuitive at first.
  4. Read the Scrum Guide. If you’ve already read it, read it again after a while.
    This is a great concise description of Scrum, and you’ll learn something new with each time you re-read it.
  5. Speak of forecast, and refrain from talking about commitments.
    There are good reasons why the authors of Scrum chose ‘forecast’ as the team’s indication of what they will achieve in an iteration.
  6. Start-off with sticky notes on a wall or whiteboard, and postpone choosing an electronic Scrum tool for as long as you can.
    Deploying a change-request on a physical Scrum board costs almost nothing. Asking for a change request on a commercial tool might block you for a long time. Making your own tool – unless you plan to sell it for big bucks – don’t do there!
  7. Learn. A lot.
    The team you are a member of should expect itself to inspect-and-adapt indefinitely. What better way do you have than increasing your knowledge to have great ideas for your retrospectives? Read books, attend courses and workshops, read blogposts. The return on this investment is priceless.
  8. Learn to trust relative estimations.
    Learning to estimate and to continuously plan in a way that reduces overloading teams is critical, and one of the hardest transitions from traditional software projects. Relative estimations are key to letting go of unrealistic plans.
  9. Excel in your engineering practices. No matter how well you do Scrum, if your testing cycle is too time consuming, if  the feedback-loop on writing new code takes too long, or if your coding standards are inadequate for short iterations – you will hit a brick wall without paying your technical debt.
  10. What are your 10 tips?
    Really, what ten tips would you give someone who is thinking about doing Scrum?
    If you can’t come up with ten good tips, either you’ve got more learning to do, or you are going through a stressed phase and need to let go, or maybe Scrum is not right for you. Whatever the reasons, if you want to succeed in Scrum (and agile SW development in general), find ways to become passionate about it.

Of course I could be writing fifty or a hundred tips or more: invest in agile requirements, sharpen your Definition of Done, how to decide on the Iteration length, Always have a well-groomed backlog for Iteration start, … I arbitrarily chose a good selection of important ten tips.

Wanna give Scrum a go and not sure how? Start with a course. It will take you through the paradigm shift that comes with agile, you’ll get to try it out in a workshop setting, and it’s fun. You’ll be far more equipped for your first Sprint than any blogpost you’ll read. Drop me a line if you’re not sure.

Everything is Hunky Dori, Always, No Matter What

What might it mean when you ask someone “how are you?” and the answer is always hunky dory?
Gene Hughson in his latest post  refers to The Daily WTF’s post on a system that never reports an error. This provokes several thoughts.

How it all went pear-shaped

How it all went pear-shaped Photo by Ted and Dani Percival http://www.flickr.com/photos/tedpercival/

1. There is a fantasy to create fail-safe systems. There is a similar fantasy to create fail-safe organizations and teams. The truth is that we would much prefer systems (both software and organizational) that are safe-to-fail. Since most software systems and most organizations operate in complex environments which are impossible to predict, knowing what failed is paramount to the evolution of the system.

In an analogy, we would love that our children will have developed magical qualities to get top grades, be friends with everyone they wish, etc. However, we will become much better parents if we invested efforts to help them let us know when they need our help.

2. In the past, Windows, based on the x86 architecture, had a magical error that told us everything: General Protection Fault. Maybe the fantasy at Intel and/or Microsoft was that the x86 with Windows 3.1 is a super quality system, that fails on seldom occasions, so only GPF is required in such conditions (of course, this is a wild and unvalidated hypothesis for the sake of the argument only).
In practice, Even the infamous Dr. Watson, in “his” first versions, was not good enough to tell us what’s wrong, and additional tools were required.
Luckily today Windows combined with 3rd party tools is much better at telling us what went wrong.
Moreover, modern tools tell us what is going wrong now, and even what is about to go wrong.

3. Conways Law tells us that the architecture of the organization is a reflection of the product architecture (and vice versa).
Relating to B.M’s co-worker in Daily WTF’s post, rather than putting the responsibility on him/her, I wonder if and how their organization is structured to hide faults, and what does it mean to admit having made an error.

In organizational life, when your team members always keep telling you that everything is OK, a good advice is to explore how you contribute together to not telling when they could use your help. What are you collectively avoiding to address the real problem issues.
Parallelly, if you are getting frequent customer complaints that are undetectable before the product is released, a good advice is to explore how your architecture is contributing to hiding away such errors.

The Sovietization of Scrum

When I just finished reading Gabi Steinhardt’s The McDonaldization of the Development Team I felt angry, almost furious, and a strong urge to utter on the keyboard what a load of nonsense this is. And then I stopped and thought to myself – why am I so angry? The answer, so I believe, is that in many ways Gabi is right. That is, he is getting many of the facts wrong, but he is not alone there – similar misconceptions of Agile and Scrum are being made in many organizations and by many experts.

There must be something else. Many Agilists claim that agility is the right thing for today’s ever changing pace, need for speed, yada, yada, yada – you know the drill. So how come many Agile implementations fail to deliver? The answer must be elsewhere – or at least, in Agile and some other thing or things.

This is what made me so angry. Although Gabi’s comparison of Agile and McDonalizing is, in my view, wrong, he is right in saying that Scrum in particular, and Agile in large, are weak in addressing the notion that resistance to Agile has a meaning. That there is a meaning behind what goes on in an organization deciding to adopt Scrum on one hand and in-practice, at the same time, sabotages its own decisions on the other.

But first, let me address some facts gone wrong in Gabi’s post.

The Industrial Revolution

All the facts in this part of the post are correct. I wish to add another observation which is missing, yet extremely relevant:

Prior to the Industrial Revolution, the social structure was very clear: You could either be Royal, Noble, Knight or Peasant. The class of your parents would determine your class, and that’s it. Your professional status, on the other hand, was quite different: In the craftsmanship process, you would start as an apprentice, learn for years, and hope to become a master. You’d hope that your master would “kick the bucket” or a master in a near town would, and so you’d have the opportunity to become one. The learning process itself was not standard and not proven.

Classes were very clear; Professional path wasn’t.

Then the Industrial Revolution came: All of a sudden you could get a job that respects its owner very quickly. You’d apply to Ford, get trained, and Hey Presto, you have a profession. Your stature, on the other hand, became very unclear. Noblesse and Knighthood gradually became not strictly Blue Blood anymore. Peasants of old all of a sudden became respectable citizens.

Classes became unclear; Professional path was.

And then the Post Industrial Milieu came: Professions became complex and complicated. Becoming a great Programmer (a craftsperson, or Master) involves a lot of learning, as well as vast experience. The same goes for a master of Product Manager (where do you get a degree in Computer Product Management?). At the same time, the social structure is vague: a degree-less person can come up with an idea for a small operating system, and become the richest person worldwide, not to mention one of the most influential ones – a position once reserved almost uniquely for Kings and Queens.

Classes remain unclear; Professional path also becomes unclear again.

The McDonald Way

Nothing more to add, other than that The McDonald Brothers, descendants of Irish immigrants to the US, established a single restaurant in 1938, developed their own “Speedee Service System”, and franchised the largest food chain ever starting 1953.

Unclear class structure and unprecedented career path. Point above proven.

The Scrum Development Team

This is where Gabi’s blog post symbolizes what takes place in so many organizations: misinterpreting the original intents of Scrum and of Agility. Please don’t get me wrong – this is not a criticism against Gabi. Nor is it an attempt to say something bad about such organizations. This is a fact: Agile is failing miserably in delivering its message to the world. I would make a wild guess that about 5% of Agile transitions become successful in a reasonable period of time. Not so complementing for Agile.

Examples from the post:

“[Scrum]… guidelines are reminiscent of mild to extreme socialist-economic models…”

Agile and Socialism are very, very much apart from one another. To name one major difference, Socialism calls for uniformity; Scrum advocates “One size does not fit all” – even within the same organization and team.

“Scrum recognizes no titles for Development Team members other than Developer…”

There is confusion here between title and role. A Developer can, and is expected to take the role of, for example, a Programmer, and it will be a disaster for the team if this particular person would write technical documents – and the team, all Developers in the team, are expected to recognize that.

Coming back to the opening of the blog post:

“Over that last decade we have seen […] Agile software development methods […]” (emphasis not in original).

Agile and Scrum and other similar modern organizational concepts, do not define themselves as methods. Instead, they define themselves as frameworks, which, the organization is expected and encouraged to adjust and then inspect-and-adapt indefinitely.

“So what can we expect when we take a […] team […] of highly competitive and smart individuals?”

It so emerges that Scrum does not encourage hiding competition within the team. Nor does it suggest that competition is neither bad nor good. Instead, taking Gabi’s example, competition is there, and the team and its eco-system should practice examining whether such competition is helpful or detrimental. Thereafter, team members should decide together how to address such competition.

So where did we go wrong?

I am suggesting that there is something else lurking here. Agile is failing because practitioners do not recognize that the resistance has a meaning. Conversely, organizations that relate to this resistance as meaningful data succeed in addressing them, become successful in implementing Agile.

For example, resistance could symbolize the fear within management in light of the extreme uncertainty. Even if this organization did, with great intention, everything Gabi himself advocates, I wish to hypothesize that they would still sabotage Gabi’s advice because the uncertainty as a source of fear would still remain.

The fact that these (more or less) 5% of organizations transitioning to agile succeed is not merely because they are becoming Agile. I wish to hypothesize that they succeed because they are conscious of potential sources to make them fail.

That is why Agile is still failing, as will any other new buzzword in this industry.

Yes, business people and engineering people should communicate better. Yes, business people should have a clearer say than is currently prescribed by Scrum. Will writing this on a manifesto and advocating it help? Hell, no. Well, not until we look at each specific organization with its own unique and concrete fears, anxieties, pitfalls, etc., and stop looking for any kind of silver-bullet that will save all organizations.

Gantt Fetish

A fetish (derived from the French fétiche; which comes from the Portuguese feitiço; and this in turn from Latin facticius, “artificial” and facere, “to make”) is an object believed to have supernatural powers, or in particular, a man-made object that has power over others. Essentially, fetishism is the emic attribution of inherent value or powers to an object.”
Source: Wikipedia, http://en.wikipedia.org/wiki/Fetishism

Engineering projects, and software projects are no exception, tend to become complex and challenging. Naturally, the bigger and the more individuals are involved in making it, the projects becomes more complex.

Also naturally, when organizations make projects, they wish to simplify them. To make them more visible and understood, so that they are more controllable and manageable. One aspect of this complexity is to understand the dependencies between steps towards completing the project.

Luckily there is a widespread tool to achieve visibility of such dependencies within the project: The Gantt Chart.

A Gantt chart is a type of bar chart, developed by Henry Gantt in the 1910s, that illustrates a project schedule. Gantt charts illustrate the start and finish dates

of the terminal elements and summary elements of a project. Terminal elements and summary elements comprise the work breakdown structure of the project. Some Gantt charts also show the dependency (i.e. precedence network) relationships between activitiesGantt charts can be used to show current schedule status using percent-complete shadings and a vertical “TODAY” line...”
Source: Wikipedia, http://en.wikipedia.org/wiki/Gantt_chart Emphasis added.

A typical Gantt chart might look like this:

A Gantt Chart

Source: de.wikipedia.org, http://commons.wikimedia.org/wiki/File:OpenProj-screenshot.jpg1

The advantages of such a chart include that it can quite clearly show the project’s critical path, its progress (how much was done, and how much is left to do), when to expect its completion, and more.

How does this relate to fetishism?

Let’s describe a plausible scenario of creating a Gannt chart with dependencies in a project. Our project consists of changes in three integrative products and ten teams of engineers across these products. In the beginning, product managers in each of the products create a list of requirements, and lay them
down on a Gantt chart, and then they work together to combine a composite Gannt chart to visualize the expected work on the entire project, including all three products.

So far there is some waste in this approach, yet it could be attributed to a necessary waste2.

At this point I wish to draw your attention to a feature of Gannt charts: the milestones, typically denoted as a diamond symbol (‘‘), as in the chart above.

In order to meet a milestone we need to know whether there are dependencies between tasks, and in our plausible story, the VP development has asked all teams to provide all dependencies in the project: which team/person you depend upon, and which team/person depends on you. “Please provide this
information by end of the week”, said the manager.

Of course, none of this can occur in your organization. This is only hypothetical. A hypothetical plausible scenario.

The result is that all teams and all their managers are now engaged in reviewing all the activities to be completed by the end of the project, attempting to provide dependencies.

This is likely the complete opposite of principle #7 of the agile manifesto: “Working software is the primary measure of progress”.

And yet, all these people are now working towards a common goal: provide all dependencies by EOW.

Recall that fetish “is an object believed to have supernatural powers, or in particular, a man-made object that has power over others”.

Seemingly this is good: Everyone, or at least many, are now working together towards a common goal. However, the object of this goal is not the real thing (making working software). Rather, all are working towards an object that is believed to provide powers that will enable managers to better monitor and
control the execution of the project. Nothing to do with working software. Nothing a sensible customer will be willing to pay for.

Moreover, among the top reasons for project failures are changing requirements (11.8%), unrealistic expectations (5.9%) and unrealistic timeframes (4.3%), according to the 2011 Standish Group Chaos Report. According to State of Agile 2012 report, the second most important reason for going Agile is changing requirements, by 29% of respondents.

It goes without saying that investing days of work in getting all known dependencies in a Gantt chart (or any other media, for the sake of the argument) is a largely futile exercise.

In his 1988 book, The Workplace Within, Larry Hirschhorn refers (to management training techniques) as follows: “[These]… will fail, of course, if the technique functions as a fetish. Fetishes are not transitional objects. Like sexual fetishes, they block relationships between people and are used inflexibly. Social-scientific methodologies that are used indiscriminately function as fetishes.”

I do truly that Gantt charts are a good thing – as long as they are not being used indiscriminately. I have worked with a Scrum team that produced a Gantt chart during every Sprint Planning ceremony. At first I felt opposed to the idea. I talked to the Scrum Master about it, and he said it’s working for them, and I said nothing more. The truth was that it was working for them – it helped the team deliver more responsibly and predictably.
A few months later, they stopped using it – the tool was not required anymore. They were not using it indiscriminately.

At the end of the day, the object of our work is working software. Visualizing dependencies or milestones or critical paths is important if, and only if, it effectively contributes to the working software of the project it relates to.

Update – 2013.10.15:
In response to referring to his book, Larry Hirschhorn points out Eli Goldratt’s Theory of Constraints as an alternative to mapping dependencies (Thank You!).
My interpretation is – rather than spending time on identifying dependencies, look for bottlenecks (“Buffers”, in Eli Goldratt’s terms) and attend to them, until new bottlenecks are found, and repeat forever. Set the pace of the process according to the observed pace of the slowest bottleneck (“Drum”), and let all other elements in the process observe this pace (“Rope”).

1Gantt chart image by Projity Incorporated (http://www.openproj.org/product-overview) [GPL (http://www.gnu.org/licenses/gpl.html), GFDL (http://www.gnu.org/copyleft/fdl.html) or CC-BY-SA-3.0 (http://creativecommons.org/licenses/by-sa/3.0/)%5D, via Wikimedia Commons

2of course one could argue that this whole concept is a waste: that creating a single backlog and not attempting to draw the anticipated progress is more sensible. This may be the topic of a separate blog post.

Velocity (or how fast does your car go?)

One of the key elements in planning in Scrum is basing your forecast on Velocity. In contrast to cars’ performance, the Velocity used in Scrum is not a performance-indicator. Rather it is a parameter used towards calculating a forecast for a team’s or a project’s short, medium and long term.

In kinematicsvelocity is the rate of change of the position of an object, equivalent to a specification of its speed and direction of motion. For motion in one dimension, velocity can be defined as the slope of the position vs. time graph of an object. Speed describes only how fast an object is moving, whereas velocity gives both how fast and in what direction the object is moving.[1] If a car is said to travel at 60 km/h, its speed has been specified. However, if the car is said to move at 60 km/h to the north, its velocity has now been specified. To have a constant velocity, an object must have a constant speed in a constant direction.

Source: Wikipedia, http://en.wikipedia.org/wiki/Velocity (emphasis in the original)

Not surprisingly, the photo chosen by authors of this Wikipedia term is this:


How fast can your car go? Put it to the test in optimal conditions, and measure it. For example, take the car to a race track, measure the top speed it can reach, and – voila! What you might get is along the following lines (emphasis added):

Performance
The Enzo can accelerate to 60 mph (97 km/h) in 3.14 seconds[12] and can reach 100 mph (160 km/h) in 6.6 seconds.[7] The ¼ mile (~400 m) time is 11.0 at 136 mph (219 km/h) and the top speed has been recorded to be as high as 355 kilometres per hour (221 mph).[13] It is rated at 12 miles per US gallon (20 L/100 km; 14 mpg-imp) in the city and 18 miles per US gallon (13 L/100 km; 22 mpg-imp) on the highway.

Source: Wikipedia, Enzo Ferrari, http://en.wikipedia.org/wiki/Enzo_Ferrari_(automobile)


Photo obtained from the Wikipedia term above

Alas, when we are referring to velocity in agile planning, we mean something slightly different. When referring to performance of cars, we relate to a measurement: how fast can this car go?

When we come to plan, we want to know how fast does this car (or team, or project) go?

Of course, now this brings into context another aspect of velocity, being direction – how fast does this car go towards the desired destination?

Using a similar analogy, how fast does the Enzo Ferrari go in conditions as depicted below?


Photo obtained from Wikipedia term Traffic Congestion: http://en.wikipedia.org/wiki/Traffic_congestion

Traffic congestion is a condition on road networks that occurs as use increases, and is characterized by slower speeds, longer trip times, and increased vehicular queueing. The most common example is the physical use of roads by vehicles. When traffic demand is great enough that the interaction between vehicles slows the speed of the traffic stream, this results in some congestion. As demand approaches the capacity of a road (or of the intersections along the road), extreme traffic congestion sets in. When vehicles are fully stopped for periods of time, this is colloquially known as a traffic jam or traffic snarl-up. Traffic congestion can lead to drivers becoming frustrated and engaging in road rage.

Source: Wikipedia http://en.wikipedia.org/wiki/Traffic_congestion

If you were to set out in your Ferrari on a journey on the Delhi road depicted above, and I was to embark on the same journey at the same time with my 2CV, by how much time would you beat me?


Source: Wikipedia, http://en.wikipedia.org/wiki/2CV

Let me help you in getting the right answer:

Driving your Ferrari you set on a 10km journey, driving 5km/h in nail-biting traffic conditions. How much time will it take you, providing that traffic conditions are more or less static (quite literary in this example)?


As we have learned in elementary school, Time=Distance/Speed, so this short journey would take you about 2 hours. My 2CV (if I really had one 😉 ) would do it in about the same time.

Coming back to software development teams, Given that the team is developing 10 things in a two-week period, and we have a backlog of 50 things left to do, we can comfortably forecast that it will take the team about 2.5 months to finish this work.

It doesn’t matter how the scope was originally estimated, how good or Ferrari like the team is, or how brilliant or Schumacher like is your Product Owner and/or Scrum Master. All we want to do is to empirically check how fast the team is going towards the goal in order to plan our journey.

Just replace Distance with Scope, and you have the answer.


With that in mind, you can make a relevant forecast on the project:

Velocity = [Done Scope] / [Elapsed Time]: What is our velocity?

By this we obtain the value of the parameter to set in answering the questions below:

Time = Scope / Velocity: How long will it take us to complete the desired scope?

Scope = Time * Velocity: How long will it take us to complete this project?

Note, that Velocity is not necessarily a one single parameter value used in all kinds of forecast horizons. In fact, typically you will need different parameter values for different contexts:

[Team Velocity] = [Done Stories] / [Number of Sprints]: What is our team’s velocity?

[Project Velocity] = [Done Features] / [Number of Releases]: What is our project velocity?

[Portfolio Velocity] = [Done Themes] / [Year]: What is our portfolio velocity?

Note also, that the above is not applicable for everyone. One organization may need to use [Done Epics] / [Quarter] to calculate their projects’ velocity, while another may need to use [Done Things] / [Day] to calculate theirs.

What happens when we treat Velocity as an indicator of our capability, rather than as a parameter based on empirical evidence?

Traffic congestion can lead to drivers becoming frustrated and engaging in road rage.

Paraphrasing on the above, “Slow projects progress can lead to managers becoming frustrated and engaging in team rage.

At this point it doesn’t matter why the progress is slow. It is more important to acknowledge that this team is now slow. Only after planning based on the current speed and direction of the team, can you try to alleviate some of the obstacles to increasing the speed. Some of these reasons may (or may not) include:

  • The team is occupied with a lot of support issues, diverting from the project goal (analogous to road-works)
  • The team is dependent on one or more other teams, leading to slow delivery of done things (analogous to congestion due to junctions and intersections)
  • The team is working on too much in parallel (analogous to congestion due to exceeding road capacity)
  • The team is working very hard, but on things not related to the project (analogous to driving very fast but in the wrong direction)
  • The team is pushed too hard, leading to working too fast neglecting quality and capability (analogous to speeding beyond road conditions)

There are many other possible reasons. But when one is stuck in traffic jam, and getting all worked out about it, one tends to ignore the objective, empirical, conditions, and focus instead on the subjective, intrinsic, emotional condition. Similar things happen in projects.

As a Courtesy for the Next Teammate

I have recently returned from a trip abroad, and, during the flight, I came across the following notice:

2013-06-11 11.24.36

I saw this and thought about working in a team. Think of all the people on the airplane as a large group, there is a subgroup whose role, among others, is to make sure the restrooms are tidy and clean. We know them as flight-attendants or stewards. In order to ensure that everyone gets a good experience, they would need to enter the restrooms after each time it is used, and clean after the travellers.

Compared to a software development team, this would mean someone, say testers, would need to refactor and clean the code each time it is being committed, to ensure that the code is in a good-enough state for the next programmer to visit the code. Read more…

There’s a lion lurking in the organization

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

Imagine the following scenario

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

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

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

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

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

What just happened here?

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

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

Teams, Organizations and Lions

There is a lion lurking here.

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

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


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

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

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

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

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

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

Dealing with Lions

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

I think not. Read more…

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.

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…

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_


Post Navigation