
When I read: “Agile is much more than just Scrum” - in the description of the Certified Agile Professional certification company ScrumTrek, then the first thing I thought about was: why ScrumTrek, then you really had to call yourself AgileTrek? After completing this training, I returned to this statement with a more serious attitude. So what did I get from the training? Records, handouts and Certified ICAgile Professional? But what about understanding what Agile is? What is the concept of Agile-approach? What is Agile mindset?
In this post, I share my impressions about the training. This is not so much a retelling of the content of the training as a subjective assessment of the benefits of the knowledge gained in it. Hope this helps determine if you need this training.
')
Agile history
I remember well the story of Agile, which the trainer presented in the form of progressive maturation of the entire software development industry.
Code-and-Fix allowed the industry to start writing code relatively cheaply without any plans, documentation and special requirements for the qualifications of developers.
He was replaced in the 1970s by the Waterfall model, which reduced risks, increased the transparency of software development, and also eliminated the problem of high software maintenance costs while maintaining low requirements for the qualifications of developers. The model began to be used everywhere, which quickly exposed its problems. Waterfall works well only in those cases when everything is known in advance: which product needs to be developed, which implementation technologies need to be used - and there are no changes along the way.

The first attempts to rectify the situation are connected with the emergence of iterative approaches in the 1990s. On the one hand, this contributes to cheaper computers, when machine time ceases to be an objective limitation, which allows for repeated experiments to increase the functionality of the product. On the other hand, new IT technologies are increasing competition, so businesses have to quickly apply them in business. Who introduced a new technology before the rest, and won both customers and the market. From this moment begins the active development of flexible development processes, which aim to provide businesses with a quick supply of functionality. In essence, there is a rollback to the “quick” Code-and-Fix method, but it is complemented by planning and eliminating risks.

By the way, it seems to me that to this day the majority of corporate developers are not using Scrum at all, as they think, namely, an iterative waterfall. Look at the diagram below, does it somehow work for you?
Or just the same as in Scrum?
In 1992, Crystal appeared, which for the first time focuses on frequent delivery of working code to end users. Then, in 1994, DSM (Dynamic Systems Development Method) was introduced, which proclaimed a focus on business needs and the minimum quality level of software (approximately the same year, the term Refactoring appeared). Finally, in 1996, the Scrum Framework was introduced, which became the de facto standard for managing agile development. In the same year, paired programming begins for the first time. And in 1999, XP appeared, which brought the concept of user stories (User Story), release planning and continuous integration (Continuous Integration). The result of all these private initiatives was the
Agile-manifesto of software development , developed in 2001, which enshrines the values and principles proven by the 10th anniversary, which make it possible to quickly deliver the functionality to the business.
Further development of Agile is associated with attempts to eliminate all possible losses (downtime) in the software development process, thereby further increasing the speed of delivery of functionality. In 2003, Lean Software Development appeared as an adaptation of Toyota's lean manufacturing concept to the software development industry. In 2006, the movement continues due to the emergence of Kanban Software Development, which presents a ready-made algorithm for eliminating losses in the stream of supplying value (functionality) to a business. Also in 2011, in response to the explosive growth of SAAS (software as a service), the DevOps concept emerges, which integrates development and maintenance to eliminate losses at their interface.

Total production (development) has ceased to be a narrow link, learning how to quickly meet the needs of the business. Nevertheless, the development of Agile continues. Firstly, in the field of Agile scaling in large enterprises (SAFe). Secondly, the huge number of failed investment projects raises the question in the field of product development: how to develop the most demanded product as cheaply as possible? In 2009, the answer to this restriction is Lean Startup.
What do you think will happen next? It seems to me that in the near future, the change in the education system is inevitable, since the processes are not executed by themselves, but by people.
Values and principles of Agile
Together with the participants, the trainer consistently and deeply examines each value and each principle of the Agile-manifest of software development. I admit that before the training I sincerely believed that I understand the values and principles perfectly. It turned out that this is not entirely true.
For example, the second value of Agile: "A working product is more important than comprehensive documentation." At one time it was a declaration of the negation of the waterfall model, in which the understanding of progress is largely based on the project documentation. But in version 2 of the Agile-manifest, the wording changed: “Business value is more important than a working product” (
Agile Manifesto 2.1 - “MoreAgile Manifesto” ). This is an example of the evolution of Agile values associated with the appearance of Lean Startup: too many working products turned out to be useless.
Scrum and Kanban
A significant part of the training is the review of the Scrum Framework and Kanban. Retelling this part of the training is beyond the scope of this note. I will only note that every nontrivial moment a coach helps to feel at the tips of his own fingers through a team game. But this is worth talking about in more detail.
Agile Games
All games were easy to learn and fun to use. During one game on the second day of training, one of the participants exclaimed: “And what did we do before? Here it is! ”Below I will talk about what we have learned in games.
Penny / Multitasking games live (on ourselves) and convincingly (with a regular stopwatch) demonstrated the need to take small portions into the work and not to perform several tasks at the same time. We saw how this eliminates losses due to downtime in a strictly sequential workflow (waterfall), losses due to accumulation of unfinished work (mouth full chews longer) and context switches (in a waterfall model, an employee’s work on several projects is also most likely) .

Planning pocker is such a simple technique by the assessment team that even within a short game it allows you to experience your merits. For example, all members of my gaming team agreed in the end that most of the time we didn’t spend at all on estimating the labor costs of a particular job, but on discussing works that we initially understood differently. In other words, the main benefit is not at all in the number of assessment, but in the same understanding of the work. On the other hand, being limited in time, we avoided disputes and discussions if our assessments converged immediately. Simple things, but how difficult it is to follow them in your work! Is not it?
The gaming staging of the Daily Standup Meeting brought us back to the discussion of Agile values. For example, a Scrum Master should not be a manager for a development team or behave accordingly, that is, distribute tasks, turn on emotions and oppose themselves to a group, thereby turning the meeting into a dull reporting meeting of team members on themselves.
Ball Point game showed how team dynamics work. As before, the experimental rabbits are ourselves (this means that you feel everything, and not just watch), and the digital results are quite convincing. What do we understand?
- Larger teams evolve more slowly, as the number of team members increases, communication becomes more complex.
- The greatest performance gain comes from a change in the principle of work, not calls: “Let's push! Stay calm and carry on!"
- It is more important to launch suggestions for improvement in an experiment more quickly than for a long time to look for an ideal solution.
Conclusion
And How? Now you understand what Agile is? If not, I recommend to visit the training. If yes, then I recommend bringing your entire team to the training, especially if you just start Agile in it.