During my Monday morning e-mail and blog reading catch-up, I was pleasantly surprised to find a comment on my blog from Jonathan Rasmusson, the author of The Agile Samurai, as well as a link on his blog (The Agile Warrior) to my posts. I love how just a couple of blog posts created content that was searchable and he took the time to reach out and thank me for posting about his book. I will not reward him with a brief review of his book since my earlier posts were just about the greatness of the graphics and promo video.
First, a little background about my role. I am new to agile software development; in fact, I had no background in anything development related when I moved to a Product Development team in the spring. I worked on a business team that had a development team on their application, but I was not part of the business team. All I knew about the process was that the business team never felt like they were getting what they were promised and the development team always felt like the business was changing priorities or not being clear about expectations. This team was not using an agile methodology and the project has since been put "on hold"- probably permanent hold. Looking back, I am not sure why I was so willing to move into a role where my only experience with the process was so negative- other than the promise that this was not the way things would work in the future.
While most other company projects were using the agile software development process, the development leads for each project were acting as business analysts so my move in the spring made me the first official business analyst on the team. I had no idea what I was doing, but I knew what our business did and was willing to learn how to be part of the process. The first book I was given to read was User Stories Applied by Mark Cohn. This was helpful to me at the time because the project I was working on was in desperate need of some solid user stories, mostly epics, which we could then slowly work toward accomplishing. The book probably was not the best starting place to learn about the whole process, but it did help me understand a piece of the process well. We created many new user stories and cleaned up the backlog significantly to refocus the project. Over time and with the help of our Software Development lead, I learned a lot more about agile as problems arose or the process had hiccups. We hired a new business analyst to take on this project in the summer, and the results of tightening up the process and writing better user stories were very clear as time went on- things were getting done.
After I left that project, I moved on to two new projects. The first was an application that had only one developer and was loosely using an agile methodology. The other was a project that was just getting off the ground. With the first application, we had some of the same problems I had faced with my first project. We needed to tighten up the process, get the right people involved, and refocus. We took on an epic that had been being asked for by one of the business units for over a year and we are slowly making progress toward that goal. On the other project that is just getting off the ground, we are not to a point where we are creating many user stories yet. We are still making hardware/software decisions, but once we are ready to create the new application(s), I feel good knowing that I have learned enough about the process to get things started in a good way from the start. We still have our issues- recently there have been a lot of discussions about whether it is appropriate to estimate bugs and spikes, how we move a current process onto a nonlinear estimation scale, estimating across applications when some developers work on multiple applications during an iteration, the role of the business versus development team, and many more- but if there is one thing I feel good about it is that agile is a set of guidelines, but each process is unique.
This gets us to The Agile Samurai- I read it 10 months too late. I finished it earlier this month while in San Francisco with a project team that is working on a project that has had some difficulty getting started on a new application. I couldn't help but think of all the ways the content could be useful to the process- especially The Inception Deck. Currently, we write project charters and the developers will not put resources on a project until we have one. They live on our internal wiki and can be referenced to address issues like scope and project team roles. They are usually brief, but could potentially be bulky. In The Agile Samurai, however, Jonathan recommends an Inception Deck to answer 10 key project questions. These 10 questions address everything a charter was meant to, but it seems less bulky and can be turned into something you can plaster on the wall when talking about a project to keep everyone focused. We have even talked about turning these into posters and sending them out to our business and development teams to hang up as a constant reminder. I have not been through the process yet, but an eager to try it on one of my new projects because writing charters has been painful for me so far. The Inception Deck concept is not painful.
In fact, nothing about this book is painful. It is easy and light when it comes to content so it is the perfect quick reference and is not bogged down in the details. Struggling with estimation? Quickly open it up Chapter 7 and in 5-10 minutes you have a quick review of the process. Not only are the examples easy to understand, the content is light hearted and fun. Let's face it, no one is going to die if our agile process fails, so let's not take it too seriously. In addition, the process isn't that complicated so why make it seem that way? Some other agile books I have seen read more like textbooks and I just cannot get motivated to sit down and read them, I only use them for reference from time to time. I think the only content that is missing from this book is the same thing I have not found much content around in general and that is the concept of using agile in an ongoing fashion. Our projects are not ever done. In most cases, we release new features directly to users every two weeks, and then we start another iteration of new stories and bugs to continue making the applications better. There isn't a lot of content in The Agile Samurai or elsewhere to address the challenges of agile as an ongoing process. The biggest issues being spikes, no one ever seems to agree on when to use them or feel good about how to handle scheduling them, and the struggles of prioritizing immediate and long-term needs in iterations. Either way, I highly recommend The Agile Samurai and think it is a great first read for anyone new to the agile software development process.
