Agile does not mean fast

When people think of Agile, what drives customers’ interest in Agile is thinking that Agile will enable them to get projects don’t faster and cheaper than the classic project management. But that is not always the case.  

Agile is not synonymous with fast. The dictionary defines “agile” as “able to move quickly and easily”. An Agile team is one that can quickly and easily react to changes in project’s requirements and new ideas as the project takes shape in front of the customer. If you think of a project as a road trip from point A (start of the project) to point B (delivery of the project), an Agile team is the one that doesn’t get slowed down or thrown off course by road construction, avalanches or collapsed bridges. Agile teams don’t blindly follow the GPS. If the GPS is leading them straight into the ocean, they can adjust their course quickly enough to not slow down the project. They don’t need to stop or even return back home and plan a different route.

But all that does not imply that they will get to their destination faster than anyone else. It just means that they will get to their destination, no matter the obstacles along the way.

Such agility, however, comes at a cost. The overall trip may end up taking longer than what the GPS originally promised you because it didn’t know about the missing bridge ahead. And it may even cost more: you might need to bring an extra person with you, someone who knows the roads well. But you will get to your destination and with great road trip stories to tell.

 

The cost of Agile

 

A lot of customers want to run their projects Agile. Agile is hot, sexy and all the cool kids are doing it.

But when your customer asks you to run their project Agile, do they really know what they are getting into?

Everybody likes the advantages of Agile: the daily stand-ups, the working product at the end of every iteration, the team working on features that add value. But there is a cost and a time commitment that is not always expected or understood.

An Agile project runs on user stories. “As a website admin, I want to Create a new user”. “As a new user, I want to Register on the site”. “As a user, I want to Sign up for a course”. A well crafted Agile story is made up of acceptance criteria that defines all the business rules behind the story. If a user wants to sign up for a course, what are the rules? Can they select any course? Can they select more than one course? Can they select a course that has already started? Can they select a course that starts tomorrow and it is 9 PM today? Can they sign up if they are currently enrolled in another course? What if the current course ends before the other one begins? And so on and so forth.

Somebody has to define all these stories and think trough all these scenarios. That somebody is your customer. In an Agile project, no longer can they simply work with you through the analysis phase, wait for you to write up the spec document, approve the spec and walk away awaiting the first demo milestone. In an Agile project, the customer has to be involved a lot more, almost every step of the way as stories are being written. Are they willing to make that commitment?

The other side of user stories is that somebody actually has to write them. A business analyst or an architect has to work with the customer to think through all the scenarios and to capture them into stories that will then feed the development team. Depending on the size of the team, there may need to be multiple authors. 1 author should be able to keep up with a team of 2 – 3 developers. But once the team grows to 4, 5 or more, the developers will generally consume stories faster than 1 author can write them. And considering that the story author wants to stay at least 1, if not 2 sprints ahead of the developers, story writing becomes a full time job, which will add to the cost of the project.

So when a customer asks you to run their project as Agile, make sure they understand what’s involved. Start your project with an education session on what it means to do an Agile project, explain the time commitment on their part and the additional cost to the project. And if at the end they still want to do it, make them sign something, an Agile manifesto of sorts.

 

Agile or waterfall

Coke or Pepsi? Miller or Bud? Mac or PC? Agile or Waterfall?

When a consulting company embarks on a project, what is a better methodology to use: Agile or the traditional Waterfall? What projects lend themselves better to one or the other?

Waterfall methodology seems to work better when a project presents a known problem with a known solution. Upgrading a server, creating a time-off system, or building a submarine — all are projects that are better executed by the waterfall approach. You know the problem, you know how to solve it, chances are you’ve solved it before and probably more than once. Each project will have a defined scope, a set of requirements that must be met in order for the project to be completed: the server must be upgraded to the new version, the time off system must allow employees submit leave requests, and the submarine, well, the submarine, must submerge. There’s little room for creativity, in fact, creativity may be bad — a creative approach may cause the submarine to sink or the leave request to violate HR policies.

Unexpected problems may certainly arise in each project, but nothing that would require you to completely change your approach. Nothing that a good PM can’t deal with.

The Agile methodology, on the other hand, seems to be better suited to that creative approach. You know the problem, but you don’t know how to solve it. Building a system to allow employees take advantage of a new benefit and trade unused time off for cash or for cash donations to charity may be an example of such project, especially when the HR policy around this benefit is still being defined. Such project would not have a defined scope or a set of requirements. The requirements are going to be defined throughout the project as it is being built and features are starting to take shape, sparking new ideas and new features.

But there’s a caveat. The business owner, the client needs to know what they are getting into it and agree that their project is going to be an Agile project, a creative process focused on delivering business value rather than fulfilling a set of requirements from a contract.