Becoming agile

Agile, through the storms

20 Jul 2014

Beaten Team Syndrome

You may have noticed that my blog has moved to the Practical Agile website.

So I have been importing a few old posts, and just posted a new one today. Click to read my latest post Beaten Team Syndrome –

What is it about? Have you seen, or maybe experienced yourself, a team that was taking more and more and more scope, when clearly it will be impossible to them to deliver?

And who tends to take the blame? Of course – the team!

My latest post compares this to a well known social behavior – Battered Person Syndrome, and suggests some practical ways, particularly for the Scrum Master or team lead, to identify and handle it.

As always, please comment – I am always happy to engage in discussion.

Posted in Agile, Human Relations and tagged , , | Leave a comment
14 May 2014

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.

Posted in Agile and tagged , , , , , , | Leave a comment
13 Dec 2013
5 Comments

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.

Posted in Agile, Human Relations, Quality and tagged , , , , , , , , , , , , , ,
18 Nov 2013
9 Comments

Don’t Worry, Be Happy… Until One Day

Continuing the disclaimer of two other posts I am referring to – this is not a political post.

Gene Hughson has recently written on the US healthcare.gov project, in response to Uncle Bob’s post from November 12th.



This is not the first time that a software failure had caused severe damage to mammoth projects. Here’s a short quote from Wikipedia on the first launch of Ariane 5:

“Ariane 5’s first test flight (Ariane 5 Flight 501) on 4 June 1996 failed, with the rocket self-destructing 37 seconds after launch because of a malfunction in the control software. A data conversion from 64-bit floating point value to 16-bit signed integer value to be stored in a variable representing horizontal bias caused a processor trap (operand error) because the floating point value was too large to be represented by a 16-bit signed integer.”
Source: http://en.wikipedia.org/wiki/Ariane_5#Notable_launches

The emphasis I have added points to a basic flaw in computer programming, often experienced by novice engineers. One would expect that a high-profile aerospace project will hire better engineers than that, don’t you agree?

Uncle Bob Martin thinks so:

“[…] So, if I were in government right now, I’d be thinking about laws to regulate the Software Industry. I’d be thinking about what languages and processes we should force them to use, what auditing should be done, what schooling is necessary, etc. etc. I’d be thinking about passing laws to get this unruly and chaotic industry under some kind of control.
If I were the President right now, I might even be thinking about creating a new Czar or Cabinet position: The Secretary of Software Quality. Someone who could regulate this misbehaving industry upon which so much of our future depends.”

Moreover, Uncle Bob refers to another aerospace disaster – the Challenger explosion, and the engineers’ responsibility in not stopping the launch:

“It’s easy to blame the managers. It’s appropriate to blame the managers. But it was the engineers who knew. On paper, the engineers did everything right. But they knew. They knew. And they failed to stop the launch. They failed to say: NO!, loud enough for the right people to hear.”

In response, Gene Hughson writes:

“Considering that all indications are that the laws and regulations around government purchasing and contracting contributed to this mess, I’m not sure how additional regulation is supposed to fix it.”

Sadly for our industry, I agree with Gene. Yes, engineering practice has, on the whole, a long, long way to go to become anywhere near excellent. I have a lot of respect for Uncle Bob for his huge contribution there.

But the Challenger disaster is first and foremost not an engineering failure. The disastrous potential of the problematic seal was known for a long time before it actually materialized, to everyone’s shock.

““The Rogers Commission found NASA’s organizational culture and decision-making processes had been key contributing factors to the accident. NASA managers had known contractor Morton Thiokol’s design of the SRBs contained a potentially catastrophic flaw in the O-rings since 1977, but failed to address it properly. They also disregarded warnings (an example of “go fever”) from engineers about the dangers of launching posed by the low temperatures of that morning and had failed in adequately reporting these technical concerns to their superiors.”
Source: http://en.wikipedia.org/wiki/Space_Shuttle_Challenger_disaster

At the end of the day, it boils down to the fact that NASA’s leadership were operating under the false belief that with every launch of the shuttle, the risk of the seal failing reduces, completely opposite to common sense.

Mr. Larry Hirschhorn has an excellent description of this in his book The Workplace Within.

In such atmosphere, when my managers, and their managers, are so indifferent to life-threatening flaws, heck, why should I exercise excellence in my mundane tasks? Why should I risk my own livelihood? After all, this is the culture here, in this workplace.

