At the OOP 2015 conference Colin Hood talked about bridging the gap between requirements engineering process definition and successful iterative roll-out. He presented how the introduction of improvements to requirements engineering can be done better when done step by step, and how relative safety is needed to enable people to take the steps.
For change to be successful attention must be given to the psychological needs of the people , as Hood explained in the introduction of his talk:
We must consider the people as the most important element of the change. We have to consider the anxiety that change may bring, and also the motivation to change. It is perhaps obvious which reaction we would get when asking a busy person to do extra work when they can see no benefit. But still change programmes fail because leaders mistakenly see the change to be a purely technical challenge.
Hood mentioned some of the barriers to change (based on Shein and Lewin):
- Lack of discomfort with the current, fear of the new.
- Ignore information that does not fit in with past.
- Lack of psychological security with the change, fear of loss of identity or status.
You need to break organizational change into manageable parts to be able to do step by step improvement. According to Hood for each step you need relative safety, a likelihood of success and a good reason for taking the risk.
Hood explained in his session how you can map a Plan Do Study Act (PDCA) Deming cycle on Scrum. For Plan a team needs to agree upon the step that they will take next, to Do the step they will need support. The retrospective meeting maps to Study as the team reflects on how things went and which lessons they can learn from that. For the Act teams use actions from the retrospective. What if organizations skip the retrospectives and don’t take actions? Hood suggested to explain the importance of retrospectives and give examples of how to do them and for doing the actions coming out of the retrospective.
InfoQ interviewed Hood about doing step by step improvement with relative safety, increasing the feeling of safety, why safety matters in agile transitions and deploying requirements engineering and management practices with agile.
InfoQ: You mentioned that to do step by step improvement you need relative safety. Can you explain what you mean with this?
Hood: People quite rightly consider whether a risk is worth taking. It might be that the rewards are so high if things are successful that people are willing to risk everything. It might be that the consequences of failure are so severe that the risk can never be worth taking.
Normally the risks we are confronted with at work are not so extreme, but in some cases they might appear to some people to be extreme. For instance someone might feel they risk losing their job if they make a mistake.
Relative safety is when people feel comfortable trying something new with little fear of the consequences. This can generally be achieved in two ways; either make the risk of trying new things very low, or by making the situation extremely dangerous if things are not changed.
If the head of an organisation brought the whole work-force together and explained that if things do not change the organisation will cease to exist in 3 days, most people would be prepared to try new ways of working. Similarly consider how many people ignore the safety announcements on-board aircraft, but think how attentive they would be if the pilot said, "We are going to crash, but if you do what I say we will survive!".
In normal working conditions I find it works very well to help people learn in a risk-free environment.
InfoQ: Do you have examples from adopting new processes or practices in organizations that show how you can increase the feeling of safety?
Hood: Coaching is extremely important. Training can help to give new skills or knowledge, but implementing this without help generally causes much anxiety. If a good coach is on hand to motivate a team and help to show that whatever happens we will be successful then people will find it easier to try new ways of working.
The most important requirement of a pilot project is that it is seen to be successful. If the new ways of working have the results as planned then the pilot project was obviously a success. What is not so obvious, is that if the new ways of working do not have the results as planned then the pilot project is also successful if we learn from the experience.
Managers should act as coaches and need to provide their staff an environment of relative safety. Staff need to know that trying and learning from their new-found experience is highly valued.
InfoQ: In your opinion, are safety and agile related? How does safety play a role when an organization is transitioning to agile?
Hood: Agile is a word that is understood differently by many people. Generally what most peoples understanding have in common is the respect for people and the avoidance of unnecessary work. I like to refer back to the Agile Manifesto to see what is important and if people share a common understanding. For brevity I will avoid addressing each point.
The need for safety provides a particular source of requirements. When the requirements are established the rest is development as normal. If safety requires certain processes to be followed then these processes need to be followed. Of course with respect for people and avoiding unnecessary work. If a safety manager requires certain inputs to be implemented with redundancy then this is what needs to be done; with respect for people and avoiding unnecessary work.
Agile should not be interpreted to mean working with no plan or architecture. Such an immature and incorrect understanding would surely be incompatible with safety.
Working iteratively, producing deliveries often, involving the customer and other stakeholders, and learning from mistakes are all values that agile commends and support better achievement of safety goals.
InfoQ: If an organization wants to adopt an agile way of working, which requirements engineering and management practices can they deploy?
Hood: Everything. Simply value people over blindly following a process. Work in steps and change the plan according to what has been learned. Try to support people to realise that they are responsible for their decisions, and achieving the aims is paramount.
Modelling helps a great deal when people know which aims they are following, that is that they know what they are trying to achieve with modelling. For instance we model to:
- show what we have understood
- check consistency
- specify in a more understandable way
- simulate
- create designs
- elicit requirements
We need to be clear which of the above aims we are following for the modelling to achieve those aims.
InfoQ: Are there requirements activities that you would suggest that organizations should abandon when transitioning to agile?
Hood: No. Be aware that very often requirements activities are misused to create too many things called requirements. It can happen that orgainsations administer themselves to a grinding halt as they suffocate under a mountain of things labelled as requirements that no-one will read or use.
Generally what needs to be changed is the level of granularity of specification, and the need for working step-by-step to allow frequent delivery of prototypes and early releases.