Becoming agile

Agile, through the storms

Archive for the tag “Management”

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 , , , , , , , , , , , , ,
01 Jan 2013
8 Comments

Don’t reorganize – Deorganize!

Organizations tend to do this every now and again: Reorganize the structure to suit a new strategy, a change in the management team, try out a new hierarchy model, and so on.

In this post I lay out some alternatives, and end with a practical first step.

One of the pitfalls of reorganizations is that they provoke a huge amount of anxiety and resentment: people’s direct and indirect managers change, their role description changes, their promotional path becomes unclear.

I would like to suggest a different approach. Instead of a reorganization, gradually deorganize. Shed away redundant structure, and replace them with loose structures. Allow your organization to grow in response to real market needs, and not according to a decision that was made a couple of years earlier based on data that may have been momentarily correct, but have become irrelevant for today’s reality.

Sounds impossible? Actually, you see such structures every day of your life. When you see ants collecting food for winter, when you see schools of fish swimming together, when you watch migrating birds practicing towards their long flights and when they embark on their fantastic and inspiring far-away journeys.

Waders in flight Roebuck Bay. Photo by Mdk572, Source: Wikipedia http://en.wikipedia.org/wiki/Bird_migration

These structures are not decided upon – they emerge according to changing needs of the group. Even ants have changing realities: when their nest is being attacked or flooded, as well as when they prosper and have food in abundance to accumulate for rough times.

In our business life we like to think that we can create strategies that can predict our organizations’ growth and needs for upcoming years. The truth is as far from this as can be. A good strategy is one that enables the organization to continually change in reaction to its present reality. Read more…

Posted in Agile and tagged , , , , , , , , , , ,
30 Oct 2012

Got lost? Try stopping

One of the anxiety provoking situations working in organizations is getting lost; not knowing what to do next.

Let’s face it, imagine your manager entering the team’s room, when none of you really know what to do next? Not a pleasant moment.


Photo by brewbooks, at http://www.flickr.com/photos/brewbooks/6032820148/

Reflecting on the famous verse from Psalms 121: “A song of ascents.
I lift up my eyes to the hills– where does my help come from?” and the answer immediately follows: “My help comes from the LORD, …”

This text is translated literally from Hebrew:

“שִׁיר, לַמַּעֲלוֹת:
אֶשָּׂא עֵינַי, אֶל-הֶהָרִים– מֵאַיִן, יָבֹא עֶזְרִי.”

(תהילים קכא פסוק א’)

But it could be translated differently. Those of you, who are not Hebrew speakers, may find this strange. I encourage you to check it out, if you sense any doubt:

“A song, for ascents:

I lift my eyes, lord of the mountains– From void, comes my help.”

Now there is no question. So the next verse is not an answer for the above, it is the next statement: “My help comes from the LORD, …“; maybe the LORD will help me find my way through the void.

Ok, so the manager enters the room, and you are lost. You have no idea what to do next. What do you do?

There is a tendency to come up with a solution, any solution, as long as we are making progress.

Further in the psalm we learn that:

“…indeed, he who watches over Israel
will neither slumber nor sleep.”

Once again, the original suggests an alternative:

“הִנֵּה לֹא-יָנוּם, וְלֹא יִישָׁן– שׁוֹמֵר, יִשְׂרָאֵל”

This interpretations suggests: “…indeed, Israel will neither slumber nor sleep, watching over”

There is, of course, the option of getting help from the manager, from books, from an expert, from The LORD. Those options are always there.

But, hey, from time to time allow yourselves to just Get Lost, watching over yourselves from whatever lies outside.

A few more words on the context: Psalms 121 is about Jacob (aka Israel) running away from his bigger and stronger twin brother Esau. In despair he lifts his eyes to the mountains. Instinctively we imagine what he might think: from where do I get help?!

I guess this is more for you, managers, than it is for teammates. Your team is lost, facing a problem that seems as big as mountains for them, maybe even for you. Yes, they do need your help, but possibly not the kind you are used to. Sometimes they need the space to get lost and build their own help from void, from nothing; to learn from their own mistakes and from their own experience.

