Agile

Our Sprint Velocity Never Seems to Change. We don’t Know Why!

Story point is about size, not about time.

At best it can be about a range of time but not about absolute time. In many teams people map story point directly to time and may get into vicious cycle towards burnout.

Let’s try to understand why.

Let’s say, the team mapped 1 story point to 1 day. As they do that, the team velocity becomes almost constant. The reason being, the team capacity in terms of number of days remains constant.

As team mapped 1 story point to a day, the story points to be planned or achieved will always be around the capacity (number of business days available) of the team.

Management folks may complain that team throughput is not changing. Throughput might have already changed but it will never show up.

Instead of completing 10 similar sized stories, team may be finishing 14 already but that will never reflect as number of days required to accomplish them remain constant from sprint to sprint.

So never map a story point to time unit as that will create more problems than it solves.

More on Story Points and Agile Estimation

This post is a part of a blog post series on story points and agile estimation. To read rest of the posts on the subject, please navigate to All About Story Points and Agile Estimation Series.

Demystifying Continuous Delivery

by ShriKant Vashishtha Leave a Comment

We face real-world challenges where straightforward answers provided in rule books are in conflict with empirical evidence. That’s where Tim helps us understand these nuances and demystifies the problem space.

Our Slack group “Agile Commune” contains many insightful conversations with Tim. We’re publishing some as part of “In Conversation with Tim Ottinger” series. Looking forward to your comments and experiences on these topics.

People talk about CI (Continuous Integration) and CD (Continuous Delivery) in the same breath but may not be aware of their differences: Continuous Integration in itself is not Continuous Delivery.

Similarly, people used to releasing multiple features in a rollout may find it difficult the need of multiple deployments in a day OR multiple releases for a feature.

So let’s hear from Tim more on Continuous Integration, Continuous Delivery, and DevOps!

The Essence of Agile

by ShriKant Vashishtha 2 Comments

A question, “What exactly is Agile?”, keeps troubling people.

They either make reference to the manifesto or map it with Scrum and then get circled in its events and practices.

Though Agile movement started as a better way of developing software, it has moved beyond software development.

Agility has evolved into a way of thinking, permeated to organizational work culture, experimentations, better ways of doing business, product development and servicing customers.

It started in the context of and in reaction to the Waterfall approach initially. Now it doesn’t have anything specific to compare to. It’s ever-evolving.

That’s the reason, even though the movement began with Agile manifesto, the manifesto in itself didn’t remain a constraint in making further improvements ever. In the last few years, people have evolved and embraced Modern Agile concepts, Lean thinking, Lean Startup and Design Thinking approaches for the same reason.

Definition

If you look at the online dictionary, ‘agile’ means “able to move quickly and easily” with an emphasis on changing direction. Taking a cue from its dictionary meaning – ‘agile’ is the ability to create and respond to change, quickly and with ease in order to succeed in an uncertain and turbulent environment.

From the software development perspective, in the late 1990’s, several software development frameworks emphasized close collaboration between the development team and business stakeholders; frequent delivery of business value, self-organizing teams; and smart ways to craft, confirm, and deliver code.

In early 2001, 17 software development practitioners gathered in Utah to discuss their shared ideas and various approaches to software development.

‘Agile’ is an ordinary word in English, it means “able to move quickly and easily” (online dictionary), with an emphasis on changing direction. It was for that reason we chose the word to match the sense of the way we wanted to work, when discussing our approach to software development back in 2001.
— Alistair Cockburn

Once these practitioners had the word in place, they had to decide what it meant to them for the purpose of writing software. They chose 4 values to centre themselves in the world while working and added 12 principles.

Question: There may be innumerable practices suited to, or may evolve in a context. How to ensure if those are acceptable in Agile methods?

Answer: Agile methods are based on common sense. As long as a method or practice is in line with the intent of agility and with Agile values and principles, you are fine.

For instance, a team realized that distributed retrospective along with the customer team was not helping them in solving local problems. They decided to have a local retrospective as well and it worked pretty well for them. Similarly, though the definition of Ready is not essential in the Scrum guide, it is tremendously useful in the context of distributed teams working in opposite time zones.

Summary

Essentially, agile is about:

Are we able to create change and respond to changes, quickly and with ease in an uncertain and turbulent environment?
Do we center ourselves on manifesto’s four values and principles?

References

Alistair Cockburn’s Interview

In Conversation with Tim Ottinger Series: Should We Really Care for Agile Maturity?

by ShriKant Vashishtha Leave a Comment

We keep facing real world challenges in Agile world. For some challenges, the rule-books provide straightforward answers but empirical evidences show the contrary. That’s where Tim steps in and helps us in understanding the nuances and demystifying the problem space.

In recent past, we have had many such conversations with Tim on our Slack group “Agile Commune”. All those are full of insights and very helpful. We’re making some of them public as part of “In Conversation with Tim Ottinger Series“. Looking forward for your comments and experiences on these topics.

Shrikant: Hi Tim. The tools (like Scrum, Kanban, TOC, XP etc) are to solve business problems. They themselves are not the goal. How do you define agility?

Tim: To me “Agility is a means to an end, not an end unto itself.”

I would say that agility is a process goal, not a business goal.

To be able to change direction at the drop of a hat is powerful — provided your organization plans to do some pivoting.

Agile methods have the goal of creating some agility in the business, or at least the conditions making it possible.

Some methods are better at using agility than others.

But remember that a skateboard is more agile than a freight train, but a freight train is bigger and faster than a skateboard.

Be sure you know what you want.

What Exactly do We Want to Achieve Through Agile? – A Google Maps Example

by ShriKant Vashishtha Leave a Comment

‘agile’ is an ordinary word in English. It means “able to move quickly and easily” (online dictionary), with an emphasis on changing direction.

So essentially ‘agile’ is the ability to create and respond to change in order to succeed in an uncertain and turbulent environment.

Recently I observed that real world traffic and Google Maps can help a lot in explaining the concept of agility. This post is all about joining the dots.

Driving in a real world traffic is not straightforward. Time taken to cover a distance depends on traffic jams, weather conditions and other unknowns.

When someone asks how much time it will take to cover a specific distance in Delhi traffic for instance, only true answer is a range of time, say anything between 30 minutes to 1-1/2 hours.

Moving back to software world, when someone asks a similar question, e.g. provide an estimate for a complex software project, there can’t be a single estimate but will be a range of estimates, i.e. anything between ideal scenario and the worst case scenario.