Insights

By Willem Botha, DVT

With the ever increasing need for software development teams to react faster and deliver quicker solutions to problems, agile has become an essential framework to follow. That said, what is the role of the Business Analyst (BA) in an agile world and is the BA still needed as part of the team?

Let’s start at the beginning and go back to the basic definition of business analysis. According to the International Institute of Business Analysis (IIBA), a BA is a liaison among stakeholders to understand the structure, policies, and operations of an organisation, and to recommend solutions that enable the achievement of goals.

Thus the BA’s role is not centred on software; it is about suggesting solutions to business problems and enhancing processes. Software can be part of a BA’s recommendations which a stakeholder would then vet and forward on to a product owner for detailed evaluation as a product enhancement.

In agile when we are talking about a BA or agile BA, we are typically referring to the technical BA when software was part of the recommendation already.

Does the agile BA exist?

Let’s have a look at the characteristics of an agile BA according to the agile manifesto:

• Adaptability: Everyone associated with agile must be adaptable. However, the traditional BA has always needed to adapt to the business process, software development process or even a lack of process.
• Goal Oriented: The goal is to add value to the organisation by solving business problems. This is true for both the agile BA as well as the traditional BA role.
• Innovation: The agile BA, as well as the traditional BA, is looking for new approaches to solving the business problem and improvements to the business processes in which the problem exists.
• Leadership: Being an agile BA or traditional BA means taking the lead in providing solutions to business problems.
• Empathy: The BA deals with the business sponsor, customers, users, solution team, technical personnel and management. Both the agile BA and traditional BA need to exhibit empathy and understanding for all these roles.
• Business Oriented: While the agile software development team is focused on the technological issues of producing working software every two weeks, the agile BA needs to provide the business justification. This has always been true for the traditional BA.
• Anticipation: The agile BA, as well as the traditional BA, must be thoroughly familiar with the problem domain, the business area in which the problem exists and to anticipate positive and negative impacts to other areas of the organisation.

Based on the characteristics listed for an agile BA we can see that there is clearly no difference to the traditional role played by the BA. So if the agile BA does not exist, do we need the business analysis role in agile?

The answer is a definite yes! But, why am I saying this?

Let’s look at what the most successful agile teams have in common:

• Everyone in the team understands the “Why”.
  • In the agile world, the BA needs to manage the communication channels with business to understand “why we are working on something.”
  • The BA needs to foster a shared understanding, thus a two-way communication flow between development and business.
• Teams can make faster decisions by getting answers quickly.
  • With distributed teams where product owners sometimes oversee multiple projects, the agile BA understands the product vision to provide the answers to questions from the teams.
  • On smaller teams, the product owner and agile BA role are played by the same person. However, the focus is still on clear communication to all team members.
• Although the BA role might not exist in the agile team, the skills associated with a BA is still needed.
  • In smaller teams the product owner may have the required BA skills, making the BA role redundant. That said, the product owner role is usually played by the BA.
  • In bigger teams, the agile BA provides the detailed requirements for the different product owners.
• The development team still needs someone to take the lead in analysing business requirements and facilitating the process with business.
  • Keeping the noise away from the team and providing clear prioritised work for two-week sprints.
• There’s still a need to facilitate requirement sessions and documenting these requirements clearly.
  • Where detailed requirements are necessary, documentation needs to be based on a set template for the team following Unified Modeling Language (UML) standards.
  • The team decides when detailed requirements are necessary. However, documenting the business requirement is still required for new members joining a team.

Now if we are saying that the role of the BA might not be needed in an agile team - but only the skills associated with the role, are developers able to play this part in the team? I asked the development community I work with to provide me with answers to this, and it was clear that it depends on team dynamic and the size of the project.

Team dynamic

• If the team has dedicated developers, then they cannot play this role. They have to wrap their minds around difficult technical concepts. They will not be thinking in abstract or general terms and will be busy with the specifics.
  • A representative for the business requirement is still needed. Someone must have a clear singular focus on the business need and guarantee that this prerequisite is solved and achieved.
  • Sometimes if not done correctly, developers will solve problems that do not exist or invent their interpretation of the business requirement.
