Agile Software Balance using trophic cascade analogy: Learn how to strike the perfect balance in Agile Software Development with our expert insights.
Does building a mobile app make more sense than buying an off-the-shelf solution and customising it for your business?
There’s no clear-cut answer to the question, but it’s important to understand the differences between the two approaches as part of a broader mobility strategy. Unfortunately too many companies only ask the question after they’ve gone too far down the road with one or the other, spending time and money without getting a desirable outcome in return.
Exploring what your business needs from an app should always be the first step to deciding which way to go, and yet too few do the due diligence before calling the developers. Need CRM? Field service and facility management? BI dashboard? Chances are it has been built already, white-labeled and available for integration into your own hybrid environment without too much fuss.
Building a custom solution tends to be more expensive than retrofitting a ready-made app. The question then shifts to - what do you want the app to do for your business that is different to what’s already out there?
The point here is that the real purpose of a great mobile app is to provide the end user with the best possible experience of your company through their device. A banking app, for instance, becomes the primary interface with a bank, and in some cases becomes the primary way you do business with that organisation.
Looking at your app through your users’ eyes: what do you want them to see and experience, what do you need them to access, how do your want to transact with them? Is the app going to be little more than a static information portal, or will it give them access to dynamically changing content? Will they be able to generate reports and interrogate your business systems, or will they be limited to one-way communication with your support teams?
These are just some of the questions that derive from considering how your app fits into your broader business strategy as part of comprehensive mobility strategy.
Build versus buy is a decision that often somehow doesn’t factor much into the procurement process, and without sufficient research a convincing argument can typically be made for a bespoke application to be built. However, a solid R&D exercise in the investigative phase of a project will go a long way in addressing suitability and quality concerns. Look for apps from a vendor with a solid reputation, and license those accordingly where it makes sense to do so.
What’s not in question is whether or not you need to go down this path in the first place. It has largely become accepted that every company is a software company in one way or the other. If you’re not in software, if you don’t have a mobile app or a good web presence, you’re going to be ignored. Not every company necessarily needs its own app, but even asking ‘how mobile friendly is our website?’ could be a good starting point.
About DVT
DVT provides tailor-made software solutions and related professional services to clients throughout South Africa. DVT’s technology solutions include. Net and Java, enterprise mobility and data & analytics. Its range of professional services includes project management, business analysis, business process analysis, software quality assurance as well as Agile consulting and training. DVT’s product based solutions include Agile team management (Axosoft and Rally), performance testing (NeoLoad) and practice management (Thomson Elite). Visit us at www.dvt.co.za.
Editorial contacts:
Karen Heydenrych, Communikay, 083 302 9494, karen@communikay.co.za
Christopher Dawson, DVT, 011 759 5930, cdawson@jhb.dvt.co.za
Organisations often adopt agile as a way to challenge their status quo. However, if agile is only seen as a process or method to manage the agility of your teams without first changing the way you think, it’s not going to work.
Often organisations aren’t happy with the rate of delivery on certain projects. They have no transparency and realise very late in the process that they are behind schedule. When they can’t keep up with the demand, someone else always seems to deliver faster. That’s when things need to change, and they turn to agile for the answer.
Since agile teams deliver faster, they continuously improve, sprint after sprint. The teams’ velocity increases iteration after iteration, so the thinking goes that – if they can be measured by velocity – they can be managed when ‘slacking’.
This goes on for a while, but when the teams’ velocity starts to slip, someone else inevitably decides what the velocity should be. From that point teams start getting measured on stats, but without first understanding individual teams’ stories this can quite quickly instil fear. Fear kills innovation, which drives the wrong behaviour. Instead of being open and transparent, teams start telling management what they want to hear, hiding behind reality.
Managers need to change the way they think, which in turn will change the way they act. This is the key to agility: it’s a different way of thinking.
A stored procedure, SQL query or class does not overnight become easier when you decide to adopt an agile framework. Lines of code aren’t shorter than before; instead teams find ways to work smarter to deliver business value faster.
They become self-organising, guided by good leaders. Good leaders understand that when teams become more self-organising, they (as managers) might lose some of their ‘powers’. That’s a positive; they instead empower their teams to make decisions, building trust within the group.
Good leaders understand that they need to allow their teams to make mistakes, because they understand the importance of learning. For instance, if a team makes a mistake with a deployment to production instead of creating another SOP (standard operating procedure) or more governance, they will find a way together to make deployments easier. Instead of only deploying twice a year, they encourage their teams to deploy more often.
Daniel Ek, the CEO of Spotify, has a saying: Good leaders think like this: if we aren't failing then we're not innovating. We aim to make mistakes faster than anyone else.”
I recently had a conversation with a test analyst. She reported a bug in her company’s daily scrum. The developers said it is a new story, but she was adamant it was a bug. So she asked me how they should manage it, since she’s obliged to report on all the bugs.
Bug-story-bug-story… what does it matter? Set the priority and get it done. Often developers have some sort of KPI attached to the amount of bugs they code, and testers are rated on the amount of bugs they find. In both cases their increases or bonuses are connected to these stats. Yet we are blind to the behaviour this drives in our teams. No wonder they clash so regularly.
Let’s think differently. We’ll call it a ‘learning opportunity’ or a ‘cool story’. It might be a team’s first time building a specific feature and they are still learning. Other more senior teams may have built something similar hundreds of times before. So rather than managing the team with the bug stats report, why not think: they had several learning opportunities. Good leaders will also give open and honest feedback, not allowing teams to make the same mistake over and over.
Leaders understand that creativity lies in the midst of chaos. It is okay to have chaos every now and then. But in this chaotic state they allow their teams to manage themselves and won’t interfere or try to fix the situation unless asked.
They also understand that they don’t always know everything, knowing how and when to submit to a fellow team member.
I will never forget my early Scrum Master days, when I experienced leadership that changed my whole career. The CTO of the company I worked for asked me to investigate why a team best known for delivery suddenly stopped delivering. I did the investigation and took the results back to him, explaining what happened. He then asked for recommendations and my opinion on how to fix the problem. I gave him my opinion; he looked at me, said “go do it,” and walked away.
He trusted me, valued my opinion, and without second thought allowed me to experiment. He did not expect any solution the next day or even the next week, as long as we managed the challenges. Under his leadership, I had many opportunities to ‘experiment’ with teams, taking good teams and making them great.
Leaders don’t always have the opportunity to pick who will follow them. In organisations – unlike politics and sport – the followers don’t have the opportunity to appoint the leader; they either emerge or get appointed by management.
Why not allow your teams to pick their leader for a specific situation? Be the commander on the battlefield that allows his soldiers to call an airstrike. Magic happens when we take agility to the next level, by thinking differently from the norm.
Learn the essentials of becoming an Agile Business Analyst. Get tips and insights for effective transformation in your career. Read our guide now!
