Insights

By Karl Fischer

The business and technology world is undoubtedly undergoing an incredible journey. There is an avalanche of technology capabilities and opportunities that can seem overwhelming at first, but that wave of innovation is also one that is enabling success.

The traditional lines between "business" and "IT" have at the very least been blurred if not eliminated in organisations adopting the digital revolution. For these companies, IT is a business life-blood and business a heartbeat that drives demand for technology and requirements.

So how does IT become the Business Hero of today?

Having a roadmap (a "GPS" for millennials) to guide one would help, so here are the six advisory steps we utilise at DVT to assist our clients to understand digital and agile transformation context and become heroes to their business.

Step 1: Know where your business wants and needs to go.

Understand the opportunities and how they line up with what your business is trying to achieve.

For the digital (or digital aspirant) business, there are a few typical positions that you can identify and align with to provide the technology focus needed to enable achieving those goals. Consider Gartner's "Journey to Digital Business":

Source - Gartner

Knowing the goals and objectives of your business, then consider the maturity of your IT function and consequent ability to contribute.

KEY ACTION:

Know your business's key objectives and then align with and measure your IT activities toward achieving those goals. Develop your framework by positioning where IT is today for your business, and where it needs to be to make your business successful.

Step 2: Road trips are better with friends (Collaboration is the new normal)

In most established organisations, the IT function has evolved over time and is probably not identified alongside innovation and agility. If IT in your business is seen as the Innovator, then you are well ahead of the curve. But most departments will need to show a new dimension and practice conscious change management to reposition IT as a key enabler of the business.

A good anecdotal gauge is if there is a distinction between "business projects" and "IT projects". When there isn't, IT has "made it" into being just another key business contributor. Getting there often means bringing in "friends" with specialist skills and experience that can fast-track you into the technologies and processes that are enabling digital initiatives (Think cloud, social, mobile and analytics). More importantly, the nature of the engagement with your new best friends can well be different to consulting engagements of the past with the "experts", providing an expensive opinion as to what needs to be done. Ever had that experience where you were left wondering, "That's interesting, but HOW do we do this?"

At DVT, we look to establish a partnership with our clients that will see them function not just deliver on project objectives but gain the insight, skills and capability that will enable them to take the initiatives forward in the future. When our clients are better off, we've delivered on our partnership commitment. Our extended eco-system of partners with specialist skills ensures we are well positioned to provide a full-fledged solution. Digital is complex and extensive in scope. Bringing the right parties to an initiative, with the right attitude toward a common intent leads to better results.

KEY ACTION:

Find partners with the experience that compliments your team and where collaboration and knowledge transfer are part of the engagement.

Step 3: Get to know the roads (Ask someone who has been there before then review the options)

Leverage expertise both internally and externally to understand your tactical choices. Consider short little "trips" (experiments with the technology or process) that will give you a better idea of learning curves, ease of use and relevance to the key outcomes your business is looking to achieve.

Knowing there is more than one way to achieve an outcome (and continuing to look for options even after you have a favourite) immediately reduces risk about the investment you will recommend. It's important that IT has considered the alternatives and is providing an informed, business savvy opinion.

KEY ACTION:

Initiate "meet-ups" to talk digital and new ideas and open the invitation to both internal and external parties.

Step 4: Listen to the GPS. Guides are useful, but take the shortcuts

Expectations have changed significantly as to what is possible, what IT should be providing, and the speed at which solutions should be delivered. Fortunately, IT and technology have been innovating at a similarly dramatic pace. There is a multitude of technologies, methodologies and collaborations that can help IT shift its performance and rise to the challenge.

The Agile business may adopt a credo of "fail fast, succeed faster" but that's likely to create significant discomfort in the boardroom unless it's explained (and shown to be managed responsibly). Akin to looking for the shortcuts on the map and having the GPS recalculate the path to journey's end, the introduction of new processes, expertise and technologies can radically shorten the transformation of IT into a current and relevant digital business partner. There's no singular path to the outcome, so consider your options and start with small-scale initiatives on which you can build momentum and where success is probable.

KEY ACTION:

Look for short-term, manageable changes that can start to move your function toward the end goal state (effectively making change through bite-sized, right-sized initiatives).

Step 5: Look at the road, not the representation (Plan and then plan for change)

Expect to make changes and adjust your plans. Having a plan is great. Being responsive and prepared for a change in the journey needs to be standard practice (Agile in essence and action). All too often the adoption of Agile is used as the excuse for:

• lack of planning - "Agile is about doing, not planning" – False
• lack of documentation - "Agile doesn't use requirements documentation or value specifications or analysis" – False
• lack of outcomes - "Agile means we change to work on each and every new request" – False

In the context of the transformation of IT functions, management teams need to consciously manage the change being introduced into the function. Changes in methodology can be difficult to achieve if attempted as purely an IT change. Agile is manifestly NOT just an IT change in how projects are run.

As an organisation focused on Agile, both as a service to our clients and as to how we operate, we know that successful implementation of Agile is a journey best led by those who have been down the path (multiple times). It's why we offer Agile Transformation programmes to our clients and follow them ourselves, believing in an evolution driven by a shared Agile philosophy.

KEY ACTION:

Adopt a conscious programme of change management that intends to see the transformation of the organisation to an Agile entity. Note that just because methodologies like SCRUM have typically taken root in IT departments does not mean that everyone in your IT department (and certainly not across your organisation) understands Agile and is supportive of the change. Consider utilising a formal Agile transformation programme that has been implemented through other organisations and customise it accordingly.

Step 6: You don't need a car if you can Uber

