Why You Should Adopt Agile

September 25, 2013

Are you on the fence about adopting agile? If so, what is holding you back?

Agile development is all about delivering the greatest value in the shortest time possible, using the least amount of effort. This does not equate to being simplistic; it’s about using the most direct approach to accomplish what is needed. For those who are considering adopting agile (and for those who need to persuade others), here are some points to consider.

Iterating is NOT Just a Re-Work Strategy

September 18, 2013

Not with agile development, anyway…

When iterating is taken at face value without further discussion and clarification, the concept can create a misunderstanding about what we’re striving for with agile development. Here are a couple of negative connotations typically associated with iterating:
“We’re re-taking ground that we have already covered.”

“We didn’t‘do our homework up front.”
This can lead to that inevitable judgment:
“This agile stuff is crap. We’ll never get anything done by continually re-working everything.”
In the first place, if you are re-working everything, something is fundamentally wrong that any process alone can’t fix. It’s a signal that you aren’t aligned with what your customer wants. In fact, you don’t even have a basic understanding of what your customer really needs.

What It Means to Be Adaptable

September 11, 2013

“Responding to change over following a plan” is one of the four values of the Agile Manifesto. Is your first reaction to think about changing requirements? This is often the general perception of what adapting means in an agile context, particularly when we refer to one of the principles of the Agile Manifesto:
“Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage”
We do need some flexibility in our thinking and approach so that we can adapt to new or changing business requirements. We can’t have the mindset that everything is cast in stone and unchanging because software development is a product development exercise where learning and discovery will take place.

Order in the Backlog!

September 4, 2013

Ah, the English language! It is rich, yet full of little nuances that can create difficulties. For example, what is the difference between a prioritized Product Backlog and an ordered Product Backlog?

For those who may have overlooked it, the 2011 Scrum Guide changed from referring to the Product Backlog as being prioritized to it being ordered. And since this wording was retained in the 2013 version of the Scrum Guide, just what is an ordered backlog, and how is it different from being prioritized?

Let’s start with prioritization, which can be a challenging thing to do because I’ve come across managers (stakeholders) who desire multiple “number one” priorities. Yes, this is a case of not prioritizing at all. Enough said on that point.