I’m baaaack! On the road again

I’m baaack! On the road again.

I know it’s the wrong song, but it my head I sound like Aerosmith singing “Back in the Saddle”.

60 degrees in early March in Chicago, weekend — I’m riding! Get that bike out of the basement; dust off my helmet and the riding glasses; and let’s see whether all this riding on rollers is going to pay off.

First of all, no amount of indoor training can truly prepare you for the road. No matter how fit and strong you think you are, the road is hard. When you’re going 20+ miles per hour and spinning at 80+ RPM in your largest chainring, it is likely not the months of off-season training paying off, it’s the wind in your back. Unfortunately, you only realize this when you turn around and that wind hits you in the face.

Second, it still is early March in Chicago. Going out in shorts and a short sleeved jersey with just a t-shirt underneath may not have been the best idea. When the sun is behind clouds and that wind is in your face, it is bloody cold.

And lastly, I missed my kung-fu movies and definitely did not miss suburban drivers and unchained dogs.

But nothing can take away the joy of actually being outside, on the road, watching the empty brown fields and bare trees fly by. And, all joking aside, the off-season training really does pay off. Even on this first ride of the year, you feel stronger and better prepared than you would have been otherwise. You can actually enjoy the ride as opposed to struggling through it and cursing all those rich winter-time foods.

So here’s to a great start of another riding season.

 

 

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.