2024 Public Training Schedule
November 18 – 21, 2024 – Agile Analysis and Design Patterns
Half-Day Sessions
December 9 – 12, 2024 – Agile Analysis and Design Patterns
Half-Day Sessions
Follow me on Twitter:
Blog Post Categories
- Announcements {19}
- Articles {2}
- Bits and Pieces {74}
- Blogosphere {1}
- Bonuses {2}
- Build in Small Batches {27}
- Collaborate {38}
- Create CLEAN Code {34}
- Implement the Design Last {11}
- Integrate Continuously {30}
- Off-Topic but Interesting {3}
- Rants {82}
- Refactor Legacy Code {24}
- Say What, Why, and for Whom Before How {22}
- Seven Strategies {38}
- Specify Behaviors with Tests {17}
- Write the Test First {27}
Archives
Privacy Policy
(c) 2024 To Be Agile
- April 18, 2023
- Integrate Continuously
Wrapping up this series of seven blog posts on burning down risk, I want to talk about validation.
Validating our ideas, assumptions, and features is critical to tell us if we are on track. We want to get software in the hands of our users as quickly as possible so that they can tell us what works for them and what doesn’t. If a picture is worth a thousand words, then even a mockup of the feature is worth a million words.
When we put our minds to use a feature, we can get a good sense of how to design it well, and that’s our goal. It’s often a refinement process we don’t get right the first time. It’s through the interaction with our users that they discover and we discover the best ways to use the software.
I call this using development as a discovery process, and it’s where the actual value of software development comes in. It’s not the code but rather our understanding that we gain on how to do things better that is the real value developers provide. The code embodies that understanding so that others can benefit from it. The understanding is the real value to me of developing software. Software embodies our understanding.
In Agile and Scrum, we talk a lot about validation and feedback. We get feedback on many levels. We get feedback from our users, who tell us what they want and verify that our build addresses their needs. We get process feedback that tells us how to improve our process. This includes retrospectives and feedback from the team.
There’s also the feedback that we get from our build and our tests that tell us if we are introducing defects into the system so that we can recover quickly. For developers, feedback from the build server running continuous integration is one of the most valuable forms of feedback. When I am writing code, I run my build frequently. Whenever I have a bit of functionality, I check it in and get feedback from my build to validate it, and the rest of my system runs as expected.
Agile is all about feedback, and software development efficiency has a lot to do with the length of our feedback loops. We want to get feedback as soon as possible, and that means building the smallest piece that shows value.
Previous Post: « Build the Smallest Piece that Shows Value
Next Post: Look for Small Improvements »