Embracing Change

The Agile development process encourages us to respond to changes in requirements as a regular part of the process. How we react to unexpected change can define a team’s Agile maturity.

Sometimes it is difficult not to resent change especially when it is difficult to incorporate into existing work. Or there is a feeling that the change goes contrary to previous work.

It’s important to remember that Agile promotes frequent, early demonstration to ensure that the requesters can adjust before things have gone too far.

Change can come in many forms and sizes. I have experienced them from tiny wording changes to entire developments being cancelled half way through development; this happened when the business changed its strategy.

When users make change requests they often have no way of knowing what the impact of the change will have. (I use the term user to include clients or customers as well as internal and external users of the software.)

It’s our job as experts in the software production businesses - whether developers, testers, analysts or project management - to guide them through the process.

What do you want to change?

Project managers want to limit the amount of change that occurs once a project is in motion. There are good reasons for wanting this.

PMs are working to hard deadlines. They have taken estimates from many teams, some of which are not IT or Agile even, and are trying to co-ordinate so that everyone reaches the finish line at around the same time. They want to be able to close the project shortly thereafter so that they can move onto the next one.

Any change, even a minor one is going to impact this end date. It is not always clear how a change will do this. PMs use a process called Change Control to formalise requests for change.

They can monitor the number of items on this list and ask development teams for impact assessments. If a project is generating too many requirement alterations, or the cumulative size is high, they get early warning that the project is going to be late.

Another use for this Change Control process is that they can use an approval gate to simply block changes from getting through. The danger is that the development team will not have a conversation with the users; the visions of what the solution should be will diverge.

PMs want to protect their developers time. A change request can require cost analysis and impact assessment. This is time that the developer is not working on new functionality and therefore impacts the project delivery date.

By trying to shield developers from the sort of requests and conversations that crop up from time to time during an Agile development, a gap can appear between what the developer thinks the user wants and what the user thinks they want (and neither may be what the user needs).

The formal Change Control process helps PMs to keep their sanity, but it does not really fit into the Agile methodology. We need to keep the back channels open by using frequent stakeholder demonstrations and question and answer sessions. There has to be a means for changes to get in without having to run through a change control gauntlet.

Time should be allowed for some reworking of things after the users see the first iterations of a new development. Good PMs will add this on to any estimate and allow a certain amount of change.

Agile teams should also try to account for this in their own backlog by adding stories to cater for alterations. This needs co-ordination as you don’t want to account for the change twice.

It is important to realise that everyone is on the same team. Value the feedback given by your users by responding to it. Talk to them about their ideas and help them to understand what they really wanted.

What do you really want to change?

A sign of the maturity of a team within the Agile process can be how easily modifications to what was planned can be taken up without changing the delivery date by too long.

Often this is anecdotal, since we do not track each minor tweak to the requirements. A change control process, even an informal one, should leave some sort of record that a decision has been made.

Tracking the impact on the final release date can also be challenging. In an ideal, Dev Ops world, where the change will find its way into a production deployment shortly after the developer is finished (with automated testing fully in place), there still may be some confusion caused.

Consider a project where content is delivered incrementally to prodution but toggled off until the last piece is in place. Continuously changing requirements is going to make it difficult to know when this “final date” will be.

Development teams are often asked for things the wrong way. Requirements can be unclear, unmindful of downstream impact, or don’t show the change in terms of the big picutre. Assumptions are dangerous as long as they are not documented and often this is left until too late.

Sometimes users don’t know how to ask for changes. They ask is terms of a single idea, but when you delve deeper, the thing they ask for is not what they really need, or only scrapes the surface of what is required.

This can create a confusing state about what is needed. Unless a conversation is had, and face to face works best in my experience, things might stay this way.

Agile is an iterative process. We know that our first set of requirements are not going to remain static. We know that after speaking with users that they will make changes.

Perhaps something is possible which they thought was impossible or difficult. How else can we find out what these needs are without interaction?

What happens when a user realises they have made a mistake? How open are we to them coming back with what looks like a u-turn? We need to encourage team spirit - we are in this together - and the sooner that we start in the right direction the better for everyone.

An environment for change

Here are some ideas that might encourage a working environment where everyone sees the value of change and embraces it equally.

Have one person calling the shots. Too often I have found there to be no clear product owner that can make a decision. Different opinions or simply a lack of any opinion means that developers need to decide themselves what to do.

The people we need to make those decisions are often engaged with other business as usual work or simply not allocated enough time to get into the work. Delegation down to a level of subordination where they cannot make the decision, whether by lack of experience or authority, also causes problems.

When it comes around to demonstration and testing, problems naturally arise. The argument (or excuse) “but that’s the requirement you signed off” is answered with “but that‘s not what I want”.

