Traditionally software development is driven by requirements – descriptions of functions the product should perform once done.
In the past those requirements were handed down to the development teams as a bulky specification document. Now, with agile methods being widely used they are usually put on a backlog. This backlog is managed by someone – sometimes called a Product Owner – who can move requirements up and down at any time etc. We all know this. This change alone did bring a lot of improvement. It enabled flexibility in responding to change on the product level and helped reduce waste from implementing unnecessary features.
The problem is I think this is not good enough. I think the problem is the requirements themselves. I think we could even call them dysfunctional.
Here is why.
Requirements – as they are practiced by most teams now – are deeply rooted in the sequential, cascading way of building products, with its clearly divided silos of narrow specialists. In each silo those specialists perform on the product the single activity that is their specialty, then pass it on to another silo. Understanding of the product’s purpose, understanding it as a whole is unnecessary – or at least not crucial and expected. Everyone is supposed to do well the one thing that is within their competence – and such are obviously also the limits of responsibility and expectations.
If a piece of software is needed to solve a business problem a group of “business specialists” creates and describes the needs (sometimes already selling the result to clients), then passes this description on the silo with “analysts” who in turn produce requirements, that are in turn passed to the silo with “programmers” as a description of what they are supposed to build – and so on.
The key dysfunction of this model is not even the specialization of workers (an idea stemming from 19th century industrial revolution and its 20th century success – good for making repeatable physical products in mass quantities, not for creative intellectual work), that fails to engage their full potential. The key problem here is the alienation of workers from both the product and other silos. The result is lack of shared responsibility for the end product, especially for it being indeed a solution to the original problem.
This is why a typical employee feels he has no influence on the product nor the company as a whole. This feeling – so common in larger organizations – is killing engagement and creativity. Instead, it fosters an attitude typical of the “deferred life plan”: I sit at work doing something I don’t care about only to get paid.
Agile changed a lot within the development silo. In most companies we no longer have “internal silos” – analysts, programmers and testers working in separate departments (companies that still don’t get it will change or die out). Teams share responsibility for the product, but they share that responsibility only on the technical level, not on the product level. So yes, it helped, there is more engagement etc. but the alienation between business and development continues. Common attitude in the ‘development silo’ is now “we are blacksmith trolls down here, we forge whatever is asked of us, we do it well because we pride our craft – but whether that makes sense, solves client problems etc.? We don’t care. It’s the problem of the business trolls”.
I think part of the problem here is requirements in their traditional form. What does it change if we put requirements handed down the ‘development silo’ from ‘business silo’ on a “product backlog” and call someone “The Product Owner”? Very little. This still doesn’t full potential, brainpower of people in the organization. It still the old waterfall, just one level up. In fact, once we have backlog etc. in place it may make the problem less visible, because now that “we are agile” everything seems ok.
I think that what agile is all about – at least as much as I understand it – is creating teams that will collaborate to deliver products having shared responsibility for them – and influence over them.
To achieve that we need to break one more silo – the ‘business silo’. We should build true crossfunctionality by including the “business specialists” on the teams. And teams should get problems to solve or ideas to validate, not requirements.
It seems like a small change but it is, in my opinion, fundamental. Implementing it means shifting everyone’s thinking. Implementation is no longer a goal in itself for the team – solving the original problem is. Everyone is involved, everyone’s ideas count not only regarding the technical solution but the overall solution. And responsibility is shared too – no more finger pointing blaming the other silo – “stupid busines” or “lazy developers”.
Can a backlog and a role akin to Scrum’s Product Owner still help if we have problems/ideas instead of requirements? Yes. Keeping a list and deciding which ones to address first is helpful. Backlog makes the problems/ideas waiting to be addressed visible, helps gather more information about them, serves as a communication device for other teams. A role of PO can help if it is hard to decide on the order on the backlog – if consensus can’t be reached someone has to step in and decide.
Conclusion is: want true agility? Get rid of requirements! Instead create really crossfunctional teams that include non-technical talent you have and have them work a backlog of ideas/problems.
Note: I’m fully aware what I call for is already how things are done in best, most innovative companies. I’m also aware this is what at least some of “agile gurus” had in mind when they created the backlogs. Yet still I frequently see companies who claim to be agile yet persist in keeping development and business silos separated. And they stick to requirements. I truly believe changing from requirements to ideas/problems could help transition further.
Last comments