• If you have a team of agile people working toward a common goal, where each person does what is best for the project and team at any given time, then yes, the same person who writes code can also perform the function of business analysis.

Nature of the project

• With bigger projects, the role of the BA is better suited for requirement analysis and documenting these requirements in advance, with the development team left to focus on the work in the current iteration.
• Conversely, there are smaller projects where the development team could easily just sit with the business owner and understand the full scope of what is needed.

Business analysis should not be focused on software thus falling outside of the agile process. The notion of an agile BA is not new; it is still the traditional role played by the BA. Moreover, once software has been identified as a solution the BA or technical BA role is still needed in the agile team.

The core principles of the BA role still exist and are needed by the team. Agile has merely freed up the BA to be a BA, instead of a technical BA. These core principles are:

• Facilitate communication and understanding.
• Set team objectives per iteration.
• Fill the role of the business owner or Product Owner proxy

The need for quality analysis in a world of increasing change and technological complexity is high. The role of the technical BA does not have to be a particular person. However, the responsibilities of the role should not hamper delivery from a development point of view.

Agile has also changed the way the BA plays his or her role. The amount of analysis has changed - BAs only do what’s necessary, ensuring that there is no waste in the analysis process.

Focus on T-shaped skills

According to HRZone.com, T-shaped skills describe specific attributes of desirable workers. The vertical bar of the T refers to expert knowledge and experience in a particular area, while the top of the T refers to an ability to collaborate with experts in other disciplines and a willingness to use the knowledge gained from this collaboration.

What does this mean for the business analyst? It means being more aware of the customer journey; what problem needs to be solved, why business needs the product and ultimately how customers will use the product.

Finally, influence the team dynamics by working closely with the product owner, development team and business to help establish a shared goal.

At the end of the day, it is the goal and not the role that is important. It is also clear that the business analyst has an essential role to play in an agile world.

I tend to simplify. Perhaps over-simplify. Ask my 14-year-old daughter how often she hears “That’s really quite simple” to which she has to answer, “No, it’s not.” She’s probably right, however, given I’m older than her, I have a decent shot at being right. At least once. Perhaps it’s this time when considering just how simple all this new tech capability is in the digital business world. Really! Hear me out. (Stop rolling your eyes.)

Selling the Drama

I love the band LIVE. Their track “Selling the Drama” includes the verse,

I've willed, I've walked, I've read
I've talked, I know, I know,
I've been here before, yeah

Incredibly relevant to simplifying things (and my posts). Mantra: It’s been done before despite all the new talk.

Hype seems to surround tech advances these days more than ever. I think the Gartner Hype Cycle should reflect a MUCH steeper and MUCH higher front end to the peak of inflated expectations. The Hype Cycle is a great litmus test for the “fake news” of how AI / blockchain / (substitute new tech here) is going to solve all problems, take all jobs, get absolutely anyone elected to President. The BOTs have arrived, People. Ask them to take you to their leader. Who is that? Amazon? Google? Facebook? Apple? All plausible candidates. Perhaps look for whoever is SCL’s (Cambridge Analytica’s parent) next big client. Not sure what that last reference is about? Conversation for another day / post.

Back to topic. Simplicity in the face of tech hype. Gartner was already mapping the transformation of business in 2014 due to the “Nexus of Forces” (SMCI – social, mobile, cloud and information). 2014, that’s so long ago right? Have those elements been replaced now by BOTs, AR (augmented reality), ICO’s and Thinking Machines? Yes, the acronym would be BAIT. Wonder why? Simplified view (an opinion with which you are free to disagree – please do) is that no, the big trends of SMIC are still the major trends. They have spawned new focus elements (BAIT are examples) and will continue to do so at speed. Probably almost as fast as the changing value of Bitcoin. Is it really that difficult to stay up to speed and leverage the new opportunities in these and other trending technologies? Again, no. Not when you can over-simply as I do. Hence the easy as Ai, Bi, Ci.

Easy as AI, BI, CI

