Value Driven Development
When it comes to developing software, you can play buzzword bingo with the processes and methodologies thrown around: Agile, Scrum, Kanban, Acceptance Test Driven Development, Feature Driven Development, etc. Some seem more vetted than others, but, at the end of the day, you are the person that needs to know what’s right for you and your team. But how do you do that? To figure out where you’re going and how you get there, in software as well as in general, you need to know your context and your value system.
Context: Who are you?
What you do as a part of the endeavor determines your context. A developer has a different view than a marketing director. A graphic artist has a different view than a QA tester. This plays a vital role in the next piece.
Value System: What’s important to you?
Your view of the product and/or what drives you determines what is most important to you. This is the basis of your value system or the product’s value stream. How you see things will change the evolution of the product.
“I’m the marketing director for my firm.” You’re probably looking for the shiny features to be able to point at in brochures and displays to get people to buy your product. You don’t particularly care about the development life-cycle, as long as you get your shiny.
“I’m in charge of maintaining the website once it is up and running.” You’re probably interested in the administration packages of the product. You also look for testing performed to ensure that the website will have the up-time you want.
“I’m a developer that needs to write software for our client.” You’re probably interested in the requirements of the software to be able to build the right thing. You’re also hopefully interested in writing tests to be able to ensure that, as things change (and they will), your code will be solid.
“It’s not hard to make decisions when you know what your values are.”
What if you have all kinds of people with their own opinions and values that conflict with one another? I recently had a project where there were dozens of teams and hundreds of software developers, testers, designers, architects, etc. building a product. Everyone had their own view of what needed to happen. As one of many product owners on the project, I had to balance the needs of the customer, the requests of management, and the desires of the developers to generate stories and acceptance criteria to manifest a product and its feature sets that would eventually be marketed and sold. Did everyone get what they wanted? No. Did everyone understand the common goal we were working toward? I personally tried my best to convey that, so I hope so.
Remember, whenever you see “[Fill in the Blank] Driven Development”, that fill-in-the-blank just told you their value system and what really drives them.