There are key technology enablers that must be part of your thinking for enabling agility, speed of delivery and value delivery: Social, Mobile, Analytics and Cloud. Be aware of the platforms and capabilities that these digital enablers have provided and how you can leverage them for lower cost, rapid development (prototype evolutions) that can help quickly prove a business concept with minimal investment in infrastructure. These mediums lend themselves to collaboration with partners and customers which in turn can help you drive innovation and align with market needs.

KEY ACTION:

Look into the use of "multi-speed" IT (adopting different processes, team structures, and technologies to enable different IT supported areas such as "innovation" (what is wanted) versus "operational support" (what is in place). Service partners can then spin up short-term teams with essential skills to enable such initiatives and introduce fresh thinking.

As Dorothy famously said, "We're not in Kansas anymore", the landscape in technology continues to change dramatically and with it brings new dynamics that demand collaboration, innovation and agility to be successful. With IT being at the centre of this tornado, it's both a challenging and incredibly opportune time for leaders in this space.

The six steps discussed in this blog are how we at DVT open the conversation with some of our clients (collaborators) to ensure that investment in IT will secure both short-term and on-going success for their business.

Visualise the journey, choose your "friends" for the trip, and start your engines! Your business teams are already asking "Are we there yet?”

Sources and Recommended Reading

Gartner – Post Event Trip Report – Digital Maturity Benchmark Summary, 2014

Accenture "Driving an ambitious agenda to transform Accenture into a digital enterprise"

HBR "7 questions to ask before your next digital transformation", Barry Libert, Megan Beck, Yoram (Jerry) Wind, July 2016

Software testing or setting a test automation strategy enables continuous testing, leading to the desired return on your investment.

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.

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.

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

As business analysts in an agile environment, we tend to find that our requirements are guided and approved by the product owner.

Business agility enables organisations to innovate and deliver goods. Learn the framework for business agility and tips on improving it in your organisation.

In this article, I'll discuss how design teams can adopt Agile and use the Scrum framework to achieve delivery in terms of customer experience journeys, prototypes (low and high fidelity) and services blueprints.

The background

When I first joined the design office nine months ago I didn't have a clue how I was going to be a Scrum Master to a design team. I was unsure of end delivery from a full design perspective. From past experience, I was used to working with technical teams (developers, testers, BA’s architects and one or two designers).

The first few weeks were spent trying to understanding what the teams deliver and handover and this left me somewhat confused. I then remembered no matter what needs to be delivered, if the Agile principles are followed anything is achievable with the right team and skills.

Let's look at how the Agile principles were followed within the design team:

Principle 1

Our highest priority is to satisfy the customer through the early and continuous delivery of valuable software.

From a design perspective, testing is always an important task that needs to be fulfilled as the customer's experience is extremely important, which requires improvement regularly.

Principle 2

Welcome changes in requirements even late in development.

Agile processes harness change for the customer’s competitive advantage.

When business requires a certain feature to be improved, the team then works towards a solution. Pitfalls are noted immediately and the direction is changed.

Principle 3

Deliver working software frequently, from a couple of weeks to a couple of months, preferably on a shorter timescale.

The team always aims to deliver a shippable product or feature after each sprint which can have an immediate impact on the customer's experience. As an example, suggesting the removal of steps in the customer journey which can improve turnaround times.

Principle 4

Business people and developers must work together throughout the project.

As a Scrum Master for design teams, we realised that most people within the organisation don’t understand what designers do. We then started to include the relevant stakeholders and decision makers during the problem and solution discovery. The benefit - everyone is kept in the loop until the final product or feature is handed over. Additionally, it eliminates the pressure from stakeholders pushing for timelines as they are then aware of the process.

Principle 5

Build projects around motivated individuals. Give them the environment and support that they need and trust them to get the job done.

This also relates to Principle 4. Once individuals are enabled and trusted to deliver, they will do their best. In our case, the design team gained trust among each other and with their stakeholders.

Principle 6

Efficient and effective method of conveying information is face to face conversation.

The team was co-located however two of the designers were based in Cape Town which had no negative effect on delivery. The team used a tool called Zoom for all ceremonies, ideation sessions and check-ins which allowed for face-to-face interaction.

Principle 7

Working software is the primary measure of progress.

Teams should always strive for the primary objective - improved customer experience.

Principle 8

Agile processes promote sustainable development. The sponsors, developers and users should be able to maintain a constant pace.

Working together effectively and maintaining consistency with business stakeholders and decision makers was key to our success. Aim to deliver consistently for customers across different channels and platforms to improve the experience.

Principle 9

Continuous attention to technical excellence and good design enhances agility.

Our team learned to design with reusability in mind, questioning fit for purpose. If the experience designed does not fit the criteria then the approach is adjusted to be fit for purpose.

Principle 10

Simplicity and the art of maximising the amount of work not done is essential.

For this team it was simple: ‘Is it fit for purpose?’

Principle 11

The best architecture requirements and design emerge from self-organising teams.

Our team became accountable and responsible to each other. Our biggest fear was to disappoint each other in terms of failing to deliver. This meant that we were cross-functional and assisted each other from time to time.

Principle 12

At regular intervals, the team reflects on how to become effective, then tunes and adjusts its behaviour accordingly.

Our team had different skill sets such as UX, UI and service design. The youngest team member was 23 and the oldest is 51 and the level of respect and value this team had for each other was incredible. They were open to learn from each other and to handle criticism well. They didn't get attached to ideas and learned from past failures.

Lessons learnt

Agile can be implemented and followed in design successfully. Just remember to stick to the principles and it will more than likely come naturally to you.