It is heartbreaking that the loss of the Columbia can be attributed to similar management pitfalls as that of the Challenger:

“In a risk-management scenario similar to the Challenger disaster, NASA management failed to recognize the relevance of engineering concerns for safety for imaging to inspect possible damage, and failed to respond to engineer requests about the status of astronaut inspection of the left wing. Engineers made three separate requests for Department of Defense (DOD) imaging of the shuttle in orbit to more precisely determine damage.”
Source: http://en.wikipedia.org/wiki/Space_Shuttle_Columbia_disaster

Coming back to Uncle Bob’s conclusions, in his talk, How schools kill creativity, Sir Ken Robinson points out that the school system, in its efforts to teach, are killing creativity in favor of grades. We can only assume that legislating computer engineering studies will, at best, not harm the existing engineering quality. It will probably achieve worse – well certified engineers, with little ability or drive to excel.

This failure has little to do with teaching and certifications, and all too much to do with culture, professionalism, and plain simple awareness.

When managers practice such “It will be OK” attitude, everyone does. By the sound of it, the healthcare.gov failure discussed here is not that far off.

In 1992, Prime Minister Yitzhak Rabin was speaking at the Staff and Command school to prospect senior officers. Here’s what he had to say about “It will be OK”:

“One of our painful problems has a name. A given name and a surname. It is the combination of two words – ‘Yihyeh B’seder’ [“it will be OK”]. This combination of words, which many voice in the day to day life of the State of Israel, is unbearable.

Behind these two words is generally hidden everything which is not OK. The arrogance and sense of self confidence, strength and power which has no place.

The ‘Yihyeh B’seder’ has accompanied us already for a long time. For many years. And it is the hallmark of an atmosphere that borders on irresponsibility in many areas of our lives.

The ‘Yihyeh B’seder’, that same friendly slap on the shoulder, that wink, that ‘count on me’, is the hallmark of the lack of order; a lack of discipline and an absence of professionalism; the presence of negligence; an atmosphere of covering up; which to my great sorrow is the legacy of many public bodies in Israel – not just the IDF.

It is devouring us.

And we have already learned the hard and painful way that ‘Yihyeh B’seder’ means that very much is not OK.”

Source:
http://www.imra.org.il/story.php3?id=46224

No, Uncle Bob, engineers are not to blame on this. Management must take responsibility for nourishing a culture that allows such poor standards.

Posted in Human Relations, Quality and tagged , , , , , , , , , , , , ,
15 Nov 2013
6 Comments

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.

Posted in Agile, Human Relations and tagged , , , , , , , , , , , , ,
08 Oct 2013
6 Comments

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 activities. Gantt 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.

Posted in Agile, Human Relations and tagged , , , , , , , , , , , , , ,
12 Aug 2013
1 Comment

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 kinematics, velocity 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.

Posted in Agile and tagged , , , , , , , , , , , , ,
27 Jun 2013
2 Comments

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…

Posted in Agile, Quality and tagged , , , , , ,
10 Jun 2013
1 Comment

Scrum Master is Not Merely a Facilitator

For some reason, for many the essence of the Scrum Master role boils down to: “remove impediments for the team” or “is responsible for the Scrum process”.

Others declare that “the Scrum Master is a kind of a PMO”, or “a facilitator for the team”. Not that it is not part of the Scrum Master role – but it certainly is not the essence.

Furthermore, such statements are demeaning, in my view. Strong word, and yet, making statements such as the above, to me, indicates that the speaker may not yet understand what agility really means.

And please don’t get me wrong – it’s not that I think that facilitation is something to look down at. On the contrary – facilitators can save a conference from failing miserably. Similar arguments can be made on PMOs. These roles and professions are important and significant in their own right. But this is not the essence of the Scrum Master. Moreover, it takes courage to step out of these simplistic views of the Scrum Master, and delve into the complexity of becoming one. What follows is highlighting the other, more important, aspects of being a Scrum Master

Photo by OregonDOT, source: http://www.flickr.com/photos/oregondot/6235421713/

Read more…

Posted in Agile, Human Relations and tagged , , , , , , , , ,
27 May 2013
3 Comments

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…

Posted in Agile, Human Relations and tagged , , , , , , ,

Post Navigation

← Older Entries