Author: Jon Derbyshire

The Death of the Traditionalist

Written by Jon Derbyshire on June 28, 2018. Posted in Articles.

In the same way innovation is leading to disruption in the tech industry, so too will individuals in traditional roles continue to innovate, experiment and try new things.

This is a good thing! It really is. Innovation and experimentation often leads to big wins or changes that further industries, professions and companies.

However, along with innovation comes failure. ‘Fail fast, fail often’ seems to be the new mantra of the start-up industry, and it’s also bled significantly into agile environments. It’s become an acceptable practice in companies all over the world, but we must remember…….failure is still failure even when we learn from it.

There is a fine line between risk and recklessness. Measured risk can have big payoffs. Measured, being the keyword.

How Does This Affect Me?

Business analysis, at least in terms of how it is viewed nowadays, is still a relatively young discipline. As such we have a great scope and willingness to embrace new methods and ways of working. Over the past 5 years, there has been a huge increase in the number of business analysts calling themselves agile business analysts. I too am guilty of this despite having more years working in waterfall than agile.

Death of the Traditional

I love what I do, and because of that, I spent a lot of time absorbing new materials related to the practice and wider industry. From traditional means such as books and blogs to newer modern ways including webinars and podcasts. All of these channels offer great value and insight for learning and are largely driven by the contributor’s experience of successful practices.

What I find much rarer these days is hearing stories of the times when the analysis was wrong or failed to offer value. These examples tend to only come up either from individual 1 on 1 conversations, or as part of examples from materials aimed at newer business analysts just starting out, on what to avoid doing.

Reading between the lines, it appears to me that some of the more traditional methods, once applied as best practices, are slowly dying out. As such you rarely see them mentioned in articles, posts or examples from the last 5 years or so.

I’m talking of the techniques I once studied 17 years ago at university or applied often in the early stages of my career when the business landscape was very different and the internet was still in its earlier and often frustrating stages, such as SWOT, PESTLE, MOST and CATWOE.

These seem to have been entirely replaced with modern techniques evolved for more modern and agile times such as user stories, use cases, wireframes, story mapping and MoSCoW.

Don’t Count Them Out Just Yet

Maybe one of the reasons for the decline of these models may simply come from the natural evolution of the business analyst cycle. Many of the industry veterans who got their start and were ingrained in these methods have gone onto bigger or different things. Those who came up or into business analysis in entirely agile environments probably haven’t ever been shown the more traditional/older models. Innovation has won out and is enabling BA’s in modern day do a very good job using only the newer sets of tools.

Innovation of Old

Fashion trends, language and pop music all seem to experience cycles. What was once in style, went and of style and then had a revival. Maybe the same could happen in the business analysis industry.

OK, that probably is a step too far. But what if, the innovators and those looking to continuously adopt new methods to try, innovated by reviving the traditionally taught models

Example 1 – MOST

For those unfamiliar with MOST analysis, it is a model used for evaluating whether the internal project you are working on is aligned to 4 main corporate strategies

Mission – Where does the business want to go/purpose of the business.

Objective – Goals of the business.

Strategy – High-level approach to achieving the goals.

Tactics – Means to implement the strategy.

I don’t really see MOST used much these days but without any deep background, it’s quite easy to see its relevance to modern and agile environments.

Imagine that you are working for a game development company. Your company has a vision or a goal driving it towards where it wants to be. You’re working with product owners, product managers, basically all the main stakeholders to come up with games to pitch to the company owners. You’ve brainstormed lots of ideas and now it’s time to build the business case for each. Applying MOST analysis to your game ideas can a modern day take on the traditional MOST analyst.

Let’s actually apply MOST to a real-life example (made up on the spot to demonstrate the ease of use). Let’s take Rockstar Games – the originators of Grand Theft Auto and red dead redemption. Imagine it is the early stages of the company and we are going to look at whether the game ideas being pitched will fit into the company ethos build using MOST. Those which do will be taken forward. Those that don’t will be scrapped before wasting the founder time.

