One of the features of my new day job is that the development environment is full-on Agile. It’s my first experience in such an environment, and while I’ve worked in plenty of places that used bits and pieces of Agile, an “all Agile all the time” development model is quite eye opening. I’ve had to literally learn and adapt to Agile on-the-fly — by fire, if you will.

For the uninitiated or inexperienced developer, working in an Agile environment might feel like being micro-managed. We have a scrum meeting every day. We talk about every issue in the sprint… every day. And there’s a good chance you’ll get asked later in the day if you’re going to be done on time with your issues. Coming from a smaller company where we (in hindsight) pretended to be agile, all the meeting time seems like a lot of overhead to invest when I’d rather be coding. But after a month on the job, I can see that this methodology works to achieve several interesting goals, including accountability, predictability, and organizational growth.

Accountability

At every scrum every issue in the sprint is reviewed. The assigned developer must give a status and report if the work is on track or blocked. And if blocked, what the impediment is. This keeps the scrum master in the loop and aware of what may or may not prevent him (or her) from keeping his promises to his boss about deliverables. But it also keeps each developer accountable for their deliverables. There is no time lost, therefore, wondering when something needs to be done: It’s in the sprint. The developer committed to having it done. The whole team knows what he’s doing and what he committed to.

Predictability

Before a sprint starts, the team agrees to what work will be in the sprint, and when it will be completed (in 2 weeks, say). Usually you want to be able to say, at the end of a sprint, that you accomplished “X”. It’s important that a sprint be achievable, otherwise, you never deliver what you said you’d deliver (for the sprint). And the more achievable a sprint’s tasks, the more predictable your engineering efforts can be.

My first complete sprint comes to an end today. It was a little longer than normal because of the holidays. However, there was the right amount of work in the sprint to keep everyone busy while also allowing everyone to achieve their goals and complete the work on time. That alone is a nice feeling to run with into the next sprint.

Organizational Growth

At daily scrum meetings, and after a sprint completes, the pace and status of the work in the sprint is constantly evaluated to ensure that missteps are not made. Or, if they were, how to avoid similar missteps in the future. By analyzing our performance in real-time, we grow both as individual contributors and as a team. And ultimately we become a more productive part of the company.

I do not profess to be an Agile expert. In fact, I only know from what I’ve experienced to this point. To be sure, Agile takes some getting used to. I can already see, however, how it can be a beneficial methodology for development groups, especially if you open your mind to the possibilities it affords.