There is learning without teaching, and there is teaching without learning. If you notice that you teach your team the same things time and again – try another way. For example, let them learn their own way. In the process you will also learn to contain the team’s anxiety and refrain from automatically offering your help.

Many thanks to my mentor at my studies, Haim Deutsch, staff member in the program, for turning my attention to this notion

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

To the team, and beyond!

For the second year in a row, the Agile Practitioners 2013 conference is on its way, scheduled for early next year.

For starters, save the date! On January 29-30, 2013, at Kfar Hamaccabiah near Tel Aviv

The theme of this conference is “Agile Beyond the Team”

Hyde Park Corner tube station, photo by Mike Knell

We give much focus to the team in our work. Sometimes we call it development team, and at times implementation team – to refrain from making assumptions on the team itself.

This time, during the conference we wish to explore the teams’ eco-system: what do we need to provide within and outside our organisations to get teams to thrive in an agile culture.

Do you feel you have a say? Would you like to share your expertise? Maybe you have a view on management or on leadership or on software architecture or on people skills or on complexity of human systems that you wish to share? Any other related subject is, of course, also welcome

We have opened a Call For Papers for people like yourself, who wishes to spend up to 45 minutes influencing people for make this agile world just a little better.

Got you interested? Follow the link, fill in the form, and tell us what you want to talk about!

As a speaker, should your idea make it to the programme, you will be entitled to a free admission to the conference 2nd day, and to a 50% discount on the workshops during the 1st day (Details of the workshops will follow soon).

If you wish to follow and get updates on the conference, you can register via the conference’ main page.

 

Posted in Agile and tagged , , , , , , | Leave a comment
06 Sep 2012
3 Comments

Becoming Agile on Becoming Agile

I am sharing a post from our LinkedIn group on how to commence your journey:

Original Question:

How to establish agile development in a very tight and constrained department

“I have been studying Agile development (Scrum in particular) and wish to implement it within my team. Team is around 20 over developers, QA engineers and several key role personal (DBA, S.A,B.A and such). Problem being the team turnover rate is high. To add more complexity to the situation, lots of delivered products require CRs and bug handling while new assignments keep piling up, and the team keeps answering customer care 30%~40% of their time. 

Is agile good for this situation? Is working in “small” amount of work units the answer to better productivity? I have my management full support to move the team forward into agile development yet I find it hard to drive it given the conditions described above. Any advice from the masters?”


Photo by Schplook at http://www.flickr.com/photos/45040273@N02/5444960010/

My response:

@****, I am starting from the last part of your statement: You have full management support, which is wonderful. It means they trust you to make changes that are good for the organization. You will need to find out whether this includes also management commitment, that it, are they willing to change to accommodate your changes. If they don’t you will need to adapt in order to become agile while still answering their needs.
As for becoming agile:
The complexity you describe exists in many places, in many different manifestations. You will need to find a way that is suitable for your context. In order to do so, you will need to experiment, and find if what you do works well for you. If it doesn’t, you will need to design another experiment. If it does you will design experiments to make it even better, and to adapt to the changing reality.
The big question you must be facing now is HOW? How do I even begin to design the first experiment?
In order to design good experiments, you will need to acquire knowledge – both practical and theoretical. What makes an organization become agile, and what diverts it away from agility?
This can be done through experiences – courses and workshops. Practical Agile (my organization) runs such courses. Find out more about it here. Of course, there are others to choose from.
You can also read books. Shirly just posted in this group Agile Bench’s list of books by category.
I have recently posted Jurgen Appelo’s 100 most popular books on agile

What’s your idea of becoming agile?

If you’ve got your own ideas of effectively becoming agile, please share them! You can either share them as responses here, or, even better, respond directly on the post in LinkedIn, to help the guy by sharing your way. If you think I am wrong, or maybe not good enough in my response, heck, you will also help me grow better Agile Practitioners

Posted in Agile and tagged , , , , , , , , , , ,

Post Navigation