How to handle business change within an agile development environment?

Question

Most of the questions around agile development processes are focused on the IT side of the work, leading to technical changes that are implemented. In parallel with these technical changes, there can be a vast amount of business change - especially in large organisations that may have many people who use the system. My experience (gained mainly in waterfall environments) is that business users want to be trained in the new features, they want to be given clear communications about what will happen next, and they will, in many cases, delay the implementation of new functionality until they are ready to run with it following training etc. This is especially true if the change is non-trivial - i.e. new functionality, significant changes to screen layouts and process flows, etc.

For example, a new set of features are to be introduced into a Human Resources system, with incremental changes being brought in over several months. So this week the system has changed from last week, and in two weeks' time there will be further changes. Staff who use the HR system expect to be able to use it without change, or to be trained in the new features when there is a major release of the system (as per previous implementations of the system). The local "experts" in each office are unhappy because they no longer feel that they know all that is going on within the system, and as they see it, it is in constant flux. Meanwhile, the developers and the Product Owner are pushing ahead to implement all the nice new features.

My question is therefore around how such users can be brought along on the journey without imposing delays on the development community, who are tasked with implementing technical change?

Answer 1

I don't think this is specific to frequent releases (though it does exacerbate the problem I guess) as the main problem is "I used this system yesterday just fine and now I can't find the functionality". These probably should help:

1. Invest in great UX. If the tool is intuitive and convenient people will understand how to use the changes without training.
2. Keep "local experts" close. E.g. create weekly meetings where you show them new changes, ask for opinion, etc. They will be able to help others once the new feature is released. This is where feature toggles may be helpful as you may decide to release and then show the changes on the meeting. This is just to ensure the experts don't block your delivery. Also this may allow them to play with the feature before exposing it to the wide group.
3. Send "press releases" - news about what was delivered. These should be short and simple, preferably with screenshots. In my team we send these only to the experts because not all features are relevant to everyone. The rest will know about the changes from the experts.
4. Some services announce about new features right on the UI. They create notification area, people click there and are able to see what has changed. Again - screenshots are probably the most important part here.
5. I've seen tools which allow to turn on the new functionality optionally by users themselves (again - it should pop up in the notification area). So some people will start getting acquainted with the new features, ask questions. Then at some point you remove the old UI, but at least those who used old looks may ask around and get their answers from the "more progressive" folks.
6. Try not to change UI drastically. Think carefully about the changes and predict if this functionality is going to be updated again soon - maybe bunch those tasks together.

Answer 2

If a company is to be Agile, "the entire company" needs to be Agile. It's not something you just decide to do, or actually... decide on the development team to do. It's a change in mindset. For example, you can't keep things like traditional "Command and Control" attitudes in the company's top layers, while placing all the responsibility for making Scrum succeed somewhere lower in the food chain. The developers should now follow the Scrum rules and commit to 100% delivery every sprint or else... while in the rest of the company, it's "business as usual" doesn't really work. Bosses and managers need to understand the new mindset. Clients also. You can't have a client who isn't involved, who tells you what they want, then go missing, only to get back to you six months later and demand you deliver what you promised. And they want you to deliver everything they asked for, before the date they imposed, and it's your own damn business how you make that happen, by using Scrum or whatever else you want, it doesn't really matter to them. An agile transformation needs to start from the top and flow downward; the other way around doesn't really work. It's useless if the team uses Scrum to perfection, but at the top, people don't have the right values.

