Lately I have been thinking a lot about my firm eSolia’s way of managing support and projects. We have a lot of experience with PM for both business and IT, and have applied that experience repeatedly to improving our process. However, one day I was reading something about Agile teams and a Lean approach to doing business, and I started to notice that our approach already matched what was being discussed. Perhaps our approach would benefit from what was being discussed “in the literature”.
Looking into Agile, Lean and Scrum more, one thing I noticed about the Agile Manifesto is, it seems many teams claiming Agility are taking the most extreme stance possible, almost making reactionary excuses to avoid anything that smells of “structure”. Very rebellious, and it’s no wonder many of those same teams also claim that Agile does not work. But this sort of reactionary stance is not quite what the manifesto is stating.
Examining The Agile Manifesto Statements
What I want to do in this post is to look at the statements in the Agile Manifesto, and try to read between the lines. Here’s the four statements:
- Individuals and interactions over processes and tools.
- Working software over comprehensive documentation.
- Customer collaboration over contract negotiation.
- Responding to change over following a plan.
Now let me comment on each of these, which are value statements, in essence, that speak to priorities, rather than give license to ignore some of the less pleasant tasks a team working in the modern world has to undertake.
Individuals & Interactions over Processes and Tools
This statement means to me that teams should be talking to each other, celebrating and respecting the individual and his or her skills, rather than sticking to a fixed process idea, or a fixed standard tool. What it does not say is, “it’s ok to forgo all processes, toss out all tools”. From what I read, groups mis-interpret this to understand it as meaning they have license to be bound by no process.
This reaction may be to overly bureaucratic or illogical processes and forced tool lock-in, and I can sympathize. However, any team working within a business will have some manner of processes to follow. It’s certainly true for my firm’s work in IT Project Management, and in the very creative endeavor of software development. This first statement of the manifesto, itself is a reaction to such bureaucracy and inflexibility.
Working Software over Comprehensive Documentation
Another admonishment to “get your priorities straight”. In my case, it would usually need to be “working systems over comprehensive documentation” but in either case, of course, zero documentation is also not good. It’s saying make sure you focus on getting the thing working, before you get mired into “comprehensive” (read: overly detailed, soon-to-be-stale) docs. As much as possible, documentation should be built into your day-to-day process.
There is a sweet spot of an effective, just-right level of docs, between no docs at all, and the unpleasant situation where gantt charts so large you can’t even read through them in a short period of time, much less print them, and your team is spending most of its time tending to the docs. You have to ask, “am I trying to be an expert in MS Project, or am I trying to be an expert Project Manager.” Personally, I prefer the latter approach, keeping my eye on the prize, and conserving trees! That said, documentation is not the most popular subject, so you have to make it easy for the team, and there are many creative ways to “build it in”:
- Tools that auto-document databases or user interfaces.
- Sufficient time logging by the team members, that lets the team lead show stakeholders what it takes to create or implement a like system.
- Satisfying business requirements such as having test evidence for systems of record for compliance to regulations (FDA or SOX regs).
- Integrated tools like blog-posting from the command line, or Twitter posting from an instant message client.
- Programmer commit logs that have enough information to go back and figure out what was done.
Customer Collaboration over Contract Negotiation
The concepts of “user stories”, a prevalent way of defining testable requirements by software teams; of the “Lean” focus on letting customers “pull” from your firm the value that you define together with them from their perspective; of always linking customer requirements to acceptance testing, are all inherently collaborative in nature. If you are discussing the finer points of your contract mid-engagement, then you probably have not worked hard enough on collaborating, or establishing rapport with your customers. That’s not good, and there are plenty of good collaboration solutions out there, these days, as well as “team techniques” like SCRUM.
Responding to Change over Following a Plan
Reading into this point of the Agile Manifesto, nowhere does it say “you should not follow a plan” or indeed “there shall be no plan” as I have seen implied in many an article. No, this is urging teams to favor a flexibility in response to sticking steadfastly to a plan that’s, for example, derailed. The implication, to me, is that your planning should be flexible enough and malleable enough to bend and flow with the curve-balls that any creative endeavor will throw you.
The Agile Manifesto is not a license to favor only a relaxed, “anything goes” approach, but is rather a reality check, to get teams to favor such things over an overly-defined, restrictive, anal-retentive approach to project management. Teams that believe Agile is “broken” because they are not seeing the improvements that many such teams see, may wish to re-think their overall approach, and adjust as appropriate after reading and digesting these basic tenets once again. Thinking on these points written so long ago, the Agile Manifesto values are neither easy nor for the lazy, but they should be effective basic rallying points for teams, implemented correctly.
Japan, Winter 2009