Dilbert Knows Agile | centresource blog | nashville, tn

4

Dilbert Knows Agile

by Matthew Phillips on Oct 27, 2011 under Development, Interactive Strategy

No planning, no documentation, no problem. That is the Agile development approach right? Well, I might be new to this Agile approach, but I would argue it’s MORE. I am a Project Manager by heart, so NO planning and NO documentation is simply unacceptable. Sorry Dilbert. Seeing how Agile Development is a buzz lately, I figured I would approach this topic from a Strategist’s point of view.

So, what is this Agile Development thing?
Doing a quick search of Agile Development you will get several different definitions. Most all of them say its a hard term to define. The key words you will see are “evolve”, “collaboration”, “iterative” and “cross-functional teams.” However you want to define it, we love agile development because it provides us the freedom to make decisions as we go.

What is the process for Agile Development?
Well…Agile :) We start out with a charter, a mission statement for where we are going. This will be our flag ship document that everything is based on upfront. From there, we plan for the checkpoints to review progress and analyze results. With each milestone that comes it is expected that timelines will adjust. Tasks may be completed quicker, we may add more work to the task. Revisions come as needed, but always with purpose.

When taking on an Agile project I look to document the process. Documentation is the best way to track and show results. From a strategist point of view taking on an Agile Development project can be a bit intimidating. Since Strategists are ultimately responsible for scope, timeline and budget; Agile development may seem like herding cats. We need to defend decisions with documentation.

Share This

Agile-a-go-go

Your comment “We need to defend decisions with documentation.” shows that you haven’t really grasped the ethos of agile. You shouldn’t need to “defend” your decisions. In agile decisions are taken with the knowledge to hand at the time, involving the people who need to have a say, and with the understanding that things may need to be adjusted over time. You adjust and revise, but not to get to where you intended to be in your mission statement, but where you recognise you need to be as you learn along the way. You can adapt to a changing market, changing business priorities and changing constraints, to continuously deliver real business value – that’s agile.
Agile-a-go-go

Your comment “We need to defend decisions with documentation.” shows that you haven’t really grasped the ethos of agile. You shouldn’t need to “defend” your decisions. In agile decisions are taken with the knowledge to hand at the time, involving the people who need to have a say, and with the understanding that things may need to be adjusted over time. You adjust and revise, but not to get to where you intended to be in your mission statement, but where you recognise you need to be as you learn along the way. You can adapt to a changing market, changing business priorities and changing constraints, to continuously deliver real business value – that’s agile.
Mphillips

Sorry for my delay in response. I’m not sure that your comment is different from the thesis of the
post. I agree that priorities are set at the beginning of each sprint,
by the appropriate team members based on the market and business
constraints at that time. “Revisions come as needed, but always with
purpose.” Even if checkpoints, daily scrum meetings and a only launch
with working software approach, variances can happen without good
documentation. My point is in an agency / client relationship looking
back on decisions made several months ago can be foggy. I doubt that
anyone would disagree, we need the ability to review documentation from
past periods in case budget or velocity are questioned.
Mphillips

Sorry for my delay in response. I’m not sure that your comment is different from the thesis of the
post. I agree that priorities are set at the beginning of each sprint,
by the appropriate team members based on the market and business
constraints at that time. “Revisions come as needed, but always with
purpose.” Even if checkpoints, daily scrum meetings and a only launch
with working software approach, variances can happen without good
documentation. My point is in an agency / client relationship looking
back on decisions made several months ago can be foggy. I doubt that
anyone would disagree, we need the ability to review documentation from
past periods in case budget or velocity are questioned.