This practice is about initially focusing on what to build, who it’s for and why they want it before focusing on implementation.
Minimize Dependencies
In 2020, I finished a series of 72 blog posts that expanded on the first set of “Seven Strategies…” for each practice in my book Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software. I included two sets of “Seven Strategies…” in my book and so I am expanding on the second set …
Continue reading “Minimize Dependencies”
Read MoreSplit Stories on Acceptance Criteria
In 2020, I finished a series of 72 blog posts that expanded on the first set of “Seven Strategies…” for each practice in my book Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software. I included two sets of “Seven Strategies…” in my book and so I am expanding on the second set …
Continue reading “Split Stories on Acceptance Criteria”
Read MoreUse Acceptance Criteria for Stories
I’m wrapping up this series of blog posts based upon Seven Strategies for Writing Better Stories from my book, Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software, with my last strategy–use acceptance criteria. There are many ways to define or break down and split up user stories. Generally speaking, …
Continue reading “Use Acceptance Criteria for Stories”
Read MoreThink About Edge Cases
Continuing my series of posts based on Seven Strategies for Writing Better Stories from my book, Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software, here is the next strategy. Although stories are composed of three elements that include WHAT the feature is, WHO the feature is for, and WHY the …
Continue reading “Think About Edge Cases”
Read MoreStart Simple then Enhance
Continuing my series of posts based on Seven Strategies for Writing Better Stories from my book, Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software, here is the next strategy. Another great aspect of using stories to drive Agile software development is that we can start with simple stories that create …
Continue reading “Start Simple then Enhance”
Read MoreKnow Why a Feature is Wanted
Continuing my series of posts based on Seven Strategies for Writing Better Stories from my book, Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software, here is the next strategy. One of the most powerful and important aspects of user stories is the WHY clause. WHY a feature is wanted is …
Continue reading “Know Why a Feature is Wanted”
Read MorePersonify the Who of Stories
Continuing my series of posts based on Seven Strategies for Writing Better Stories from my book, Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software, here is the next strategy. When developers know WHO a feature is for and can identify with that user then they can often build a better …
Continue reading “Personify the Who of Stories”
Read MoreHow I Use User Stories
When I write user stories, in addition to the story itself, I like to help define edge cases in my stories and I typically do this as acceptance tests. There are automated acceptance test tools such as FIT and Cucumber that not only allow me to define acceptance tests but also help me run them …
Continue reading “How I Use User Stories”
Read MoreUser Stories Support Object-Oriented Development
The number one worst practice I see consistently in object-oriented software development is writing procedural code. Even object-oriented programming projects contain code that is highly procedural. You’ve probably seen code like this yourself where it’s basically a series of steps that prescriptively describe a process that is then wrapped within a class. This is really …
Continue reading “User Stories Support Object-Oriented Development”
Read MoreSummary of Seven Strategies Series
I finished my “Seven Strategies” series of 72 blog posts with seven strategies for implementing each of the nine practices from my book, Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software. These posts are filled with practical advice for implementing the nine core practices from Scrum, Extreme Programming, and …
Continue reading “Summary of Seven Strategies Series”
Read MoreSupport Refactoring
I’d like to conclude this series of blog posts on Seven Strategies for Product Owners with a final strategy that often gets overlooked on development teams but is vitally important: support refactoring. Sometimes Product Owners resist the team’s desire to refactor because they don’t get any new features after refactoring but often times refactoring is …
Continue reading “Support Refactoring”
Read MoreRemove Dependencies
One key characteristic of great Product Owners is that they help remove dependencies whenever the team encounters them. Dependencies can show up in many different forms. Our team may need some code from another team in our company, but the other team hasn’t yet built it for us. Or one feature that we may have …
Continue reading “Remove Dependencies”
Read MoreAnswer Questions Quickly
One of the most important skills for a Product Owner is to answer questions quickly, which means that they have to really know their product and understand WHY it’s needed, WHAT’s needed, and WHO it’s for. Developers have to dive deep when they’re writing software and they come up with questions that non-developers may never …
Continue reading “Answer Questions Quickly”
Read MoreDescribe What You Want Not How to Get It
So much of good software design comes down to separating the WHAT from the HOW. WHAT we want should be expressed in the interfaces of the services that we create. It should clearly state WHAT the service provides, the parameters that it needs to take in, and the value that it returns. Our services should …
Continue reading “Describe What You Want Not How to Get It”
Read MoreHelp Developers Understand Why and for Whom
The traditional ways that we describe how to build something, whether it’s a blueprint for an office building or the specification for a computer program, it always involves a document that describes WHAT to build and often includes information on HOW to build it. However, these documents are often missing critical information on WHY these …
Continue reading “Help Developers Understand Why and for Whom”
Read MoreUse Development for Discovery
Before you begin to build a house and break ground on the foundation you better have a blueprint and know exactly what you’re going to build. In physical construction, we really need to plan things out ahead of time to ensure that we have the right materials at hand and that things come together as …
Continue reading “Use Development for Discovery”
Read MoreBe the SME
I’m kicking off a new series of blog posts based on the Seven Strategies sections in my book, Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software. The next seven blog posts will each be based on a different strategy from the section in my book called on Seven Strategies for …
Read MoreWhy Practice 1: Say What, Why, and for Whom Before How
In honor of the 10th anniversary of this blog, which I first started under the name Techniques of Design and then became To Be Agile, I’m starting a new blog series. Actually, I’m starting nine new blog series, a series on each of the nine practices from my book, Beyond Legacy Code: Nine Practices to …
Continue reading “Why Practice 1: Say What, Why, and for Whom Before How”
Read MoreWork Through Examples
One of the biggest challenges in building software is specifying what needs to be built. A blueprint captures all of the valuable information we need in order to build a building and details such as the tensile strength of the material and how to build a foundation are available through other sources. Blueprints have no …
Continue reading “Work Through Examples”
Read MoreBuild What Users Want
Our users are only human and its human nature not to always know exactly what we want. I realize that sometimes we have to build software on specifications and all the requirements are needed to be identified upfront. But statistically, it is rarely the case that all requirements are needed. It turns out that nearly …
Continue reading “Build What Users Want”
Read MoreRequirements Aren’t Required
In traditional software development, up to half of all development time is spent writing, maintaining, and interpreting requirements. Even more than bugs, requirements are the single largest time sink in developing software. But what’s the alternative? How will developers build what the customer wants if they aren’t told what the customer wants? The full answer …
Continue reading “Requirements Aren’t Required”
Read MoreSeven Strategies for Product Owners
Often we find at the core of a great product is a great Product Owner (PO). The Product Owner holds the vision for the product and prioritizes the work to be done. They steer the team to create the product. If the product they define is not ultimately what the customer wants then no matter …
Continue reading “Seven Strategies for Product Owners”
Read More