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 Systems Engineering Training Program
    • Problem statement
    • Introducing and collecting participants' concerns
    • Training Review
    • Team Breakdown
    • Why architecture is needed - how not to ruin a project
    • What is architecture?
    • Where is the border of micro-design and architecture?
    • Who is the consumer of architectural artifacts?
    • What answers should the selected architecture respond to?
    • Architecture as a risk plan - compensate for the uncertainty of the future
    • What sources of project risks can we single out?
    • How can you address external risks in your architecture at an early stage?
    • How can you address the internal risks in your architecture at an early stage?
    • The boundaries of the system and how to fix them
    • Architecture as a project plan - to increase production efficiency
    • What are the requirements for PM / RP architecture?
    • How can I create a project plan for architecture?
    • Is the critical path visible?
    • How to parallelize work?
    • Architecture as component requirements - provide flexibility and lower support costs
    • What assumptions do we rely on when designing using off-the-shelf components or external systems?
    • How can we formulate our expectations from external components?
    • How to address the risks of non-compliance with our expectations?
    • Requirements for architecture: the beginning of the checklist - what not to forget and not to miss
    • Architectural methodology - how to make engineering decisions in favor of business needs and make decisions transparent to business
    • What determines design and architecture decisions? Where to find answers to justify them?
    • How to compensate for uncertain requirements?
    • How to justify decisions on the methodology?
    • Architecture as a function of requirements - how to do what you need, reduce rework and increase customer satisfaction
    • What types of requirements can be distinguished?
    • How can “critical paths” be defined in requirements?
    • How do requirements define system boundaries?
    • What do you know the typical requirements profile → typical architecture transitions?
    • Separately about scalability
    • “Compromise” and “Specialization” - how to make decisions in case of constructive conflict of expectations
    • What are the requirements?
    • How can engineering solutions address these relationships between requirements?
    • How to relate to design patterns - their value and problems
    • Architectural perspectives and architecture documentation - how to spend resources focused and address risks early
    • In what form can architectural decisions be documented? What artifacts can be issued?
    • What is more important - DB schema or concurrency design?
    • At what point to document and what?
    • Architecture Requirements: Continued Checklist
    • Architectural methodology - how to design in conditions of external uncertainty
    • What do you do if you do not know future changes?
    • Axis of variability requirements
    • BDUF vs YAGNI
    • Encapsulation of variability
    • Architectural methodology - how to design in conditions of internal uncertainty
    • Key component expectations based on requirements
    • Early Verifications of Key Contracts
    • External and internal expertise, wireframe prototypes
    • Tests as an early contract review
    • Architecture Requirements: Checklist Completion
    • Final retrospective: what to use in production tomorrow

    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.

    Agile Mindset Solution Design Training Program
    • Problem statement
    • Introducing and collecting participants' concerns
    • Training Review
    • Team Breakdown
    • Patterns of the origin and development of architecture - when you need and do not need to make decisions
    • Metrics of architecture and design - how to measure the dynamics of changes and the "hot" sections of the system
    • Metrics
    • The benefits of metrics
    • Sonar demo
    • Architecture verification and validation - how to deliver a quality product and learn about defects as early as possible
    • Architecture as a function of the process - how to make successful projects
    • What is a process / methodology?
    • What types of decisions are made at this level?
    • How can one deal with the uncertainty of requirements?
    • How to reduce cycle time?
    • How can decisions be transferred to performers?
    • How can you work collectively with a code base?
    • Modern Process Templates - Toward Incremental Architecture
    • Modern project management templates: matstat, theory of real options, theory of limitations, reduced WIP
    • Interaction of roles in the project
    • The fractal nature of projects - why we make mistakes in evaluations
    • Multiple Script Trails
    • Architecture as a function of company structure - how to build a production system for fast and high-quality delivery
    • Matrix vs feature teams
    • Architecture as a function of the team management model - how to build communications for fast and high-quality delivery
    • Collective ownership of the system: templates, incl. DDD
    • Architecture Requirements: Continued Checklist
    • Architects as a function of legacy systems - Solution Architecture
    • Reuse
    • Specialization vs generalization
    • The role of documentation and tests
    • Flexibility in making architectural decisions - which we do not take into account when killing projects
    • What factors depend on sound engineering solutions?
    • Architecture as a function of team management trust
    • Architecture as a function of team trust in management
    • Architecture as a function of company structure
    • Architecture as a function of partners
    • Architecture as a function of corporate policy
    • Architecture Requirements: Continued Checklist
    • Architecture as a function of the company's business model - how architecture helps businesses achieve results
    • What business metrics are there?
    • What business models are there?
    • Architecture Requirements: Checklist Completion
    • Final retrospective: what to use in production tomorrow

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

    After the training, participants will be able to:
    • Make architectural decisions on time - no sooner or later, thereby optimizing the cost and risks of the project
    • “Diagnose by photo” - understand the project status and architectural risks by architectural metrics
    • It makes sense to choose architecture verification tools - to ensure product quality as early as possible and without extra costs
    • Customize the process for minimum delivery time
    • Customize team structure and communication, dramatically improving the speed and quality of engineering decisions
    • Reduce the cost of new solutions by efficiently reusing existing systems
    • Better understand top management business solutions and provide business strategy support in systems architecture
    • Inspect existing architecture for compliance with business objectives and strategies - select key points for speedy refactoring
    • It is reasonable to make architectural decisions and argue for them
    • Provide the necessary architectural flexibility
    • Reduce running costs by clearly focusing on really important issues
    • Reduce costs and risks of future support
    • Easily and efficiently resolve engineering conflicts - without swearing, insults and dramas
    • It is reasonable to make engineering decisions in the face of uncertainty - when it is not clear to the end what and how to do
    • Speed ​​up delivery through meaningful concurrency
    • To understand the needs and way of thinking of the business - to give the business the information that it really needs about the status of the project
    • Rebuild the manufacturing process with minimal effort to reduce delivery time and improve quality

    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!

    Also popular now: