Agile Quickies: Deliver working software frequently
If you’re anything like me you waited until the last day of the semester to knock out that huge paper that you’ve known about for 10 weeks. You scramble to make your points, cobble together resources and hit submit at the last possible moment. With a sigh of relief, you know you could have done better, could have done more and you have a hangover from the 24 hours of straight work and countless double shots of espresso (cold brew from a Ball can preferably). Often times we treat projects the same way. We know we have a date in mind for delivery, so we keep that at a distance while we plan, negotiate scope, brainstorm, tweak, and add new features, because, “Hey, it’s not releasing until next quarter”. Or we try to put too much into one release, trying to get the whole kit and caboodle into one release, so we work and work to build and build, and features get stale or code gets tangled, or the customer forgets what they asked for.
Delivering frequently serves three very valuable purposes: provides a (reasonable) sense of urgency, allows us to ship (and plan) smaller but valuable functionalities to the client, and allows us to maintain our code freshness.
By creating a reasonable sense of urgency it forces us to think about the most valuable things to deliver. This helps us prioritize and find efficiencies in our planning and development processes. The longer cycle to delivery, the more easily scope creep can slip through. If we work too quickly, we can skip out on quality and cause undue stress, but if we don’t impose shorter timeframes we can fall into the trap of feeling like we have too much time.
When we deliver smaller features we are given the opportunity to adjust quickly when we learn more about the challenges of our customers, without having invested an embarrassing amount of time, energy and capital. We also are able to garner a sense of accomplishment, which can build momentum and sustain motivation. Fully completing items not only helps us to stay organized and focused, but provides a better update on status and a more relaxed state of operating1.
Additionally, by delivering frequently, and in small iterations, we have a better chance of delivering quality and avoid stale code. Large features can become more complex, requiring more in-depth testing and opening the door to more edge cases. Not only does a smaller feature make it easier to spend the time to thoroughly test but because of the size, there are fewer opportunities to go “Code-Nose-Blind”2 where we overlook bugs that we’d otherwise pick up on because we’ve been steeped in the same feature for a long time. Furthermore, by having frequent deliveries, we’re able to promote broad technical enhancements and refactors quickly to allow for more streamlined development for future features.
By focusing on delivering smaller features, and more frequently, not only are we satisfying the customer with new functionality, which can drive engagement, but we can also respond more quickly to feedback and concerns. We are able to keep first things first, and work in a way that keeps us engaged and motivated. This is a win-win, because the customer is happy, but the team building the product can feel fulfilled as well.
How do we embody this Principle?
- Planning small, valuable features that can be delivered within 3 months time
- Collaborating with the customer to understand their needs, wants and challenges, and planning with that as our first priority
- Committing to timelines and scopes that are informed by the development team and negotiating from there
Making it practical:
- Bring the Scrum team into the Discovery phase of a project life-cycle to have them weigh in on scope and feasibility.
- Create a quarterly roadmap one quarter at a time, ensuring that we are aligning with the realities of where the product is currently with the challenges of the customer and our business strategies.
- As a scrum team, build epics (features) in a way that allows us to deliver a full feature in 3 months or less, and build sprints that deliver full sub-features, or pieces of functionality.
Further Reading:
Continuous Development Will Change Organizations as Much as Agile Did (hbr.org)
The Real Reason Unfinished Jobs Stress You Out, According to Psychology | Inc.com
1 The Real Reason Unfinished Jobs Stress You Out, According to Psychology | Inc.com
2 This may be a Patrick Original™
