Agile Quickie: Working Software & Responding to Change
Today we’ll be learning about the next two Agile Values, Working software over comprehensive documentation & Responding to change over following a plan. I’m going to do my best to keep this Condensed.
#3) Working software over comprehensive documentation
Both of today’s Agile Values go really well together. The best way we demonstrate value to the customer is by providing working software. This will allow them to work with it and let us know whether or not it solves the problem we were hoping to solve. Documentation is valuable, but not at the expense of delivering something that works. Many times we will talk more about a solution than we do providing a solution. The beauty of an Agile Mindset is that we embrace experimentation, and we become allergic to red-tape and bureaucracy. Extensive Design and Define stages, and even in-depth status updates, often have the team focusing on the wrong things, which distract from the most important thing, which is satisfying the customer.
How do we embody this value?
- By looking to provide a quick and effective solution for a customer’s problem. Think of this as getting the code to do what you want, knowing you’ll refactor later.
- We prefer to demonstrate status through working software, or complete features rather than update slides and emails.
- We look to segment our work to deliver fully functioning small features rather than large updates and perfect solutions.
Making it practical:
- Story refinement — We don’t look for perfection, but rather a viable solution that we can perfect later on. We get just enough requirements to build a solution and iterate.
- Continuous Delivery — We look to build stories that deliver vertical value, meaning a complete feature or workable portion by the end of the sprint every sprint.
- We document as we go rather than build comprehensive, catch-all documents before we begin. This doesn’t mean we don’t have requirements to begin with. It means we have a solution to a problem, we build to that, and work to improve rather than fully define everything before we begin.
#4) Responding to change over following a plan
Responding to change is THE MOST misunderstood, and weaponized value within Agile. For some, this value would be the definition of Agile, and would look no further. This unfortunate reality causes Agile transformations and projects to fail. Agile does mean responding to change rather than following a plan. However, this MUST be rooted in delivering quality and value, listening to the customer, and interacting with individuals to ensure we’re responding rather than reacting. Agile does not mean changing all the time. That’s chaos. Agile means building and planning things in a way that allows us to change when higher value is identified.
How do we embody this value?
- We take a measured approach to responding when new information becomes available.
- We listen to our customers first, plan small iterations, and build our expectations in a way that allows for shifts to cause as little disruption as possible.
Making it practical:
- Size small and deliver. Focus on the INVEST principles when sizing work. When we work on small, deliverable, segments of features, we are able to compartmentalize more easily, and deliver more quickly. This will allow us to better estimate when we can deliver (smaller is easier to see) and we can follow through and move on with less disruption and greater peace of mind.
- Keep things decoupled as much as possible, in code and in delivery. Single-tasking is a good thing.
- When we receive feedback, measure it against what is already planned and determine true value and priority. What is urgent isn’t always important.
- Don’t plan any project/feature that will take more than 3 months (6 sprints) to deliver.
- Have the delivery team determine what can be delivered from a request and negotiate size and scope thereafter.
- CONTROVESIAL SUGGESTION: Set a date of delivery, and negotiate scope to deliver to that date. Build iterative improvements afterwards. DON’T change delivery dates.
