As I said
somewhere else in this site, I'm passionate when it comes to programming, seeing it as a craft to be perfected. It is no surprise, then, that I became a confessed Agilist.
Something happened today that made me think about what I think is the meaning to be Agile. The quick answer would be "To value the
Agile Manifesto", but somehow I felt that there is more to Agile than that. This is the end result of my musings
Being Agile is more than follow a strict set of practices religiously,
that span over all the software development life cycle. It more than
trying to go faster, or trying to work better.
Being Agile means to embrace uncertainty, accept change. It means to
work on what is actually needed, to produce actual value. It is not
measured by the number of practices being followed, or by tagging your
process with a methodology. It can be measured by how much we value the
manifesto, but the best measure should be the smiles in our users and
our team.
Being Agile is more than having a tag or following a procedure. It
is a way of thinking, a professional lifestyle, that must be ingrained
in the core of the corporate culture, from the C level to the
developers, including all the departments.
To become Agile you must be ready to break some paradigms, to challenge the status quo.
Are you ready?
Johanna Rothman, in
in her product development blog talks about when a spec should freeze. She basically said "specs never freeze, people communicate about what they want all the time".
What caught my eye was one commenter that said "
There is always a point at which the spec must freeze; otherwise,
either quality will suffer in some way, or the wrong functionality may
not be delivered". That's kind of true, but the problem is not with the lack of spec freeze.
There are two reasons we would like to freeze the spec: either we're working with several groups that don't belong to the same team (ie, hardware and software team), and the spec is the point of communication between them, or we work with just one team but want the team to be very sure what we want delivered. The former is material for another post, so I'll focus on the later reason.
One thing about freezing specs is very unusual: it is one of the very uncommon points where all the actors involved agree that must be done. Why? Because it adds an illusion of predictability (we know what is going to be delivered way in advance), and is a shield to deflect blame. This blame deflection eagerness can make the act of changing the spec a very expensive process. The irony is that by protecting themselves, they are increasing the chances of failure.
In my experience, assuming that the team is able to deliver whatever is on the spec, the problems is not the act changing of the spec that brings the problem, but the lack of focus when changing it and the unwillingness to change the schedule.
If the team has the golden pair of good Product Owner and Project Manager, both will make sure that the changes to the spec are really needed and will negotiate any change in the scope.
If all the actors trust each other, and all the changes to specs and schedule are visible to everyone, there is no need to freeze the spec.
I have seen all scenarios: I had an spec that was "open" for about 6 months. It grew in scope. We even rewrote complete parts of already implemented the functionalities (early stories) because the business side discovered that they got it wrong the first time. And it was ok. The business side was deligthed with the end result.
On the other (darker) side, I had a spec frozen that covered a 3 month development. We required 2 more requirements after that (frozen, of course) to get to what the business needed. It took us 6 months, we delivered what was on the spec, by the letter. But the business was not deligthed.
And finally, I witnessed (as an outsider, thanks God) specs changing weekly, in an uncontrolled way, adding scope and changing functions that where implemented the week before in a radical way... without changing the schedule.
In short, trust each other. Then you won't need a spec freeze, only a "we have enough to start working" flag on the spec.
I have been in a very unique position, seeing crunches that worked and crunches that didn't on the same team (same people, same project).
Those that didn't work, started with the management saying (nearly at the end of the plan) "we are late, crunch time". People felt that things were poorly planned, deadlines where imposed from above, and all those things developers think at those times. End result: we made the dates... with a lot of effort, a lot of "burn down", and alot of defects.
Later on the same project but different release, priorities changed, new requirements came, and the deadline was no longer "achievable", We negotiated a new reduced scope, but even the reduced scope was not possible under normal circumstances (scope could not be reduced further because monetary penalties for the client were at stake). Result? We told that to the team, and curiously enough the TEAM declared "cruch time, let's hit that deadline!". High morale, High energy. One month later, we made it. With a lot less errors than the last time.
Yes, crunches work some times. The interesting thing is identifying why those "some times" it works.
My guess?
When management declares "crunch time", and the team feels that the plan was impossible to begin with and that it was a known fact since the beginning, the crunch will fail (low morale, low productivity, etc,etc,etc). But if the team feels that the plan was achievable, and that what happens is just a roadblock in an otherwise clean road, they will "do their best" to hit the deadline anyway (programmers are stubborn optimistic beasts). Management must just take care that no one burns out due to overwork, the sense of purpose will give the morale and energy needed.
So, at the end, if you manage your project correctly and "crunch time" is due to an unforseen cause the team will help you to hit the deadline. If you mismanaged the project, the team may save you once or twice. After that, they lose trust and will eventually leave.
Good luck, and Happy Blogging!
