A fun buzzword I am seeing in job descriptions is agile. You will be part of an Agile team…, or …using Agile methodology.
It’s very common in the software industry, but certainly getting some usage in other industries that have projects where the goals or scope may change during the development of the project. As such, there are loads of resources about agile or scrum methodologies, history, management, etc. that I encourage you to explore if you need a deeper dive. I work on an agile team, so I can add some insights to how this might impact your work.
The basic philosophy behind is to work fast and iterate. For my team, this means we only schedule our work in two week sprints. Every two weeks, the big boss sets our priorities, we make a detailed plan about how we will tackle those priorities by assigning ourselves tasks. The planning process is very transparent, so the whole team and the boss usually have a good sense of whether it is a stretch to meet our goals, or if we might need additional resources to complete the tasks.
For example, I work on a team of writers, so we often need a subject matter expert to support our new documents. Just making project planning a regular activity for the team reduces a lot of stress from poor planning or time management.
Then, at the end of two weeks, we present our work in a Sprint Review, which feels like lab meeting sometimes. For big projects that take more than two weeks, we present our progress or identify the challenges we expect to face in the next sprint. The Sprint Review includes a larger audience of stakeholders, in my case the trainers who will deliver our materials, and some of the people who will sell or manage the materials.
At this meeting, we get feedback, which is especially helpful for those ongoing projects. It gives us a chance to make adjustments before we have fully polished a product that isn’t what the stakeholders want or need. Iteration is really the big insight of agile teams. In some work environments, people can feel that the “constant criticism” is difficult to handle, but as a former scientist, I don’t feel that the criticism is that neither frequent nor overwhelming.
During our sprint, we also try to stay flexible about who is responsible for which tasks. Typically, when I finish one task, I pick up whatever is next in terms of the team’s priority that we discussed in Sprint Planning. I might go from writing a storyboard to recording audio of that storyboard, or just writing the next storyboard. This helps my team get our important tasks done first, and it reduces slowdowns. It also keeps my job from getting boring. I know what I am doing tomorrow, because I didn’t finish the animations I am working on, but next week I am not so sure.
After each sprint, we also have a retrospective where we can collect or deal with issues going forward. We can request things like spending time in the next sprint to solve a recurring problem, or just call out things that went well. “We need to update the style guide.” “I love the new templates!”
Verbalizing those things with my team really helps keep communication clear. If there is a misunderstanding during the sprint, it will come back up when everyone has cool heads, and is thinking about how to improve for our next sprint. If there are recurring issues, we may brainstorm solutions, like a better way to communicate or notify the team when tasks are ready to be picked up. Then the big boss sets our priorities for the next sprint, and we either carry on, or tackle something new. But we don’t get caught in the classic problem of unclear priorities leading to inefficient use of time.
I really enjoy working on an agile team. We don’t waste time on work that isn’t going anywhere, and we are generally wrapping up work on a regular basis. Because the planning process is very transparent, we don’t have cases where the boss wants A one week, B the next and when B is delivered, they only want to know what happened with A. This saves a lot of grief. We also don’t have a lot of extraneous meetings, because our tasks are defined in a way that we don’t require committees for decision making. With good project management, it is possible to break large, complex projects into more manageable tasks, so we can make progress towards our long term goals.
—
Sandlin Seguin,PhD is an eLearning Specialist with Tableau Software, where she helps customers learn to see and understand their data. Previously, she earned her PhD in molecular virology at the University of Pittsburgh, and worked as a Curriculum and Faculty Development Specialist at Bellevue College.
