A long time ago I left college with the notion that I wanted to ultimately run my own business, my job experiences were purposefully diverse, giving me experience in Sales, Banking, Management and ultimately IT and luckily I've been able to do that several times. While I wasn't always engaged in the world of technology during some of its growth, I've always been involved in building and delivering great product.
What I learned during this time is that building great products is much like writing a symphony, you have many instruments that you can choose from for your piece, but if you don't bring them together in the right way, if you don't understand the limitations of those instruments you don't end up with a masterpiece, but rather something that might sound like noise.
I have often used the concept of a symphony as an example for the way that we manage software project delivery. You have an individual, Conductor, who is responsible for ensuring that everyone in the symphony is playing their parts correctly, are watching the conductor for queues on changes that might be made in the middle of the concert. When everything comes together correctly you get beautiful music, when it doesn't.....not so nice. Building software in an Agile world is much like this, the Conductor is the Product Owner and the delivery teams are the musicians who watch the conductor for their queues when small changes are made in the delivery.
Understanding your craft, be it song writing, engineering, sales, etc....is an important element of you becoming great at what you do. The craft of building great products is being able to master how to manage all of these different crafts in order to bring about something great. My wife, who is an Arts Manager, has often likened software development as just as much as artists realm as an engineering one. I have another post I'm writing that explores this in more depth.
For those of us who build a product with software we define our vision, much like a composer will do. Once the vision is identified then we determine what components (or instruments) we will need to accomplish our vision.
What are the types of instruments that we use build product with software?
- Product Owners/Managers
- Product Developers
- Product Testers
- Software - Java, .Net, etc...
- Hardware - Servers, Databases, etc..
What is our endgame with these ingredients? Build product with software that delivers functionality that customers want and are willing to pay for. If our instruments aren't aligned with this primary goal, we'll waste time and money and deliver quality that isn't what the customer expected.
When we talk about quality in the software world, we talk about defects, code quality, etc..., however from a holistic standpoint none of this matters if you haven't delivered a product that people want. Your first goal as a Product Development team is to understand and align yourself to this completely. If you focus more on delivering technical quality then you aren't delivering the quality that the customer is expecting. Using the example of a restaurant, I can cook and deliver the absolutely best Pasta Primavera to you, but if in fact you wanted a Steak, then I have missed your quality expectations. It doesn't matter how good the food was, how well it was delivered, it failed to meet your expectations so the entire element of how you perceive the quality of my business is affected.
I think we are moving towards understanding this with concepts such as Personas, however I'll be honest I've been in only one place where we paid attention to these personas as we built our product, I think many of our high-tech companies that have evolved over the past 10 years are much more focused on the technical aspects of the product over what the customer wants. Example? Facebook, Google. They release new features and then gauge response and then remove or modify the product features based upon feedback. I think long-term this is not the paradigm that will bring success to most organizations, eventually you need to be driving your company based upon what your customers want, not what seems cool and technically challenging.
Building great product has absolutely nothing to do with technology. Technology is merely the enabler of a product that customers want and are willing to pay for. If we could find a different way to deliver the product without technology (or at least the technology we have in place today) we would do that in a heartbeat.
If we are to re-align our instruments as a technology team delivering quality what would they look like?
- A clear understanding of what the customer wants, ensuring that whatever we work on is aligned to that need.
- A clear set of requirements that support that need. Agile provides a process for capturing user needs with User Stories, however the key miss I see with most user stories is that they aren't written to align to the customer need.
- A set of software specifications that support the User driven stories.
- What do we mean specifications? Using tools and processes such as TDD and BDD to define the user story at the technical level. Again another big miss I see with teams who write user stories is their acceptance criteria stays too high level to understand the technical elements we need to delivery as part of our technical quality.
- Though Agile is about conversations over documentation, we really can't deliver high quality software unless we build a shared understanding of the user stories and a depth of understanding via specifications.
- A feedback loop that delivers customer feedback to everything we do.
Notice, in the new set of instruments there is no mention of technology, how you deliver a feature is entirely up to the technologists. Their responsibility is to deliver customer features, the expectation as professionals is that they will do it with quality.
Delivering great products comes from the intersection of customer needs and high quality technology. Great product can survive from lack of technical quality in the short team but it can never survive the lack of focus on features driven by the customer.