What Will Happen To Me?

The transition to agile is a disruptive one. It affects many core processes. It also affects the roles that people play. Both of these can be a barrier to its adoption. Bigger companies in particular have a natural resistance to process change. As to role changes, if a change was going to affect your day to day role, wouldn't you be nervous?

In this post, I'll talk about the latter issue: that of roles. I'll go through some of the more common roles and compare life before and after agile. Since there's a lot to cover, I'll break it into two posts. This one will focus on individual contributor roles. The next one will cover management roles (including project and product management).

Developers

Before agile, developers had to give "good" estimates up front. Usually, you had no idea how everything was going to come together, so these were just educated guesses. Your estimates became part of "the plan" which then got tracked for the rest of the release. Your work typically came from specifications. Once you were done implementing something, you forgot about it. Eventually, you'd probably see some bugs come your way.

In agile, estimates are done by the team. High level estimates are created to allow you to get "a feel" for the release. Smaller task level estimates are created during iteration planning (when you're about to do the work). Instead of working off of a spec, you're more likely to discuss things with team mates while you go. You tend to work in smaller chunks. If you get into a difficult situation, the rest of the team knows it within a day. You're not done until you have unit tests and QA is done. Generally, your schedule has less peaks and valleys. It is more of a constant flow.

QA

Before agile, you tried to get as much information from the developers as possible about the features. This allowed you to create test plans. Some times, you were successful, some times not. Once the code was handed over, you began testing it according to the test plan. Often, there were major discrepencies. It was hard to isolate things because so much was included at once. Getting time from the developers was difficult because they had moved on.

With agile, you're working as more of a team. In iteration planning, you get a good feel for what each feature will include. You work with the developers as the feature is being written to test daily increments rather than weeks of work. This makes it much easier to isolate. It also allows you to be much more thorough. If you run into an issue, the developer is there to work with you on it. They're not done until you are. Automation becomes much more important as you work to increase your releasability.

Writers

Your situation is very similar to that of QA. Agile gets you much more involved than you were previously. Where before you had a thorough doc plan going into the release, now it is more incremental in nature. Every so often, you take a step back and try a look at the forest. Your day to day life is with the trees.

Architects

Before agile, you would come up with high level designs for the release. These designs would take into account potential future directions. Some of the things you designed for would never come to fruition. This resulted in more complexity than was necessary.

Now that you're doing agile, you try to do just enough architecture. Your catch phrase is "making decisions at the last responsible moment". Your goal is to create architectural runway for the developers just before they need it. You try to keep things as simple as possible and only add in more complexity when it is needed. You have a much better feel for what the teams are doing on a daily basis since you attend the agile meetings.

Usability

Your situation is very similar to that of the architects. Where before you were focused on designing things in specs (many of which never came to fruition), now your goal is to keep just ahead of the developers. Like the writers, you need to take a step back every so often so that you can ensure the user experience is consistent and well designed given the current functionality.

Overall

No matter who you are, agile has made things more of a team effort. Additionally, you're on the lookout for things that can be improved so that these can be discussed in the next retrospective.