Mission – To develop games the founders would want to play that doesn’t conform to the rules or standards current games developers are working within.

Objectives – Develop whatever they want, whenever they want and not have to answer to anyone.

Strategy – Create in-game controversy / real world feel / give the players moral choices but with complete freedom to destroy traditional morals.

Tactics – Gorilla marketing strategies /controversy in the news / word of mouth

For anyone who has played, seen, or heard about grand theft auto you will know that the game would have been a resounding YES. Whereas, if you were to be reviewing a pitch for a game like ‘The Sims’, you would have likely rejected the game pitch before the presentation stage and gone back to the drawing board.

Example 2 – PESTLE

PESTLE analysis is used to evaluate the environmental factors which impact a company. It’s a great tool to apply when thinking of starting a company going or moving into an established market. Something which probably happens more than ever in modern times. Providing a deeper understanding of certain areas which will need a more robust and comprehensive analysis done before going to market, PESTLE helps to focus on the important facets within 6 main attributes:

Political (current and potential influences from political pressures)

Economic (the local, national and world economy impact)

Sociological (the ways in which a society can affect an organization)

Technological (the effect of new and emerging technology)

Legal (the effect of national and world legislation)

Environmental (the local, national and world environmental issues)

And again let’s apply it to a modern company. This time I will pick a young company proving extremely popular in the fitness industry at the moment – Gymshark

Political	Must be aware of taxation rules around new and growing companies Pressure is being applied to the government to increase health and fitness initiatives Increased political volatility across the world
Economic	The weakened pound may increase costs of purchasing from other countries Potential difficulties on securing finance in a difficult economy Inflation Pressures Retail struggling and consumer spending being squeezed Traditional marketing being replaced by social media marketing
Sociological	Must be fashionable and appeal to modern day influences (i.e. youtubers and Instagram fitness accounts) Sizing must not alienate large parts of the demographic. Need to remain independent and not flood the market devaluing its niche appeal
Technological	Modern fabrics cost more Must use flattering cuts The delicate balance between fashion and function
Legal	Must compete with mainstream competitors without infringing on any copyrights Health and safety rules
Environmental	Environmentally friendly packaging Environmentally friendly policies are a must

PESTLE isn’t ground-breaking, but it does highlight areas of analysis that will need significantly more analysis. Its application to agile is just as relevant as it is to waterfall. It can be applied at strategic or product level. If nothing else it highlights potential issues and risk for the risk register and for teams such as development, design or logistics to consider.

Innovation through Foundation

As with all innovation and evolution, what sticks will be that which tends to work. In today’s continuous improvement focused environments such as software or infrastructure, we all need to be trying new things and applying new knowledge.

But let’s not leave behind all of the foundational techniques business analysis was built on. Let’s consider innovating through brilliance at the basics as well as new innovation. Applying modern takes to traditional models can really add value and prove fruitful. After all, despite it being a much different time, these foundations built the industry that all brought us to this point. They shouldn’t be discounted or left out of today’s application.

The BA Skill Set – The Growth Mindset

Written by Jon Derbyshire on June 7, 2018. Posted in Articles.

How many of you know people in their roles who are doing things the exact same things they were doing years ago, without ever really improving their delivery or results?

The best advice I could ever give is to never become that person – you will only look back and regret the time you wasted.

I know first-hand, because I wasted a number of years being that person. Luckily, I was able to make changes and have never looked back since.

“Turn your face to the sun and the shadows will fall behind you”
– Maori Proverb

There are many different ways into the role of a business analyst. Some study business or a similar field and specifically pursue business analysis. Many others tend to be subject matter experts within a company and are transitioned into the role, sometimes by accident.

“If we’re growing, we’re always going to be out of our comfort zone”
– John Maxwell

The one key factor for ongoing success in both, is developing a growth mindset.

But that’s just the latest buzzword… right?

