Introduction to agile methodologies
This week I attended a short introductory session to agile methodologies. An Atlassian colleague, Stuart Bargon, gave us a great overview of Scrum, Kanban and Extreme Programming (XP). We also had a brief discussion about how we can improve the integration of technical writing into the agile development process. These are my notes from the session.
To kick off the session, Stuart asked us what we already know and understand about agile methodology. There was an interesting range of answers:
- One of the technical writers has documented GreenHopper for a year and a half, and therefore understands agile as a use case for that tool.
- Another person went into details of the scrum and issue tracking procedures he’s experienced in the development teams.
- Someone else had read the Agile Manifesto and understood the aims, but had never put it into practice in a team environment.
The Agile Manifesto
Stuart discussed each of the principles of the Agile Manifesto, illustrating some of them with examples from his own experience.
- Inevitably, we dwelled a while on the point about “Working software over comprehensive documentation”. We didn’t come to any specific conclusions though, other than that everything is relative.
- I said that my favourite principle, and one I think Atlassian does really well, is: “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”
- Stuart pointed out that this one is particularly relevant to technical writers, in that it emphasises the diversity of skills amongst team members: “Business people and developers must work together daily throughout the project.”
- Another one relevant to us, in our role as technical communicators: “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”
- Concerning the point about self-organising teams: “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” Stuart pointed out that this is not a licence for a free-for-all. From a management perspective, the idea is to create an environment that gets the team to organise in the way you want it to. People are more motivated if they decide they want to do something themselves.
I found this point interesting: Many of the ideas in agile methodology come from the way Toyota works. In particular, Toyota’s teams regularly stop and examine their work to see how they can improve the quality. See the book “The Toyota Way“.
These are the methodologies we touched on:
- Extreme Programming (XP) – a set of processes
- Scrum – a lightweight process
- Kanban – an even more lightweight process
Generally, agile practitioners pick and mix these days. They take bits out of the various disciplines to suit their needs.
Extreme Programming (XP)
We touched on the principles of Extreme Programming. It’s important to note that not many people follow all the principles devotedly. Instead, people take the bits they need. See this diagram of the Extreme Programming project.
Stuart ran through the basics of the Scrum process:
- Write feature requests as “stories”. You should include the specific persona and the reason that persona wants to perform the task specified.
- The “product backlog” is the list of stories in order of priority. Stories at the top of the list should be small. The stories at the bottom of the backlog tend to be just ideas and perhaps still rather big chunks. They must be broken down into smaller stories as they approach the top of the list. Some people use the concept of an “epic” to group related stories and keep them together as they approach the top of the list.
- The “sprint backlog” is the list of stories to be tackled in a particular sprint.
- The “sprint” is a period (often two weeks) during which the development happens. There’s a planning meeting at the beginning of the sprint and a retrospective at the end. The idea is that each sprint delivers a potentially shippable product.
- Scrum defines 3 roles: The product owner creates and prioritises the backlog, defines the stories, decides what goes into the next sprint. The scrum master works with the team day to day and is focused on the current sprint, fixing anything that’s stopping the team from working. The team does the development work.
- When estimating the stories, you try to use the idea of “story points” rather than time. The story points are expressed as a number, based on the relative complexity of the work required.
- You work out your “velocity” based on the number of points that you have managed to complete during the sprint. For example, if you had an estimate of 10 points for the stories in a sprint, and completed 8 of them during the sprint, then your velocity is 8. You can work out an average over a number of sprints, and use this to compile estimates for your product backlog.
Stuart gave us a number of good sites for information about Scrum:
- Visual presentation from Mountain Goat Software.
- Reference site: ScrumAlliance, including What is Scrum?
- Jeff Sutherland’s blog, and in particular a presentation on Scrum Metrics for Hyperproductive Teams. Here it is on YouTube.
Stuart remarked that the processes of Kanban are even simpler than Scrum.
The first step is to map the workflow of your development team. Stuart drew a number of columns on the board:
- In development
- Ready for QA
- In QA
- Ready for deployment
- Deployed (Done)
You then set limits on the columns, determining the number of cards (tasks or issues) that can exist in a column at the same time. For example, the above set of columns might have these limits: 4, 2, 1, 3, 3.
A good guide for setting the limits on the number of cards is the team size. For example, if you have 10 team members, the total number of limits across all the columns should add up to 10.
The idea is that anyone can write a story and put it on the board. You can reorder the items in the “Scheduled” column.
A developer takes the top card from the schedule and puts it into the next column (“In development”). When development is finished, the card moves into the next column (“Ready for QA”).
But you can’t put a card into the next column if the column is already full.
If a card cannot move into the next column, that means that the person who wants to move it must first tackle one of the cards in the column that is blocking the flow. In this way, the work flows through to the last column. Nothing has any value until it’s in the last column. There’s no value in the whole process unless it’s producing a number of cards in the “Done” column.
One of the attendees remarked that Kanban probably requires more behavioural change than Scrum.
Cards: Agile in a Flash
The cards cover the principles of standup meetings, retrospectives, values and principles, coding standards, code ownership, test-driven development, story prioritisation, why you would want to use agile methodologies, and more.
We took a quick look at how you prioritise stories.
- First triage the stories. Assign story points, rather than trying to prioritise the stories in order of importance/desirability first.
- Break them down into smaller stories if necessary to fit into a sprint.
Stuart told us a funny story of a developer who had tried to break a story into smaller stories. The story was a web form that was rather long, with may fields. He broke it down into a number of stories, each containing just one or two fields. Instead, he could have produced the whole form in one sprint, but with less complex validation and business rules. The first approach makes it difficult for testers and technical writers to do their work within a sprint, because there is no story that contains the entire form.
Stuart also discussed ways of prioritising stories by putting them in a quadrant, with axes such as complexity and business value.
In a sprint, it’s best to do the high risk things first because then you can deal with any issues that come up.
Contact with customers
Contact with customers is one of the agile ideals. It’s interesting to note that, as technical writers working at Atlassian, we have quite a bit of contact with customers. We work on a wiki, where people comment on our docs. They also see our names and email addresses on the docs, and email us directly. And they can make requests of us and the development teams via our public JIRA issue tracker.
How can technical writers work within the agile framework?
We didn’t have time to discuss the specifics of how the different product teams work, and how we technical writers can better integrate our work into the processes. Just a few general comments came up.
- Log the documentation issues in the development team’s issue tracker.
- Get rid of the lag: the scenario where the technical writers develop the documentation after the developers have finished their sprint. We had a bit of a discussion of the obvious challenges: Things do change during and after the sprint, so the technical writers will need to keep up with the iterative process too.
- Push back and insist that the developer teams finish stories in a sprint, because otherwise it makes it difficult for the technical writers to do their work.
- Sit down with the scrum master, explain the challenges and discuss the solutions.
- Highlight any problems during the retrospective.
We discussed the idea of getting the documentation included in the “definition of done” for a development issue. There are pros and cons. For example, a pro is that the development team will be more aware of the work the technical writers are doing and of what needs doing. A possible con is an increase in the tension between the development and the technical writing teams.
Stuart mentioned that in an agile team, there’s less of the idea that a team member is a specialist. Rather, each developer can work on any story. This could also work with the technical writers when embedded in the teams. The technical writers can give more input during planning meetings, into the design of a feature and how it will affect other parts of the product. Similarly, developers can do the drafts of the documentation to ensure it is all finished within the sprint. If you use a task board, such as in GreenHopper, you can see quite clearly the stages that the various stories are in. If a number of them get stuck in the “documentation” phase, that will be clear to the entire team. Therefore people will be more likely to jump in and grab a documentation task off the sprint backlog.
It was interesting to hear a summary of agile methodologies from an expert in the field. As someone who lives and breathes agile, Stuart was able to condense the essentials into a very short session and add some great titbits of personal experience too. I’m looking forward to the next session, which will cover specifics of the processes followed by the Atlassian development teams. We will discuss how we can better integrate technical writing into those processes. Thank you Stuart for a very useful introduction to agile methodologies.
Update: A few hours after I published this post, Mary Connor wrote an awesome post over on Clever Hamster, entitled How does Agile affect documentation? If you’ve got to the end of my post and want to take the next step, Mary’s is the one for you.
Posted on 26 February 2011, in atlassian, technical writing and tagged agile, agile methodology, agile technical writing, atlassian, extreme programming, Kanban, Scrum, technical documentation, technical writer, technical writing, XP. Bookmark the permalink. 9 Comments.