Tuning the mind to agile frequency

For a long time and successfully, we help a variety of specialists to share their own knowledge in all possible areas, in the first place - management and management, which is becoming more and more relevant over time. The same goes for development, design and architecture.

Gradually, we collected key design techniques from basic methodologies and architectural standards and translated into human language. We connected our own experience and working solutions of our many customers, and as a result received a number of training sessions. Moreover, their format is practical, therefore, participants will come to most decisions on their own, which gives a tremendous conversion of skills to application in production.

For whom :

• Engineers: architects.
• Technical managers: team leaders and technical leaders.
• Managers: project managers and product managers

Experience at the start :

• Preferred experience in industrial development of 2 years.
• Design skills are required within the scope of the Agile Mindset in System Design course, especially for participation in the advanced training: Agile Mindset in Solution Design.

Dividing all the available experience into two large components of one whole, the picture is as follows

Agile Mindset in system design . Requirements, architecture, process

Remember, when was the last time you had to prove the strengths of an architectural solution with all your might, but never achieve success? Or, when you triumphantly implemented at first glance an absolutely correct solution, which later fails completely. Such moments raise a number of fair questions: “What have I done wrong? How to correctly and logically present your point of view? What is the difference and where is the line between conscious and informed architectural solutions and amateurish approach? ”

This training is about common sense - about the validity of engineering solutions in the face of uncertainty. We will analyze what engineering decisions depend on and learn how to clearly substantiate them. Let’s think about what should be the expectations from architecture and whether you have it in your project at all. We will learn to objectively solve engineering conflicts, and you will forever forget the word "holivar". Take a completely new look at design patterns and now squeeze the most out of them. We will understand how to efficiently build documentation for the system so that it really starts working, rather than being “write-only”. We will learn how to focus in our decisions and finally find out where to start - with the database schema or “concurrency design”. And one of the most important things in training is learning to not do too much work.




Agile Mindset in designing solutions . Process, team, culture, business

Look at your production software delivery system and solution architecture. Can you clearly substantiate the choice of process and architectural approaches through business metrics and company strategy? How teams are structured, how communications are built and the architectural process is organized - does this give the business the necessary metrics?

This training is about industry-proven architectural, process, and organizational patterns and their meaningful choices. That is, about how to build the architectural process and structure of production in order to address the needs of the business.

We will understand why the solution architecture that is too early or too late is pain and how to measure it and track its risks. Let’s figure out how to ensure the quality of the product in the early stages. We will learn how to build processes to reduce delivery time without increasing staffing and how architecture should support such a process. We will determine the optimal team structure to increase delivery speed and product quality. We learn what factors are important for architecture, but we stubbornly ignore them, collecting a rake.

We will understand how the business model of our company will help to create and maintain architecture.

Results and gained experience / expertise on the results of the training

Trainer: Evgeny Krivosheev
Has seven years of experience in developing and teaching technologies on the platforms J2SE, J2EE, BEA Systems, IBM, as well as parallel development. His experience allows him to act as an architect in the development of large commercial systems, while he is able to convey complex technological knowledge to a wide range of people.

A few simple questions regarding the potential and incentive to participate in the training, to Yevgeny Krivosheev:

- Eugene, who is the target audience of Agile Mindset engineering training in general, which specialists will get the most out of it?

Our trainings are designed for average (regular) developers and more trained specialists.

Junior developers may also be interested in training, but after becoming familiar with the basics of Agile. The second training, which is no longer dedicated to architectures, but to specific processes and business models, is likely to be difficult for a junior, as it is not intended even for senior developers, but for architects and PMs with development experience.

One way or another, the essence of the two trainings is precisely the establishment of “end-to-end” rules for developers, architects, project managers, resource managers, product managers, and even, perhaps, owners. This is done to obtain a single decision-making model.

The goal is also for engineering to help business, not interfere. It helped to develop, earn more money and solve other problems: reducing delivery time (time-to-market), increasing its predictability and improving the quality of the system.
For this, it is critical that engineers hear the business, and the business readily answers the questions of the engineers.

How specifically to make engineering decisions? How to build architecture? How to communicate? Both trainings are designed to answer these questions and help find a solution.

- What practical skills or techniques can be mastered during the training?

The most important thing is communication skills. During the training, we learn to communicate in a single language and understand what guides other roles in the process of architectural design. Most of the problems of software engineering, in our opinion, rests primarily in communication: they don’t hear each other’s roles, they operate on different concepts, and they don’t go beyond the “operational walls”.

The second skill is a specific set of techniques and patterns of system design. These skills can be process and engineering.

How to build work and architecture in an ever-changing flow of requirements? To do this, we need methodological support (what?) And specific engineering solutions (how?)

- Why is Agile Mindset a “mindset”, and how does this mindset help design large-scale architectures?

This whole section of the real world exists is divided into two rather large parts: the world of formal or sequential methodologies and processes and the world of flexible methodologies and processes (fewer formal initial settings, more reaction to what is happening in real time).

The benefit for the participants is expressed in the following metaphor: “Finally, the tasks will be done!”. Formal and consistent approaches imply a long feedback loop - a lot of time passes between the idea and implementation, a lot of effort is spent on communication and overcoming various barriers: bureaucratic, communication, and possibly organizational.
What is important in the world of agile methodologies? A relatively small developer feedback loop. The employee sees that the result of his work is quickly being implemented and contributes to the positive motivation of the whole team.

Come and implement common sense in your company!