Whether you believe this or not, the fact remains that the philosophy behind the growth mindset is still both accurate and true. Decades ago, people rightly believed that you needed to get a job, work hard, keep your head down and you would be rewarded. With the explosion of the internet, entrepreneurship and the start-up mentality, the old way to success has been blown out of the water.

“If opportunity doesn’t knock, build a door”
– Milton Berle

The next generation of business analysts have a huge advantage; this is the only way they know, and they are good at it. With information now so readily available, and so many channels available for learning, they will one day be the industries’ thought leaders. Don’t get left behind.

But what about all the experience I’ve gained? That can’t be for nothing?

Experience is essential. No amount of learning can replace experience. But the key driver of future success is combining that experience with ongoing learning.

“Once you stop learning, you start dying”
– Albert Einstein

Whether you are the foremost expert on your subject area, or you are the only person with a deep understanding of your company’s key systems, you have to continue to improve. You need to continue to learn new skills, to further expand your knowledge, and also to help guide others with less experience than yourself, as they continue to improve and make an impact.

But how can I build a growth mindset?

This is actually the easy bit. There are a few key factors to building a growth mindset.

a) Reframe your thinking – Rather than going through the motions and delivering in the same way you always have, take a step back. At every opportunity think ‘what are we trying to achieve’ and ‘what don’t I know that could be holding me back’. These two questions on their own will really allow you to step back and think about how you are presenting to different audiences and how you can tailor your delivery to their needs. The second question, often overlooked, is often a strategy of strategic thinkers. Harvard Business Review magazine often states strategic thinking is the primary skill missing that will hold back senior managers from achieving the C-suite roles they covet. This question will help you anticipate gaps in your analysis and pre-empt questions you may later encounter. It’s a fantastic skill to develop at any stage of your career, and one that will benefit you and your employer no end.

“If you don’t know what you want to achieve in your presentation, your audience never will”
– Harvey Diamond

b) Embrace failure – People who see failure as a learning opportunity are people that, like compound interest, will always improve at a greater rate over time. Whilst failure can have catastrophic consequences, failure cannot always be avoided. Using mistakes as a learning platform is a powerful mindset shift which leads to growth. In 1985, Apple fired Steve Jobs from his position as CEO. He was rehired in 1997 and went on to become one of the most successful CEOs of all time. Everyone makes mistakes, it is how we handle, learn from, and come back from them that is the true testament of a growth mindset.

“Failure is so important. It is the ability to resist failure or use failure that often leads to greater success”
– J.K. Rowling

c) Create habits – A growth mindset can be developed simply by developing habits of learning. If you turn learning new things into a habit, you can create a habit loop. Eventually, you will thirst for knowledge. In his book ‘the Power of Habit’, Charles Duhigg states that: “Once a small win has been accomplished, forces are set in motion that favour another small win.” Simply learning one new thing a day will develop a growth mindset. Every day you learn is an opportunity for you to improve.

“Successful people are simply those with successful habits”
– Brian Tracy

d) Learn from everyone – Understanding that everyone is able to teach us something we don’t know is critical to growth. It’s not just those people with more experience or those who we look up to, who can teach us. Approaching situations as if we knew nothing about them can often lead to learning things we hadn’t realised we missed. A well-known technique in business analysis is called ‘the 5 whys’. For those who don’t know, this techniques states, if you ask someone why 5 times, you will get to the root cause of any problem. Albeit simplistic, anyone who has used this technique in the past can attest to its effectiveness. Learning from everyone will open up your growth potential and ensure a 360-degree learning experience.

“Everyone you will ever meet knows something you don’t”
– Bill Nye

But what if I’m still struggling? Am I just incapable of building a growth mindset?

For many people, the growth mindset can feel elusive. Change can be hard, especially if you are naturally resistant to change. The chances are you are only stuck because you fall into one of the following categories which can block a growth mindset:

