Behind every great IMQS product is a multi-skilled product owner (PO), hard at work outlining their vision, establishing goals and motivating their team. POs are the corner stone of IMQS product development, so we thought you should meet them. This month we introduce you to Jaco Botha – a keen implementer of Agile Software Development and the man behind all our engineering modules.
Product development at IMQS is built around Agile Software Development. We more particularly harness the power of Agile Scrum to manage tasks within a team-based development environment. Scrum can be considered a micro-level approach to project management that helps us to manage the many obstacles that plague Information Technology (IT) development teams.
Our product owners (PO) are key stakeholders in every project. The role requires a committed, business savvy decision-maker who is able to clearly communicate their vision and remain actively engaged with their team and their client throughout the lifecycle of a project.
Jaco Botha is one such individual. We asked the man behind our engineering modules - including our water and sewer infrastructure, water demand management, as well as electricity and roads modules - about his journey to product ownership at IMQS.
My background lies in programming. I have 13 years of programming experience in the desktop environment.
I later became a Business Analyst (BA), where I built up experience in product development, mainly focused on financial accounting software. I spent six years in this environment working for, amongst others, the South African Revenue Service (SARS) developing financial transaction applications. It was during this time that I also first started working in the Web environment.
When I moved to IMQS it did not only entail a geographic change – I was previously located in Gauteng – but a change in domains. IMQS builds applications for infrastructure asset management. Knowledge of any domain obviously makes your job easier. However, as it goes in the field of IT, successful product development is more firmly rooted in understanding and then mastering processes.
I believe that this is what I was able to bring to IMQS - the ability to manage the processes necessary to build effective software products, no matter the industry.
In the previous environments where I worked, product development was based on the Waterfall Methodology.
With Waterfall there is a lot of emphasis on getting all the specifications right up front before programmers are involved. We went to work designing the end product to field level. This would include, for example, database design and structuring, ERD’s, as well as screen layouts and interfaces. This meant that there was very little left for the developers or programmers to actually do. In some way, Devs became much like bricklayers.
The main problem with building the whole system on paper, so to speak, is that you can’t test it!
When I moved to IMQS, I was glad to be confronted by a new methodological environment - Agile Software Development.
With Agile we don’t go into as much detail during the analysis and design phase of a product. Agile requires us to ask different questions. Rather than focus on “how” we need to do something we spend our time clearly defining “what” we need to do and “why” we need to do it.
Within this framework I follow a very simple formula - define the goal, structure the plan and measure progress accordingly. By continuously being able to measure your outputs against your goals you are able to identify gaps. In so doing you continuously improve by learning from your experience.
Agile also requires us to work closely with our clients throughout the process. Effective product development, on the one hand, rests on keeping the expectations of the client firmly in sight. On the other hand, when a client changes their expectations, you need to be able to easily adjust your goals and plan.
At IMQS we have been really good at being Agile. However, we have also learned that being too agile can be counterproductive.
IMQS works mostly with municipalities. In this sense, our clients are very structured bureaucratic organisations that understand linear processes far better than fluid or networked ones. Our product development approach has evolved in relation to this environment.
Our product team has learned to strike a balance between the linear Waterfall framework and more extreme versions of Agile that are characterized by limited documentation and a lot of exploration. This is why our flavour of Agile has involved investing more time and effort into upfront requirements. In other words, clearly defining the “why” and “what”, as I mentioned earlier.
Our pragmatic approach has afforded us far greater success in translating our Agile framework into something more structured to deal with the needs of our clients.
My focus is to add value to people and to give people the tools in their hands to help them get their work done. The first thing then that comes to mind is that the products we develop at IMQS truly can, and do, make a difference to the country I live in.
On the ground level, our engineering products help operational teams to easily locate and isolate burst water pipes before they even go into the field to fix them. More broadly, our Project Control System and Asset Management Module help to build systems that can guide better financial and infrastructural management, as well as put checks and balances in place that hold people to account and in effect root out corruption.
Over the last three years I have also really enjoyed being a part of developing a cohesive unit for product development at IMQS itself. Being a PO affords you with daily challenges like sharing resources to get products delivered on time. With this in mind we have, over the last six months, made a more assertive decision to bring our POs into one room. This has helped to construct a collaborative environment where there can be a cross-fertilization of knowledge, energy and ideas on a daily basis. As a cohesive product team we have stand-ups that help us to share information and structure the resources across products. Working in this environment is a constant reminder of the true collaborative spirit in which product development at IMQS takes place.