MarkStringer.github.io
Bricks Without Straw - Or Maslow’s Hierarchy of Needs - For Software Development
Go ye, get you straw where ye can find it: yet not ought of your work shall be diminished.
Pharoah - The Bible, Exodus Chapter 5 Verse 11
So I’ve spent most of the last 6 months or more developing this course to prepare people for the BCS Agile Foundation Certificate exam. The blessing and the curse of this exam is that it’s very wide-ranging. It isn’t just Scrum - it’s lots of other aspects of Agile, and their pre-history. Somehow, part of this prehistory is Maslow’s hierarchy of needs.
Maslow’s idea is that not all needs are equal - if fact some of our needs need to be met before we can think about meeting other needs. Our basic physiological needs have to be met (air, food, water, shelter, warmth) before we consider other needs such as personal security. When these neds are met we then can consider the need for love and affection and belonging. And beyond that, we can look for higher levels of fulfilment in our lives - esteem, self-actualisation and finally self-transcendence.
As with many concepts that populate business and self-help books, there is a substantial “Criticism” section on the Wikipedia page. And a lot of the criticism centres around the simple point that this hierarchy simply isn’t observed empirically. But I’m not going to get into that right now.
Stringer’s Hierarchy of Development Needs
The model here is useful because so often, I seem to find myself in a situation where I’m being asked (to use another model) to create “Bricks without straw.”
Regularly, it seems that we’re asked to do sophisticated, creative problem-solving within the ever-present “aggressive timescales” whilst at the same being told that we can’t have access to development environments, test environments or release environments, that we can’t use meeting rooms (I talked to a Scrum Master who works for one of the biggest organisations in the country last night - he told me he doesn’t sit with his team because the developers are already sitting together, seven of them in a four-person room).
Regularly, we’re asked to do sophisticated, creative problem-solving, without access to the people who want the software, or the people who know how it should work.
Regularly, we’re asked to do sophisticated, creative problem-solving, providing value-for-money, within the ever-present “aggressive timescales” whilst at the same time being in dispute with our customers over payment.
Being asked to do things at the top of the software development hierarchy of needs, when basic things at the bottom of it - like being able to get in the building, or being paid - aren’t in place, tends to fill software development teams with rage, despair, apathy and resignation. And these emotions, again, aren’t exactly conducive to creative problem-solving. So there’s a really obvious question:
Why do customers do it?
I’m hoping the reason is because they’re not aware of the hierarchy. This would be great if it were the case. Because, following Daniel Kahneman’s Principle “What You See is All There is” (WYSIATI) all we would need to do is show our customers the pyramid and point out that there a problems with its foundations and we won’t be able to reach its peaks until these problems are fixed.
Pharaoh - a Tough Customer?
But unfortunately there is at least one other possibility. That, like the Pharaoh, the customer thinks that the work of developing software/bricks is just too easy if all the requisite foundations are in place. Like the Pharaoh, the customer, for some reason - possibly under the delusion that suffering somehow makes better software - wants the development team to struggle. What to do if that’s the case? Is there any other option that to try to escape into the desert?