Header image source: Silicon Valley
The Agile Samurai is a book about a new, warrior-style mindset for developing code. The book takes the traditional “Waterfall” method of development (first plan, then code, then test) and translates it into an ultra-fast-paced series of sprints where bite-sized tasks are cooked from start-to-finish every week and change and adaptation is always on the menu.
The Agile Samurai understands that there are constraints in every project that are non-negotiable, and some that are negotiable. Budget and time frame are non-negotiable, but features of the program might be able to be delivered in a stripped-down, just-the-basics version first, and then improved upon later if time allows.
The title suggests a warrior whirling through an ever-changing battlefield, dodging blows and making swift attacks. Developing software can be just as hectic - requirements change, clients get new ideas, your lose your fellow warriors/developers when they quit their job - and the agile samurai can’t go in expecting to follow the plan as it was first written. Change is part of life.
In any battlefield, it’s important to know both your enemy and yourself. That’s where user stories come in. A key part of the process is to figure out what your users need and want so you can build those features as quickly as possible. The book recommends talking to prospective customers and getting their perspective on what they need. User stories are written with the format “As a ___, I want ___, so I can ___.” They should also be written in plain language that customers can understand. Each story can fit on a digital or physical card.
For a website that sells yarn, a feature where the user can browse the yarn for sale is a must. A checkout system, a payment handling system - likewise. A whimsical developer might be tempted to spend a long time tinkering with something less urgent, but the agile development method helps ensure she keeps her eye on what’s important - making a Minimum Viable Product for her customer.
Self-knowledge is another principle of the agile developer. In order to assign the correct number of tasks for each sprint, the developer should be able to estimate how long each story will take. This may take some trial and error, but being able to deliver on time is a priceless asset in an ever-changing business scenario. While there are several methods to estimation, the key points are that the measurement style should be relative and based on “points.” What one point represents can depend on your team. The team should decide on a couple reference stories that represent relative sizes and use those as a guide for sizing the rest of the stories. When coming up with how many points to assign each new story, the team will each suggest their estimation. The average of those estimations will be used. The author believes that the combined estimations of a group are usually more reliable than one person’s guess.
Another important element of Agile development are the meetings that teams hold to keep on track. Developers should constantly be in contact with their client in order to get updates to requirements. The beginning of the Agile development iteration starts with a Story Planning Meeting. In this meeting, you quickly review the Stories you are working on and make sure they make sense. At the end of the process, there is a retrospective, where the team reflects on what went well and what could have gone better. The author recommends these should be honest, but compassionate, with people receiving feedback in a way that encourages them to continue to improve and not get discouraged. And throughout this process, teams hold a daily standup meeting, where developers share what they are planning on getting done that day and what they’ve been working on. The author recommends to make these meetings energetic and short. Iteration Planning Meetings, or IPMs, happen to plan the next cycle of work. Developers meet with the client, review how things have gone so far, let them know about any problems, and make estimations for whether the project is on track and on time. The author recommends letting clients know of any upcoming problems early, at an IPM, so they aren’t surprised.
Overall, the Agile Samurai has shown me a model for a disciplined, energetic, nimble style of programming. I believe that it will serve me well going forward.