Book: The Agile Samurai
- Read: December 2011
- Rating: 9/10
The Agile Samurai by Jonathan Rasmusson is a great introduction to Agile Software Development. Whether you’re working for a megacorp or at your own startup, whether you’re a project manager, a programmer, or a customer, this book provides great detail on what most software development should look like.
My Notes
Deliver something of value every week. Break big problems into small ones. Focus on important things and forget everything else. Get constant feedback. If and when you are going the wrong direction, change direction.
Most software is believing an unrealistic plan + random miracle will result in working software.
You cannot ever gather all requirements at the beginning of a software project, and the ones you do gather will change. You will never have enough time or money to do everything you want to do.
The customer must be engaged. If they don’t even want to show up, then the project must not be important to them and it’ll inevitably fail. Set expectations with the customer. They must set priorities. They must also decide what not to build.
The agile analyst will help write user stories. The agile programmer will turn user stories into software, make technical decisions, and help make estimates. The agile tester will write tests for stories and confirm stories work as expected. The project manager will track how the team is doing and communicate the state of the project. They will also help remove roadblocks that are in the team’s way.
A great way to start the project is by asking four questions to the whole team:
- What am I good at?
- How do I perform?
- What do I value?
- What results can you expect me to deliver?
The assumption of consensus where none exists is what kills most projects.
A majority of the book is about creating an inception deck. An inception deck answers these simple questions and is generally a great way to get consensus about the software:
- Why are we here?
- Elevator pitch
- Product box (what would it look like?)
- NOT list (what are we not doing?)
- Meet the neighbors (who is involved in the project in the broadest form?)
- Show solution (blueprints)
- Up at night (what do we lose sleep over?)
- Size it up (how long will it take?)
- What’s going to give? (time, scope, budget, quality— choose 3)
- What’s it going to take?
Ask questions as if you were the customer.
Remember the furious four: time, budget, quality, scope. You will always have to limit one or more of these. Be sure that there is agreement about which should be sacrificed first. Generally, time, budget, and quality are fixed, whereas scope should be flexible.
Creating user stories is hard. Make sure you have the correct emphasis on the correct syllable. Good stories should be independent, negotiable, valuable, estimatable, small, and testable (INVEST).
Use a point-based system to size tasks. Size them based on previous, similar work. If there is none, then be sure to figure it out as you go- and be flexible on what you’re actually doing. Measuring your team’s speed is the team velocity.
When reality sets in, and you’re not doing things as well as you’d like, then you have to be able to adjust your plan quickly and efficiently.
Your first plan:
- Create your master story list
- Size it up
- Prioritize
- Estimate your team’s velocity
- Pick some dates
The burn-down chart and burn-up chart are ways to track how much you have remaining (down) and how much you have accomplished (up).
Create personas for your stories. If you have different users (and you always do), then create some different personas for each of them, and understand what their role is and how they interact with the software.
Make sure the code matches the language the customers use.
Four things to do during any iteration:
- Make sure next iteration’s work is ready
- Get feedback on last iteration’s stories
- Plan the next iteration’s work
- Continuously look for areas of improvement
Create a visual workspace. Have a story wall, a release wall, a velocity and burn-down graph, and an inception deck.
When fixing code, write a unit test before fixing the bug. This will help in the future to make sure the bug doesn’t come back. Unit tests give instant feedback, lower regression testing costs, reduce debugging time, and let you deploy with confidence.
Refactor your code constantly. Don’t wait multiple iterations.
Practice Test-Driven Development… Red, Green, Refactor: Test fails, Test passes, refactor.
Always have your software at a production-readiness state. Software spends more time in production than development.