a) Pride – you have been doing this a long time. Admitting you still have a lot of room for improvement is difficult, but it just takes one moment of learning to help spark the shift in mindset you need. Aim to learn one new thing or technique a week to start with. The more you learn the more you will start to see how you can apply the learnings in your day to day role. Combine this with your experience and think back to how you would have handled past situations had you known this. If you would have done something differently, congratulations, you have just grown with your new knowledge.

b) Laziness – You have got to a point where you can do a good enough job, and you are now just going through the motions. Imagine your company brings in a new person and you are paired with them on a project. If they outshone you and others noticed, would you feel threatened? You don’t need a challenge, you just need to wake up to the fact your laziness is holding you back from being the person you can become. Be mindful the next time you’re are doing something and realise you are on autopilot. Just realising you are on autopilot is enough to refocus your attention and you can look at ways to improve what or how you are doing something.

c) Fear of Failure – Trying something new will draw attention to you and you don’t want people to judge you on something you are not yet good at. Here you just need to remember that not everything has to be outward facing. As an example, maybe you are working on some analysis you do on a regular basis. Why not try to present it in a different way, or with a new technique you have recently learnt about. You don’t have to present the new way to others until you feel comfortable, or maybe you present both pieces of analysis. You will never know how it is received until you present it. Chances are you will never be derided for doing extra work to help present a situation in a better light. If you choose not to share it this time, take comfort in that fact you learnt, applied and grew in your role, even if, for now, it is just inward facing.

“You’ll always miss 100 percent of the shots you don’t take”
– Wayne Gretzky

Taking ownership starts with you

Building a growth mindset is simply a shift in thinking that allows you to better yourself. Challenge yourself to learn and develop your skills and abilities through constant improvement.

There is nothing more conducive to future failure in business than accepting the phrase ‘because that’s how we’ve always done it’. In business analysis, this is like a red rag to a bull. Challenging the status quo more often than not leads to positive change over time. The same goes for you as an individual.

Developing a growth mindset is the key to living your best life.

“In a growth mindset, challenges are exciting rather than threatening. So rather than thinking oh, I’m going to reveal my weaknesses, you say, wow, here’s a chance to grow
– Carol Dweck

The BA Skill Set – Splitting User Stories

Written by Jon Derbyshire on May 31, 2018. Posted in Articles.

I’ve spent a lot of time working with a large number of developers over the past 3 years. Their skill sets and experience have varied greatly, but the one consistent behaviour I’ve encountered, is they all work in a logical structure.

Their focus tends to be on one working piece at a time rather than a full pass and then review.

It’s also how I have tended to approach my requirements after transitioning to agile many years ago. Although I’ll have a rough idea of the requirements at a high level, the detail comes from working on a small number of requirements at a time. This way further requirements are teased out in the details and the cycle continues.

Although I’ve picked up a great deal of experience writing requirements in different ways, it has primarily been user stories that have been the preferred requirement for development teams.

Early in my transition, I found some of my more complicated user stories tended to be too large to be delivered within a single sprint. Over time, I acquired more skills and gained more experience in breaking down larger stories into more manageable chunks.

I’m a firm believer in the Peter Drucker quote “what gets measured gets managed”. As such within such short sprint windows, it’s the user stories which are kept lightweight that offer real value to the overall delivery and allowing the team to deliver more quantifiable value.

There are many different techniques for breaking down stories out there, but the one that has resonated the most with me is Mike Cohn’s SPIDR method. It also happens to be one of the simpler methods once you understand the basic concepts.

SPIDR is an acronym for 5 techniques used for splitting user stories.

S – Spikes
P – Paths
I – Interfaces
D – Data
R – Rules

Spikes

In bucking the acronym trend, S (Spikes) is actually the technique which tends to be invoked last and least often. Similar to spikes in the agile development process, the spike occurs when a story cannot be estimated and requires a time-boxed period in which further research and understanding can be carried out.

It reasons that with this increased knowledge comes more likelihood that we will better understand the story and be able to then break it down into smaller stories.

As a BA I often feel like I’ve failed to deliver good enough developer requirements if a spike in splitting is called. That being said, I recognise how valuable they can be, especially recently when working with newer technologies the team were not already familiar with. Without a much better understanding of the story, the development team and I run the risk of delivering a substandard product.

The best developer I ever worked with used to plan out his development on paper before ever attempting to write a single line of code. In a similar vein, the spike allows the time needed to better understand and plan the customer’s requirement, and thus, we have a better chance of delivering actual value first time without the need for the dreaded re-work.

Paths

A path describes where alternate flows exist towards the same end goal. Let’s take an example from a recent project I’ve been involved with. The high-level story is that a customer needs to be able to pay for goods within a store. This story has many paths available. For example, the ability to pay with cash, credit card (both chip and pin and contactless), customer credit account and mobile payment including both apple pay and android pay.

In this case, the original story can be broken down into 6 smaller stories, each with their own specific details and individual tests.

As a BA we would have to look at the individual merits of the split, working out if 6 stories offer more value than say 4 stories where 2 of those have the same requirement covering multiple methods of pay.

We could then estimate each story and rather than doing all in one sprint, we could do just the most valuable for now and work on other later into the project.

Each path allows us to specify each path in its own story, then re-group certain paths if they offer no additional value being treated as individual stories.

Interfaces

Interfaces refer to the amount of detail across, or from differing channels. Let’s take another example from one of my recent projects. Once complete, this project will offer the customer the ability to order across multiple channels including the website and mobile site (optimised for phone and tablet), but for the initial phase, we have chosen to offer the service only via the website. While mobile customers are an important subset of customers, the biggest value is getting the project out there, getting customer feedback, and measuring initial performance so we can better serve the customer. Mobile will follow, and when it does, it will likely be an even better and more polished customer offering based on the fact we have split the initial story into individual channels.

Splitting stories down based on interfaces offers an increased amount of flexibility and the ability to more accurately estimate the development and testing time required for each interface.

Data

Let’s say for example we are rewriting our website. We have a number of large stories related to the content we are going to display on the landing pages of the website. We know that based on the time of year women’s clothing is traditional much more likely to be the biggest seller over menswear and home furnishings. We would, therefore, write stories targeted at getting these types of products displayed prominently. For now, we focus only on womenswear as that’s where the most value lies at this time of the year. Later on, we will do the same for homewares, then after that menswear.

We split our stories based on the most valuable data and that offers the best return on the time invested for the customer/business. Splitting stories based on data gives a greater degree of flexibility.

Rules

Business, regulatory, technology rules etc…. all offer the potential for splitting stories.

Let’s take the example of a customer of a clothing retailer with a credit account. The company ran a credit check on the customer at the time they opening the account. Based on their credit score the retailer internally sets different credit limits to reduce the risk of customers defaulting on repayments, and to be more ethical by helping to reduce the customers’ ability to overextend their credit to the point they cannot afford the repayments.

The business rules in this case state that a customer cannot purchase goods on their credit account for a value higher than the company defined credit limit.

To split the story this rule could be omitted and the developer’s first iteration allow purchases up to the top value of the largest credit account. The additional rules with much more complex logic will be delivered in a later iteration, but to test the functionality of a credit account purchase, rolling out without the self-imposed business rules allow the business to test the rest of the functionality much quicker.

Splitting the story based on the inclusion/exclusion of rules allows quicker delivery and testing. The value of the rules can then be realised in a later iteration by changing the now working version.

Success and Story Sizes

I’m a firm believer that ideally the largest sized story allows an individual developer to deliver within a few days. Based on that principle, over the course of a sprint, the number of stories that can be delivered allows the project manager/product owner the ability to forecast realistic delivery dates and better plan releases.

As a business analyst, it is imperative that I give the developers the best chance of accurately estimating stories within sprint planning and delivering a good number of them each sprint. My end goal is to put a working version of the required functionality in front of the customer, as early and often as possible. The success of this relies heavily on the size of the stories in the backlog.