Nimble Development: Know the critical path
Comment
Many principles behind nimble development become natural over time. The nimble approach requires a quick assessment of an entire project with the goal to identify the key components, the moving pieces, the critical functions. Those are the first things you’ll build.
What you build at first doesn’t have to be great. It doesn’t have to have a fancy interface or complete screens. Under the hood it just needs to work. Start simple. If you build something simple at first, you’ll be more nimble later on.
It is important that you have something working as early as possible and that you complete the loop. Most likely the project is to build or program some functionality that has some sort of start and finish. For example: create user, read user, update user, delete user. Understand the life cycle of what you’re doing. Identify it at the beginning of every project you start. It’s there and it’s critical.
Then write it down where others can see it and edit it. Because others on the project, probably yourself, will ask it many times. More important is how you’ll use it to stay focused. It’s a shield, cattle prod, a shepherd’s hook, to guide us away from the dangerous scope creep cliffs12. Writing down the critical path of your project is like putting a stake in the ground. You can point to it and say, “we must stay close to this.”
The following must be asked and understood by those designing, building, and supporting a product. Every person working on a project, trying to understand the details and scope of a project, inevitably makes decisions based on insufficient or incorrect information. Document collaboratively the answers to these questions and the result will be a more nimble solution in less time. Someone on the project will need to know the answer to at least one of these questions.3
- How will this be used?
- What components will we use to make it work?
- How will the new and existing components perform together?
- Are we using the most appropriate technology and design?
- How will we release this for testing and use?
Whatever you build shouldn’t break what already works. The less that has to be tested the better. The less stuff you interfere with the better. Implement new functionality in a way that doesn’t break what already has been tested and released. Being nimble means knowing how to avoid sticky and slippery areas.
- Flashback: Catcher in the Rye. [↩]
- I used to be very, very good at this. I first heard this term from my manager, urging me to stay focused on what needed to be done. [↩]
- Rainwater, J. Hank. (2002), Herding Cats: A Primer for Programmers Who Lead Programmers. Apress. Page 109. [↩]