Setting the mind to the frequency of Agile

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

Gradually, we collected key engineering techniques from basic methodologies and architectural standards and translated into human language. We have connected our own experience and working solutions of our numerous customers, having received as a result a number of training sessions. At the same time, their format is practical, therefore the participants will come to the majority of the decisions themselves, which gives a tremendous conversion of skills into application in production.

For whom :

• Engineers: Architects.
• Technical managers: timlidov and tehlidov.
• Managers: project managers and product managers

Experience at the start :

• Experience in industrial development from 2 years is desirable.
• Required design skills in the scope of the course "Agile Mindset in system design," especially for participation in advanced training: "Agile Mindset in design solutions."

Dividing all existing experience into two major components of one whole, the following picture

Agile Mindset in system design . Requirements, architecture, process
')
Remember, when was the last time you had the last effort to prove the advantages of an architectural solution, but did not succeed? Or, when with triumph you introduced at first glance an absolutely right decision, which suffered a complete fiasco afterwards. Such moments give rise to a number of fair questions: “What did I do wrong? How to correctly and logically present your point of view? What is the difference and where is the line between conscious and reasonable architectural solutions and amateurish approach? ”

This training is about common sense - about the validity of engineering solutions in conditions of uncertainty. We will analyze what engineering solutions depend on and learn how to clearly substantiate them. Let us think about what should be the expectations of architecture and whether you even have it in your project. We will learn to solve engineering conflicts objectively, and you will forget the word "holivar" forever. We take a completely new look at design patterns and now squeeze the maximum out of them. Let us understand how to efficiently build documentation for the system so that it really starts working, and not “write-only”. Let's 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 of the training is to learn not to do extra work.




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

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

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

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

We will understand how our company's business model will help create and maintain architecture.

Results and experience / expertise from the training results

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

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

- Yevgeny, who is the target audience of engineering trainings for Agile Mindset in general, which specialists will draw from it the maximum possible?

Our trainings are designed for medium (regular) developers and more well-trained specialists.

Younger 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 complicated for a junior, since it is intended not even for senior developers, but for architects and PM's with development experience.

Anyway, the essence of the two trainings lies precisely in the establishment of “cross-cutting” rules for developers, architects, project managers, resource managers, product managers, and even, perhaps, owners. This is done to obtain a single model of decision making.

The goal is also to ensure that the engineering helps the business, and does not interfere. She helped develop, earn more money and solve other tasks: reducing delivery time (time-to-market), increasing its predictability and improving the quality of the system.
For this, it is critically important that the engineers hear the business, and the business readily answers the questions of the engineers.

How exactly to make engineering decisions? How to build architecture? How to communicate? These questions are designed to answer and help find solutions to both training.

- 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 other roles are guided by 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, operate with different concepts, do not go beyond the “operating 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 a constantly changing flow of requirements? This requires methodological support (what?) And specific engineering solutions (how?)

- Why is Agile Mindset as “mind set”, and how does this setup help in designing large-scale architectures?

This whole slice of the real world 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, tasks will be done!”. Formal and sequential approaches imply a large feedback loop - between the idea and implementation a lot of time passes, many forces are spent on communication and overcoming various barriers: bureaucratic, communication, and possibly organizational.
What is important in the world of flexible methodologies? A relatively small feedback loop with the developer. The employee sees that the result of his work is quickly introduced and contributes to the positive motivation of the whole team.

Come and introduce common sense in your company!