How We Box Ourselves In (with Software Projects)

August 28, 2013

In last week’s post I advocated that if our goal is to produce great customer outcomes (at a profit), then we shouldn’t box ourselves in. I outlined some ways that plan-driven approaches box ourselves in, such as by fully defining requirements and approving requirements up front – and then planning oriented around delivering those requirements according to an estimated schedule.

This gets ugly if someone high up in the organization has a pre-determined date in mind. Teams can get pressed into the, “What is the date that I’m thinking of?” game. But it can get ugly for other reasons. I’ll use this post to explore why traditional, plan-driven approaches go bad.

Producing Great Outcomes: Don’t Box Yourself In!

August 21, 2013

When it comes to transitioning to agile, some changes are easier than others. The easiest change to make always involves the other guy or gal; or in the case of agile, when it involves the development team and not the rest of the organization.

If everyone in the organization does not understand how agile planning differs from traditional planning, organizational friction and frustration will result because expectations are different. Agile teams will be expecting and doing one thing while other parts of the organization will be expecting and wanting to see something else.

With agile, the challenge is to: Produce great customer outcomes in the shortest amount of time possible – using the least amount of effort – while creating a sustainable, rewarding, satisfying work environment.

Fundamentally, we’re striving to define, deliver, and profit – in a way that meets this challenge.

Velocity: It’s Strictly a Team Measure

August 14, 2013

But just what is velocity? It you equate velocity as a strictly a measure of speed that can be universally measured and compared, think again.

Speed measures how fast you are going, but velocity adds an extra dimension: direction. Therefore, velocity is a measure of how fast you are moving in a given direction. When it comes to agile (Scrum) teams, velocity is a measure of how fast a team is delivering value to the customer, following the direction set by the product backlog.

A few key factors that impact a team’s velocity:
  • The composition of the team and team dynamics.
  • The adaptive state of the product(s).
  • The practices (or lack of practices) employed by the team.

Three Keys to Being Responsive and Adaptive

August 7, 2013

A key benefit of being agile is the ability to adapt to rapidly changing conditions with minimal disruption and effort. As the leading agile framework in use today, Scrum provides the necessary guidance to make this happen from both a product planning and implementation perspective.

However, “It’s in the way that you use it,” as Eric Clapton’s song puts it. To be truly responsive and adaptive we need to make sure that we have all of the enablers in play, leveraging the Scrum framework for what it is: an agile framework.