Dec 5

Written by: Peter Henry
Friday, December 05, 2008 11:04 PM

As I'm learning more and more about Agile practises/procedures, I'm starting to see why people fall in love all over again with development.  The more I talk with people about agile and scrum, the more I realize it's fundamentals are to help people accomplish things!

Before going down the Agile road last year I read a great book review about David Allen's book Getting Things Done.  It is a great read and after going through Ken Schwaber's book Agile Software Development with Scrum, I'm seeing some similarities.  Ok, you might have to stretch a little bit, but creating lists at the right time, reviewing them constantly and removing any/all distractions to let you work on only what's the top priority are only some of the similarities between Agile and GTD.

Focusing in on what's important!  That's what I want to talk about in this blog entry.  What YOU'LL get out of going Agile?!

Role/Actor	What You'll Get Out Of Agile	What It'll Cost You
Management (someone who calls the shots)	You will get a deliverable, something you can see/touch/smell/play with/install/uninstall/complain about or congratulation your people on.  This will happen on a regular and predictable timetable.  You will have specific periods of time to give your input and your input will be tracked and action taken upon. Less fire fighting/tactical reactions and more proactive/strategic decision making time.	Control.  You will have to forfeit the control you think you have over people to let them get their jobs done to make you look good. Oh, and make sure you're teams have a copy of a good word processor and spreadsheet.  You can get away with just this until you get to know Agile more.  Don't spend any money yet on expensive tools (save your $ for an end of sprint lunch for your teams :>).
Developers (someone who knows what OOP, TDD, BDD, XML, PPT, CLR, JRE, and TLA mean)	You will get to make decisions that will impact your day to day work as well as the success of your team, department and company!  With proper communication, you'll probably only get bugged about "issues" at specific times of the day/sprint/retrospective.  You will not have adhoc phone calls asking about lookup table values, configuration questions or "why doesn't this work the way I want it to?"  You will get a say in what you're team works on as well as have direct input into it's architecture, imagine that a jr developer having architecture input, very cool!	You will have to take ownership.  You own your work.  If it's done, great, if not,  you have to take the heat.  But don't worry, if you tell the truth at the Sprint meetings, people will know what's coming long enough ahead of time to help so you're NOT in that type of situation, so it's all good.
Customer (the one with the $$$$)	You will get what you want for the price you want.	You will HAVE to give your input.  Gone are the days you can just write up a two page document and expect to get it perfect the first time, and on budget.  You will have to commit some time to periodic reviews and give your advice, opinions on potential course corrections.  But this is good news, you will find out the corrections sooner than later, when it's CHEAP and easy to make them.

 

See, it's not that complicated, and that's the crux of it all, isn't it?  Make it simple to "get!"  That leaves more time for people to do their work and just get'er done! :>

 

 

References: Mark Levison: Scrum in a Nutshell or 5 minutes to learn scrum (http://www.notesfromatooluser.com/2006/11/scrum_in_a_nuts.html)

Copyright ©2008 Peter Henry

Tags: