![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Entry tags:
- agile,
- en,
- it,
- management,
- motivation,
- psychology,
- qa,
- quality,
- re,
- se,
- visualisation
Про ёжика в тумане, зазнайство, языки программирования и вериги
Marzellus 2024
This is a small addition to my previous post The State Transition Table of the Agile Age / 45 kB / 2024-01-13.
My intention was to share impressions, not knowledge. However, it would be good to explain my old advice to leave any agile software project between the milestones Tnass and Tnakh. (Теперь я знаю, что такое agile проект / / 2015-03-03)
Please note, I have no intention of explaining the Shlaer-Mellor method, or advertising it. I have slightly improved my text in the following parts.
It was wrong to use the hammer metaphor. Modern software developers usually do not build any material goods with their own hands, but they intensively play computer games. Hence, they mistake a hammer for silver bullets. I have replaced a hammer with a toolbox in my comparison.
A multi-tooling is also a sin in the modern software industry, because you cannot be described as an adept of the tool X, the method Y, or the framework Z. Thus you cannot be recognized as an ally or a foe. The agile experts simply do not know how to deal with you.
It is also annoying that you cannot participate in "My ruler is better than your hammer" arguments because you can suddenly take a measuring tape from your toolbox. This destroys all available strategies for professional discussions.
Grady Booch, one of the three giants of the object-oriented approach, once asked in a newsgroup to define the software architecture. There were many wise answers and brilliant theories, but then a user pointed out that in the Shlaer-Mellor method this would be simply the highest level of domain design.
This definition is a disaster. You cannot pose as an expensive consultant if your answers can be directly applied to real-life tasks.
The Shlaer-Mellor method can deal with uncertainty, but it can also deal with complexity. There are methods to test requirements and to replace base libraries. However, it does not contain the most desired feature — it cannot hide errors.
Thus, such a thing cannot survive in the modern software development industry because it is forbidden to exist. It is now unknown, and this is for the best.
I had also mentioned the agile refactoring. It may be perceived as a mystery that code improvements implemented by your colleagues break your logging, remove your tests, and backfire in unpredictable parts of your project.
This is a mystery only before you write down a balance for time, amount of features and quality. I would not describe these dependencies here.
My explanation of Tnakh starts with a banal but usually overlooked truth: A software source code is not a fixed piece of art but a ever-changing knowledge base. It stores information for both computers and software developers.
We start from an empty state transition table for an Agile Project and observe its growth.
I use the following model.
There is an agile software developer, Mr. Smart, who is only adding features. He is an experienced developer and — to some extent — can control the unintended consequences of his code changes.
Mr. Smart adds one feature per software release. We project his work onto a state transition table with:
- 1 state-signal combination for the desired behavior. This cell is marked as "_feature",
- and 4 state-signal combinations for the behavior that Mr. Smart can understand, consider by his code changes, and cover with tests to detect and remove errors. These cells are marked as "_control".
I would remove some decorations to make the following visual effects more compelling.
An agile project always starts with the Agile Advertisement Phase.
Mr. Smart implements the first feature. He must not consider anything except the desired behavior.
Then Mr. Smart adds the second feature. He must consider the existing source code but this is a simple task.
The second feature is represented as a new signal and a new state. The state transition table is extended by one row and one column.
The existing code is represented as the old state and the old signal. There are two intersections for new and old. They are marked with "_control", because Mr. Smart is nearly perfect and can avoid problems in areas that are within his reach.
Mr. Smart spends twice as much resources on controlling existing behavior as on adding new features, but the complexity of this task is perfectly manageable.
The limits are reached in the next release.
Please note that the additional work volume grows from zero to the limits available for one feature.
Mr. Smart could be really smart and be able to manage not 4 but 10 state-signal combinations, but this work would demand time without agile results that could be shown to his manager, Mr. Strict.
I had made many measurements in real-life projects, and I would say that the ratio of 1 to 4 is not only suitable for my explanation but also quite realistic.
The Agile Advertisement Phase is a success. The agile approach has proven its advantages for Mr. Strict.
At the same time, his software developer, Mr. Smart, has reached his limits, but Mr. Strict does not know about it. "Agile" means "uncontrolled". You cannot detect such conditions unless you build a non-Agile and rather non-trivial measurement system.
The Agile Introduction Phase starts without anyone noticing this transformation.
The next feature adds some unknown and probably harmful behavior.
The fifth feature adds already 4 dark cells for 4 + 1 controlled cells, but the overall image is still optimistic.
The monsters that emerge in the darkness of uncontrolled parts are still small. Our agile project is still successful. Mr. Smart adds new features without delays, and Mr. Strict praises him for his perfect work.
There are significant delays between the time when problems are created and the time when they show on the surface.
Uncontrolled behavior may produce errors in some conditions, but it may be pretty harmless in other conditions. Many errors are perceived by users as the result of their own dumbness, which does not allow them to use this sophisticated software properly.
The agile processes are also very rigid in error reporting cycles. An error that was thrown into users could return to the developers after several months. Much more time is needed to get the feeling of the overall dynamics by multiplication of errors.
The next transition also happens unnoticed by anyone involved. The speed of growth of dark areas outruns the speed of adding controlled behavior.
This is the Agile Saturation Phase.
The sixth feature adds 6 uncontrolled cells for 1 + 4 controlled cells.
You can notice that the darkness has already covered the third part of the software behavior.
The proportion 1 to 1 is reached with the addition of the feature 9.
There are 9 cells with desired behavior, 30 cells with controlled behavior, and 42 cells of darkness.
What is even more alarming is the future trend.
Each new state-signal combination increases the controlled area by 5 cells. This is the limit of the available workload per added feature.
The darkness grows with the speed 2 * ( N - 3 ). The feature number 13 adds already 20 uncontrolled cells.
There are 13 + 46 = 59 controlled cells against 110 dark cells. The further growth makes the reliable strip over the darkness more and more thin.
Of course, this is an abstract model. You could not see something so simple in a real-life agile project.
This model does not consider the team dynamics. Mr. Strict would not look for errors in his processes — he would look for additional staff to cover the growing holes.
It is impossible to introduce direct quality measurements into an agile project. The dark areas are not software bugs, but only the areals of their habitation. Mr. Strict would only notice the indirect signs of problems after these bugs became numerous and mature.
However, the indirect measurements are also incorrect. Mr. Strict could create an Excel spreadsheet for the dynamics of incoming error reports, but an agile project reaches specific bottlenecks after some linear growth.
A test department cannot report more errors than it finds. The available staff is limited, and errors that are reported many times must be filtered out. Last but not least, the manager of the software testing department, Mr. Fox, wants to preserve his positive image. His goal is the steady production of bug reports, not a war against the software development department.
Mr. Smart also discovers a simple but very effective trick. Users cannot find errors that are hidden behind errors that prevent further workflow. The software that does not start at all contains only one potential bug report and unknown — usually quite large — amount of unreachable errors. These errors would be available to users only in future software releases.
There are no standard ways to measure an agile software project because each agile developer does not use standard methods as they are described in books but adds something that he mistakes for improvements.
Of course, there are always non-trivial ways to construct suitable metrics. If you find them, you would better keep your knowledge to yourself.
In my experience, managers are almost always shocked when you show them the results of your measurements. Even if you don't get fired for wasting your working time on useless activities, your managers will tell you that you must improve your measurements to produce more optimistic predictions.
I add here the simplest metric — the number of specific cells in the tables above — and represent it on a simple diagram.
This metric is a good model for the dynamics of a real-life agile project.
Let's say, the green line represents the implemented functionality. The yellow line represents the work volume. These are the paid work hours, and this line also represents the budget of this project. The red line represents internal problems.
The numbers are abstract, but the overall dynamics of these variables are pretty common. Even if you do not measure anything, you can detect the characteristic milestones by using indirect indicators.
The first 3 releases — the Agile Advertisement Phase — show the perfect software development described in books and prays of Agile Consultants.
The releases 4 and 5 — the Agile Introduction Phase — add some problems, but they are still small and manageable.
The release 6 starts the Agile Saturation Phase. Problems are already clearly visible, but they do not create any serious concerns — they have not overgrown the volume of work. Thus, they are not perceived as something dangerous.
The release 7 is the first milestone Tnass mentioned in my old post. It marks the border between the Happy Agile and the hard times when the available resources are spent solely to fight errors.
Please note, this is an agile project, and thus users are also playing this game. The time saved by software developers means time spent by software users. The Agile Work Creeping is an interesting subject, but I would not explain it any further.
The milestone Tnass is the best time to start paying attention to job offers from other companies.
I mention for my Russian-speaking readers that "nass" in Tnass means not the saturation with errors, but the end of the previous happy ignorance of their existence. They can guess the right word. This milestone marks the optimal duration for an agile job.
Of course, the further multiplication of problems cannot be infinite. The people who pay money can tolerate these dynamics only to some extent.
Let's say, we speak about a startup, and the investor, Mr. Rich, was happy with the release 3, because he had heard only positive news. He was still optimistic about the release 5, because he had awaited linear growth for all variables.
When the project reaches 20 — the release 7 —, Mr. Rich tries to fight "small problems". His attempts are chaotic and disturb the remaining productive work. He replaces the agile master and the product owner, increases the testing department, and fires the lead software developer who had tried to slow down the implementation of new features.
Mr. Rich is angry on the level 40, disappointed on 60, and frustrated on 80. When the project reaches 100, Mr. Rich withdraws further investments.
The release 13 marks the second milestone — Tnakh. The company management seeks other money sources. The project survives some time on the remaining financial resources. Then it collapses.
If you are smart, you are out of this game between releases 11 and 12. If you are an agile consultant, you must collect perfect recommendations and success stories before the release 6. The information about problems in the release 7 reaches you when you are spreading your agile experience in another company at a better position.
I can also give practical advice to people who think they could fight the growing darkness.
This is possible, but you must be cautious of the milestone Ti.
An agile project means an uncontrolled project. You can do anything by mixing sane parts with formal agile rituals. You add any suitable word before the word "agile", and you can sell your fraud to your management.
For instance, we can introduce measurements and call this "controlled agile". We can add formal requirements and call this "user driven agile". We can add formal diagrams and call this "visual agile".
Of course, you can look at the tables above, open the Shlaer-Mellor toolbox and reduce the overall complexity by making state machines smaller. This would be done by dividing the functional areas of the source code.
It is difficult to make a proper design without using suitable tools, but it is a realistic task as long as you know what you are doing.
It is common practice in the modern industry to hide some sane software development behind an agile facade. Most projects that are advertised as the success of agile (and are not frauds) have pretty interesting hidden parts that fight the destructive features of agile.
The milestone Ti marks not technical but political transformations.
If an agile project shows catastrophic dynamics, management blames the staff for not being properly agile. If a quasi-agile project is in good health, management praises not the people who are doing the real job, but the clever agile method that leads them to success.
You may be a perfect professional who has successfully cured the inborn agile diseases and who produces perfect results, but at some random time Ti some Mr. Idiot reaches your management and explains that your Agile is not enough agile.
Users are happy with the produced software. There are no major problems with quality or deadlines. Developers are productive and well-trained. However, a good project could be made much better, and the amount of features delivered with each release could be significantly increased when your management eliminates disturbing deviations from the perfect agile.
Yes, the suggestions of Mr. Idiot merge your small and tidy state transition tables into one dirty monster, get rid of documentation, and prevent attempts to control the overall software design.
The milestone Ti marks for you the time to move for the best. It is impossible to persuade your management that the ideas of Mr. Idiot are bad — you yourself have created the agile illusion.
And this illusion does not preserve anymore a safe place for you.
The Agile Tnakh Explained
This is a small addition to my previous post The State Transition Table of the Agile Age / 45 kB / 2024-01-13.
My intention was to share impressions, not knowledge. However, it would be good to explain my old advice to leave any agile software project between the milestones Tnass and Tnakh. (Теперь я знаю, что такое agile проект / / 2015-03-03)
Please note, I have no intention of explaining the Shlaer-Mellor method, or advertising it. I have slightly improved my text in the following parts.
It was wrong to use the hammer metaphor. Modern software developers usually do not build any material goods with their own hands, but they intensively play computer games. Hence, they mistake a hammer for silver bullets. I have replaced a hammer with a toolbox in my comparison.
A multi-tooling is also a sin in the modern software industry, because you cannot be described as an adept of the tool X, the method Y, or the framework Z. Thus you cannot be recognized as an ally or a foe. The agile experts simply do not know how to deal with you.
It is also annoying that you cannot participate in "My ruler is better than your hammer" arguments because you can suddenly take a measuring tape from your toolbox. This destroys all available strategies for professional discussions.
Grady Booch, one of the three giants of the object-oriented approach, once asked in a newsgroup to define the software architecture. There were many wise answers and brilliant theories, but then a user pointed out that in the Shlaer-Mellor method this would be simply the highest level of domain design.
This definition is a disaster. You cannot pose as an expensive consultant if your answers can be directly applied to real-life tasks.
The Shlaer-Mellor method can deal with uncertainty, but it can also deal with complexity. There are methods to test requirements and to replace base libraries. However, it does not contain the most desired feature — it cannot hide errors.
Thus, such a thing cannot survive in the modern software development industry because it is forbidden to exist. It is now unknown, and this is for the best.
I had also mentioned the agile refactoring. It may be perceived as a mystery that code improvements implemented by your colleagues break your logging, remove your tests, and backfire in unpredictable parts of your project.
This is a mystery only before you write down a balance for time, amount of features and quality. I would not describe these dependencies here.
My explanation of Tnakh starts with a banal but usually overlooked truth: A software source code is not a fixed piece of art but a ever-changing knowledge base. It stores information for both computers and software developers.
We start from an empty state transition table for an Agile Project and observe its growth.
I use the following model.
There is an agile software developer, Mr. Smart, who is only adding features. He is an experienced developer and — to some extent — can control the unintended consequences of his code changes.
Mr. Smart adds one feature per software release. We project his work onto a state transition table with:
- 1 state-signal combination for the desired behavior. This cell is marked as "_feature",
- and 4 state-signal combinations for the behavior that Mr. Smart can understand, consider by his code changes, and cover with tests to detect and remove errors. These cells are marked as "_control".
============================================
... | STATE_OLD_1 | STATE_OLD_2 | STATE_NEW |
============================================
... ...
//-----------------++- --+------------+-
/* SIGNAL_OLD_1 */ ,{ , _control |
//-----------------++- --+------------+-
/* SIGNAL_OLD_2 */ ,{ , _control |
//-----------------++- -+-------------+-------------+------------+-
/* SIGNAL_NEW */ ,{ ... , _control , _control , _feature |
//-----------------++- -+-------------+-------------+------------+-
I would remove some decorations to make the following visual effects more compelling.
An agile project always starts with the Agile Advertisement Phase.
Mr. Smart implements the first feature. He must not consider anything except the desired behavior.
//===========================|
// || STATE_01 |
//===========================|
/* SIGNAL_01 */ { _feature }
Then Mr. Smart adds the second feature. He must consider the existing source code but this is a simple task.
The second feature is represented as a new signal and a new state. The state transition table is extended by one row and one column.
//======================================|
// || STATE_01 | STATE_02 |
//======================================|
/* SIGNAL_01 */ { _feature , _control }
/* SIGNAL_02 */ ,{ _control , _feature }
The existing code is represented as the old state and the old signal. There are two intersections for new and old. They are marked with "_control", because Mr. Smart is nearly perfect and can avoid problems in areas that are within his reach.
Mr. Smart spends twice as much resources on controlling existing behavior as on adding new features, but the complexity of this task is perfectly manageable.
The limits are reached in the next release.
//=================================================|
// || STATE_01 | STATE_02 | STATE_03 |
//=================================================|
/* SIGNAL_01 */ { _feature , _control , _control }
/* SIGNAL_02 */ ,{ _control , _feature , _control }
/* SIGNAL_03 */ ,{ _control , _control , _feature }
Please note that the additional work volume grows from zero to the limits available for one feature.
Mr. Smart could be really smart and be able to manage not 4 but 10 state-signal combinations, but this work would demand time without agile results that could be shown to his manager, Mr. Strict.
I had made many measurements in real-life projects, and I would say that the ratio of 1 to 4 is not only suitable for my explanation but also quite realistic.
The Agile Advertisement Phase is a success. The agile approach has proven its advantages for Mr. Strict.
At the same time, his software developer, Mr. Smart, has reached his limits, but Mr. Strict does not know about it. "Agile" means "uncontrolled". You cannot detect such conditions unless you build a non-Agile and rather non-trivial measurement system.
The Agile Introduction Phase starts without anyone noticing this transformation.
The next feature adds some unknown and probably harmful behavior.
//============================================================|
// || STATE_01 | STATE_02 | STATE_03 | STATE_04 |
//============================================================|
/* SIGNAL_01 */ { _feature , _control , _control , _pokhuy }
/* SIGNAL_02 */ ,{ _control , _feature , _control , _control }
/* SIGNAL_03 */ ,{ _control , _control , _feature , _control }
/* SIGNAL_04 */ ,{ _pokhuy , _control , _control , _feature }
The fifth feature adds already 4 dark cells for 4 + 1 controlled cells, but the overall image is still optimistic.
//=======================================================================|
// || STATE_01 | STATE_02 | STATE_03 | STATE_04 | STATE_05 |
//=======================================================================|
/* SIGNAL_01 */ { _feature , _control , _control , _pokhuy , _pokhuy
/* SIGNAL_02 */ ,{ _control , _feature , _control , _control , _pokhuy
/* SIGNAL_03 */ ,{ _control , _control , _feature , _control , _control
/* SIGNAL_04 */ ,{ _pokhuy , _control , _control , _feature , _control
/* SIGNAL_05 */ ,{ _pokhuy , _pokhuy , _control , _control , _feature
The monsters that emerge in the darkness of uncontrolled parts are still small. Our agile project is still successful. Mr. Smart adds new features without delays, and Mr. Strict praises him for his perfect work.
There are significant delays between the time when problems are created and the time when they show on the surface.
Uncontrolled behavior may produce errors in some conditions, but it may be pretty harmless in other conditions. Many errors are perceived by users as the result of their own dumbness, which does not allow them to use this sophisticated software properly.
The agile processes are also very rigid in error reporting cycles. An error that was thrown into users could return to the developers after several months. Much more time is needed to get the feeling of the overall dynamics by multiplication of errors.
The next transition also happens unnoticed by anyone involved. The speed of growth of dark areas outruns the speed of adding controlled behavior.
This is the Agile Saturation Phase.
The sixth feature adds 6 uncontrolled cells for 1 + 4 controlled cells.
//==================================================================================|
// || STATE_01 | STATE_02 | STATE_03 | STATE_04 | STATE_05 | STATE_06 |
//==================================================================================|
/* SIGNAL_01 */ { _feature , _control , _control , _pokhuy , _pokhuy , _pokhuy }
/* SIGNAL_02 */ ,{ _control , _feature , _control , _control , _pokhuy , _pokhuy }
/* SIGNAL_03 */ ,{ _control , _control , _feature , _control , _control , _pokhuy }
/* SIGNAL_04 */ ,{ _pokhuy , _control , _control , _feature , _control , _control }
/* SIGNAL_05 */ ,{ _pokhuy , _pokhuy , _control , _control , _feature , _control }
/* SIGNAL_06 */ ,{ _pokhuy , _pokhuy , _pokhuy , _control , _control , _feature }
You can notice that the darkness has already covered the third part of the software behavior.
The proportion 1 to 1 is reached with the addition of the feature 9.
//===================================================================================================================|
// || STATE_01 | STATE_02 | STATE_03 | STATE_04 | STATE_05 | STATE_06 | STATE_07 | STATE_08 | STATE_09 |
//===================================================================================================================|
/* SIGNAL_01 */ { _feature , _control , _control , _pokhuy , _pokhuy , _pokhuy , _pokhuy , _pokhuy , _pokhuy }
/* SIGNAL_02 */ ,{ _control , _feature , _control , _control , _pokhuy , _pokhuy , _pokhuy , _pokhuy , _pokhuy }
/* SIGNAL_03 */ ,{ _control , _control , _feature , _control , _control , _pokhuy , _pokhuy , _pokhuy , _pokhuy }
/* SIGNAL_04 */ ,{ _pokhuy , _control , _control , _feature , _control , _control , _pokhuy , _pokhuy , _pokhuy }
/* SIGNAL_05 */ ,{ _pokhuy , _pokhuy , _control , _control , _feature , _control , _control , _pokhuy , _pokhuy }
/* SIGNAL_06 */ ,{ _pokhuy , _pokhuy , _pokhuy , _control , _control , _feature , _control , _control , _pokhuy }
/* SIGNAL_07 */ ,{ _pokhuy , _pokhuy , _pokhuy , _pokhuy , _control , _control , _feature , _control , _control }
/* SIGNAL_08 */ ,{ _pokhuy , _pokhuy , _pokhuy , _pokhuy , _pokhuy , _control , _control , _feature , _control }
/* SIGNAL_09 */ ,{ _pokhuy , _pokhuy , _pokhuy , _pokhuy , _pokhuy , _pokhuy , _control , _control , _feature }
There are 9 cells with desired behavior, 30 cells with controlled behavior, and 42 cells of darkness.
What is even more alarming is the future trend.
Each new state-signal combination increases the controlled area by 5 cells. This is the limit of the available workload per added feature.
The darkness grows with the speed 2 * ( N - 3 ). The feature number 13 adds already 20 uncontrolled cells.
//===============================================================================================================================================================|
// || STATE_01 | STATE_02 | STATE_03 | STATE_04 | STATE_05 | STATE_06 | STATE_07 | STATE_08 | STATE_09 | STATE_10 | STATE_11 | STATE_12 | STATE_13 |
//===============================================================================================================================================================|
/* SIGNAL_01 */ { _feature , _control , _control , _pokhuy , _pokhuy , _pokhuy , _pokhuy , _pokhuy , _pokhuy , _pokhuy , _pokhuy , _pokhuy , _pokhuy }
/* SIGNAL_02 */ ,{ _control , _feature , _control , _control , _pokhuy , _pokhuy , _pokhuy , _pokhuy , _pokhuy , _pokhuy , _pokhuy , _pokhuy , _pokhuy }
/* SIGNAL_03 */ ,{ _control , _control , _feature , _control , _control , _pokhuy , _pokhuy , _pokhuy , _pokhuy , _pokhuy , _pokhuy , _pokhuy , _pokhuy }
/* SIGNAL_04 */ ,{ _pokhuy , _control , _control , _feature , _control , _control , _pokhuy , _pokhuy , _pokhuy , _pokhuy , _pokhuy , _pokhuy , _pokhuy }
/* SIGNAL_05 */ ,{ _pokhuy , _pokhuy , _control , _control , _feature , _control , _control , _pokhuy , _pokhuy , _pokhuy , _pokhuy , _pokhuy , _pokhuy }
/* SIGNAL_06 */ ,{ _pokhuy , _pokhuy , _pokhuy , _control , _control , _feature , _control , _control , _pokhuy , _pokhuy , _pokhuy , _pokhuy , _pokhuy }
/* SIGNAL_07 */ ,{ _pokhuy , _pokhuy , _pokhuy , _pokhuy , _control , _control , _feature , _control , _control , _pokhuy , _pokhuy , _pokhuy , _pokhuy }
/* SIGNAL_08 */ ,{ _pokhuy , _pokhuy , _pokhuy , _pokhuy , _pokhuy , _control , _control , _feature , _control , _control , _pokhuy , _pokhuy , _pokhuy }
/* SIGNAL_09 */ ,{ _pokhuy , _pokhuy , _pokhuy , _pokhuy , _pokhuy , _pokhuy , _control , _control , _feature , _control , _control , _pokhuy , _pokhuy }
/* SIGNAL_10 */ ,{ _pokhuy , _pokhuy , _pokhuy , _pokhuy , _pokhuy , _pokhuy , _pokhuy , _control , _control , _feature , _control , _control , _pokhuy }
/* SIGNAL_11 */ ,{ _pokhuy , _pokhuy , _pokhuy , _pokhuy , _pokhuy , _pokhuy , _pokhuy , _pokhuy , _control , _control , _feature , _control , _control }
/* SIGNAL_12 */ ,{ _pokhuy , _pokhuy , _pokhuy , _pokhuy , _pokhuy , _pokhuy , _pokhuy , _pokhuy , _pokhuy , _control , _control , _feature , _control }
/* SIGNAL_13 */ ,{ _pokhuy , _pokhuy , _pokhuy , _pokhuy , _pokhuy , _pokhuy , _pokhuy , _pokhuy , _pokhuy , _pokhuy , _control , _control , _feature }
There are 13 + 46 = 59 controlled cells against 110 dark cells. The further growth makes the reliable strip over the darkness more and more thin.
Of course, this is an abstract model. You could not see something so simple in a real-life agile project.
This model does not consider the team dynamics. Mr. Strict would not look for errors in his processes — he would look for additional staff to cover the growing holes.
It is impossible to introduce direct quality measurements into an agile project. The dark areas are not software bugs, but only the areals of their habitation. Mr. Strict would only notice the indirect signs of problems after these bugs became numerous and mature.
However, the indirect measurements are also incorrect. Mr. Strict could create an Excel spreadsheet for the dynamics of incoming error reports, but an agile project reaches specific bottlenecks after some linear growth.
A test department cannot report more errors than it finds. The available staff is limited, and errors that are reported many times must be filtered out. Last but not least, the manager of the software testing department, Mr. Fox, wants to preserve his positive image. His goal is the steady production of bug reports, not a war against the software development department.
Mr. Smart also discovers a simple but very effective trick. Users cannot find errors that are hidden behind errors that prevent further workflow. The software that does not start at all contains only one potential bug report and unknown — usually quite large — amount of unreachable errors. These errors would be available to users only in future software releases.
There are no standard ways to measure an agile software project because each agile developer does not use standard methods as they are described in books but adds something that he mistakes for improvements.
Of course, there are always non-trivial ways to construct suitable metrics. If you find them, you would better keep your knowledge to yourself.
In my experience, managers are almost always shocked when you show them the results of your measurements. Even if you don't get fired for wasting your working time on useless activities, your managers will tell you that you must improve your measurements to produce more optimistic predictions.
I add here the simplest metric — the number of specific cells in the tables above — and represent it on a simple diagram.
This metric is a good model for the dynamics of a real-life agile project.
Let's say, the green line represents the implemented functionality. The yellow line represents the work volume. These are the paid work hours, and this line also represents the budget of this project. The red line represents internal problems.
The numbers are abstract, but the overall dynamics of these variables are pretty common. Even if you do not measure anything, you can detect the characteristic milestones by using indirect indicators.
The first 3 releases — the Agile Advertisement Phase — show the perfect software development described in books and prays of Agile Consultants.
The releases 4 and 5 — the Agile Introduction Phase — add some problems, but they are still small and manageable.
The release 6 starts the Agile Saturation Phase. Problems are already clearly visible, but they do not create any serious concerns — they have not overgrown the volume of work. Thus, they are not perceived as something dangerous.
The release 7 is the first milestone Tnass mentioned in my old post. It marks the border between the Happy Agile and the hard times when the available resources are spent solely to fight errors.
Please note, this is an agile project, and thus users are also playing this game. The time saved by software developers means time spent by software users. The Agile Work Creeping is an interesting subject, but I would not explain it any further.
The milestone Tnass is the best time to start paying attention to job offers from other companies.
I mention for my Russian-speaking readers that "nass" in Tnass means not the saturation with errors, but the end of the previous happy ignorance of their existence. They can guess the right word. This milestone marks the optimal duration for an agile job.
Of course, the further multiplication of problems cannot be infinite. The people who pay money can tolerate these dynamics only to some extent.
Let's say, we speak about a startup, and the investor, Mr. Rich, was happy with the release 3, because he had heard only positive news. He was still optimistic about the release 5, because he had awaited linear growth for all variables.
When the project reaches 20 — the release 7 —, Mr. Rich tries to fight "small problems". His attempts are chaotic and disturb the remaining productive work. He replaces the agile master and the product owner, increases the testing department, and fires the lead software developer who had tried to slow down the implementation of new features.
Mr. Rich is angry on the level 40, disappointed on 60, and frustrated on 80. When the project reaches 100, Mr. Rich withdraws further investments.
The release 13 marks the second milestone — Tnakh. The company management seeks other money sources. The project survives some time on the remaining financial resources. Then it collapses.
If you are smart, you are out of this game between releases 11 and 12. If you are an agile consultant, you must collect perfect recommendations and success stories before the release 6. The information about problems in the release 7 reaches you when you are spreading your agile experience in another company at a better position.
I can also give practical advice to people who think they could fight the growing darkness.
This is possible, but you must be cautious of the milestone Ti.
An agile project means an uncontrolled project. You can do anything by mixing sane parts with formal agile rituals. You add any suitable word before the word "agile", and you can sell your fraud to your management.
For instance, we can introduce measurements and call this "controlled agile". We can add formal requirements and call this "user driven agile". We can add formal diagrams and call this "visual agile".
Of course, you can look at the tables above, open the Shlaer-Mellor toolbox and reduce the overall complexity by making state machines smaller. This would be done by dividing the functional areas of the source code.
It is difficult to make a proper design without using suitable tools, but it is a realistic task as long as you know what you are doing.
It is common practice in the modern industry to hide some sane software development behind an agile facade. Most projects that are advertised as the success of agile (and are not frauds) have pretty interesting hidden parts that fight the destructive features of agile.
The milestone Ti marks not technical but political transformations.
If an agile project shows catastrophic dynamics, management blames the staff for not being properly agile. If a quasi-agile project is in good health, management praises not the people who are doing the real job, but the clever agile method that leads them to success.
You may be a perfect professional who has successfully cured the inborn agile diseases and who produces perfect results, but at some random time Ti some Mr. Idiot reaches your management and explains that your Agile is not enough agile.
Users are happy with the produced software. There are no major problems with quality or deadlines. Developers are productive and well-trained. However, a good project could be made much better, and the amount of features delivered with each release could be significantly increased when your management eliminates disturbing deviations from the perfect agile.
Yes, the suggestions of Mr. Idiot merge your small and tidy state transition tables into one dirty monster, get rid of documentation, and prevent attempts to control the overall software design.
The milestone Ti marks for you the time to move for the best. It is impossible to persuade your management that the ideas of Mr. Idiot are bad — you yourself have created the agile illusion.
And this illusion does not preserve anymore a safe place for you.