Imagine taking your brand new lowrider to a mechanic to have a hydraulic lift kit installed. You go back the next day to pick the car up and before you can say anything the mechanic jumps in, flips a few switches and your lowrider starts to hop. You are thrilled but as soon as you climb in and turn the key you realize that your lowrider no longer rides. If this happened to you, you would not be pleased with your mechanic. As software developers our goal is to deliver value to our customers. We can think about this value in two ways; the primary value that we deliver is flexible software that is capable of meeting the changing needs of our customer, the secondary value that we deliver is software that satisfies the customers current functional requirements. "The primary value of software is that it is soft. That it is resilient in the face of inevitable change. That it not only meets the users' requirements and solves their problems in the present tense, but that it can be readily adapted to meet needs that will arrive tomorrow, or the next day." - Robert Martin When a customer asks us to add a feature to their software, they are explicitly asking for the new feature and implicitly assuming that we will add it in a way that maximizes its primary value. Said another way, when a customer asks us add a feature they don't expect us to break existing functionality in the process So we can think of our software as having both a primary and a secondary value, but how do these values play into Scrum? Here is the definition of Scrum as found in the Scrum Guide: "Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value." I find that definition very interesting for two reasons; it talks about the inherent complexity of the problems we solve, and it talks about the value of the solution. I believe that understanding how complexity impacts the value we deliver is important, so lets talk about it. Writing software that delivers the value that a customer needs when the customer needs it is hard. It is hard because the problem we are solving with software is usually complex, and it is hard because when people communicate complex ideas there are always assumptions made. To make matters worse, the customers' needs will change with time and each change introduces a new opportunity for miscommunication. Scrum addresses this complexity by taking big picture ideas that represent functionality that the customer wants and instead of defining everything upfront, small groups of functionality are defined and implemented. Each implementation cycle is called a sprint, and sprints focus on well defined user stories. Releases are planned per number of sprints, and you have reached your final release when the customer is satisfied with the amount of value delivered. Scrum minimizes the complexity of the problem being solved because it only allows you to focus on one group of small, understandable parts at a time. This is great for the customer because the customer gets feedback on the state of the code at the end of each sprint and has the ability to change the teams priorities before the next sprint begins. Planning for change allows the team to deliver the highest possible value. Over time the process looks like this: Each sprint delivers value to the customer by moving feature requests up the pyramid, making complex ideas simple enough to understand and implement. In between each sprint feature requests can be added, moved, or reordered. Scrum is a very flexible way to deliver the highest possible value to your customer in the shortest amount of time. But what about the idea of software having both primary and secondary value? I believe that when the Scrum Guide says that Scrum is a framework within which people can deliver the highest possible value, it is talking about the highest secondary value. I believe this because the overall design or architecture of the software is allowed to emerge as each sprint focuses on delivering new features. If you aren't careful, this emergent design will simply move the complexity from the problem domain to the solution domain. Said another way, Scrum helps me to better reason about the problem I am trying to solve by breaking it into small well defined pieces, but my implementation of these small well defined pieces in software can grow in complexity with each new piece that I add. I am maximizing the secondary value of my software at the expense of my software's primary value. I recently became a Certified ScrumMaster and in order to prepare for the certification exam I took a ScrumMaster course. One of the many things that I learned in the course was that Scrum accounts for the technical debt that can accrue over multiple sprints. Scrum allows for the creation of non-functional user stories and the execution of non-functional sprints, where non-functional simply means not mapped to a user requirement. Non-functional stories and sprints are how you can bring the primary value of your software back into focus. In summary, Scrum is a great way to deal with the complexity of the problem domain. It effectively minimizes risk on both the customer and the development team by allowing both sides to plan for inevitable change. While Scrum is an effective tool for maximizing your software's secondary value you have to be careful that you don't allow the complexity to simply shift from your problem domain to your solution domain, negatively impacting your software's primary value. You can keep the complexity in your solution domain in check by measuring it throughout the project and introducing non-functional user stories and sprints into the process as needed. If you want to learn more about how to measure the complexity in your code be sure to attend my upcoming CLA Summit presentation, "Architecting Complexity: How understanding complexity promotes simplicity". Jon McBee is a Principal Software Engineer at Cambridge NanoTech and is a Certified LabVIEW Architect, Certified LabVIEW Embedded Developer, Certified TestStand Developer, an NI Certified Professional Instructor, a LabVIEW Champion, and a Certified ScrumMaster
0 Comments
Leave a Reply. |
Tags
All
Archives
October 2019
LabVIEW Blogs |