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,
Christopher Dawson, DVT, 011 759 5930,
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.
There are different opinions out there on best practices for developing RESTful services. Projects have different needs, developers have different opinions and HTTP has its limitations just like most other technologies.
Large organisations often struggle to achieve the benefits of Agile when deploying products that require enterprise-level planning and collaboration.