Any reading (meaning YouTube search) on AI will point you to the fact that AI has been around for a long time. Like more than a year! (That’s my Daughter’s comment.) The flood of exposure in the media and online platforms is just a reflection that the tech has found its way into (early) easy to try / use formats. Google, Microsoft and Amazon all have incredibly capable variants that are made available for use through UI driven configurations. Yes, UI driven. Fill in the boxes, point to data, submit. Watch machine do smart things. The end is nigh. Except not. ML has been around for a long time. The algorithms were just tough to create, needed huge processing power and required stuff the rest of us mortals avoided: math and stats. Yuck. But now that’s hidden behind a nice shiny wrapper of cloud computing and add-ons (billable). So, we now all have access to do smart analysis and use correlation. However, what to do with that new hammer? Are you looking for a nail or do you have one? Other aspects of AI similarly are becoming incorporated easily into process/applications. As examples NLP (natural language processing) is ubiquitous (just ask your smartphone) and available as a service for incorporation into your business processes (think online support chat by BOT). More? Computer vision and robotics in warehouses (ask Amazon), Ad targeting in Facebook and Google, AR apps on the App Store. All too simple?

Business Intelligence (BI) similarly has been a part of the corporate landscape forever. At least as long as Internet Dinosaurs like myself remember (I am a fossil in current Internet age terms). The accelerator these days is that the tech has moved the capability from the IT department (“give me a report please IT”) into the hands of the business users (“I’ll do it myself thanks with Excel / Power BI etc.”). Fantastic. Faster, better, mobile, more. Bad decisions made with confidence based on bad data. Damn. Thought that does point out the new role for IT in partnership with Business: effective Data Stewardship and Data Strategy. Modern BI capability is available via instant online subscription and comes with immediately available AI links by the way. Imagine that. Challenge is, as before, do you know the right questions to be asking of this new analytical wonder? Do you have the data you need? Is that data complete, accurate and secure?

CI (Continuous improvement) is my last pick in justifying my “it’s all easy in digital” throwaway statement. With links to six sigma and subsequent variations, the change in accessibility and capability nowadays is absolutely stunning. You can learn about CI in bite sizes of your choice on YouTube. Enough to understand what it is and… plug into a platform that will do the work for you and present the analysis in pretty pictures. Dinosaur-day processing constraints that necessitated sampling data (n=20 right?) are gone. We have scalable cloud processing and storage. Just process ALL the data. Now. No sample. Technique of analysis: leave it to the machine to find the best statistical fit. What was your hypothesis again? That’s probably still the most important question. Also, the human element that requires some creativity and intuition to get to an analysis that will deliver value faster. If you always do what you have always done, expect similar results (until someone eats your lunch). If you leverage CI, you seek improvement, innovation, revolution and becoming the moving target. Just move fast. Remember Bitcoin.

Value (forget the rest, read this)

Hype is greater than ever surrounding new tech and its progression. The speed and seemingly SCI-FI type new capabilities (Googles AlphaGo) astound on a daily basis. Despite the new acronyms (we in IT and Consulting make a living out of those), the new things really are just old things made easier. That’s good news. AI, BI and CI are phenomenal levers to apply in your world (business or otherwise). Their ability to help drive innovation, improvement and revolution are limited only by their maturity (check the Hype Cycles please) and the creativity of us simple users. Start your process with the simple question “What value can I deliver and where is the opportunity to find that value?” (Don’t tell the machines this. It’s our secret advantage given we can actually answer that question.)

We all got a lot smarter, faster and capable thanks to first knowing our ABC’s and now our Ai’s, Bi’s and Ci’s. Need a plan of attack for what to do next? See my next post or check YouTube. It’s probably there already in a perfect 2’35” clip by some BOT that just parsed this post. But then you already knew that given you had SIRI find and read this article to you, right?

It takes particular skills and an understanding of the software testing world to be a great tester. One needs technical know-how, the ability to identify the top trends and of course software testing savvy. These are skills that can be learned and practised over time. However, there is one other requirement which is often lacking - passion.

Every once in a while, we pause our hectic work schedules, take a step back, and reflect on what it is that we’re doing, why we’re doing it, and how we can improve. A big part of this process for us as software testers is identifying the most common issues our customers face, so we can better assess the steps we’re taking to solve their problems faster and more cost-effectively.

In today’s increasingly competitive business world, we don’t have the luxury to roll out new products and projects in six weeks, let alone six months or a year, as was the case in the past.

