Agile So Far
Agile is an umbrella term for a number of software development methodologies with a common set of principles. Basically it is a method that of managing projects that emphasize individual interactions collaboration and working software over and pretty much everything else.
Earlier this year I decided to update our current rapid application development methodology by incorporate some of the practices prescribed through Agile. My team started off with SCRUM meetings which are basically a daily stand-up meeting with a very specific agenda: you discuss what you’ve done the day before, what you’re going to do that day and bring up any obstacles or roadblocks on that may be impeding your progress. After a few months of doing this on a regular basis I decided to take the next step and get some training on how to fully implement Agile. In May I attended a fantastic Agile boot camp at ASPE-SLDC and came back reenergized and excited to get to all this into place. Over the course of May and the beginning of June my team and I went through multiple trainings on the methodologies prescribed by Agile; product release and iteration planning, relative estimation, and all of the practices that support these.
Our first iteration started on June 29, beginning with our very first planning meeting. My team is a little bit different than typical development teams we very rarely have projects that involve more than two team members and at the very most three people working on the same project at a given time. Typically we run projects at an individual level with me managing anywhere between 7 to 10 projects on any given day. Also, because we can’t give up support tasks during the course of an iteration we also implemented something a little bit different; we took the scrum master role and instead of that person purely responsibility for managing the day to day and removing obstacles we also assigned them as a jumper who takes care of support and any kind of production issues that pop up during the iteration thereby, in theory, eliminating interruptions to the rest of the team.
So far it’s working out really well. I believe our scrum master/jumper is fairly overwhelmed with tasks although I think he’s enjoying navigating his way through issues and knocking off to-do items quickly. The rest of the team is managing fairly well with their user stories and tasks but I think we’re still having an issue collectively in our ability to identify all the tasks that are necessary to implement a specific story; it can be difficult for some people that don’t go to that level of detail other than their own minds to start communicating those externally. We are also are having some struggles with time estimation and nailing down exactly how long it takes to accomplish tasks. I hope that most of my team understands that this is our first shot at it and I’m not expecting 100% accuracy nor am I expecting everything to run perfectly the entire time. I’m more interested in making sure that we’re learning and growing through the process, we are developing our own iteration flavor and that during our retrospective we discover ways to adjust and improve for the next one.
Taarradhin 