Continuous Improvements. There is a clear part of project work: to close the project on time, on budget and to meet requirements, including quality requirements. People understand this and will focus on it. However, why might the technical side not be enough?
People fall into psychological traps all the time. For example, it is common knowledge that work is like a perfect gas – it takes up all the time allocated to it. Why? Because people, knowing that they have a lot of time, procrastinate when they start work: at the beginning they work relaxed, but after doing the necessary work, they want to improve the result. This ends up in overtime, complete disregard of technical debt, workarounds and poor quality.
During the project there will be not only risks associated with the team, but also external risks, which will lead to delays, unnecessary work, postponement of high-risk and critical tasks for later....
Therefore, in addition to technical work, there is also regular work to improve processes. Within Agile, it is suggested to do this every sprint on Retrospective. People do not like to do it because they do not have time because they need to do tasks.
Focus. People tend to forget what they are doing, especially if they are distracted by urgent or interesting things. Agile works with focus by getting people to analyse their tasks every day, review every sprint and prioritise the backlog.
Transparency. Transparency itself is not necessary, but having it pulls people out of their usual state of mind. If anyone in the company can look at the results of any other person's work, then pretending to be busy, appropriating the results of another person's work, no longer works.
Transparency can be achieved with task trackers, boards and shared environments. But getting people to put honest and up-to-date information there is more difficult.
Value Delivery. Whatever people do, they do it for a reason. Value Delivery is about doing what the customer needs – even if the customer does not know they need it.
Demanding Environment. The biggest challenge in implementing change is people's resistance. There is a rationale for the team doing the wrong thing, and there is a rationale for doing the right thing. The whole team or individuals refuse to admit it: ‘this is not our case’, ‘this is too small a problem’, ‘implementing this change will force us to rebuild the whole system, which is very expensive’...
The Demanding Environment does not solve the whole problem of resistance, but it helps to reduce the probability of its occurrence.
Demanding Boss is a specific person who demands something from employees or a team. When people are demanded to do something by another person, they tend to resist. People will get angry if they are hosed down by a neighbour, but few people will get angry at the rain. That is because rain is not subjective: it does not choose to go or not, while the neighbour chooses to be considerate or not.
Demanding Environment is based on the fact that people get feedback from the environment, not from other people, and on the fact that people themselves participate in creating their own constraints.
Feedback from the environment is realised through monitoring processes: how customers or competitors are behaving; what test results are providing. If a team leader is convinced that a certain feature will be a success with customers, but customers do not use it no matter how intensely the button blinks when the app is launched – it means that the team leader has received feedback. Not from a UX specialist or an analyst, but from the environment – living but distant people. It is difficult to get angry at them, although some managers do it anyway.
Creating constraints means that the team is involved in setting its own constraints, taking into account the requirements of the project: defining goals, formulating epics, breaking down the work, deciding in what order the work will be done...
In this case, if sufficiently objective metrics show that something is going wrong and if the team itself has made strategic decisions, there is no stakeholder to complain about. The team has to face the consequences of its own decisions.