Gain insights into digital transformation decision-making with DVT. Learn how IT trends impact business strategies and stakeholder decisions.

The successful shift to being an Agile organisation isn’t just about training; it’s essential to have a smart approach to people change management.

Have you ever wondered just how far you could take your business with an Agile transformation?

I often get asked this question by clients that have undertaken to transform their businesses with Agile, but while Agile is indeed a transformative process, it’s also far more than most companies realise when they sign on for the ride.

Agile is not just an IT framework. It’s more than just a ‘new way’ of doing projects. In fact, when I speak of Agile, I’m referring to five fundamental and very different aspects of the concept as a whole: people, process, leadership, structure and culture. Before I can answer the question – how far can you go with Agile – let’s first consider these five pillars of Agile in more detail.

People

This is probably the easiest aspect to grasp and simply speaks to how we treat one another and how we view our people and staff as an Agile business. Agile is totally people focused, empowering and liberating, so this pillar is key to the success of an Agile way of working. Agile enables people to be fully engaged, at their best performance and responsive.

Process

Agile is not linear. There are different frameworks and methodologies to choose from, all of which form part of the process we ultimately decide to follow. These frameworks are there as a guide to help us reach our goals as an Agile organisation. The purpose of the various frameworks is to get us into a habit of doing things differently and to be more relevant to the market and responsive to change.

Leadership

Agile defines leadership as the positive, empowering and supporting influence you have on people, and the feedback you receive in return. This only occurs within the context of a relationship. In contrast, active management is focused more on what you can get from your people because you pay them.

Structure

Agile calls for an organisational structure change where people are loosely coupled but tightly aligned, thus able to make lower level decisions while staying consistent in what we are trying to achieve as a team. As long as the vision is shared, it’s up to the team to find a solution and drive the delivery.

Culture

Probably the most important but least understood of all the pillars, culture speaks to factors such as autonomy, ownership, freedom and innovation. A strong, agile culture exists when direction doesn’t need to be given on a daily basis, only guidance since the vision and goals are shared with the team in context. Agile breeds a no-fear culture, where the business through its people isn’t afraid to fail to succeed.

Now that we have a handle on the five pillars that make Agile what it is let’s look at the three components that support every Agile transformation: mastery, purpose and autonomy.

1. Mastery.

You want to enable your staff to master this thing called Agile, what it is, and what it’s not; what it means to your organisation, the governance you need to put in place to steer the course, and ultimately how to navigate your new Agile business. Things like Agile Training, consulting sessions, directions and transparency during the journey are key.

2. Purpose.

There’s a purpose behind every Agile transformation, programme and project - not only at an organisational level but also on a personal and interpersonal one. There’s an overarching purpose – to make the business more successful, or to break into new markets, for example, and also a softer purpose – to make a difference in people’s lives or to make it easier to achieve their career goals. Whatever your purpose, it’s important that people buy into it and that it is common knowledge. I’ve often heard of people who gave of their time or joined organisations for free because they bought into its purpose and what it was trying to achieve, simply to be part of it.

3. Autonomy.

This is self-explanatory – and also self-perpetuating. If you’ve mastered Agile and have a well-defined purpose, you become autonomous based on trust. As a leader, I share the value of appointing people you trust, and trust them to get the job done.

Now that we understand how an Agile transformation works in relation to the five pillars of Agile, we can start to think in terms of Agile maturity. Companies undergoing an Agile transformation are typically graded by where they are on the Agile Maturity Curve. There are six grades along the curve: limited, evolving, responsive, continuous delivery, value-driven and beyond Agile.

All but a small number of companies starting their Agile transformation journey or setting off from a large and cumbersome legacy base find themselves at a level one (limited) grade. Even fewer will ever go beyond Agile, which today is epitomised by the likes of Google, Facebook, Apple, Spotify and other industry pioneers that have redefined what it means to be Agile. Most companies fall somewhere in-between.

Like most things in Agile, there’s no hard and fast rule on what makes one company ‘responsive’ and another ‘value-driven’. There’s an old saying that says ‘you don’t know what you don’t know’. Most Agile ‘sponsors’ are also high-level managers that have been with the organisation for a long time and don’t have a context on what should be done differently to how it’s always been done. Often the company’s people and processes are very mature, but the leadership – in Agile terms – is not. Alternatively, everything else is in place, but the organisational culture is keeping the business anchored.

