![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
When I was first interviewing for my current position, my boss-to-be said they were "sort of doing a kind of Agile development". I relayed this to my then-coworkers, to a loud chorus of "NO! Not Agile!" followed by warnings about how horrible it would be. (This from Technical Writers who had never worked in an Agile environment, mind.) So I came to this position with some trepidation about the processes I would have to adopt.
After 9 months of working in a 'kind-of' Agile environment, as we try to actually get Agile, I can see both why they were concerned, and why their concerns were misplaced.
A brief intro to Agile software development is probably in order. The basic idea is that you chunk work into units, and assign units of work (commits) to units of time called sprints. The duration of the sprint can vary -- we do two week sprints because it works for us. During the sprint, we have biweekly status update 'meetings' (scrums), as well as an initial sprint planning/commit meeting and a wrap-up meeting at the end of the sprint.
Writer concern #1, then: "you're wasting time in 'a lot' of meetings."
Not really. The planning meeting takes ~1/2 hour, with a team of 6 writers. Same for the wrap-up meeting. The biweekly scrums take all of 5 minutes, if you're organized, which you should be, because that's the point of having sprint commits. All you have to do is answer 3 questions:
Which leads nicely into writer concerns #2 (and #3): "you spend all your time tracking your work instead of doing it."
Biweekly scrums mean that you only have to remember what you did for the last two and a half days. Is that so hard? You don't have to account for every minute of your 8 hours (see also #3, below), but you should be able to jot down the projects/documents you worked on at a high level.
It also helps your peers - not that they do Big Brother-esque tracking of your work - but they may have forgotten that this bit of info they got for their doc actually needs to be shared in that other doc as well until they see/hear your scrum notes. The scrums enable and facilitate quick communication among team members.
But speaking of Big Brother and time management, writer concern #3 is perhaps the hardest to get over: "sprint commits are a tool for micro-management and punishment."
Okay. We're writers. We all struggle with the perfectionist thing, and the deadline issues, etc. Even if it's "just" software help files, we put a lot of effort into making them useful. But here's the thing: in a well-run Agile environment, if you can't finish all your commits within the sprint, you have options:
It's not a system set up to penalize failure. That's not the point. The point - and yes, it took me a while to get this - is to be able to:
Yes, it makes you more aware of how you're spending your time. That's not a bad thing (unless you feel guilty about how much you're slacking (writing blog posts?) at work - in which case, you need to adjust your workload somehow anyway!). Figuring out your personal velocity - how much work you can do in a set amount of time - actually makes it easier to say no, and to do proper time management. Over-committing in an Agile environment doesn't help anybody meet their sprint goals.
Yes, it requires other teams to be as committed to the process as yours is. If yourcode monkeys developers aren't chunking their work into buckets (committing to sprints), there's not much point in trying to do Agile documentation. When you are all sprinting, it's easier to see where to fit things into the timeline, and to get the dev teams to commit to time for reviewing the docs, instead of just brushing it off as unimportant because they're too busy. Win-win, right?
I'm pretty much over my fear of Agile processes. I've learned to embrace the tools (we use Jira) and the philosophies; they actually make my life easier because I can see my goals, and the path to reach them, easily. Becoming Agile is a process in and of itself: it takes time, and iterations. We learn from our mistakes, share the knowledge between teams, and keep moving forward. Eventually, it will even feel like we're sprinting.
After 9 months of working in a 'kind-of' Agile environment, as we try to actually get Agile, I can see both why they were concerned, and why their concerns were misplaced.
A brief intro to Agile software development is probably in order. The basic idea is that you chunk work into units, and assign units of work (commits) to units of time called sprints. The duration of the sprint can vary -- we do two week sprints because it works for us. During the sprint, we have biweekly status update 'meetings' (scrums), as well as an initial sprint planning/commit meeting and a wrap-up meeting at the end of the sprint.
Writer concern #1, then: "you're wasting time in 'a lot' of meetings."
Not really. The planning meeting takes ~1/2 hour, with a team of 6 writers. Same for the wrap-up meeting. The biweekly scrums take all of 5 minutes, if you're organized, which you should be, because that's the point of having sprint commits. All you have to do is answer 3 questions:
- what did you do since last scrum?
- what will you do before the next scrum?
- are there any roadblocks in your way?
Which leads nicely into writer concerns #2 (and #3): "you spend all your time tracking your work instead of doing it."
Biweekly scrums mean that you only have to remember what you did for the last two and a half days. Is that so hard? You don't have to account for every minute of your 8 hours (see also #3, below), but you should be able to jot down the projects/documents you worked on at a high level.
It also helps your peers - not that they do Big Brother-esque tracking of your work - but they may have forgotten that this bit of info they got for their doc actually needs to be shared in that other doc as well until they see/hear your scrum notes. The scrums enable and facilitate quick communication among team members.
But speaking of Big Brother and time management, writer concern #3 is perhaps the hardest to get over: "sprint commits are a tool for micro-management and punishment."
Okay. We're writers. We all struggle with the perfectionist thing, and the deadline issues, etc. Even if it's "just" software help files, we put a lot of effort into making them useful. But here's the thing: in a well-run Agile environment, if you can't finish all your commits within the sprint, you have options:
- increase the 'weight' (number of units of work) of the issue to account for the fact that there wasn't enough time to finish it
- roll it forward into the next sprint (yes! really!)
- discuss the roadblocks that prevented you from getting the work done with your scrum-master/team-lead and build a plan for the next sprint. (For me and my team, roadblocks are most often technical reviews that are out of our hands until the dev team does their part. So they get threatened with the rubber hammer until they turn their reviews in. I'm not even kidding.)
- adjust your commits for the next sprint accordingly
It's not a system set up to penalize failure. That's not the point. The point - and yes, it took me a while to get this - is to be able to:
- estimate how much work the team can do in a given time period (team velocity)
- assign work that fits the estimate
- complete the work
- repeat
Yes, it makes you more aware of how you're spending your time. That's not a bad thing (unless you feel guilty about how much you're slacking (writing blog posts?) at work - in which case, you need to adjust your workload somehow anyway!). Figuring out your personal velocity - how much work you can do in a set amount of time - actually makes it easier to say no, and to do proper time management. Over-committing in an Agile environment doesn't help anybody meet their sprint goals.
Yes, it requires other teams to be as committed to the process as yours is. If your
I'm pretty much over my fear of Agile processes. I've learned to embrace the tools (we use Jira) and the philosophies; they actually make my life easier because I can see my goals, and the path to reach them, easily. Becoming Agile is a process in and of itself: it takes time, and iterations. We learn from our mistakes, share the knowledge between teams, and keep moving forward. Eventually, it will even feel like we're sprinting.
