May 1, 2011 at 15:28Pitfalls Scrum - mottled frames
I want to share practical experience in implementing flexible methodologies on high and medium complexity web development projects and to warn against insidious risks.
In most simple Internet projects, the “simplification” of classic development processes worked well, flexibility helped, but in relatively large and complex “high-voltage sparks” with a partial lethal outcome were observed.
Go.
There are flexible development methodologies (Agile), such as Scrum, simple and comprehensible in a couple of days. And there are "hard", weighty, requiring many months of immersion, such as RUP.
Flexible methodologies convince us to “believe” that due to the fact that the requirements are constantly changing, we can refuse to hell with many years of experience in developing software absorbed by classical methodologies, the same “waterfall”, to decisively simplify everything and throw ourselves into the arms of the “communist” freedom, honesty and equality.
Why be afraid? Crazy bearded specialists talk about processes, artifacts, Requirements Traceability Matrix - and we are in a shirt, barefoot, just ... we will program any Internet project for 3 sprints! Hurray, comrades, to victory.
So, the “simplification” offered by flexible methodologies is very conditional and insidious. “Relaxed” on the one hand, you have to stretch yourself on the other hand.
The worst thing that I had to contemplate in the field of software development was the stupid implementation of simple management frameworks like Scrum, with almost complete disregard for the engineering practices of extreme programming (XP) necessary in such cases, leading to catastrophic consequences both for the quality of projects being implemented and their deadlines fulfillment.
Projects quickly turned into a garbage can and immediately went to a nursing home to die without ever starting a full life.
It is the tough XP practices developed by blood and sweat, the practices of survival in chaos that can only balance the situation and launch a successful development process leading to the goal!
In the light of the above “horrors,” I want to talk about the risks that lurk in the flexible methodologies of software development using the example of Scrum and the ways to reduce them that I know of.
Let's start with recruiting the team in the real world of harsh reality.
Consider typical roles in a PHP / MySQL web development project.
In addition to general technical education and knowledge of the basics of applied mathematics, an employee needs to understand in detail the technology / programming language, and not to climb on any occasion in google.
Unfortunately, we do not have specialized higher education institutions preparing web developers.
Mostly self-taught, not having the necessary minimum. Sometimes these are former typesetters / testers who want to increase salaries - colleagues often do not understand why it is necessary to add indexes to SQL tables, and there is nothing to say about relational algebra, OOP and theory of algorithms. At the same time, people “confidently” write “object-oriented” g ... code, sometimes associated with the processing of financial transactions, and quickly :-)
There is only one way out - to teach on our own, attach to a knowledgeable theory and hardened in projects developer, send for Zend certification.
Good, experienced programmers who often know other, “complex” programming languages such as java, C # and in passing learn PHP, sometimes of course come across, but rarely. You need to have these in a team, I’ll tell you why.
To control the quality of work of "mostly inexperienced" programmers, I strongly recommend that you audit the code by an experienced, expensive programmer who is well versed in security issues and use auxiliary tools to partially check the code style.
If the code is not checked, then object-oriented distortions will arise and begin to multiply, and the code that is not born will become rotten.
He took in quotation marks. In general, a programmer should read the SQL standard at least once in his life and confidently design and work with a DBMS, but, unfortunately, this rarely happens. As a rule, a developer may well know one DBMS, but swim a lot in another DBMS.
Therefore, sometimes they emphasize the special role of a SQL specialist, who can be an analyst, an architect, or a system administrator - if only he understands the relational theory and specific DBMSs.
There is no university for layout designers either. Self-taught. The declarative theory of “typesetting” is much simpler than programming, but requires knowledge of a large number of features and subtleties, which is why it stood out in a special craft.
To control the quality of work, you can, in principle, partially use automated tools for checking compliance with web standards (w3c) and check visually in different browsers.
A typesetter can, over time and after reading several weighty books on software development theory and hard practice, become a programmer, but this is rare.
A special role for "especially smart and thoughtful." It requires an analytical mindset, attention to detail. Good analysts are obtained from physicists and mathematicians, but other specialties are also found. If the analyst learns UML or any other design methodology, then a super-analyst will be able to express the requirements in a language that the developer understands.
A very responsible role, requiring in-depth knowledge of design patterns, serious development experience and, importantly, support for software systems. Unfortunately, architects become only empirically, failing more than one project. And it is sometimes possible to determine that problems with embedded architecture in a system are not immediately possible, but after a certain time, when it is too late to change anything.
Some people think that the tester does the dumb and thankless job in projects. In fact, it is from ignorance. A good tester (there are no specialized universities) engaged in self-education can draw up a high-quality testing plan and write automated tests, and a bad one will poke languidly and aimlessly on the pages of the site, leaving bugs alive.
There are courses from some vendors, such as RedHat, that train system administrators, but without in-depth practice, a real system administrator is unlikely to succeed. And you can check the quality of work, as a rule, only after a serious accident when restoring data from backup.
And now we apply the practical knowledge gained about the roles in the team to the techniques declared in Scrum / XP and try to get a working solution.
As you can see, the roles are all very different, requiring deep specific knowledge and experience. In practice, employees only partially mutually enrich each other with knowledge from different fields, but they don’t smell of the cross-functionality Scrum tells us about. With a stretch, we can talk about interchangeability only among representatives of the same role, but even there people with different qualifications and experience do not always work.
If the specialist is inexperienced, it is necessary to follow him more experienced. I do not recommend planting together (XP practice) two inexperienced people - they will make it 2 times worse.
It turns out that the representatives of each role, in a good way, should be monitored by the "senior mentor". This can be a functional manager (department head) or a senior specialist (lead developer / analyst / sysadmin) who has the necessary competence and is directly responsible for the quality of the work being monitored.
We understand that if we do not ensure the proper level of quality control of the work of specialized employees, we will get a code that is bad and expensive to support, surface analytics, stupid architecture and hole testing.
So we got “half-paired” from pair programming, with the presence of specialized responsible specialists, and from a cross-functional team - only a ghostly exchange of experience (who decides to let the layout designer correct the billing code).
So, we considered some practical risks. In a future post, we will talk about management risks - leadership, gouging in teams, collective irresponsibility, pseudo-progress, and how to deal with it effectively.
In most simple Internet projects, the “simplification” of classic development processes worked well, flexibility helped, but in relatively large and complex “high-voltage sparks” with a partial lethal outcome were observed.
Go.
Flexible and “tough”
There are flexible development methodologies (Agile), such as Scrum, simple and comprehensible in a couple of days. And there are "hard", weighty, requiring many months of immersion, such as RUP.
Flexible methodologies convince us to “believe” that due to the fact that the requirements are constantly changing, we can refuse to hell with many years of experience in developing software absorbed by classical methodologies, the same “waterfall”, to decisively simplify everything and throw ourselves into the arms of the “communist” freedom, honesty and equality.
Why be afraid? Crazy bearded specialists talk about processes, artifacts, Requirements Traceability Matrix - and we are in a shirt, barefoot, just ... we will program any Internet project for 3 sprints! Hurray, comrades, to victory.
So, the “simplification” offered by flexible methodologies is very conditional and insidious. “Relaxed” on the one hand, you have to stretch yourself on the other hand.
We use Agile, but have you forgotten XP practices?
The worst thing that I had to contemplate in the field of software development was the stupid implementation of simple management frameworks like Scrum, with almost complete disregard for the engineering practices of extreme programming (XP) necessary in such cases, leading to catastrophic consequences both for the quality of projects being implemented and their deadlines fulfillment.
Projects quickly turned into a garbage can and immediately went to a nursing home to die without ever starting a full life.
It is the tough XP practices developed by blood and sweat, the practices of survival in chaos that can only balance the situation and launch a successful development process leading to the goal!
In the light of the above “horrors,” I want to talk about the risks that lurk in the flexible methodologies of software development using the example of Scrum and the ways to reduce them that I know of.
Let's start with recruiting the team in the real world of harsh reality.
HR risks
Consider typical roles in a PHP / MySQL web development project.
PHP programmer
In addition to general technical education and knowledge of the basics of applied mathematics, an employee needs to understand in detail the technology / programming language, and not to climb on any occasion in google.
Unfortunately, we do not have specialized higher education institutions preparing web developers.
Mostly self-taught, not having the necessary minimum. Sometimes these are former typesetters / testers who want to increase salaries - colleagues often do not understand why it is necessary to add indexes to SQL tables, and there is nothing to say about relational algebra, OOP and theory of algorithms. At the same time, people “confidently” write “object-oriented” g ... code, sometimes associated with the processing of financial transactions, and quickly :-)
There is only one way out - to teach on our own, attach to a knowledgeable theory and hardened in projects developer, send for Zend certification.
Good, experienced programmers who often know other, “complex” programming languages such as java, C # and in passing learn PHP, sometimes of course come across, but rarely. You need to have these in a team, I’ll tell you why.
To control the quality of work of "mostly inexperienced" programmers, I strongly recommend that you audit the code by an experienced, expensive programmer who is well versed in security issues and use auxiliary tools to partially check the code style.
If the code is not checked, then object-oriented distortions will arise and begin to multiply, and the code that is not born will become rotten.
SQL Specialist
He took in quotation marks. In general, a programmer should read the SQL standard at least once in his life and confidently design and work with a DBMS, but, unfortunately, this rarely happens. As a rule, a developer may well know one DBMS, but swim a lot in another DBMS.
Therefore, sometimes they emphasize the special role of a SQL specialist, who can be an analyst, an architect, or a system administrator - if only he understands the relational theory and specific DBMSs.
Typesetter
There is no university for layout designers either. Self-taught. The declarative theory of “typesetting” is much simpler than programming, but requires knowledge of a large number of features and subtleties, which is why it stood out in a special craft.
To control the quality of work, you can, in principle, partially use automated tools for checking compliance with web standards (w3c) and check visually in different browsers.
A typesetter can, over time and after reading several weighty books on software development theory and hard practice, become a programmer, but this is rare.
Analyst
A special role for "especially smart and thoughtful." It requires an analytical mindset, attention to detail. Good analysts are obtained from physicists and mathematicians, but other specialties are also found. If the analyst learns UML or any other design methodology, then a super-analyst will be able to express the requirements in a language that the developer understands.
Architect
A very responsible role, requiring in-depth knowledge of design patterns, serious development experience and, importantly, support for software systems. Unfortunately, architects become only empirically, failing more than one project. And it is sometimes possible to determine that problems with embedded architecture in a system are not immediately possible, but after a certain time, when it is too late to change anything.
Tester
Some people think that the tester does the dumb and thankless job in projects. In fact, it is from ignorance. A good tester (there are no specialized universities) engaged in self-education can draw up a high-quality testing plan and write automated tests, and a bad one will poke languidly and aimlessly on the pages of the site, leaving bugs alive.
Sysadmin
There are courses from some vendors, such as RedHat, that train system administrators, but without in-depth practice, a real system administrator is unlikely to succeed. And you can check the quality of work, as a rule, only after a serious accident when restoring data from backup.
And now we apply the practical knowledge gained about the roles in the team to the techniques declared in Scrum / XP and try to get a working solution.
Cross-functionality in project teams is a myth
As you can see, the roles are all very different, requiring deep specific knowledge and experience. In practice, employees only partially mutually enrich each other with knowledge from different fields, but they don’t smell of the cross-functionality Scrum tells us about. With a stretch, we can talk about interchangeability only among representatives of the same role, but even there people with different qualifications and experience do not always work.
Quality control - hierarchy of responsibility
If the specialist is inexperienced, it is necessary to follow him more experienced. I do not recommend planting together (XP practice) two inexperienced people - they will make it 2 times worse.
It turns out that the representatives of each role, in a good way, should be monitored by the "senior mentor". This can be a functional manager (department head) or a senior specialist (lead developer / analyst / sysadmin) who has the necessary competence and is directly responsible for the quality of the work being monitored.
We understand that if we do not ensure the proper level of quality control of the work of specialized employees, we will get a code that is bad and expensive to support, surface analytics, stupid architecture and hole testing.
So we got “half-paired” from pair programming, with the presence of specialized responsible specialists, and from a cross-functional team - only a ghostly exchange of experience (who decides to let the layout designer correct the billing code).
So, we considered some practical risks. In a future post, we will talk about management risks - leadership, gouging in teams, collective irresponsibility, pseudo-progress, and how to deal with it effectively.