This is where astute mentorship is key, because Agile maturity isn’t just about expensive training and leadership courses, but rather focused on coaching in the areas that need strengthening or alignment. Looking at the Agile Maturity Curve will give you a better idea of what the end goal looks like and focusing your budget appropriately. Sometimes it is more spent on change management and influencing the culture, as appose to Agile training and coaching.

Surprisingly, most of the change will come with the ‘softer’ aspects of Agile – how you treat people, enable people, lead people. An Agile way of working in an Agile organisation often lies in finding the right level of collaboration and communication. Sending your staff on an Agile framework course won’t teach them how to be Agile. Soft training and Strengths-based training will assist in this area.

Take a longer look at the organisations that have truly gone beyond Agile, and they’ll all put their success down to the ‘softer’ aspects of kindness and trust, a sense of belonging and ownership instead of a process or management focus. It’s very different to the conventional way of thinking, and how we traditionally get people to move in a certain direction, but there’s also no question that it works.

So how far can you take your business with an Agile transformation? Tread softly, and before you know it, you will have a friendly, learning organisation which is engaged in the organisational purpose - operating as high performing teams.

About Melani French
Executive head of DVT business enablement

 

This article was published exclusively on ITWeb on 3 July 2018.

What topic gets raised by just about every management consultant, psychologist, counsellor and often your line manager? It's communication, defined as 'a two-way process of reaching mutual understanding, in which participants not only exchange (encode-decode) information, news, ideas and feelings but also create and share meaning.

In today's competitive business landscape we often hear that innovation, new technology and digital transformation is the answer to success. However, a critical element for any business to succeed ultimately lies with its people and how they communicate with each other.

So what are the right ingredients to building relationships and creating quality conversations? What makes an Agile team successfully work through daily standups, sprints and retrospectives? At the same token, how do we improve the collaboration between the various teams in a Waterfall environment? The one key element is trust. If we trust an individual, we are more open to ideas and new ways of thinking.

A new field developed by Judith E. Glaser called Conversational Intelligence (C-IQ) shows what it is about conversations that trigger trust or distrust. Thanks to advances in neuroscience we can understand that every conversation has a specific physiological impact. Some discussions can make us feel good or bad because neurochemicals released in our brains affect how we feel.

C-IQ is not about how smart we are, but how open we are to learning new and effective powerful conversational rituals that prime the brain for trust, partnership, and mutual success. If we look at working in an Agile way, effective communication is essential for teams to deliver consistently. One of the Agile Manifesto's core values is individuals and interactions over processes and tools. "Give them the environment and support they need, and trust them to get the job done."

C-IQ lies at the heart of building trust. A safe environment without fear is required to achieve this. By tapping into C-IQ, conversations trigger different brain activities for constructive communication. (That's the feel good and trust or distrust moment)

Some of the benefits of utilising Conversational Intelligence include:

• To activate better conversations and connect with others in a healthy and productive way. Breakdowns often occur when people talk past each other, not to each other.
• Down-regulating behaviours that activate the ‘fear’ hormone and up-regulating behaviours that activate the ‘bonding’ hormone.
• Being able to listen to connect and to not wonder what your next words will be in a conversation.
• Learning how to deal with unhealthy conversations and moving from judgement to appreciation.

All these benefits ring true to working in the software development environment. C-IQ supports a shift from “I” to “WE”, the basis of working effectively in teams. Business people and developers must work together daily throughout the software development process. The Agile Manifesto and values emphasises the role of conversations.

It is clear from the above that conversational intelligence is also a key competence for Business Analysts to have since conversations and building trust are at the core of their work.

Sound research has been invested in C-IQ based on the neurochemistry of the brain through conversations. It is up to us to discover how to build on relationships with our colleagues and teams.

Carina Fourie will present on Conversational Intelligence – the neuroscience behind conversations at the upcoming BA Summit on the 2 October at 10am. To register, click here: https://basummit.co.za/

The DVT Academy offers Conversational Intelligence Workshops to organisations and teams. Click here for more information: https://www.dvt.co.za/training-courses-conversational-intelligence-skills-development