Working software, why you need to be involved to make it happen
Agile management — it’s all that has been on our minds this year as we’ve facilitated a full transition over to this management style. We’re continuing to work on this process — as is the Agile way — with lots of iterations to come. If you’re not familiar with it, Agile management is focused on iterations and working towards maintaining a usable product while keeping the customer happy. It’s the most popular way of working in software development and it is creeping into other industries as we speak.
The easiest way to start implementing an Agile workflow is to focus on internal changes. This is because this is the area that you have the most control over. Often people get hung up on how to get a team working together in an Agile environment, what software to use and how to change their internal processes. This is of course super important for any organisational shift, but something that is just as important — if not more — is the engagement and collaboration with clients.
Where the client comes into the Agile picture
So where do our clients come into the development process? Hint — it’s not just paying the bill and a handshake at the end of the project.
Agile development is all about having a working, viable product at all times, and the only way to get a product that is working to a client’s needs is to understand and listen to your client. This doesn’t sound like rocket science, but it’s really only something we’ve embraced in the last 4 years!
Depending on the project size, we ask every client to nominate one key contact person for us to liaise with, and internally we assign two key contact people to liaise with this person. Having one person to liaise with who can authorise decisions, budgets and help provide guidance from their organisation helps speed up the process of decision making and product delivery. We have two people internally to ensure that at least two people understand a system inside and out, and they can sign off on each other’s high level decisions.
Once we’ve got our key contact, we arrange regular meetings — weekly or fortnightly — to discuss work we’ve done, the next feature we want to release, and to hear feedback from the client-side. Depending on the size of the project, we’ll schedule regular meetings to talk about work scheduled in, how to prioritise the workload, what features should be worked on next etc. This means that we are continually developing the product to our client’s needs and the deliverables continue to change as their needs do.
Why would you need a client involved in a project
Having a client involved in a project has a lot of benefits, primarily because we get to release a product to a client super fast — usually within four to six weeks of signing a contract! We’ve got a working prototype ready for our clients quickly, and plan in the features as we go. Sometimes this will go on for about three months, and sometimes it’ll continue for years!
The involvement of a client in a project goes beyond quick product release and meetings for the sake of meetings. The main reason we want to work directly with you, our client, is to fully understand what your organisation does and what you need. When we are commissioned to build a system for you, we take that seriously. We want to make sure that all of the time and money that you have invested in this system results in something that you can use with your team and will truly improve the way you work.
When we bring a client on, we like to hear all about their day, their experiences, their expectations and the struggles of their workplace. We want to hear about all of the problems that are going on so we can begin to build a system that leads to them working their ideal day.
field, and you are the expert in yours . To bring the two together and create something hugely beneficial, both experts need to be involved. Agile development means that we can continue to work together to understand and empathise with your unique needs and life experiences. Agile workflow means that we can develop solutions for problems you encounter along the way after you start using the base product, because inevitably, things you may not have thought of at the start will become clear as you go. Every iteration intends to make your use of the product more natural and ultimately will create a seamless workflow. We learn about these experiences by attending regular meetings, getting feedback from people in the field and visiting sites to undertake training and scoping.
Where things can fall a part
This all sounds like a project mecca doesn’t it? Sitting around talking about hopes, dreams and concerns, going on trips all over the place learning about customer needs and maybe doing a little bit of development. Where does it go wrong? And could it ever go wrong?
Call us pessimists, but things can always go wrong. Just as Agile development relies on engagement from both the internal team and external stakeholders, these two pillars can often (in our experience) be why a project falls apart.
Client feedback
This is unfortunately one of the biggest challenges we face doing our work. Having a key client-side spokesperson for a project helps expedite the approvals process, but just as easily, can slow it down. We rely on user feedback and suggestions to develop a product, without it we can’t do any work. If our client-side collaborator is too busy to get feedback from their team, it drastically halts the process for us. For us to maintain a working viable product, we need to understand your needs. No matter how much research, visits and reports we participate in, we can’t know what your team’s exact lived experiences are — because they’re not ours.
User testing — the part of a project that can make or (literally) break it. Whenever we develop a project, we always work in a team. Once we’ve released a new feature, we test it internally to see if we can break it. If it all seems to be working, we release it to the client to test internally because most times they will use it in a different way than we would.
We recently released a feature in a system we manage that enables employees at an organisation to complete and submit forms. We tested it and it all worked perfectly — but then we received a notification on one of our internal logging systems that the feature broke. We weren’t sure what happened, so after speaking with our key contact, we discovered that the employee filled in the form with emojis! This is something that they used to do on the paper form version, so why not carry it over to the digital one? Our team wouldn’t have thought that was something to be considered, so we made some amendments so emojis could be used. It was all resolved within a day.
Testing is super important because we can’t always predict exactly how you’ll use a system or what people will do when they’re in it. We work with you to undertake the testing process, but it is primarily driven by the key contact person, so there is a person internally that employees can go to to ask questions and make suggestions. It’s up to that key contact person to relay that information to us and work with us on creating a solution.
As you can see, working in an Agile way does require a lot of work from the client. While you might be hoping that you can just contract a developer to build you some software, you’re going to be getting a lot more value for your money if you are also fully immersed in that project process. We’d like to think that you’ll also be a lot more proud of the outcome and the product you’ve helped create, the ways in which you’ve been able to help your whole team work more effectively going forward. Of course, you can still develop a system using a waterfall methodology — but it will still take a long time, still cost money, and you might not like what it turns out to be — but you don’t have the opportunity to give that sort of feedback or change anything at the point it’s called ‘complete’. Of course, we’re biased, but we really think that being able to collaborate with our clients and adapt a project to their needs as they arise is surely the best way to create a great product. When it comes to our tech-heads, working in an Agile manner is all about working together, and less about cool acronyms and ping pong tables.
Originally published at https://www.hutsix.com.au on September 21, 2021.
