Maslow’s hierarchy of needs is a theory in psychology which attempts to classify human “needs” in order of importance ranging from low to high. The lowest needs being the ones most fundamental to life, the highest being the most aspirational or transcendent.
The hierarchy of needs is arranged in a pyramid, once lower level needs are met you can move up to the next level. Lowest on the pyramid are things like Food, Sleep, Water. Here’s a visual:
Self-actualization is highest in the list and presumably by the time you’re operating at this level you’re ready to transcend these earthly bonds.
I did a simple thought experiment to try to determine how this would work in a software development team. Software can suffer from very basic needs such as lack of disc space, or sufficient air conditioning. You might laugh but I’ve been in the office at 4AM when the A/C is off working on production releases with a team of developers. It’s not fun. On the contrary, a well setup team doesn’t worry about these things, they’ve moved up the pyramid. This got me thinking, what sort of pyramid do you need in order to operate as a “highly effective team”. How much of the pyramid do you have already and what are the gaps?
Here’s what I came up with (click to view)
Shanahan’s Maslow Hierarchy
My analysis is by no means complete but I ended up with Seven levels. Seven’s a good number. They break down like this:
Level 1 – Physical Needs
These are the basics that every developer needs in order to do some work. A Compiler, Computer, Desk, Cube, Coffee, Lights, Air Conditioning, Team Structure (folks need to know who to talk to), Project Schedule. No surprises there. I’ve included a box for “Google” which represents internet access. Yes, I have seen teams that are asked to code whilst lacking internet access. Can you imagine ramping up without reference material? I’ve also included Software Licenses because some shops develop using trial licenses only. Lastly, Whiteboard and Markers go a huge way in terms of communication. Of course this list could be much longer but I stopped there.
Level 2 – Tools
Level 2 looks at “tooling”. You have a compiler but level 2 adds in productivity features like Intellisense. A Quiet Office w/door is vastly superior to a cube (in some cases, not in others). Code is managed in a Source Control system and Coding Standards are documented. Requirements might be capture in MS Word but at least they are documented. Some Basic Project Management exists with maybe a weekly team meeting. Code Reviews are manual and defects are tracked in a dedicated Bug Tracking system (e.g. TFS). The team has access to Vendor Support Accounts for when they encounter problems.
Lastly, formal Environments e.g. SIT, UAT etc. are established.
Level 3 – Common Components
Ok, now we’re starting to work smarter not harder. Horizontal functions and cross-cutting concerns have been pulled out to some degree into Common Components. Typical pieces include Authentication, Authorization, UI Layer Design Patterns, Data Access, Localization, Logging and Exception Handling. A formal Build Process has been established. Non-code artifacts like Design Docs and Test Cases are managed in MS Word.
Level 4 – Re-Use / Frameworks
Taking the Components from level 3 and tying them together we get a Framework. Integrated components and Comprehensive Developer Utilities and e.g. a Data Access Layer that works together with the MVP Pattern used by the UI Layer. The pieces work in concert with the whole exceeding the sum of the parts. More like a Framework than isolated components. This in turn institutes a Consistent Architecture across projects. The Build Process is now Automated and we can start to tackle Distributed Development.
Non-code artifacts are no longer managed through Word but through dedicated systems e.g. CaliberRM, DOORS, TFS. We also begin to see higher level concepts come into play like B2B interactions, e.g. Identity Federation. These high-order concepts are not possible unless the lower levels of the pyramid are firm.
Level 5 – Automation
Now we look for efficiencies, scaling back the human processes required and moving to an automated life cycle where appropriate. Tying the various sub-systems and processes together through automation. Virtualization or Cloud Computing might enter here. Things like Code Generation and Continuous Integration are implemented and we start to see comparable Metrics coming out of the projects. Source Control is governed by Policies which enforce things like “all code must have a unit test” etc. Requirements, Test Cases, Code and Defects are all linked and we begin to see traceability through the project’s deliverables.
Level 6 – Software Factory
By operating as a “factory” the team introduces Governance around non-software artifacts. Projects are more predictable and Metrics are harvested consistently. Estimates are more accurate and justifiable leading to more achievable project timelines. Results can be Quantifiable rather than purely Qualitative.
Level 7 – Software as a Commodity
Now you’ve reached Nirvana, or almost. Projects are “Turn-Key” with a high degree of predictability, very low risk and very accurate estimates. The management team has End-to-End Traceability/Visibility and there is a complete feedback loop from Project Inception through to Live Date.
This was a useful (and challenging) exercise. If I’m being honest I would say we’re operating at level 3 or 4 right now and failing to climb higher because we keep getting dragged back to lower levels.
My gut reaction was that the smaller the team, the more nimble they can be between levels and I often envy smaller shops with less constraints and more freedom to move around this pyramid. I’m not sure that holds though since perhaps the smaller the team the more volatile the lower levels of your pyramid might be? Conversely the larger the team the more stable the lower levels would be but the tougher it is to move up the pyramid. There has to be a balance.
Given enough resources and a solid foundation I feel the pieces are out there now to rise higher, they just need to be applied.
The question now is whether “Shanahan’s Hierarchy of Software Development” belongs in Zachman? or “Popular Psychology”?