The Agile methodology has always been a big player in the business world. The promises to deliver working code fast while accommodating for changes in specification are always well seen by managers and consumers.
What happens when Agile is not enough?
I work as one of three developers serving hundreds of customers with custom solutions. And all off them need it fast. We have three big challenges to face:
The first challenge: The backlog
All these users are free to ask for solutions, after all, it's our job to improve their lives. One key detail that seems to be missed is that the solutions need to be prioritized.
Every request is "Critical" or "High Priority", making all of those effectively low priority.
If you are using the Agile methodology, you have to get your users to understand that the problems you face go beyond their cubicles. When users can't prioritize, your Scrum master is forced to not only master it's job, but also analyze and weight demands, as well as tame the unhappy customers that happen to have lower priority demands.
The first step to solving this problem is determining what makes something important or not. In our case, it's: Cost Saved, Time Saved, Accuracy Improved and Efficiency Improved. Just ask the user, is their change doing any of these? If so, by how much?
The second step is to add a new face into the process. This is a role that fits between the Scrum Master and the Users. In our case, we call it the Business Analyst.
The Business Analyst should be able to extract all the relevant information from the customer and he/she needs to be able to control them so they don't get unhappy or worse, unwilling.
You can always win back an unhappy customer, but when there is no desire to work together, all hope is lost.
Feelings and emotions aside, you do not want to have unhappy customers running around inside your company. That is one of the biggest reasons why departments as a whole lose confidence in IT and create their own in-house solutions (that are often undocumented, messy and will break once the developer leaves).
The second challenge: The Requirements
Agile is meant to be used when the requirements change. Slightly. When your problem space is constantly moving and your target isn't clearly defined, you end up doing something I like to call orbiting.
One of the ways to solve this is to prohibit changes in specifications while the product is in development. But then, while you do achieve stable code and solutions, they are all outdated and don't really solve the problem the users had.
To try and stop this, we also use our trusty Business Analyst. This is why they need to know what the business does and how they do it better than the average business member.
The number one pain point when a specification changes is when a consideration made no longer makes sense.
Imagine I tell you that there is no way we will ever have field X blank. You go ahead, use field X as a key in your database, use it to make relationships with other tables and then, right before you launch, your customer sends you a data-dump with a bunch of null values in field X.
What do you do? Ignore the null values and use the rest of the data? Generate placeholders? Well, you can't do anything. The data needs to be analyzed, not tampered with. So you change all your code and rethink relationships to get to the same result.
That could have been avoided if either your Business Analyst or your Key User gave the problem some love.
We know you can't expect the end-user to know their data. That is why you need someone to know it for them.
The third challenge: Testing & Validation
A common theme within companies is that IT people are seen as the Printer-dudes, the Internet people or the Laptop Shamans. And while we may do some of that occasionally, we also do so much more.
How do you get your users to cooperate with you when there is no respect for your job?
"My job is incredibly important but I'll give you some of my time since you are saving me countless hours of painful, unsatisfying work."- No One, Ever.
If your company is well integrated with IT, you might think this is an absurd behavior and that no one would ever do this to a department that is so vital. Thank you, but it happens.
The big problems are Avoidance, Laziness and Lack of Ownership.
User avoidance happens frequently. How many times did you talk to a manager or a higher-up about an e-mail you sent them and they went: "Oh, send it over again. I didn't read it."?
I have a theory that the words Testing, Validating and Quality Control are end-users kryptonite. Whenever you say one of those they will look at you with scared eyes and beg you to do it yourself.
But how? How can you possibly validate all your solutions when they are highly business-dependent. We know it runs, we know it works. But does it work for them? This is why Key Users are important. People that understand the data, the process and the needs are the people that can catch problems early on and then validate if everything is working down the line. If you have a good Key User in your company, give him/her a hug. They deserve it.
Laziness is an obvious one. If they don't want to test they won't. And they'll say they did just so you get off their backs. This is fine when you have solid requirements and your functional testing reflects the end-user experience. However, that is not always the case.
It's important to let the users know that when they approve a software change, it's their fault for not catching problems outside the code realm. And this is why lack of ownership hurts.
Your team will be seen as incompetent and inefficient until you drill down into your users minds that validating is their function. You can sit down and make databases dance and spin around to show you crazy things. But what crazy thing they get to see is their responsibility.
A good Business Analyst or a good Key User might solve your problems here, but if you don't have those, try getting one or two users and then ask them to test and validate the tool in front of them. Ask questions about everything. All the business definitions, all the relationships, the interface. Ask away and start cultivating that culture into your end-users one test at a time. There will be resistance, but it's necessary.
And that's it!
I know I haven't gone into much detail on methodologies and how to specifically solve the problems but my intent with this was not to give you a manual, those don't work.
Be Agile with your own Agile methodology. Be meta-Agile. Break your development flow until you are solid enough to still deliver. This is how you raise strong teams and this is how you get your end-users to see your importance.
If you don't have Key Users, dedicate your time to find some. If you can't, find smart people that are easy to work with and motivated, then train then in the process and the data.
If you don't have Business Analysts, get someone with a big brain and a bigger smile. They will need to be incredibly smart to absorb all the requirements and ask the right questions. And they will need to be even more charismatic so they can ask what they need without being left on read.
Thank your for reading.