“If you love what you do and are willing to do what it takes, it’s within your reach. And it’ll be worth every minute you spend alone at night, thinking and thinking about what it is you want to design or build. It’ll be worth it, I promise.”
— Steve Wozniak
In the previous post, I suggested that you, as a business person, express every requirement (or “Story” if you are using Scrum) in terms of the business value it delivers and also in terms of the user’s interaction with the application. In this post, I look at the flip side: functionality coming back from Engineering.
As you may have experienced, once the Engineering team starts works on your requirement or Story, it can quickly devolve into the technology abyss. Despite your couching it in business value terms, the Engineers come back talking about object models, design patterns, refactoring and other terms in which you aren’t conversant. If the work requires them to use a new tool or framework (or if they remotely think it should), the discussion will soon get into whether Technology A, B or C is better, and a religious war of sorts might erupt. Engineers will break into camps supporting one option or another and debate rages on. Pretty soon, the actual requirement and all notions of business value are long forgotten.
Very often, the business person is intimidated by the discussion and – so as not to risk looking foolish – they let the Engineers carry on [1]. Eventually, the Engineers come up with an approach, or choose a technology or an Architecture and the work is undertaken. As a heads up, I can advise you that anything that starts with a lot of technical analysis and debate usually ends up taking a long, long time. And when delivered, it may or may not do what the person writing the requirements asked for. It’s a little like the old cartoon you see frequently:
We all laugh when we see this, but it is only amusing because it is so accurate. We need to find a way to accurately specify what is needed and make we’re transparent about what is being built so that we can inspect it at intervals to ensure it meets the well-defined requirements. I’ll have an entire Blog Series focused on how to specify software effectively, but for now, let’s just say that the solution to the problem of losing control of a requirement (or an entire project) to the Engineers is these two steps:
- As outlined in the previous post, describe the requirements in terms of real user scenarios and impacts, as well as explaining the business value that the requirement will provide. Ideally, record the requirements in something visual (such as a wireframe or a prototype if the application has a user interface [2])
- Have the Engineers describe back to you in terms of the real application scenarios the impacts (and risks) of each technical option they are discussing. You must compel Engineers to describe everything they are doing and all their decisions and challenges in terms of the impact on the business value and/or the user (not in technical “mumbo-jumbo”).
Let’s look at an example of point #2. Assume that you have specified a page in a web UI and on that page, you specified the need for a calendar date “picker”. Based on this requirement, the Engineers say that they need to implement a new JavaScript UI framework to support the behavior you described (a calendar that “pops up” when the user clicks on the date field). In this case, you need to have them explain – in business terms – why the various tools and frameworks you already have are insufficient. Based on your requirement for the date picker, ask them what happens without the new JavaScript UI framework. Let’s assume that they tell you that using the “crappy UI framework” they have now, they can’t have a calendar, but only a boring old set of three drop-down boxes for Day, Month and Year. If this is good enough for you (and your users), then you’re fine. If it’s not, ask them the effort required for the fancier version. If they say 3 months of elapsed time, you might decide that “boring” and “old” are quite acceptable. And, trust me, if they say three months to put in a new UI framework, it is hugely underestimated.
This is a simple example, but trust me that virtually every technical thing that the Engineering team gets obsessed with can be translated into its business impact. It takes extra work on their part and massive persistence on yours. Eventually, after enough occurrences of this, they will know that you’ll demand it, so they’ll have the explanation ready for you. And you know what happens then? The Engineers will have started to think like the business people – and that is almost always good [3]. And you know what else happens? You will start to understand a lot more about the technology because you will regularly see the technical topics translated into what you understand – business. This is why you’ll see good Business Analysts and Product Managers with no technical expertise start to talk more confidently about technical topics. And that’s almost always good, too.
This post is based on or excerpted from the upcoming book “De-Engineering the Corporation” by Darryl Ricker
Footnotes:
[1] This is the Emperor’s New Clothing syndrome – link.
[2] This will be covered in great detail in the upcoming Blog series on specifications.
[3] I’ll give some examples later of situations where you might regret empowering the Engineers to think about the business aspects, but 95% of the time, it is a positive advancement.
Credits:
“What the Customer Really Wanted” diagram from http://www.projectcartoon.com/
Leave a Reply