12

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?

4
  • What size team? How many users, and how many offices? Dec 24 '20 at 19:04
  • You can decouple delivery from deployment. Just because work has been completed or delivered doesn’t mean the business is forced into a continuous deployment model. You can still do scheduled releases with most agile frameworks.
    – Todd A. Jacobs
    Dec 25 '20 at 9:07
  • @user3067860 - the dev team is small - typically about 8 to 10 developers (the team does change slightly in size from time to time) but thousands of users across multiple offices internationally.
    – Iain9688
    Dec 25 '20 at 15:41
  • 1
    Some great answers and associated comments here - I have selected the one from @stanislavbashkyrtsev as the best answer however if I could, I would have selected several as "joint winners". Thanks to all.
    – Iain9688
    Dec 27 '20 at 12:09
7

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.
5
  • I suppose there is also the bigger aspect where we should be trying to get users to expect regular change. After all, they cope with changes on their iphones etc without needing handholding, so we should be trying to encourage them to think along the same lines at work!
    – Iain9688
    Dec 25 '20 at 15:46
  • 1
    @lain9688, with iphones the nice thing is that you can control when the update happens. With web/enterprise apps - it may happen unexpectedly during hard times.. Dec 25 '20 at 16:28
  • that's fair enough, but with iphones etc you may agree to allow updates automatically, and you don't necessarily know what the update includes! Your point is well made, however.
    – Iain9688
    Dec 26 '20 at 10:36
  • @lain9688, good point, the audience can be different: early adopters/conservatives, old/young, obedient/rebels, patient/irritable, on-daily-basis-users/occasional-users etc. Some of us are lucky to have patient early adopters, others are stuck with irritable conservatives. So yeah, I guess this all also depends a lot on the target audience. Though their previous experience with the upgrades can move them from one group to another. Dec 26 '20 at 14:30
  • Intuitive means works as user expects. I dont expect you to be only able to do intuitive changes for a crowd that has essentially different worldview than yours.
    – joojaa
    Dec 27 '20 at 12:12
10

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.

7
  • 1
    I think you underestimate the pain that people feel when they have to do their work but the software prevents them. IT folks need to respect their users and realize how precious their time is. Imagine you get new releases of IDE every week and every time you have to re-configure something, find old functionality in new places, face new bugs. And you can't choose the timing! This happens when deadlines approach and you're about to do the last change and push to production; but because of updates you won't do this for another 2 days. Worst thing is: you didn't even need those new updates! Dec 24 '20 at 17:59
  • 1
    @StanislavBashkyrtsev: look at it from the other perspective. Seems the developers are agile (horay!!) and actually can deliver something each sprint, as oposed to playing the iteration game and delivering once in a full moon as I've often seen happen. Now others in the organization think this is too fast for them and not how they are accustomed to, and want to throw a wrench in their work. Is what IT does less important now because of that? The solution is obviously somewhere in the middle but I believe still leaning towards the rest of the organization having to becoming more agile
    – Bogdan
    Dec 24 '20 at 19:58
  • 2
    @StanislavBashkyrtsev if the software is critical to the employees and they need to reconfigure something every release, the developers need to update their way of working to include "don't bother users with reconfiguring". If the software is critical and the users only realize what was being developed when it gets pushed to their system, they need to take their stakeholder role more seriously and at get involved with the planning process at the least so they know it's coming AND can tell the team about possible issues with their deadline before it gets built.
    – Erik
    Dec 25 '20 at 7:41
  • 2
    @Erik, that's exactly my point :) The problem isn't necessarily that the organization isn't agile enough. I don't think the agility of organization matters much. It's more about how well you build the software and how well you communicate with the business. And no matter how agile the organization is - if you deliver bad UX and change a lot every time - it's going to make people sad. Dec 26 '20 at 9:01
  • 1
    There are some great discussion points here which exactly addresses the point that led me to ask the question.
    – Iain9688
    Dec 26 '20 at 11:01
4

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.

2
  • 2
    At best, release toggles could be used instead of feature toggles. Feature toggles can quickly get out of hand and create yet another problem next to the one you are trying to fix with using the toggles.
    – Bogdan
    Dec 24 '20 at 12:01
  • My current organisation prefers feature toggles over release toggles as it complements continuous delivery. There are certainly challenges involved, but the developers get used to this way of working and come up with ingenious ways to make it effective. For example, we have an automatic process that checks for unnecessary and out-of-date toggles and nags the developers to clear them out. Dec 24 '20 at 12:56
3

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.

1
  • 1
    Thanks for the response. I appreciate that it is a very broad question however it was written from a PM perspective as I have always considered that the role of a PM is to deliver the entire project end to end. And this includes the deployment into the user community!
    – Iain9688
    Dec 26 '20 at 10:59
2

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.