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,
Christopher Dawson, DVT, 011 759 5930,
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.
Imagine this: you wake up in the middle of the night to get a drink. You don't want to turn on the lights because you're still half asleep, but you need to or else you won't find your way. Luckily your lights are programmed to switch on, dimly, if they detect motion towards the kitchen. By the time you wake up, around seven, your music system knows to turn on the easy listening channel. You also get regular updates on your indoor temperature, notified of suspicious activity on your property, and the sprinklers know when to chase the early birds away.
Now stop imagining, because I've just built this smart house for myself, and these are some of the lessons I learned while doing it.
The first challenge was finding the right platform – information platform that is. There is a great deal of data that needs to be sent around the home network, depending on the activities in question. My first choice was .NET, because that's my default for all things cool, but after just a few iterations I had a truckload of source code for very basic tasks – and I hadn't even started on the fancy stuff.
After much research I found an open source platform built on top of node called Node RED, by IBM. It's an event processing engine that excels at orchestrating multiple data sources and consumers.
This seemed to provide just the right amount of abstraction, allowing me to think in terms of what I wanted to achieve, rather than getting bogged down in hundreds of lines of code. It uses a graphical drag and drop approach to writing software, making it very easy to mix and match multiple data sources.
While I still needed to write a bit of JavaScript, it was fairly minimal and easily managed. I believe this approach to building software will catch on more as the internet of things (IoT) becomes more widespread. I have also used it to great effect while teaching absolute beginners how to code. You can check some of the nodes I wrote on my Github page.
Within a short time, I had my basic infrastructure set up, and the house was happily sending and receiving data via multiple online services. With a few drags I could wire up a Twitter feed to update me on the current temperature, push that data to mongo for storage or update my mobile phone when there was any unexpected movement inside. It's pretty liberating and fun to use.
The only drawback to this platform is node itself. Many of the packages I relied on for low-level tasks turned out to be surprisingly buggy, and my smart house would crash very often, too often to actually be useful. The best I managed was three days of continuous use, and this was on very good hardware. I expect stability will come with maturity, but for now, a healthy dose of patience is required.
The other challenge I faced was the availability of sensors and other IoT hardware. The South African market appears to be oblivious to this need, and the few shops on the web that sell sensors are way behind the state of the art, and their devices require a lot of electronic skills to use. Your only choice is to import these gadgets from overseas, and pay more than the cost of the device in shipping and duty costs.
I'm sure this will be resolved once businesses get on board and demand makes it profitable for people to sell devices. For now, you'll have to either cough up or pull out your soldering iron. On a more positive note, it seems that the capabilities of the devices being released are increasing at a much faster rate than when I started, and the costs are going down.
As with any software project, the last and most important aspect was testing. Testing a smart house is not like testing a website or mobile app. Unit tests do nothing to verify the overall correctness or robustness of the system, and actually increase the amount of code you have to maintain. There is usually so much going on that I found it easier to just do manual testing. I haven't found a great way to test the resulting product as a whole, but the platform I used helped to simplify my code into tiny bits of functionality called nodes which I could easily test with mocha.
Today I have a fully functioning and working smart house, built on the same principles we use every day in our software development and testing projects. It may have taken a bit more elbow grease and creativity to get around the logistical challenges, but it's encouraging to know the model can be replicated with great success beyond the web and smartphone.
There is general confusion in the business and Agile world about the differences between coaching and mentoring. One can easily be confused with the other given the similarities between them.
Some key authorities on coaching and mentoring (such as Clutterbuck and Megginson) argue that any attempts to polarise the two fields is futile and negatively affects both. I agree, and by shedding some light on these disciplines we can start to make sense of the delineations and overlaps.
Mentoring is said to have originated from the Greek mythology of Homer’s Odyssey in which Mentor is mentioned as an advisor to Telemachus, the son of Odysseus. The use of the word mentor entered organisational vocabulary through a seventeenth century book The Adventures of Telemachus by the French writer Fenelon. Fenelon portrayed Mentor to embody the attributes of a teacher, guide and counsellor - a definition which still holds true today. Over the ages we have great examples of ‘mentors’ by this definition: Sigmund Freud for Carl Jung, Haydn for Beethoven, Phil Jackson for Michael Jordan and Tina Turner for Mick Jagger.
The Online Etymology Dictionary suggests the term coaching originates from the ‘koczi' - a covered carriage or wagon that was originally invented in the village Kocs in northern Hungary. The wagon was designed to protect valued passengers from the elements on their journey through a rough terrain. The word coach in the context of a trainer or instructor is said to stem from the 1830’s, when Oxford University used it as slang for a tutor who ‘carried’ a student through the exam.
The greek philosopher Socrates is considered by many as the first significant coach. He made a valuable contribution to coaching with the Socratic method, which is based on open-ended questioning in order to encourage reflection. This method is now well integrated in the coaching philosophy and is focused on coachees generating their own perspectives and actions for addressing challenges.
The practice of team coaching has also become a popular intervention in recent years. In this case there is a fine line between coaching and facilitation. Although the approach may differ, the same basic principles apply in that the coaching will challenge certain beliefs and assumptions and use specific models to resolve a specific challenge.
Mentoring has long been a popular way of transferring knowledge from generation to generation. Today mentoring programmes are widely used in organisations both on an individual and team level. Mentoring is often associated with induction, career development, and as a support mechanism in career change. The agenda is determined by the mentee and may be of organisational or individual focus. The mentor does not always work in the same organisation as the mentee or protégé, but has an in-depth understanding of the challenges and issues the mentee has to deal with. The mentoring disciplines are less likely to refer to specific tools instead emphasises more personal qualities and abilities.
Coaching, on the other hand, is still very much in its infancy both from a practice and research point of view. The multitude of definitions, tools, theories and traditions that are attributed to coaching points to the eclectic nature of the discipline. Similar to mentoring, coaching has its roots in education, organisational development, psychology, counselling and sports.
Coaching is generally seen as a thinking partnership between equals where the coach encourages clients to create their own solutions, and develop awareness of conscious and unconscious behaviour and assumptions. Cavanagh (2006) argues that the purpose of coaching is to “push the coachee towards the edge of chaos, towards a controlled and managed instability, a condition in which human growth and change is most likely”.
Coaching approaches individuals holistically and cannot be optimal without taking all aspects of the person’s life into account. Business coaches do not only focus on assisting individuals defining their core purpose, strategies, developmental strategies, developmental strengths, weaknesses and obstacles, but also take all aspects of the individual’s life into account. Aspects typically included are meaning and purpose of their work, leadership, processes and systems and work-life balance (Stout-Rostron, 2012: 4)
As an applied science, coaching has a multitude of applications and prefixes, but could broadly be classified into two categories: performance (acquisitional) coaching and personal developmental (transformational) coaching. Performance coaching is more model driven and goal focused whereas development coaching has a purpose of development of awareness, skills, behaviour modification, emotional intelligence, personal mastery and transformation. David Clutterbuck argues that despite the plethora of coaching models and approaches the mature (system eclectic) coach has a liberated approach which includes a wide-ranged portfolio of tools and techniques.
It is worthwhile to take note of the conclusion of a recent study (Salter & Gannon, 2015) exploring the similarities and distinctions of coaching and mentoring. They suggest an alternative approach to seeking differentiation between the disciplines would be to embrace diversity in acquiring additional skills and applying the intervention best suited for the optimal outcome at a given time. They specify that the practitioner should be aware of the discipline and boundaries they are operating in and be contracted with the client whether the conversation is one of giving advice or incisive questioning.
In conclusion, it seems fair to say that when you need advice and expert knowledge from a more experienced person on a specific topic, you probably need a mentor. The engagement may be less formal and structured. From a coaching point of view, you can be expected to be challenged on your world views, limiting beliefs and assumptions in order to enable you to develop your own solutions rather than the coach providing them for you.
The coaching relationship is an equal relationship of discovery, where the coach is the expert on coaching and the client the expert in their field. In business coaching it is important that the coach understands the business domain to be able to ask the right questions. A coach may sometimes act as a mentor if needed, but only when specifically required to do so.
References
Bachkirova, T, Cox, E. & Clutterbuck, D. 2010. Introduction. In E. Cox, T. Bachkirova & D. Clutterbuck (Eds.). The complete handbook of coaching. SAGE, 1-20
Chapman, T., Best, B., & Van Casteren, P. 2003. Executive coaching: Exploding the myths. Palgrave Macmillan.Chicago
Clutterbuck, D & John Wiley & Sons, Inc., from The Handbook of Knowledge-Based Coaching: From theory to practice edited by Leni Wildflower and Diane Brennan to be published in June 2011
Demik, Randal J. 2007.Coaching, Counseling, and Mentoring: A Strategic Need in Training and Development. Online Submission, Paper presented at the Academy of Human Resource Development International Research Conference in The Americas (Indianapolis, IN, Feb 2007).
Du Toit, A. 2014. Making Sense of Coaching. Sage: London.
Eby, J.E.. Allen. T.D. 2007. The Blackwell Handbook of Mentoring. Blackwell Publishing Ltd
Grant, A.M., 2012. An integrated model of goal-focused coaching : An evidence-based framework for teaching and practice. International Coaching Psychology Review ●, 7(2), p.146-165.
Larsen, SL. 2009. Social construction on the road to transformation: applying rites, rituals and play to executive coaching. Submitted in partial fulfilment of requirements for the Doctor of Education. University of St. Thomas, St. Paul, Minnesota.
Passmore, J., Peterson, D.B. & Freire, T.,(eds) 2013. The Wiley-Blackwell Handbook of the Psychology of Coaching and Mentoring, John Wiley and Sons.
Salter, T., & Gannon, J. M. 2015. Exploring shared and distinctive aspects of coaching and mentoring approaches through six disciplines. European Journal of Training and Development, 39(5), 373-392.
Stern, L. R. 2004. Executive Coaching: A Working Definition. Consulting Psychology Journal: Practice and Research, 56(3), 154.
Stober, D R.,,Grant, A.M. 2006 , eds. Evidence based coaching handbook: Putting best practices to work for your clients. John Wiley & Sons.
Stout-Rostron, S. 2012. Business Coaching: Wisdom and Practice. Knowles, Randburg, South Africa.
This is a deceptively simple question because expensive means different things to different people. For a project manager, it tends to be that testing mostly is done at the wrong time, at the end of a project when budgets are depleted and fixing errors is time-consuming. For the call centre, it is the number of support calls from frustrated users.
In other words, do you and your stakeholders have the same definition of what expensive is?
My real point is that the concept of value is multi-dimensional. Thus, in order to determine whether testing is expensive, we need to consider all the dimensions. I think there are five key dimensions, which we can call the five Ws:
- What in general makes testing expensive?
- When is it expensive?
- Where is it expensive?
- Who makes it expensive?
- Why do we even require testing in the first place?
I am no expert on how to run a profitable business and satisfy all the stakeholders involved financially, but I have to admit that, as a quality assurance professional, I am surprised to find that those five Ws are not asked. It is as if business schools only teach people how to be successful when things are going well, and not to assess and mitigate risks. Maybe it’s easier and cheaper just to say “sorry”. I suppose I shouldn’t complain because this is probably why people like me have a career in testing and quality assurance in the first place!
To get an idea what I am ranting about, let’s look at a typical process which is generally ignored during planning because it is very unlikely that there will be sufficient control over information to measure effectively the tasks performed. The process I am referring to is the defect (bug) life cycle. How much does it really cost to fix a bug found during acceptance testing or in production?
Looking at the rough sample diagram above we can see about nine possible stages to a bug life cycle. On the right are lists of typical tasks performed during each stage. If you measure the effort spent, and the cost of the people involved you might be surprised with the numbers. Assume 25 bugs out of a total of 250 bugs need to be fixed by the end of a two week period. Will you be confident to release to production without measuring the current quality through testing?
Many times we are being challenged and struggle to show quality because it might only be visible in getting to production. Over the course of development, developers will be less likely to test all of the things that can go wrong. I think it is muscle memory by constantly focusing only on getting the code to work. This explains the theory behind the graph that is part of all test related training - bugs become exponentially more expensive to manage during the SDLC.
“How much is that bug worth to the people that matter?”
The irony is that little attention is assumed to guarantee quality according to the context of the system - until something goes wrong and it negatively affects someone. During crunch periods, there tends to be an increase in the total number of testers involved on the project. Sometimes the testers with the wrong skill sets are pulled in just to get numbers up and to add more eyes to the system. However, is it sustainable, effective, efficient, or repeatable? At times, you do require the rare skills of test specialists or a tester with a broad range of skills, but the contracting fees cannot fit in your already limited budget.
Many times I run into situations where people were employed for their personality and not for their skills to make the project a success. Add to that the costs for performance testing tools and environments. Security testing is not cheap either. There are design risks if globalisation is not considered and can result in a big rework. There is also that dreadful maintenance risk to keep the system running for the next 3 to 5 years. How much is red tape crippling the efficiency and effectiveness of testing in some businesses?
Remember too that some people using the product will exploit your system. If you are still not convinced then have a read on sites like CNET.com and search for the term “glitch”.
“Could it be an intentional blindness forced onto decision makers by society to ignore the negativity of asking “what if” questions?”
Obviously there will be solutions to many challenges, at a price of course. However, changing cultures and processes over a short period seldom go according to plan. No matter how much money you throw at problems, they cannot get solved in the desired timeframes.
I believe testing can become cheaper or at the very least become better. Bring the minds of the right people together from the beginning to ensure quality throughout the SDLC with the required levels of testing. Involve all the stakeholders, including the clients, to collaborate, set realistic goals and take responsibility for the quality.
Respect the role and responsibilities of each other in the team but also understand and accept the team’s capabilities.