I’d like to share a bit of good news today. I’ve been hired to write a second book (I’m getting paid to write!). It’s about a different yet related topic: Agile software development or, more specifically, the Agile culture.
Here’s the trick, I’m not quite sure what it’s going to be about.
Since “Writing the book” was #2 on the list of topics people were struggling with and
I’m ramping up a new project, I’d like to talk about what Agile is and how it relates to the process of writing a book. This is both helping me sort some things out and I thought also might be interesting in the context of how we go about the process of writing.
Agile is an iterative method for project development. It began in the software industry but is technically agnostic – this means you can use it for any type of project.
It is good for projects where you are doing something new or the requirements are likely to change quickly.
Looking at the above chart for instance, the Y axis is the requirements for the book and the X access would be the process for creating a book. Since I've been through the process before, I’m familiar with how to create a book – the technology is relatively certain.
However, the subject matter is new to me and I’m still not exactly sure what the book is going to be about so the requirements are likely to change greatly.
Agile is a candidate for a development process when a project, any project, is in the Complex or Complicated regions.
Here is a visual estimate of where my project is on the chart:
Agile is a good method for development when you are in the Complex or Complicated regions. If you've done this type of thing 1000 times before and the requirements aren't likely to change, you’re in the Simple region and Agile is probably overkill. If you've never done it and the requirements are likely to change, you’re in the Anarchy region. Here, Agile is not likely to help you either. What you need to do if you are here is get out. Break it into smaller projects or revisit the goal of the project, is it defined? Is it simply too large?
In my case, what I’m trying to get to as quickly as possible is the angle. The angle is what value I would deliver to a specific audience. I want this angle to be a challenge that hasn't been dealt with or that we can deal with in a new way in our book. The reason for this is that the book then delivers value. The reason for getting to it as quickly as possible is that the sooner you can get to this, the quicker you can write it and stop researching and/or spinning on analysis. I think Agile provides one way to do this by writing and creating smaller pieces and iterating.
In this respect, it’s very similar to developing complex software.
How does Agile work?
I’m going to talk about a particular framework for Agile development called Scrum. The analogy is to the game of rugby where the ball is passed up and down the field numerous times between teammates to advance.
The idea with Scrum is that, instead of trying to plan the entire process from start to finish, you look at completing the project in a series of shorter sprints – two weeks at a time, for example. This way you can deliver pieces of the project along the way and also control for risk. Basically, you try something in a short period of time and then adjust.
In more traditional methods of project planning, you plan for the entire project and then execute towards the end. If something goes wrong or requirements change, you’ve wasted a lot of time in the analyzing and planning stages.
The following chart shows how Agile controls for risk:
Agile delivers small pieces of the project at each sprint. Planning happens at the beginning of each sprint and you adjust based on how you did in the last sprint. This is why Agile is a great framework for complex projects – you know as you’re going through if you need to adjust. The idea is that it’s better to spend time learning during the development process than figuring out at the end you’ve gone in the wrong direction.
How is this going to work for my book?
Basically, instead of trying to plan the whole thing out, I’m going to look for ways to start writing.
The first sprint
At the start of each sprint, or iteration, you want to hold a spring planning session with your team. This is pretty easy for me since my team is small. It’s basically me and the product owner. The good thing is that he is an Agile expert and I, at least, have run projects similarly though not using the specific Agile framework.
The goal of the spring planning meeting is to get to a commit – what the team is going to do over the next two weeks.
The way they go about this is by looking at something called the product backlog. The product backlog is a list of user stories, stories written from a user perspective about what a particular user wants to do. These stories take the shape: As a I want to so I can .
Here’s a sample:
The items are ranked in terms of priority and an estimate of how long each user story will take to develop is included. Note that the product backlog is updated by the product owner during each sprint. It’s more important to get some sizable small chunks at the top that the team can start working on. Items further down the list may be larger and more nebulous and may need to be broken out in successive sprints.
Here’s my first attempt at user stories for a book. Remember, this will be refined. The goal is to get down what I can and identify what I want to focus on in the first sprint (2 weeks).
It feels a little awkward to write these from the perspective of a reader or myself as author (not as natural as for users of software anyways) but that’s ok. Getting them down in this fashion makes you think a little differently. It makes you think about what a reader or the audience would want rather than you.
I figured I could do the top 3 in the first sprint so I broke these out further into tasks.
Acceptance criteria is also usually discussed during this initial planning meeting. What does it mean for each task to be done?
My planning for my first two weeks was done. My commitment is three user stories.
If there were a team, we’d decide how we wanted to break out tasks. We might even divide them up further. Since this is just me and the purpose is primarily to help me think about how I’m going to learn how to write about something where I’m not an expert, I didn't take this step.
Now I can work on these pieces.
The sprint planning meeting is a simple way to plan for the next 2 weeks. You want to timebox this meeting. With a team, usually it is half a day. I took 2 hours.
This helps in the writing process because often we have a tendency to want to over plan or spend all of our time in the analysis/planning stage. Pick a direction and go. The iterative nature of Agile allows you to adjust during the project.
Daily Scrum
In Agile, there is also a daily scrum meeting. These meetings are short, usually limited to 15 minutes. Each person takes 1-2 minutes and tells the team what was accomplished since the last daily scrum, what she is working on, and any impediments or issues she’s facing.
The meetings are not status meetings but are rather for the team. The idea is to report to each other rather than some project manager.
Since it’s just me, I do this with a morning "to do" list. I look at what I got done yesterday and quickly write out what I'm looking to accomplish today.
Sprint Review
At the end of each sprint, a sprint review is held. The sprint review is a meeting with the product owner to determine whether or not a story can be called ‘done’. If the product owner does not agree that the item is ‘done,’ it simply goes back onto the product backlog.
I am going to do this by posting items and talking about them with my product owner and Agile expert. (In the instructional design world, he would be referred to as my subject matter expert (SME).) The importance of doing this is that the material is new to me. He can look at it and tell me if I'm headed in the right direction or not and we can adjust accordingly.
One of the things I've found the most exciting about Agile is that the people who have done it seem to naturally understand that you're going to make changes in direction based on each sprint.
In other words, it's expected that you're going to miss the mark somewhat the first iteration. The goal is to figure out how and adjust.
This is a key difference from traditional project management where "alarms" might be raised if for some reason you have not hit a milestone. Having been on many a complex project managed traditionally, what I can tell you is that this happens anyways. The difference is that Agile understands it is part of the process and incorporates ways for the team to adjust as you progress.
What can happen on traditional projects is that the team tends to understand this and simply tells the project manager everything is ok, even if it isn't. What can happen in this situation is you get projects that are in "denial" - the project manager doesn't know things are off track until a late stage.
The next step is onto Sprint 2 where the process repeats.
What else is interesting about this?
What is interesting about this to me is that it matches the way I write. I won’t typically have everything in my head for the entire book when I start. I usually have to break it out into pieces. In part, this is because what I write tends to be “How to do something …” that I'm only just learning. The subject matter expert is typically the person with the expert-level knowledge.
So sometimes it works best to start in the middle with the something that I know best how to do. I will usually write a list of objectives at the start, but I typically find this changes as I learn more about the material.
I also find it interesting that this idea of “story” and storyboarding is used in Agile software development. You can think of users as different personas or actors who will use the software. It then makes sense to start thinking about how they’re going to use it. What are they going to use it for and then, when they go to do this larger thing, pay their monthly credit card bill from their checking account, for example, what are the smaller stories they’re going to need to be able to do such as login, find their balance, and transfer funds from their checking to their credit card account.
The other thing about Agile that is very interesting is that there is no need for a project manager. The roles involved are team, product owner, and coach. You simply keep iterating until the point when any further iterations won’t produce a significant return on investment (ROI). In other words, you stop at the point when you’ve done all of the most important pieces of development and they are considered ‘done’ and any more investment wouldn’t produce greater return. In this manner, you really don’t need project management, risk is accounted for by the iterative process. The process allows for learning and adapting rather than trying to take into account everything that could happen at the beginning.
Traditional project management is predictive, Agile is iterative. This is why Agile is often a better choice for more complex projects where it’s hard to predict what the requirements will be or the team is new to some type of technology.
I think, as a newbie and as someone who has played the role of project manager, this is the thing I'm still trying to wrap my head around.
I don’t know if this has ever been applied in writing projects, but parts of it seem very applicable. I wound up writing my first book through blogging. I gradually honed in on what I liked to write about and eventually found an angle I thought unique where I had enough material. I know many folks write similarly. In other words, just write about something and evaluate it at intervals. If it’s not working, try something else.
To me, this seems somewhere in between what I’ve heard called the “pantsers” and the planners. If you're interested in more about Agile, the Scrum Alliance has one of the best introductions.
Wrap
How do you approach writing from a development standpoint?
Call for posts: I've pretty much finished the 10-12 initial articles that were in my head for Self-Publishing 101. Since I'm starting a new book, I'm not going to have the time to create new material every week and am looking to cut back to a once a month pace.
If you have an idea for a self-publishing topic or would like to write about your self-published book, please send me a kosmail and we can setup a time for you to guest host.
---
David Akadjian is the author of The Little Book of Revolution: A Distributive Strategy for Democracy.