Agile - What's in it for me?
Introduction
Let's start with what Agile means at a very basic level. The four key elements are:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
The normal introduction then proceeds with we understand that there
is value in the items on the right, there is more value in the items on
the left.
The working practices then extend these key principles in ways that
provide a real business benefit along with a cleaner/more transparent
and positive development environment. I've been using Scrum as a team
member and team leader for nearly 2 years and have to say that while I
was sceptical early on, I've become a real fan and can see the benefits
to all side.
Business Value
There are often stories of how business feels like developers are a
lore on to themselves. The developers can't estimate with any sense of
accuracy. We don't know when the next version of the software will be
released. Well, Agile project management systems such as Scrum can
really help the business not only gain a transparent insight into the
process, they can actually affect the progress of the project as it
proceeds and provide key input rather than having software built on
incorrect assumptions.
The first part of implementing agile project management involves the
creation of an initial version of a product backlog. For the
uninitiated the backlog is simply a list of features that you'd like to
implement in a project. They can be minor things or large features, but
each should be easily describable to the team in terms of what is
required.
For a given period of development (the agile term is a "sprint") the
Product Owner (normally a business representative) gets to specify the
order of priority for the features. It may be that if the developers
can only accept 10 items from the list that these aren't the absolute
top 10 from the list (due to the size of the items, the developers
choose to commit to what they can deliver), but they will certainly be
among the highest priority items. That means that every two weeks you
get a chance to reprioritise the work the development team will do.
You are also able to easily see during the sprint progress on the
items the team chose in the form of a chart that tracks daily progress.
You may also attend the daily stand up meeting which takes no more than
15 minutes per day (although under Scrum rules at least, you must not
ask questions only listen).
As I said earlier, one of the problems solved with an agile
scrum-style system is that of estimation. Writing software is
necessarily hard to do. The traditional wisdom is that the more time
you spend estimating and analysing the requirements the more accurate
the estimate becomes. Unfortunately, recent research shows that a gut
feel (given after a few minutes discussion of a single feature) is as
accurate as one that takes days to produce. Or at least it's no less
accurate. So, I hear you ask how does agile estimation help make it
more accurate. The truth is that it doesn't, but what it does allow for
is the factoring in of how inaccurate your estimates are over a
relatively short period of time.
The way it works is this - tasks are estimated in abstract points.
The team commits to a certain number of points and tries to deliver
them. Next sprint you'll know how many they actually delivered and then
use this number of points as a basis for the next sprint. Over a few
sprints the number of points will come up and down and start to average
out quite nicely. This is a very good way of determining how much work
the team can do in a sprint. The advantage over hours is that there's
not the implied accuracy and by working abstractly it doesn't sound
like the team is only working for 4 hours per day (an estimate of 4
hours may take 7 to deliver consistently - it doesn't mean they're only
working for 4 hours per day, just that it's the inaccuracy in their
estimates).
Using the average velocity you can get an approximation of when the
project will be complete. However, remember that it isn't n weeks until
you launch, you can launch at the end of every sprint (or even before
if you practice continuous deployment) and throughtout the project
you're getting the work out there and generating business value. As all
features are developed with automated tests during the sprint you can
also be assured of a high quality product/project.
Developer Benefits
There are a number benefits to a company of implementing scrum for
your development team and they aren't all focussed at the "business"
side of the equation. For me the most important one that is very rarely
mentioned in agile/scrum presentations is the "no blame culture". Where
I'm currently leading a scrum team when we find a bug the question is
never "can you find out who wrote this line of code", it's just "how
can we fix it". It's absolutely an amazing feeling knowing if you ever
introduce a bug (nobody's perfect) that you won't have the bosses
bringing you to task for it. It may sound like this means that you can
write shoddy code in agile teams. While I guess you could write shoddy
code in any environment, with the full automated tests (a task/feature
isn't DONE unless it has automated tests that prove it) and the
collective ownership of the code there's an amazing sense of pride in
developing a great product.
In a traditional department features are specified, wireframed,
described in various levels of diagram and chart and approved in
triplicate by everyone from the cleaner to the CEO before you can write
the code. In agile environments documentation should be "barely
sufficient". That means you should document enough that you have
exactly what you need and nothing more. The environment favours getting
two people together to talk or look at a screen rather than document
and sign off features on paper. The advantage of this to developers,
aside from the obvious one that most developers hate paperwork, is that
you generally can develop features quickly and get the local business
representative to have a quick look with you early on in your progress.
This makes them happy (as they feel part of the process) and because
you end up delivering a feature that exactly suits their requirements
without writing lots of boring docs it makes you happy.
The team is empowered in agile development. This can often be the
hardest aspect for businesses to come to terms with. It can also be the
hardest one to absolutely implement. For example, if the team feels
they'd be more productive with two monitors or Macs instead of PCs
(both of which I absolutely agree with by the way) or if they want more
whiteboards, or to move desks around then they should be able to do so
without hinderance. Obviously this is difficult though as most of those
items cost money and the budget may not allow for them (however,
considering developer productivity it often is a lot more cost
effective to give developers the equipment they want). It can also mean
empowerment in removing or amending processes. For example, if it
currently takes 3 levels of sign off to deploy the software or approve
a holiday they can work to remove the inefficiencies. In the daily
stand-up meeting they can also raise anything stopping them doing their
job and it's the scrum master's (or team leader's for non-Scrum agile
teams) job to remove the impediment.
The idea of an agile team is centred around the team concept. You
aren't 8 developers, you are 1 team. Everyone should be able to work on
every part of the project; you should never have to say "I can't touch
the AccountPaymentFactory class, only John can do that". If there is a
particular skillset a developer is lacking, they can pick their next
task as being one that will help them learn it. If they want to pair
program for a while with someone with more experience in that area,
that's fine too.
Conclusion
The short summary is that agile development leads to a clearer
understanding between business and development, it allows for happier
developer through more relaxed and natural practices and it allows for
happier businesses with increased visibility and better responsiveness
to changing priorities. There are downsides - for one it's a complete
change of culture which can take some getting used to, but I honestly
believe everyone should consider agile development - particularly if
you are having any of the traditional problems with dealing with "the
other side" in your company.
What do you think? Are you an agile developer loving it as much as
I am? A traditional developer wishing for agile? Or a traditional
developer that thinks agile is a crock of ...? Let me know in the
comments.
3 Comments so far
BT wrote on 25 March 2009 at 04:55
Thank you for the post. I stumbled upon this post because I am looking for a new job and it appears that the hiring manager where I'm applying is fond of Agile development. Thus, I'm trying to get my jargon in tact.
That being said, I have a theory regarding Agile development and it may be unpopular. My theory, which I'll get to later, is based on the fact that after studying Agile development, I realize that this is the type of development my team and I have been participating in for the last six years. We just didn't know it was called Agile because it is something that has evolved based on necessity and hasn't been named.
See, I work in an under-staffed software shop where our disorderly manager over-promises functionality to end-users on a regular basis and then offers specifications on a paper napkin. We call this methodology "Bending Over Backwards" but I suppose Agile is a better term.
My theory is this, I believe that someone like my manager took the negatives of "under-staffed", "disorderly", "over-promised", and made them positive by calling them Agile. Now, people like you and I are forced to learn ever more jargon before acquiring another job. Also, we must be more positive about our manager because they are no longer unorganized but Agile and hip.
I understand my tone is coming across as sarcastic but with over ten years of experience, I believe it has some validity. I also believe that Agile development is valid as well but it also has some major drawbacks.
First, everyone on your team must be fairly adept at understanding and properly implementing object-oriented programming and other related software technologies. For example, if you're duplicating code from Windows form, to Windows form, you will be spending too much time going back and forth between coding and debugging and thus your sprints will become longer than necessary. Likewise, if your team doesn't properly use views or doesn't normalize the database, you're going to run into problems. Thus, this drawback is, if you can't afford quality staff, Agile may not work for you.
Second, if your management is constantly taking you off one hot assignment and putting you on another, you are no longer Agile but are now a Fire Fighter. Thus, your management has to be on board with this but unfortunately, they are usually the problem.
Third, you must have proper specifications. With larger projects especially, I do not see how this can be done in four week sprints. Most large projects do require some in depth planning even if the project doesn't have to be signed off by three different people. I wish there were more explanations on this aspect--hopefully, I'll find them.
Sorry for the long response but just had to release some steam.
Thank You.
Eduardo Faria wrote on 10 May 2010 at 21:06
This is a very interesting way for developing. But there are some points that we have to take care with it.
The first is the necessity, at least a bit, of a sinergy in the team.
Second and last is precaution we have to have in bigger projects, on those we have to adapt this theory in some points, of couse, this points will be relative to the project and the team sinery.
I really love this kind of coding. And without knowing it I was, sort of, using it for the past few months and it really works well.
All this brilliant developing way is awesome because it cares for the quality of the product and the happiness of the developer. And more than that, I may say that is strongly linked with the new market way that we have today.
Thanks for all.
legeenjoync wrote on 09 November 2011 at 14:50
Hi! i'm Re-twit you post: to my @vokvfqjt twitter
Click here to have your say...