There’s no easy fix; a relationship with the correct people needs to be built up. Whether it’s a chat for a few minutes at the water cooler, or they are willing to add you to their schedule, this will be because they respect your professionalism. It takes time to earn that respect.

Once you have someone with the right attributes to make decisions: knowledge, authority, time; and they are willing to share these with you, then you can start to use them as the ultimate decision maker for all change.

The best suggestion I’ve heard of, to maximise use of a Product Owner is to have them co-locate with the development team for a few hours per week, regularly during development. They don’t actually have to be in contact during this time, their own work can continue (they will need to be able to hot desk), however, their presence will be valuable in answering those simple, yet annoying questions that hold up development.

This can work best at the analysis stage but also throughout development, as some questions only emerge once development starts, needing to be resolved as soon as possible to avoid delaying that all important deadline.

It will help to grow a sense of one big team and allow relationships, trust and respect to build up between the user and all the members of the development team.

Remove the red tape from your clients or users. When a change is necessary, and is sufficiently valuable to warrant being done, don’t make them jump through hoops to get it onto your backlog.

The first thing is a conversation. Find out how important the item is; will it save money or time, remove the risk of mistake or of financial loss. Basically get an understanding of why it’s important to the person.

How soon do they want it? Can it wait until the next iteration or does it jump to the top of the priority list immediately?

Then look briefly at what might be impacted by the change. Talk this over with the individual. Can they approve the delay to the other items? If not, then who can? Go have the conversation with them and negotiate on the users behalf, or get everyone into a room.

Keep in mind the Agile principle that working software is one of the key aims - if users do not like the early iterations of a product then they are not likely to use it unless you take their opinions on board.

Think in terms of the benefits the change will bring. Figure out what the users are asking to change. How will it improve the use of the software? Articulate this in conversation with them, training users to think in terms of benefits when requesting change.

It’s much easier to approve a change when there is a clear benefit. It could be as simple as removing an unnecessary constraint from a field on a web form; a small improvement from an individual’s perspective, but when all users are considered, it may increase the overall number of people that complete and submit the form.

Rather than request “Remove the field constraint” we could state “Increase the form completion percentage by removing the unnecessary field constraint”. The intention, and the possible benefit is clear without delving too deeply into the requirement.

Think in terms of risk the change will help to reduce. It’s common enough for bugs to be “allowed” into production, so long as their impact is considered low enough. This usually happens when the bug is not introduced by the code change, it pre-existed and was only caught because of testing on the new functionality.

This is where IT professionals put on their risk or insurance salesmen hats. If the cost of fixing the bug is greater than the possible loss from an event of the bug hitting times its probability of said event happening, then you must fix the bug. If not…

The bug should be fixed, we all agree, but it’s priority depends on a potential loss from it happening compared to the benefits from something else on your backlog being delivered. Is the company willing to delay a release so that a fix can be made, tested and included?

When users start to think in terms of the risk mitigation that fixing or making a change will make, they can often decide how important it is before even raising it with developers. This is an iterative process to build up the skills and questioning attitude as the relationship between developers and users grows.

Have conversations face to face. The best way to get bad news is face to face. There is an empathic connection; you see the understanding in the other person’s face and can understand their need.

Compare to the impersonality of an email. Whether the language is formal or friendly, there is no way to really know the state of mind of the other person.

It works in both directions. There are times when developers realise they underestimated the project and have to go back to ask for more time or resources (unfortunately all too often this is after having invested a lot in the project already).

A face to face discussion about these issues enables all parties to quickly get past the annoyance and straight to solution. Save the acrimony for a retrospective (of the feature, a release or the project). Get started on the solution as soon as possible.

Consider the alternative. A request for a change or a deadline extension by email may not be noticed immediately. It may not be acted on immediately. The reactions of the recipients mat not be determined immediately. All that doubt and delay will hinder a solution.

Conclusion

The bottom line is that developing changes for users, clients or customers places us all on the same team. We need to make sure that the processes we have in place allow the right software to be delivered, on time and within budget.

Formal change control and project scoping are great tools for keeping things on track, however, if overused they can interfere with the healthy feedback Agile tries to promote.

The three main groups involved are going to have their own priorities. PMs will want to keep change to a minimum so that they meet targets. Developers want to get requirements as close to their users’s needs as possible before they start making change. Users want to see changes early, and react to them by tweaking or changing requirements.

The best way to manage these competing interests is to foster conversations between the parties, to grow the mutual respect for each others roles and interests.

As relationships grow we will begin to see the things from all sides of the problem. We will be able to speak in terms that immediately help our argument and convey the information as succinctly as possible. We can make decisions together and do so quickly.

Embrace change. This is what gives you and your organisation a competitive edge.