I need to start with the disclaimer that the quote above is from my book, from a chapter about Scrum and Agile, from a section I named "You do it!". I named it like that (and it's the section that starts the chapter) because I think it describes the main issue with failed Agile initiatives: people in the company expect Agile (usually Scrum) to be something the IT people should do. They may truly want the benefits of an Agile transformation, but don't really want to get involved. The software people should figure out how to make this Agile thing work, while for everyone else in the organization things are "business as usual":

• management still keeps their old way of thinking (traditional management techniques with command and control, imposed deadlines, demanding 100% delivery all the time, applying pressure, demanding overtime, etc);
• users of the product don't really get involved in building the product and expect things to just be delivered to them as they were before;
• Agile exposes problems in the organization, but there are people in the organization that don't want those problems exposed, thus they remain unfixed and affect the way the development team performs their work;

When these things happen you inevitably end up with things like ScrumBut instead of Scrum, or something like Scrumerfall, or just plain Waterfall performed in iterations. If the team is lucky they might be able to self-manage inside a bubble, and actually create working software every sprint, even if they might decide to deliver once in a while just so people remain accustomed with the way they received software. By the way, that's one way you might deliver your software. You create an increment each sprint - or even sooner if you have continuous integration, deployment, and delivery - but the PO can chose to have those changes delivered in larger releases so as to not overwhelm users, if that's the case. But this has issues as it increases the length of feedback loops and you can build the wrong product for a longer time until you realize and have to make corrections.

The permanent solution is for everyone to embrace this new Agile mindset and way of working. That means users need to collaborate and management needs to be supportive. The development team can't really make the change upwards, so change needs to come the other way. People are resistant to change, and if Agile is something that the development team is expected to do, then there is no reason for them to change. Some might be curious, or already have the right values, and might get involved, but many others will not do so without being forced to.

Upper management needs to bring in Agile coaches, have training sessions with employees, encourage the new way of working, set up things to increase communication and collaboration, etc. And management needs to jump on this wagon too, not simply expand the group of people that need "to do it" (have you ever seen or know about a CEO attending an Agile training session for example? Or do they think it's something that doesn't concern them?)

Do you see people in your organization that can become your allies in implementing Agile across the entire company, or are you alone and the only one "doing it"? Agile is more about systems thinking, and less about changes in the way of working inside just one department.

Answer 3

My question is therefore around how such users can be brought along on the journey without imposing delays on the development community, who are tasked with implementing technical change?

A useful technique is to apply feature toggles. The developers are constantly releasing code to production, but the features are made visible at the pace the business users want.

Answer 4

This is a really great question, although perhaps a bit too broad to be a good fit for PMSE.

Firstly it must be said that the term agile is too often assumed to refer to the Agile Manifesto for Software Development. At least that's how most people on this site are likely to interpret the word. That's a shame because the Manifesto (dated 2001) embodies ideas that are so much bigger than that. The ideas of organisational agility originated in manufacturing industry - partly as a response to or improvement upon "lean" manufacturing methods - and became generalised for managing organisations of all kinds in the 1990s. Rick Dove defined enterprise agility in 1994 as "The ability of an organization to adapt proficiently (thrive) in a continuously changing, unpredictable business environment." Some of the characteristics of an agile organisation are: empowered, self-organising teams; non-hierarchical management and communication structures; collaboration; unit redundancy.

The effect of agility in software development should be to put the business (owner/user/customer) in control, not the technology team. Business change should be driven by the business units doing the work, not by technologists or separate change organisations. So firstly I would want to focus on getting your organisation right so that staff truly feel they are involved and listened to and understand that it's their job to make improvements happen.

Software development works best with very frequent delivery. It's not unusual these days to release software changes weekly or daily whereas business change that involves people and process almost inevitably happens a bit more slowly. To handle this it helps if you have good transparency about what are the common priorities and what is to be done about them. Some specific suggestions: share the list of priorities and iteration goals with everyone; use Kanban boards and wikis to collaborate and get feedback; open your software team's backlog to user suggestions; have regular reviews/forums; adopt a train-the-trainer or user-champion approach for software changes; require software developers to do occasional day internships shadowing the people who use the software.

Answer 5

This is why product owner for one team is a full time job. The product owner doesn't usually just work in isolation, a huge part of the product owner's job is getting feedback and buy-in from all the stakeholders.

For a team with internal users, the sprint demo/review is a big help.

For the example you give, where there are multiple offices and local experts in each office, it would be best if the product owner could get a local expert representative from each office to (virtually, if necessary) attend the demo every sprint.

Then in the demo the product owner can explain the changes in business language. Even better, they can explain the reasons for the changes in a way that users can relate to. People usually have an easier time understanding, remembering, and explaining to others if they know the reasons why things were done, rather than just a list of changes. Best, if there's a long term goal planned, like your example, then they can relate these specific changes to the long term goals and other product backlog items. This prepares your users for future changes and helps them see it as a cohesive plan, rather than just random changes.

Finally your product owner can get feedback from the users. Feedback is essential for buy-in, people are going to be much more willing to support something if they feel like they had a role in it. And, of course, they may have some important point or feature that your product owner hadn't considered.

Then these expert users can go back to their offices and explain it all to their coworkers. I found that you don't really have to explicitly ask people to do this, as long as you pick the right people to start with--they will naturally help people at first, and soon everyone will know to go to them to understand the most recent features.

You can create training materials, etc., too, but I found that the personal connection really works better and faster. Even considering that a lot of people attend the demo, the demo should only take 15-20 minutes (tops) which is probably about the amount of time they would spend struggling to understand the new stuff anyway.