I have known about agile software development for many years. At least I thought I did. In the past, anytime someone mentioned agile development, I associated it with rapid speed, little or no documentation and chaotic releases to production multiple times a week. That’s all I knew about it because I heard people using the word “agile” to describe the way we were working. Needless to say it didn’t appear to be any better than the waterfall model that has served as the scaffolding for delivering software for so long. I thought it was just a fad.
Then about two years ago I started working at CareSource on the Clinical Technology Solutions (CTS) team, building custom infrastructure for clinical management. On my first day with the team, I was told to report to an area of cubicles where we would “scrum”. I had never heard of this term in a business context (further proof that my last project wasn’t doing agile).
The idea of scrum is simple. The meeting is scheduled to be just 15 minutes long. Each person in the room states whether they accomplished their goals yesterday and what they hope to accomplish today. I watched over 20 people give their status update and the entire meeting finished in just 7 minutes. Coming from government projects, you can imagine I was in awe of what I had just experienced. Straight to the point dialog, saving questions for only the people that needed to hear them until after the meeting. That’s when I knew there was something different about this process.
Agile is great but you want me to do what?
Our team eventually went through a three day training session to learn the concepts and ceremonies of agile software development. The following week, we abandoned our desks to sit together in a large conference room, taping user stories to the wall instead of using software and started pair programming. We were really going to do this. It was awkward and strange until you just start walking the walk. It was the beginning of innovation for this team.
I thought I was pretty good at embracing change but for some reason all of these new practices in such a short period of time challenged that assumption. I had lost my personal space and someone would be looking over my shoulder critiquing everything I write.
Pair programming is an extreme programming practice our team decided to fully adopt. If you were writing code, your partner for that sprint is right there with you. You take turns writing the code and being the navigator. It means getting outside of your head and explaining what you’re doing and why you’re doing it. Out of all the agile practices we adopted, I found this one to be the most difficult to embrace.
If you are going to pair program, I think you can get the most value from it when sprint work can be organized so difficult user stories are pair programmed and simple stories are done on an individual basis. By simple I am referring to stories that are similar to stories you’ve worked on in the past. Adding metadata to a configuration table or building the 20th new report screen is pretty standard stuff after a while. No need to waste more than one person’s time performing those tasks when the work is well established.
Over time, I got used to pair programming and I would be OK with doing it again in the future as long as it is not 100% of the time. It’s simply a matter of balance.
You know what you’re working on
One of the immediate benefits agile brought to our team was clarity in our work. Now that user stories were taped on the wall, it was much easier for everyone (testers, developers, business owners and stakeholders) to get involved in sprint planning since no one had to learn another software tool. Humans understand paper.
Time bandits go away
Wouldn’t it be nice if you could just write code all day without interruption? Unfortunately the reality is you have meetings, you get pulled into help debug an issue.
When someone or something outside of your team needs your time that is time taken away from the current sprint and the committed stories (a time bandit). It becomes the responsibility of the scrum master in collaboration with the product owner to determine whether the request should be made into a user story for a future sprint or if it is important enough to be worked on immediately.
Letting the product owner decide the priority of work is a huge benefit because it lets you focus practicing your coding craft without the context switching for non-sprint requests. As we all know, too many requests will eventually lead programmers to thrash violently as they leave the office with the feeling they haven’t bettered the world in any significant way.
No More Scope Creep
Traditional projects are often understood to be fixed in scope and the variables are how long it takes and how much it will cost to deliver. Agile flips that on its head and says time and resources are fixed, and the only variable is how much scope can be delivered by the fixed date with a fixed team.
A powerful concept right? Doesn’t this match reality better? If the business requests a new high priority user story in the middle of the sprint, the product owner must choose a story to remove from the sprint. This ensures developers are not working 12 hour days and thinking about their next employment opportunity. At the same time, the business gains transparent visibility into the progress of a project and focuses the team on the highest priority stories first.
Why Our Team Did So Well
From my perspective, several factors contributed to the team graduating to such extreme agile practices:
- People who are open minded. Every idea is considered and respected without judgement.
- Motivated people. The team was inspired to constantly question and improve the way things were done.
- A protected environment. Early on, the manager made the team feel safe in trying new experiments without repercussion. If the outcome was failure we were congratulated because it meant we were trying new things until we found what worked for us.