In the previous part, we examined the types of projects according to the Kinevin model, depending on which the management style is selected, one of which is “Waterfall”. In this part we will talk about newer, so-called “agile” approaches.
Content:
Now Agile is advertised, and is positioned by many almost as a panacea for everything, or rather, as a universal answer to the VUCA world (world of uncertainty). So what is Agile?
This is an approach to implementing projects using short segments - “sprints” - of 1-4 weeks and preparing parts of the overall product - “incrementations”.
The uncertainty may be due to:
with the product being developed, its requirements
with the customer/consumer, with what he wants and what he needs.
Another hallmark of Agile, especially in product management, is the creation of MVPs.
MVP is a test version of a product, service or service with a minimum set of functions that provides value to the end consumer. Read more about what it is and methods for creating an MVP at the link .
The main goal of this approach is to test the assumption and identify the error as early as possible. This is necessary in order to give the client a product that will be valuable to him and to minimize the cost of the guessing game.
Agile makes sense primarily for intricate Kinevin systems or as a hybrid element in complex systems.
The paradox is that agile is very difficult to work with planning and is demanding on the control system and team level. With weak management, this leads to huge cost overruns and missed deadlines on projects.
Therefore, now we encounter planning that is the opposite of classical planning.
But most often in life there are 3 options:
Specifies product requirements and resource limitations
We count and get that either there is not enough money or time
We adjust the content and requirements.
But in order to adjust the requirements for the project’s product, you need to master the tools of product management (in particular CusDev research ) and lean manufacturing
The main document that organizes everything is the agile development manifesto . software that highlights four core values:
1. People and interactions are more important than processes and tools.
For people to work more efficiently, processes and tools should not limit them. In Agile, no process, much less a tool, dictates what people do. They decide for themselves how to change their work processes/tools.
To speed up the implementation process, people must also interact directly (without intermediaries in the form of documents or other people), actively communicating with each other in person, rather than in writing. True, in modern business, communication is often forced to move online. But then it should be video communication with interactive online whiteboards, and not just letters and chats.
2. A working product is more important than comprehensive documentation.
To keep customers happy, they need a product that works. Therefore, product developers should focus precisely on ensuring that the product can be used as soon as possible, and not on compiling lists, diagrams, requirements, reports to the customer.
In order to meet tight deadlines with a minimum of costs, it is often not necessary to bind yourself with documentation. Maintaining documentation in a state adequate to the product often slows down development and requires unreasonably high costs.
3. Cooperation with the customer is more important than agreeing on the terms of the contract.
In order to end up with a product that is truly valuable to the customer, it is worth abandoning unnecessary details in the contract between the contractor and the customer (as well as in the requirements of the internal customer for the internal product developer). Being rigidly specified at the start, contract details make it difficult to take into account new data and priorities that appear only during development.
In order for the business value of a product to grow quickly, the customer and the developer must communicate closely as work progresses. In this case, all changes and problems that arise are promptly processed by both parties.
And for such cooperation between the contractor and the customer to become possible, it is necessary to build their trust in each other.
4. Willingness to change is more important than sticking to the original plan.
In order not to postpone project risks to the final stages (when it will be too late to reduce the content of the work, move the deadline or strengthen the team), Agile offers not only iterative work, but also readiness for changes at all stages.
To ensure that the most valuable things are done first, the current vision of the business value and product positioning must be transparent to developers, and their work process must allow for significant changes to previous plans. Developers must be willing to add unplanned new features to the product if they become valuable.
As for the readiness for changes on the part of representatives of the customer (client), in such a situation they can sacrifice something planned (but less valuable) for the sake of new opportunities. The customer's willingness to quickly sacrifice some part of what was planned is also needed in a situation where the contractors encountered unforeseen problems during development.
Without denying the importance of what is on the right, we still value more what is on the left.
The Agile philosophy can also be applied when working with personnel:
There are also principles (there is a good article about the difference between values and principles):
Satisfy customers by delivering product early and consistently. Customers are happy when the product reaches them regularly and at regular intervals.
Change requirements for the final product throughout its development cycle.
Deliver the product as often as possible (once a week, every two weeks, a month). Maintain collaboration between the team and the customer throughout the development cycle.
Support and motivate everyone involved in the project. A motivated team copes with its tasks much better than a team whose members are dissatisfied with their working conditions.
Provide direct interaction between developers (the possibility of direct contact contributes to more successful communication).
Measure progress only through working product (clients should only receive functional and working software).
Maintain a continuous pace of work (the team must develop an optimal and maintainable speed of work).
Pay attention to design and technical details (thanks to effective skills and good design, the project team is able to constantly improve the product and work to improve it).
Try to make the workflow as simple as possible and the software understandable.
Allow team members to make their own decisions (if developers can make their own decisions, organize themselves and communicate with other team members, exchanging ideas with them, the likelihood of creating a high-quality product increases significantly).
Constantly adapt to the changing environment (due to this the final product will be more competitive).
From these principles, the main tool - Scrum - is born, and Kanban is also becoming increasingly popular.
From the principles, signs of an Agile team emerged:
the Agile team is professionals with a high level of expertise in their field (programming, services, production, etc.);
there are no managers and seniors (point 11 of the principles), this is a completely flat team. There is not even an informal structure (opinion leaders). At the same time, responsibility for creating the product is divided evenly between all participants and lies with the team as a whole. In Agile, there is no single person responsible for the result;
consists of 5-9 people;
is autonomous and has enough courage to block attempts to interfere with her work and impose urgent, but not priority requirements from the outside (the Scrum master helps);
all members are interchangeable, the team is cross-functional. Any member can perform any of the tasks that the team takes on. But in complex projects this is rare, and, as a rule, there are “T-competencies”: when a participant has a deep understanding of his core activity (vertical line in “T”) and an average understanding of related areas (horizontal line), he can, if necessary, help or replace another participant;
is internally motivated to create a result: she herself determines how to organize work on the product, all participants must understand the purposes for which the product is being created, what its purpose is, what problems the customer must solve;
located in one room. This helps to communicate quickly and be aware of the overall status of work without formal status meetings. At the same time, it is better to choose a room for the team that is isolated from noise and the presence of other employees: this will help get rid of information pollution and focus on the task.
Cons and limitations (our opinion):
Agile should not be used in simple and complex projects, according to the Kinevin model. In complex projects it may be part of a hybrid approach: modification of a standard product, implementation in an unusual infrastructure.
High demands on the level of management, including working with motivation, “awareness” and competencies of both the entire team and the manager/owner. Firstly, planning is used here, when the performer himself estimates the required deadlines. Of course, you can use “poker” planning, but these are unnecessary losses. And a directive approach will lead to turnover, which is also not good. In such projects, it is important to learn from historical data in order to understand the pros and cons of both each employee and the entire team, what the actual level of productivity is. Such people need more “fine management”.
Not every customer wants and is ready to be in dialogue, to frequently connect to evaluate the sprint and the presented part of the product. From experience I can say that often the customer wants to pay and get results. He doesn’t want to waste his time and be distracted, listen to arguments and why something needs to be changed.
Agile does not like time and financial restrictions, and the payment is hourly... If there is a weak manager, high turnover, low level of the team, then you will get a “black hole” of your funds and an incomprehensible prospect of getting results.
We have had some successful projects based on the Agile philosophy, and some not.
A good example is a study for the Tomsk region. The customer and I communicated once a week, discussed the results, our opinion was heard, and we deviated a little from those. tasks. As a result, we received a good product for the target audience and 17% ahead of schedule.
The unsuccessful ones include projects in the Ministry of Energy. For certain reasons, the deadlines for all projects were constantly shifting to the right, and there was no longer any desire to do anything. As a result, everything devolved into constant preparation of justifications.
Useful links:
This is an approach/method/framework, in general, a tool that allows, with small restrictions, to streamline the work process in short segments, so that the team works according to the accepted plan and constantly learns, no one interferes with them, the person in charge has the entire development history.
How Scrum works:
The main roles that are provided:
Product Owner
This is the person who is responsible for the success of the entire product/result. He maintains the product backlog. This is the customer for the development team, who is then responsible for commercial success and demand among end consumers. This is an entrepreneur within a company. He must have sufficient competence and authority to make product decisions on behalf of the customer.
Team
Performers are those who create the product. If we are talking about software development, then it consists of testers, architects, analysts, programmers, etc. We need as wide a range of competencies as possible, and, preferably, everyone should have more than 1 competency so that people can understand and hear each other friend. Team size 5-9 people.
Scrum master
A person who supports the work of the team, helping them get comfortable with the framework and giving them the necessary tools to successfully overcome all difficulties.
It protects the team from outside interference when work is underway on the current increment. Changes should come at the end of the sprint, but not during the work.
He can use any approach: both Agile practices and, for example, Kanban (Scrum board, this is essentially a board on which all the work for the current sprint is indicated), Lean Startup and mix different approaches.
In addition, there are “additional” roles: Users and Stakeholders - persons who initiate the project (business customers) and for whom the SCRUM project will bring benefits. They are only involved in the scrum during the Sprint Review.
Basic processes that help organize work:
Sprint planning
Occurs before the start of each segment. The goal is to determine the amount of work that the team will take on in the next sprint.
The team selects the highest priority product requirements, details them down to the task level, and evaluates the complexity and relationships between tasks.
The Product Owner must remember that he can only help the team understand what needs to be done in the sprint, but not specify or select for the team the tasks that need to be included in the sprint backlog. The team, in turn, takes on only the amount of work that it can actually complete. At the same time, you need to understand that the team’s decision is not a guarantee that all planned tasks will be completed. Unforeseen difficulties or new external factors may arise.
Now we see why stability and level of competence in the team is important in Agile.
Daily meeting
Daily planning meeting (Daily SCRUM), which is held at the same time. Remember industrial meetings? This tool is generally a must for everyone. It builds control points, allows you to better plan your day, and increases the level of discipline (I completely eliminated lateness at production).
At this meeting, the team discusses what each member did last day, what they plan to do next day, and what help is needed. The flight lasts no more than 15 minutes. It is important not to be distracted by solving problems during the meeting, but only to identify them and return to the solution after the end, without distracting the attention of other participants.
The Product Owner attends these meetings regularly. He may share the results and plans of his work with the team, but should not assign tasks to the team or interfere in any way with comments on tasks.
Development
Job. The main rule is the prohibition on changing the composition of the sprint. During the sprint, you cannot add new requirements to the team's work or abandon those already included in the Sprint Backlog. A sprint can only be stopped in one case: if the Sprint Goal loses its relevance. In this case, a Retrospective is conducted to analyze the causes of the situation and Sprint Planning is restarted.
Sprint review
Open meeting to demonstrate the results of the sprint. At the end of the Sprint Review, feedback should be received from users on the results presented. If necessary, you can update the Product Backlog.
The sprint review provides an opportunity for the team to communicate directly with users and stakeholders to hear their requirements and comments on the work completed. It is worth remembering that the purpose of the Sprint Review is not to show the product increment in all its glory, but to provide an opportunity for users to analyze the work that was actually carried out and provide transparency on the progress of the project.
Retrospective
A closed meeting of the Team, at which the past sprint is assessed from the point of view of organizing processes. At the Retrospective, answers to the questions are formulated:
What was done well?
How can the process be improved?
What improvements will we make in the next sprint?
A retrospective will help defuse the situation after the Sprint Review, at which the customer refused to accept the product increment (the result of work in 1-4 weeks). Having identified the reasons for the current situation, the team can conclude that it needs to communicate more closely with the Product Owner and help him work with the Backlog.
I recommend the following meeting structure:
News and current information for team synchronization.
What's done in a week/sprint
What is planned for the next week/sprint
Risks: removed, realized, arose.
The main artifacts/documents/things that are born in the process of work:
Product Backlog
A product backlog is an ordered set of items, a queue of tasks, a list of all the features that interested people want from the product. It is formed and adjusted throughout the project. It’s good when the whole team is involved in collecting ideas and proposals. Although in the end it is the product owner who is responsible for it.
To assess the quality of the Backlog, the DEEP (detailed, estimated, emergent, prioritized) tool is used: assessment of the content of detail, assessment of labor costs, independence and prioritization of elements. The highest priority elements should have the highest level of detail. Evaluating elements helps us plan what we will plan for the next sprint and what we won’t have time to do.
To evaluate elements, relative values are used, which show the total value of the element in terms of complexity, complexity or size. Common evaluation techniques are in story points (from the English “story points”, glasses, points) - 0, 1, 2, 3, 5, 8, 13 or 20 story points, or in T-shirt sizes - S - small element, M – medium, L – large..
Sprint backlog
A set of Product Backlog elements that the team accepts for development for the next sprint. The Sprint Backlog also states the Sprint Goal (Why are we working in this sprint? What do we want to achieve in this particular iteration?) and a plan to achieve this goal.
A goal is needed to unite the team’s efforts in one direction, minimize the variability of tasks (we limit ourselves to one topic) and explain to stakeholders what the team is currently working on.
The Sprint Backlog should only include items that meet three criteria: they are clear, verifiable, and feasible. Clarity means that team members have the same understanding of the essence of the task. Verifiability means having an effective way to check whether a task has been completed. Feasibility means the ability to complete this task completely in one sprint.
A scatter of sprint elements by more than an order of magnitude is undesirable. That is, it is desirable that all ratings range from 1 to 10.
If team members have different estimates of the size of a task or element, this problem is solved using poker planning. Each team member is given a set of cards that contain all possible values for the ratings. An item is selected to be scored, the team briefly discusses its contents, and each participant places a card with their score face down on the table. Then the ratings are opened and the authors of the ratings that are the farthest from each other argue their position. All participants each take their card and the voting is repeated again until all the scores match.
Product increment
The sum of Product Backlog Items completed during a sprint and all increments from previous sprints. That is, this is the current state of the product being developed, including improvements from the last sprint.
Task Burndown Chart
Separately, it is worth mentioning the combustion diagram (Burndown). This is a chart showing the amount of work done and remaining in relation to the time it takes to develop a project. It is carried out daily.
Its goal is to conduct objective and understandable planning and understand completion deadlines:
Often it is presented as a separate artifact, although, according to the guide, it is an element of the product backlog.
It is not the simplest tool, but Max Dorofeev has a good series of videos and examples in Excel on the topic of forecasting project deadlines (quantitative methods and Excel). Below is a link to it.
Useful links:
Video:
Kanban is one of the easiest to use and favorite tools I have.
It was originally developed by Toyota for the production system, the basis of lean manufacturing. Lean manufacturing (LEAN) is now used in all major global companies.
Kanban was intended to organize production on a just-in-time basis and was in no way related to project activities.
Now this tool is actively used in the IT environment.
Its essence is to visualize the workflow and load in order to see bottlenecks and take preventive measures, solving the problem at an early stage, and constantly improve the workflow.
Kanban is very flexible. It can be interpreted quite freely.
One of its main conditions is the limitation of work tasks at each stage (Work in progres - WiP).
The example above is not the only method for visualizing a workflow.
Below is another example of work organization. We used this concept at the Ministry of Energy during the transition to remote work, and it worked very well. Intuitively understandable to everyone and relevant when the entire process is in the hands of one person.
Basic principles:
Reliance on existing work methods
Kanban starts with existing ways of working and encourages additional changes in them.
Preliminary agreement on important changes.
It should be borne in mind that constant change is a way to improve the existing development process, but making global changes has a big risk. Kanban encourages small and evolutionary changes. Actually, this is the whole essence of Japanese philosophy. No major revolutions.
Respect for status quo, roles and responsibilities
Encouraging initiative
To achieve "systematic" workflow improvement, Kanban involves the use of six steps:
1. Visualization
It is necessary to visualize the current structure of processes. The final result should contain the characteristics of a kanban system (WiP limits, commitment and delivery points), and the rules for the “as is” process. Kanban does not prescribe what a Kanban board should look like. In addition to columns, you can include horizontal rows for different types of tasks (service classes).
As shown above, you can work with at least 3 types of boards. And digital services allow you to set deadlines, checklists, add the necessary documents to a task, and track all actions.
2. Limit the amount of work in progress
Work on new elements begins only after the completion (or discarding) of previous tasks. A lot of unfinished work is not cost effective, increases production time and prevents the organization from quickly responding to customer needs.
In addition to the economy, this also negatively affects the employee’s psychology, he loses concentration and priorities, and reduces his productivity.
3. Flow control
The flow of tasks in a Kanban system should help increase value, minimize production time, and increase process predictability. It is necessary to constantly monitor the process, identify bottlenecks (a cluster of tasks at one stage or, as in the example of the Ministry of Energy, on one person) and blocked tasks (the execution of which is blocked by external factors; for this, for example, there are color marks).
4. Make the rules explicit
The Kanban system must contain rules for task distribution, criteria for readiness and transition from stage to stage, criteria for selecting new tasks and the use of service classes. The rules may vary for different stages of the process.
Transparency of rules is a major issue. We wrote about this here .
5. Implement feedback collection cycles
Kanban provides seven ways to receive feedback (cadences). Cadences are regular meetings and reviews that lead to evolutionary changes and efficient service delivery. It is important to choose the optimal cadence frequency: too frequent checks can lead to changes being made before the effect of previous changes has become clear. And if inspections are done too infrequently, poor performance will persist for too long.
The method suggests carrying out the following cadences (more details in “Kanban. A Quick Guide.” by David Anderson and Andy Carmichael):
strategy review
operational review
risk review
delivery service review
replenishment meeting
kanban meeting
delivery planning meeting
6. Collaborative improvement, evolution through experimentation
Kanban does not prescribe specific actions that need to be taken to improve your process. Based on the results of your work, put forward hypotheses about what can be improved in the process, test your assumptions in practice and draw conclusions.
This approach can be used in conjunction with Scrum.
Useful links:
The difference between Scrum and Kanban lies in the planning and inclusion of tasks in the work. Scrum has iterations of 1-4 weeks and a fixed sprint size. In Kanban, tasks can be added every day. The main thing is visualization and limiting the number of work tasks.
Another analogy: Scrum is a bus, Kanban is a minibus.
From the desire to combine these two philosophies and “softly” teach teams the basics of lean manufacturing, Scrumban emerged - a more flexible Scrum. There is no formalized document on the topic of this hybrid. Essentially, this is the result of experiments by different companies, when everyone naturally comes to the same thing.
From Scrum here:
Sprints
Once the team decides what it will work on during the sprint, members will no longer be able to receive new tasks until the end of the sprint. But at the end of the sprint, a product increment does not have to be ready. The key task of the sprint is the points of control of the team’s work and the revision of work tasks.
Daily stand-ups
Meetings lasting no more than 10 minutes, where participants briefly answer:
What tasks did I manage to complete?
What am I working on today?
What obstacles are stopping me?
Retrospectives
At the end of each sprint, the team holds a meeting to evaluate the performance of the work and the list of work tasks, priorities for the next stage.
From Kanban here:
Kanban board
A Kanban board typically contains “To Do,” “Working,” and “Done” columns that correspond to project milestones.
Cards
The tasks (cards) of the project are listed on the board. This is a common approach because in the past, teams used flashcards or sticky notes on magnetic marker boards.
Limiting the work performed
To achieve high performance, a team needs to know how many tasks it can complete during a given work period. How many cards can a member handle in a day? This constraint allows the team to prevent overwork (and burnout) while still showing progress to stakeholders.
As a result, to summarize, a visualization board and restrictions on work (WiP limits) in the process are actively used here. Items from the sprint backlog are completed sequentially; all cards do not appear in the “In Progress” column at once (and this does not contradict the ScrumGuide). The flow of work is leveled out and we get rid of unevenness in production (queues that increase execution time and the amount of additional materials, which causes overload, tiring people and reducing their efficiency and quality of work)
Well, in more detail:
a standard sprint size for the project is established;
planning, planning meetings and retrospectives are not cancelled;
planning is carried out for several tasks, but the team assumes that the tasks have many pitfalls or other tasks will arrive;
tasks are prioritized and divided into parts of approximately the same size;
before a task is taken into development, it must be worked out and analyzed;
the columns are marked with WiP - there is a limit on the number of tasks during work;
clear roles are not specified, they are introduced as necessary;
The project backlog includes only those tasks that are “ordered” by someone, while there is no separate backlog, it is a column on the board of all tasks;
there is no burndown chart, and sprints are primarily aimed at more frequent analysis of your work and more intensive improvement of work processes;
tasks are not assigned to team members by the team leader or project manager;
When a project deadline approaches, the manager freezes the feature set. You can only work on features that the team already has on the list; additional features cannot be added;
After freezing, the manager sorts out which features in development will be completed and which will remain unfinished. This allows the team to focus and complete important tasks on time;
At retrospectives, the team primarily works to reduce cycle time.
Benefits of Scrumban
High flexibility
In Scrumban, the intermediate product is delivered after each sprint. This approach allows you to make changes to the project even after it has begun. However, they do not impede progress in the implementation of the project.
Continuous Delivery
Work is presented on a board and the process is continuous, allowing teams to deliver features as they are completed rather than waiting until the end of the sprint.
Load reduction
Limiting the work to be done according to the team's capabilities allows you to move towards the goal without burnout.
Accelerated problem solving
Placing cards on a board provides the transparency Scrumban teams need to improve collaboration and quickly resolve identified issues.
Ability to implement large projects.
Because the essence of Scrum and Kanban is continuous and incremental improvement, Scrumban allows teams to work on the most complex projects.
Limitations of Scrumban
Ambiguity
Scrumban is a relatively new approach, so there is not much information on its implementation. This can make it difficult to find guidance or best practice.
Less control
Since Scrumban does not have traditional Scrum roles, team members manage sprints independently. The absence of a specific leader can lead to confusion in the distribution of responsibilities.
Complexity
Using elements of two methodologies can be confusing for team members who have used a system other than Agile.
Also a comparison of 3 approaches: Scrum, Kanban, Scrumban
Scrum | Kanban | Srcumban | |
Methodology |
|
|
|
|
|
|
|
Artifacts |
|
|
|
Events |
|
|
|
Process |
|
|
|
As a result, we have the following comparison
Who is Scrumban best suited for:
Software development projects with changing requirements
Software development with expansion of the project scope. The required result is achieved through sprints and continuous development. Teams can continue to deliver increments even as requirements change.
Projects with multiple parallel initiatives
Large companies often work on several projects simultaneously. Sometimes they are handled by the same teams. Thanks to its flexibility, Scrumban allows different initiatives to be implemented simultaneously, so even small teams can take on multiple tasks.
Startups or fast-paced environment
Startups often change their environment and projects. A new task may arise at any moment, and resources may be limited. Scrumban gives small teams new opportunities for success
Useful links:
Video:
The project management approach is chosen for a specific project.
The main focus is on preparation for the launch of the project: initiation and planning. Determine the mission and value created, combination with strategy, goals, success criteria, stakeholders, risks. The earlier the error is identified, the cheaper the correction;
Whenever possible, build informal communication with participants and stakeholders. This way we managed to pull out even “problematic” projects in a new industry. And back it up with letters and protocols.
Now is the era of hybrids and the search for a balance between “flexibility - efficiency - meeting budgets and deadlines.”
The current trend is a focus on creating value for the consumer and creating complex products.
Critical factors for the project:
Defining success criteria, milestones and risk management
Working with local staff: training in project management, acceptance of change and reasons for resistance.
In digital projects, working with data is critical:
structure of reference data;
data digitization, data model and subsequent analytics;
avoiding manual data entry;
determination of indicators that need to be established for decision-making, both when launching a project and after implementation.
We also provide a comparison of various standards from Mikhail Sofonov:
“Comparing Project Management Approaches with Animals:
PMBOK - I would compare PMBOK to behemoth because both are very structured and contain a lot of details. The PMBOK describes a large number of processes and documents, and the hippopotamus is the largest land animal and has a massive body structure.
PRINCE2 - I would compare PRINCE2 to an eagle because both are focused on management and leadership. The eagle is a symbol of strength and authority, and PRINCE2 provides a set of principles and techniques for effective project management.
P2M - I would compare P2M to a dolphin because both can quickly and flexibly adapt to changes and environmental conditions. Dolphins can easily switch between different tasks and demonstrate the ability to creatively solve problems. P2M, in turn, provides methodologies for effective project management that can be easily adapted to different scenarios.
SCRUM - I would compare SCRUM to an anteater because both are focused on teamwork and effective communication. Anteaters typically work in teams to ensure food collection, while SCRUM teams work together to achieve project goals. SCRUM is also known for its agile methodology, which emphasizes adaptability and the ability to change during a project.
KANBAN - I would compare KANBAN to an ant because both have a high degree of organization and discipline in their work. Ants are skilled builders and organizers who can work as a team to achieve common goals. KANBAN, in turn, provides a project management system that allows you to manage processes and control the flow of work, which increases efficiency and reduces risks."
Well, in conclusion, we want to share a simple thought - you cannot be Agile forever.
Let's be honest, most people hide banal chaos under Agile. Agile is not about lack of planning. In addition, he is very sensitive to the implementation of certain rules and the stability of the team, its motivation. That is, you are not Agile in this case.
But the very use of Scrum, Kanban or other approaches should lead to the elimination of the need to implement Agile projects.
But why? To do this, you need to remember why Agile appeared? To work and implement projects in situations of high uncertainty.
There is even a tool - the Kenevin model. It helps you understand what situation/system you are in and what approach you need to take and what to focus on.
At the same time, in ordered systems (simple or complex), Agile, on the contrary, is contraindicated. It increases the costs of achieving results. What is called reinventing the wheel every time. That is, Agile is about efficiency, when you need to do something, I don’t know what. But he is not about efficiency.
Now let's turn our attention to retrospectives. All approaches within Agile require regular retrospectives, analysis of one’s work, and interactions with clients/customers/partners. That is, the very logic of these tools is to get away from an uncertain situation and learn to predict them, to become more effective.
If you constantly (once every six months - year) change jobs, or constantly launch new products, rather than replicating certain solutions (which is strange for business), then yes, you need to be Agile.
But if you have a segment and you have developed with experience and expertise “standard” approaches / products that need to be adjusted and adapted in a small part, then it’s too early or you should leave Agile. You must arrive at a streamlined system where cascading or hybrid approaches are needed. These retrospectives should lead you to an understanding of what customers want in 90% of cases and how the organization / colleagues work.
As a result, if you are Agile on an ongoing basis and everywhere, and not for a period of restructuring / launch / adaptation, then this may indicate:
non-compliance with Agile tools;
you haven’t found your product and your niche or yourself, you haven’t developed the necessary expertise;
you have a unique product/project each time (which should be reflected in the high price of your services);
the organization is “sick” from the inside, and in this way you mask high turnover, lack of work on processes, etc.
Additional materials
1. Script + explanations
2. Video
***
We develop our own digital solution for your projects. You can get acquainted with it at the link:
Comments