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 the 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 kilometers 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)

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?

Traffic congestion is a condition of 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?

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 well or Ferrari like the team is, or how brilliant or Schumacher like being 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 project’s 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 a 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.

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 ago 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. Contact us if you’re not sure.

Creating a mini-waterfall

Some people refer to sprints as mini-waterfalls. Well, that’s a mistake, sprint are not that.  But a mistake or not, doing a Mini-Waterfalls still seem to be a natural step for some people when they start with their Agile transformation.
So how do you create a mini-waterfall?
Well its not very hard like anything else when you create a mini-X you start by taking the X for example:
And then you do the same thing just smaller. Like this:

See where this is going?

I encountered several contexts in which a company, after getting some basic knowledge about Agile, seem to think that they are already mostly Agile, and what is left for them to do is just start working in short cycles. So in order to become “Agile”, they take their regular process as is and shrink it down to fit in short time boxes (anywhere between a couple of weeks to a couple of months) and wait for all problems to disappear (well they just become agile didn’t they?)

Is this bad?

Well, actually by itself now. Doing a mini-waterfall isn’t necessarily a bad idea.
On the Pro side, we can say the following:

  1. Mini-Waterfalls are some kind of an iterative process so you will get more feedback.
  2. When you work in a short time boxed iterations you will be forced to work in smaller batches.
  3. To support working in small batches you will need to get used to cut and slice the work into small things.
  4. And when you work in smaller batches, all kinds of things will become visible. For example, your one week manual regression cycle is going to be a real problem. The fact that you only manage building a working version of your product once every three days might also be an issue…

So basically when you start doing a mini-waterfall you are taking one big step in the right direction
However, On the Cons side, we should probably say that:

  1. Mini-Waterfalls are some kind of an iterative cycle so you will get more feedback.
  2. Working in short iterations has been just different than working in long cycles.
  3. If you don’t do the needed mind shift, working with mini waterfall is going to be very hard
  4. And if it gets hard enough, most likely you will stop doing it.

So basically doing a Mini-Waterfall process is not a steady state. Keeping it for long is extremely hard. When you a team starts working in short iterations, things that were comfortably hidden become  visible and painful.  The natural reaction to pain is to make it go sway. You can either fix the problems – maybe becoming more agile as you do, or you make sure to hide them again by reverting back to the older process for example.

So when is it bad?

Mini Waterfalls become bad when organizations confuses them with an agile process. The difficulties of sustaining a mini waterfall along with this confusion, causes some companies to revert back and claim that Agile is bad. In fact I’ve participated in several emotional discussions with people that experienced exactly that. (BTW, trying to go down the this was not agile road only seem to fuel the fire).

Can it be good?

Well, I don’t know. However, I’m not sure that’s even an interesting question. Personally, I would avoid a mini waterfall. If you try to become agile you should probably try doing something different. There are easier and less risky ways to start. Trying Kanban might be a good alternative if you want to start at a familiar place.

But we already are in a Mini Waterfall. Now What?

First, realize that by understanding the problem you are half way there.  Best option at this stage is to face reality heads on. Stop pretending you are Agile. You are not and it’s really not important at all. Accept the fact that the problems you see are naturally caused by trying to take a lengthy process (designed for long cycles) and squeeze it into  a very short time period (iterations). What’s actually crucial at this stage is to examine the pains and learn from them. Each and every pain is a place in which something new can be learned, about your process, about your team about the context or maybe personally about yourself.  If you manage to locate the actual root cause there’s a good chance you can make real progress. Design small experiments with the goal of finding out what may be the cause of those pains. Try to test different things and see how they affect your team. Collaborate with other parties in the organization and see what they have to say. And always remember that a new process (yes, even a mini waterfall) requires a new way of thinking to make it work. Most likely old solutions won’t solve these new problems.

Scrum is not a process

