“Try not to become a man of success. Rather become a man of value.”
— Albert Einstein
In the first two posts in this series, we established that the role of Engineering is to efficiently deliver valuable functionality to Customers and that the first task of the business people is to help convince them of that.
Whether you have been successful in that quest or not, you need to ensure that every requirement for the software is expressed based on the underlying business value. You need to describe and explain that business value to the Engineers. Let me give you a simple example – recently, one of my Engineering teams created a very simple report. For the record, reports are possibly the worst thing to work on as an Engineer (other than documentation). Usually, the reporting tool is oriented to business users and creating reports rarely involves interesting Engineering work. As well, the users are typically fussy about the layout, sorting and filtering of the report and you can work endlessly on the nitpicky details without doing a single thing that exercises your technical muscles.
After the report was completed – and in the middle of a Sprint demo – I asked the Product Owner how valuable the report was to the users. He said that this particular report was massively valuable because, before it existed, the users had to spend many hours creating a report by hand with data gathered from all over the application. Because it was manual and tedious, it was also subject to error and the final report went to an important regulatory body that didn’t tolerate errors. This information came as a surprise to the Engineers, who seemed surprised (and at least a little excited) that the report was so valuable. I wished that the Product Owner had explained this up front; my belief is that the Engineers might have been a little less bored to create the report if they knew that it had massive value.
I sincerely believe that Engineers like to know the meaning of their work and that knowing it changes their interest in the work. This is why charities show pictures of children that need help to solicit donations to their cause. People want to know that their efforts have a real benefit [1].
Equally importantly, express all requirements in terms of the functionality of the application and the real-world scenarios of the user [2]. Why is this important? If you did your homework and read through the Introductory Series, you will remember that the only things that matter are those that pass across that magical Customer Membrane. So why not specify everything in a way that the work is identifiable across that membrane. If you can’t, it is possible that it isn’t a very important requirement at all.
So always explain the business meaning and value of the requirements you specify – it will give meaning to the Engineers’ work and forces you to ensure that you are specifying something of importance. If it leads to more questions from the Engineers about the business domain, then it results in learning and the more an Engineer knows about the business domain, the better an Engineer they will be.
The next post talks about the other side: the functionality being created by the Engineers.
This post is based on or excerpted from the upcoming book “De-Engineering the Corporation” by Darryl Ricker
Footnotes:
[1] I remember starting a new job where I was told during the New Employee training that our software had recently saved the life of an infant. My spirits and efforts were buoyed for months by this revelation.
[2] We technical people love to call real-life scenarios “Use Cases”, which is a term I never really fell in love with, but you can’t really avoid it. Have you ever trained someone on your responsibilities and said, “Here’s a use case that I do several times a day”? Do you ever ask your kids, “How was the use case ‘Attend School’ today”?
Leave a Reply