Getting caught up - how did the "agile experiment" work out?
For a while, blogging was a craze. Blogs are hard to keep up with, but at this point it's important at least for me to journal what goes on. So much has changed in the last year, I don't know where to begin - so I'll just try to pick up where I left off. A flury of posts to follow.
As a team we've morphed our processes to something that resembles Agile/scrum. Changing development processes is so disruptive, because it really takes a lot for your entire expanded team to get on board. There was a lot of interest, and (almost) everyone on the team was a willing participant.
It was tough not having an experienced "coach"/"scrum master" on board. We (Simon King and I) relied heavily on what we took away from David Hussman's lectures from NFJS. I got some real help in the form of our QA Lead later in the year, when she was able to attend Agile (?) in Washington D.C. She and another QA analyst came back renewed, at a time when I was "hitting the wall" and getting tired of carrying that particular ball. She has introduced at agile management tool, VersionOne, which I'm sure I'll touch on later.
In the meantime, Simon, who was my development manager - got promoted! For a while we were marching along, but running out of gas.
I have to hand it to Barbara though. Of all the people I really expected to let it regress to what we were doing before - she stuck to it, and continues to stick to agile.
As a team we've morphed our processes to something that resembles Agile/scrum. Changing development processes is so disruptive, because it really takes a lot for your entire expanded team to get on board. There was a lot of interest, and (almost) everyone on the team was a willing participant.
It was tough not having an experienced "coach"/"scrum master" on board. We (Simon King and I) relied heavily on what we took away from David Hussman's lectures from NFJS. I got some real help in the form of our QA Lead later in the year, when she was able to attend Agile (?) in Washington D.C. She and another QA analyst came back renewed, at a time when I was "hitting the wall" and getting tired of carrying that particular ball. She has introduced at agile management tool, VersionOne, which I'm sure I'll touch on later.
In the meantime, Simon, who was my development manager - got promoted! For a while we were marching along, but running out of gas.
I have to hand it to Barbara though. Of all the people I really expected to let it regress to what we were doing before - she stuck to it, and continues to stick to agile.
Again, we had a fairly lightweight waterfall-like process that worked pretty well, so it's not like people were going after our process with torches and pitchforks... Moving to agile was a huge business risk because we were moving to a process we had zero experience with. Barbara's been a tremendous help to me, helping me transition from a development role to more of a development manager role. On top of all of that, she's a good friend. Her advice means more to me than anyone else at the office.
Have we gotten better at agile?
We have become more confident in agile. I'm not talking about in the sense of reaping all of the benefits that agile has to offer a development group. I simple mean with respect to the mechanics of carrying out the process. I'm pleased that it lived this long.
So How Do We Do Agile?
We are sizing User Stories with story points (out story points are $ amounts). We do release planning based on an overall dollar amount of work we expect to get done. A $1 amount represents about a man-week for us, based on what a Sr. Developer expects that a moderately experienced developer could get done in a week. We then estimate features by giving them a $ amount of $1-$10, and then pack a release full of features in priority order. We're always working on the highest priority item throughout the release.
Next, we break out the release into some number of iterations - typically 8 2-week iterations, plus some extra time at the end for QA integration testing. I'll assign the features to iterations, and then develoment resources to particular features during the iteration. I like to have pair-programming so we have 2 people responsible for any particular part. It tends to keep the ball moving down the field.
Each feature is broken out into User Stories, each given a MoSCoW rating of priority. Each story is given tasks that it will take to complete them. Our latest accomplishment is bundling of Stories and Tasks together into what we are calling "testable units". Once a developer has something build-worthy, we let QA know and they cut a new software build from whatever source countrol branch the feature is developed on. This is working particularly well, helping solve the issue of QA getting jammed for time at the end of a release. In order to support this though, we've gone to a more agressive branching strategy, making more feature branches - merging down to the trunk when we commit to shipping them (fixing any defects found at that point directly in the trunk, as the feature branch is closed).
Hmmm what else... Well, there are things we are doing that are NOT agile. I'll cover those in another post.
Have we gotten better at agile?
We have become more confident in agile. I'm not talking about in the sense of reaping all of the benefits that agile has to offer a development group. I simple mean with respect to the mechanics of carrying out the process. I'm pleased that it lived this long.
So How Do We Do Agile?
We are sizing User Stories with story points (out story points are $ amounts). We do release planning based on an overall dollar amount of work we expect to get done. A $1 amount represents about a man-week for us, based on what a Sr. Developer expects that a moderately experienced developer could get done in a week. We then estimate features by giving them a $ amount of $1-$10, and then pack a release full of features in priority order. We're always working on the highest priority item throughout the release.
Next, we break out the release into some number of iterations - typically 8 2-week iterations, plus some extra time at the end for QA integration testing. I'll assign the features to iterations, and then develoment resources to particular features during the iteration. I like to have pair-programming so we have 2 people responsible for any particular part. It tends to keep the ball moving down the field.
Each feature is broken out into User Stories, each given a MoSCoW rating of priority. Each story is given tasks that it will take to complete them. Our latest accomplishment is bundling of Stories and Tasks together into what we are calling "testable units". Once a developer has something build-worthy, we let QA know and they cut a new software build from whatever source countrol branch the feature is developed on. This is working particularly well, helping solve the issue of QA getting jammed for time at the end of a release. In order to support this though, we've gone to a more agressive branching strategy, making more feature branches - merging down to the trunk when we commit to shipping them (fixing any defects found at that point directly in the trunk, as the feature branch is closed).
Hmmm what else... Well, there are things we are doing that are NOT agile. I'll cover those in another post.
posted by DavidVTHokie at 9:57 PM
0 Comments:
Post a Comment
<< Home