One of the most common discussion that always seem to pop up again and again, is whether Scrum /Agile is good or bad. I don’t know why, but in most cases, it’s starts with a claim that Scrum is not  good since it… and then state a reason. (Or with the claim that Agile is dead) ,for example

Scrum is not a good process cause its not complete, it doesn’t define everything you need in order to succeed.

Or

Scrum is not a good process. Team members are not equal, each has his own set of skills and ability and treating them as equals will not work.

And although in many cases, those arguments make some sort of logic, what most of them are missing is that scrum is NOT a process. Scrum is a framework.
Don’t get me wrong, I don’t believe in silver bullets, I don’t think that there is one solution (process) that fits them all. Each project context is different. The people involved are different, the technology varies, the business domain changes. While there are common patterns of issues and behaviors that we can look for, at the end each project is a unique, and therefore will need a different way of doing things in order to succeed. That’s what I love about Scrum (and Kanban and XP), they are flexible enough to handle most of the diversity you can find.

Scrum as a Framework

Scrum is just a tool. But a tool for what?
Many people consider scrum as a process for software development. That is, Scrum is a tool used in project management that will help you to create a product at the end. But that’s not exactly right.
Scrum is actually a tool for creating other tools, more specifically Scrum is the tool which you use to create a your development process. The process that you end up with after you “applied” the Scrum tool, is the “tool” you use to build your product.
Confusing? Yes? Let’s try again.
Normally this means, that in the process of using Scrum you take the company, the people/team, the technology and the product. Those are things you feed into the Scrum Machine (along with many other things) and at the end after some time you get one new development process. That process is what you use in order to manage your project.

Scrum is not a Process

So what’s the actual difference? Why, the fact that scrum is a framework important?
When I see teams taking Scrum as a process, what many of them fails to realize that there a lot of hard work involved. They start with using Scrum and expect that all of their problems will go away. They read the book follow everything that is written there with the best of their ability and they expect that everything will be fine. What then happens is that Scrum does what it was meant to do, it starts by surfacing all the underlying dysfunctions that have been will hidden there. That’s what Scrum does best.
In order for a team to create a good working process, it must resolve its dysfunctions. The Scrum framework was designed with the sole purpose of exposing them in order for the team to face them and find a working solution.
In fact, this is exactly the stage in which many Scrum adoptions fails. Its seems to be really hard, When a team starts using Scrum all kinds of problem starts. So clearly if Scrum is causing all these problems it might not be such a good idea.
In some case the team will try to stick a little longer with the Scrum book. That usually doesn’t help. In other cases the Team will revert back to old habits that seem to have worked in the past. That doesn’t work as well. They either end up in their old process (and then the claim that Scrum has failed) or they end end up somewhere else that technically looks like a scrum based process, but in essence is not (a mini waterfall is one example)
Scrum book has no solution for dealing with bad coding, it states nothing about how to create a good flexible architecture. it doesn’t give you an idea how to handle two team members that simply cant work together,….

Knowing your tool

There’s a reason why most scrum implementation fails. Like any tool, one need to learn and practice using it. No one expects that his holes will be perfect the first time he picks up a power drill. Right?
Managing a software project is a little bit more complex than that, and still people read the scrum book which seems to be simple enough and expects everything to work. It doesn’t, Especially if you confuse your tools. Especially if you think that Scrum has all the answers, Especially if you think that since scrum defines three roles those are the only roles that you ever need on a project. Especially if you think that the 4 ceremonies are all the meetings you will ever need. Especially if you think that a daily meeting is just a daily status report, Especially if you think that you can continue writing the software like you ever did and still deliver something every two or three weeks, and I can continue forever like this.
Especially if you fail to realize that when using Scrum you will need to work hard in order to create a working process for your team.
So one more time

SCRUM IS NOT A PROCESS

Are you also

  • Feeling you can do a lot better?
  • Thinking there’s much more to Scrum and Agile?
  • Having a hard time Finding your place with the team?
  • Doing things you are not sure you fully understand?

Image by Pete Curcio from Pixabay