This is published under the terms
of the licence summarized in the footnote.
All free-to-read materials on the Avancier web site are paid for
out of income from Avancier’s training courses and methods licences.
If you find them helpful, please spread the word and link to the
site in whichever social media you use.
Abstract
Have you read “The Mythical Man-Month: Essays on Software Engineering” by Fred Brooks?
This paper reminds you of it and adds some supplementary points.
Contents
Adding
man power may hinder productivity
A
bigger team and tighter configuration management may hinder change management
More
requirements traceability may hinder ability to meet requirements
Adding
more managers may make progress reports less accurate
Adding
more external reviewers may delay progress
Distributing
the design of complex system to many people makes things harder
Challenging
architectural myths and assumptions
In the “Mythical Man-Month” (ref. 1), Fred Brooks stated that "Adding manpower to a late software project makes it later."
The cause is that as the size of a team increases, inter-person communication increases disproportionately.
Brooks surely understated the problem, because several variables increase with the size of a system.
Not only do the number of people and inter-person communications grow, but also, for example:
· The depth of the management hierarchy
· The number of external actors and reviewers who require reports
· The number of documentation configuration items (requirement, solutions, test cases and traceability records)
Each increase in size disproportionately increases the complexity of what is being managed, and so, tends to reduce productivity.
So, if your project is late, you might do better to remove people until productivity improves – and also descope the work if you can.
Keeping the scope of work to be
done, and the size of the team, small, is a principle of agile development.
Anecdotal evidence suggests: an
increase in the size of a system or project team leads to a disproportionate
increase in the resources and budget needed for change management.
Why is that? Basically, the cost and difficulty of configuration management increases out of proportion to the increase configuration item numbers.
When a configuration has exceeded
the size and complexity the current team can manage, the first response may be
to recruit extra team members.
But as extra people tend to create
more configuration items, the challenge is increased rather than reduced.
The next response may be to formalise
change management processes.
This too tends to reduces
productivity, since it increases the need for inter-person communication while
not increasing product creation activity.
So, when your configuration is too
large to manage, you might do better to divide it into smaller configurations
and decouple them
Decoupling subsystems – allowing there
will be some inconsistency between them - is a principle of agile development.
As the numbers of requirements and solution items increase, so the effort of requirements traceability increases disproportionately.
The task of maintaining requirements traceability records becomes a job in itself.
Requirements management becomes bureaucracy, somewhat detached from those who define requirements and solution items
The effort of doing impact analysis and updating the requirements traceability records becomes so great that managers resist change requests.
And so, customers’ requirements are not met.
So, when requirements traceability becomes a burden, you might do better to reduce the number of requirements by abstracting them to a higher level.
Maintaining only high-level
requirements documentation is a principle of agile development.
The more people on a project, the deeper the management hierarchy, the greater the management overhead, and the less the topmost manager knows about what is going on.
Managers are responsible for project time and budget; they are reluctant to report any overrun.
Each manager tends to simplify and soften any message of risk and delay from below.
The message is softened at each step up the management chain, so that the topmost manager has the rosiest picture of progress.
The result is that a large project can continue slipping behind schedule until some kind of crisis point is reached – and the fan is hit with the proverbial substance.
All these factors are exaggerated in the IT world, where it is notoriously difficult to assess the state or progress of a project until well into system testing.
Measuring progress in terms of delivered product - as early as possible - is a principle of agile development.
As each manager up the chain realises the project is significantly behind schedule, they invite external reviewers to interview the team members and report.
I have been such a reviewer, and recall the bitterness of one interviewee:
“It isn’t just that the reviews take us away from the work.
The outcome is that we spend more time measuring how badly we are doing - and more time compiling management reports with numbers that show how badly we are doing.
We spend more time managing upwards and less tome managing downwards.
None of the reviewers actually help us to do it better.”
Continual internal and peer group
review, rather than external review, is a principle of agile development.
To build and maintain a system is intellectually challenging; it demands knowledgeable, intelligent and disciplined minds.
The complexity of a system design, and the manageability of the system’s evolution, is limited by the minds of its architects and maintainers.
Surely, the most efficient design will make best use of the power of a single human mind to remember and maintain a configuration structure?
Two strategies might be proposed.
Divide the
configuration
Divide the configuration into many small loosely-coupled modules that can each be maintained by a low-ability person.
The first strategy is OK when the configuration is a list or hierarchy of similar, simple and largely unrelated modules.
But in more complex systems, with more inter-dependent modules, it has serious disadvantages.
The larger the number of loosely-coupled modules - the more inefficient and unreliable the end-to-end processes in the overall system.
The larger the number of lower-ability designers – the more duplication and discrepancies between modules.
There will be more difficulties in integration of modules.
Change management will be harder, not least because Fred Brook’s group intercommunication formula comes into play.
Capitalise on the
human brain
Maximise the use of a few high-ability people by giving each the largest configuration they can manage.
Surely, the second strategy will prove cheaper, faster and better for a large and complex system?
Given a “normal distribution” of ability, only a minority of people have the ability to manage the largest and most complex configurations.
But in this minority are people who are able to manage a surprisingly large and complex configuration.
Taking full advantage of these people means that fewer design-aware minds and fewer managers are needed.
Change management will be much easier; which means that evolving requirements can be met.
Managers who don’t like dependencies on high-ability resources will prefer the first strategy.
The only downside of the second being the need to recruit and train up high-ability people to manage each large configuration.
So the proposal here is that each subsystem is designed as a configuration that a high-ability person can understand and maintain.
Within that subsystem, components can be closely coupled, because the impact of any change request is manageable by one mind.
Subsystems maintained by different people should be loosely coupled, so as to minimise the need for impact analysis and group intercommunication when a change request is made.
Many stakeholders want to stop scope creep
· Customers want to limit their suppliers’ ability to delay delivery and charge more.
· Service providers want to limit the time and cost they spend on fixed price work.
· Managers use change control processes to limit the changes which are accepted.
But tight change control only works if the requirements declared at the start are complete and correct, which they never are.
When requirements are uncertain or unclear, you may do better to follow the philosophy of agile methods that all change requests are welcome.
Because changes enable an improvement in the process or the solution.
Agile development is based on idea that scope can, will and should creep.
Read “The Agile Manifesto and more”.
If you are interested in this paper, you’ll probably be interested in reading “Challenging architectural myths and assumptions”.
References
Ref. 1: “The Mythical Man-Month: Essays on Software Engineering” by Fred Brooks
Ref. 2: “Agile Traceability” in the Library at http://avancier.co.uk
Ref. 3: “Software is not Hardware” in the Library at http://avancier.co.uk
Ref. 4: “When agile becomes fragile” http://billyonopensource.blogspot.com/2008/04/when-agile-becomes-fragile.html
Footnote:
Creative Commons Attribution-No Derivative Works Licence 2.0 10/04/2015 20:34
Attribution: You may copy,
distribute and display this copyrighted work only if you clearly credit
“Avancier Limited: http://avancier.website” before
the start and include this footnote at the end.
No Derivative Works:
You may copy, distribute, display only complete and verbatim copies of this
work, not derivative works based upon it.
For more information about the licence, see http://creativecommons.org