The Zen of Agile – Personal Philosophies for Practical Agile Adoption

by Derek Lynch,

Business Analysts Pty Ltd Consultant

 

I’ve somehow managed to eke out a career staggering through the murky world between data science and business analysis. My 25 years of gainful employment (other than a brief but glorious stint as a directory enquiries call centre operator in my early twenties) has involved data analysis of some description but I’m yet to write a single line of SQL code. I don’t possess either the Wizard Robes of Genius of the data scientist or the Designer Suit of Knowledge that good Business Analysts wear, but I get by.

I consider myself very blessed to have worked across multiple sectors and disciplines – having progressed from media sentiment and sports sponsorship analysis through FMCG market research, creating financial and operational business intelligence systems, redesigning government digital service offerings using human-centred design methods. Currently I am working with clients to help them realise the value of quality data and integrated insights which has exposed me to a plethora of management styles, tools and methods, all of which have shaped my own personal work philosophy and approach.

About 4 years ago now I was asked to attend agile training in preparation for joining a team of digital developers as a Data SME working on State Government digital service offerings. My instant reaction was one of panic. 25 years of data analysis is a pretty sedentary career path which has left me with all the physical agility of a wombat but, once I was assured that there would be no assault courses or climbing walls to negotiate, I went along for the ride and what a ride it has turned out to be.   Pretty much my entire career for the last 4 years has involved working on agile-managed data projects, or as a Data SME as part of an agile software delivery team. As a result, the spectrum of maturity and success of agile delivery has varied spectacularly but every day brings a new insight or learning – hopefully some of what follows will benefit you or your organisations’ own path through agile delivery.

Look before you leap – agile isn’t for every organisation, agile isn’t for every project

“Look before you leap for as you sow, ye are like to reap” – Samuel Butler

The mistake a lot of organisations or individuals make is to approach agile as Agile – the Capitalized Methodology. Agile isn’t a methodology and treating it as such confuses process with philosophy and culture. Make sure you have a clear understanding of agile principles (the Agile Manifesto is the best place to start) and that you pay close attention to understanding the implications of adopting agile principles for your organisation or project and whether or not they fit with your culture and strategic intent. It should also be remembered that agile is an umbrella term for a multitude of different project management styles and approaches (Scrum, Lean, Kanban etc.) and that understanding the nuances of these approaches is critical to choosing the approach that best suits your needs.

It’s important to remember that agile was originally created as a software development delivery approach – nothing less, nothing more. While it has successfully crossed the chasm to other types of business change it will not be a catch-all fix to all business problems. In short, do your research before committing to something that will take a lot of effort to unravel if it fails.

People make agile work – agile doesn’t make people work

“He who masters the power formed by a group of people working together has within his grasp one of the greatest powers known to man.” – Idowu Koyenikan

I was in a meeting once where our program director went around the room asking us if we preferred the agile or waterfall project approach. When she asked one of my colleagues, a much valued, highly respected and somewhat grumpy team member responded “I don’t care – I just like getting s@%t done”. While it seemed a flippant and mildly offensive response it also resonated deeply with me – and is exactly the right way to approach agile.

Adopting agile principles requires step change and in many cases a leap of faith and making sure you have the right people filling the right roles on an agile team is absolutely critical to a project’s success. Agile will NOT magically fix a toxic team culture or boost the productivity of demotivated resources, quite the opposite in fact. Adopting agile principles can sometimes feel like the grieving process in that people exposed to agile for the first time often move through the stages of denial, anger, bargaining and depression before finally accepting and adopting agile principles – different people and groups will embrace the change at different pace and it’s important that this is factored in when considering adopting agile principles.

Understand the difference between “being” and “doing” Agile

“Glory lies in the attempt to reach one’s goal and not in reaching it” – Mahatma Ghandi

Agile is a mindset, an attitude. If the company you work for focuses on doing agile rather than being agile then there’s a pretty good chance that they’re on the wrong path. Being agile is about embracing the philosophy and applying the principles of agile to your business, the doing is simply a by-product of this. Many organisations fall into the traps of:

  • Following a mandated “one-size-fits-all” standardised agile model across all teams and projects. There is no standard approach to agile, it’s very nature is dynamic through constant adaptation and improvement.
  • Paying more attention to the ceremonies and adherence to the agile “process” rather than the end goal, which is incremental delivery. Run a mile from any organisation which tries to build agile parameters into your individual KPIs!

Agile isn’t a contest or a race

“Try not to become a man of success but a man of value.” – Albert Einstein

One of the primary agile benefits for me is the focus on planning, sizing and prioritizing increments of work and the tools like story pointing and velocity measurement are critical to how agile works.

But they are also a double-edged sword.

By assigning point values as a measure of level of effort required to complete a task you are able to estimate the level of effort required to complete tasks in relation to each other, but it should be remembered that they are neither a delivery promise or a goal. Story points and estimation have no intrinsic meaning beyond providing an informal understanding of project complexity and effort and a specific team’s capability to deliver. Comparing velocities between teams or individuals in teams is both worthless and unnecessary – success is value delivered, not accuracy of estimation or compliance to a plan. Beware the project that has the mysterious ability to meet their velocity targets without actually delivering value (trust me, I’ve worked on a few of these).

Agile is Iterative, so iterate your approach to adopting agile

“To improve is to change, so to be perfect is to change often” – Winston Churchill

One of the guiding principles of agile is to incrementally respond to change as opposed to following a rigid plan so don’t be afraid to use this as a mantra for adopting agile principles. Organisations who try to implement agile too quickly and rigidly run a high risk of agile implementation failure. They often overlook the fact that adopting agile is a massive cultural change that should not be made overnight. Agile can also lead to a significant investment in terms of training and/or recruiting resources and the talent management strategy is too often considered an afterthought in adopting agile principles.

Careful consideration should be made to scaling agile adoption in terms of organisational readiness, resource constraints and leadership bandwidth. The larger and more complex the business, the longer it will take to scale successfully.

Beware the agile zealots

“The mind can make a heaven out of hell or a hell out of heaven.” – John Milton

For some reason people can become somewhat zealous in their approach to agile and insist on strict interpretation of agile principles, which in itself directly contradicts the core principles of the Agile Manifesto. The whole point of agile is to deliver value to customers faster, but this is not mandated by any prescriptive process.

Employing agile coaches is a great way to train your team and a good agile coach who considers your business needs and tailors their coaching accordingly is gold. A bad agile coach who insists on following a rigid agile methodology and preaches the gospel of “Agile Process and Methodology” can be very damaging when it comes to building maturity in an inexperienced agile team.

So should you choose to adopt agile principles for your project or organisation? I can’t answer that for you, but what I can tell you is this:

The dictionary defines agile as:

1) being able to move quickly and easily

Or

2) Relating to or denoting a method of project management, used especially for software development, that is characterized by the division of tasks into short phases of work and frequent reassessment and adaptation of plans

If you approach agile in the spirit of the first definition, I believe your chances of success are much higher.

Soft Skills Pay the Bills

 by Gareth Jones,
Business Analysts Pty Ltd Practice Manager

 

At a recent IIBA Professional Day event, a former colleague and respected business analyst and I were talking about the various topics to be presented. Some of his colleagues were only interested in the sessions that catered for the more tangible BA activities, i.e. data modelling, process elicitation and so on, whilst he was focusing more on the mindfulness and soft skill techniques. We both agreed, that whilst the tangible techniques are necessary for all BAs to learn, it is the underlying competencies that will differentiate between success and failure.

Much like the tangible BA techniques, there are a raft of underlying competencies to get our heads around. Each of which require their own individual focus and continuous improvement approach. To give each budding or even seasoned BA a bit of a leg up, I thought I would share some of the key underlying competencies, or soft skills, that I feel are necessary for all BAs to focus on.

 Analytical Thinking: OK, so a no brainer with this one… or is it. “BAs use analytical thinking by rapidly assimilating various types of information (for example diagrams, stakeholder concerns, customer feedback, schematics, user guides, and spreadsheets), and identifying which are relevant” IIBA BABVOK v3. We are presented a topic, problem, or statement (see one liner here), and from this we collaborate with a number of people to determine the most adequate solution to address a business need. Without structuring our thought, applying traceability to our analysis, and interacting with people with various perspectives, we would struggle to form any trustworthy insight. To do this effectively we must learn new concepts, think outside of the face value of the problem drawing from past experiences and our own research, consider people, process and technology impacts, trace symptoms to root causes to problem solve, and reiterate this to various stakeholder groups in a level that is relevant to their interests. Simples!

Trustworthiness: Transparency breeds trust! The aim for every BA should be to become a trusted advisor. By this I mean, those that the BA works with and supports will take the information presented by the BA with an increasing level trust, to a point where it is accepted as verbatim (trusted). This requires the BA to be extremely diligent in the analysis they do and the perspectives they consider, it is hard work. But the flip side is that it provides a great platform for the BA to display the leadership often necessary to keep projects and initiatives on the right path.

In addition to this level of trustworthiness, BAs are often in a position where they are eliciting information from stakeholders that they may not want shared or linked back to them. In these cases, the BA must develop a strong level of trust with the individual stakeholder to elicit the correct information, and then be able to present this to other stakeholders in an objective manor that enables informed business decision making without having to disclose the source.

 Adaptability: Change is a constant. It is no coincidence that the IIBA speaks of both individual adaptability and adaptive project approaches. As organisations embrace adaptive or agile delivery models, changing requirements and priorities, as well as competing initiatives, will mean the BA will often needs to pick up a new requirement and drop one which they may have applied a good deal of thought to. Additionally, as agile uncovers information in an iterative process, what we think we ‘know’ may not turn out to be what we deliver in the end. Finally, each team and each initiative are unique, so what may work for one may not work for another. All of the above adds a little extra pressure on the BA to be across the change and prepared enough to help drive it and, in some situations, comfortable with not knowing all the detail.

The requirements we specify will be open to scrutiny, regarding feasibility, level of detail and granularity etc. This is only to achieve the right outcome, and we should never personalize this. Given each of our outputs as BAs are typically another’s inputs, we need to adapt our approach to suit the team and the level of detail they need for delivery. Requirements were never owned by the BA, we were only ever a temporary custodian of them. We need to maintain that focus to ensure the best requirement is delivered for the team, not just the one that we worked on.

 Facilitation: Don’t imagine them naked, I am not sure if that has ever worked. And forget ‘Practice Makes Perfect’, perfection doesn’t exist. ‘Persistence Beats Resistance’, this is something you can apply as it works both internally and externally. Cast your minds back to school where you had to deliver a presentation to your classmates. The majority of people were so nervous, their hands were shaking, and their voice would quiver. Those that did nail it were often met with congratulations rather than jeering as regardless of whether you were cool, a dweeb, or otherwise, everyone knows how scary those presentations were.

Well, if you’re a BA or want to be, standing up in front of people and guiding discussions and teams is ‘Par for the Course’. So if internally, this scares you, the go out and do it anyway. Persist. Look at programs like Toastmasters to get comfortable with the notion of public speaking. Lead a discussion at your next BA Forum. Write a blog for industry and present the information in a public setting. You need to persist to overcome your internal resistance!

This also gives you a platform to work on your communication skills, both verbal and non-verbal. Building the comfort in standing in front of people will give you the head space to focus on voice projection, body language, and so on.

 Leadership and Influencing: We play a pivotal role in business improvement, own it! Whilst we down own the requirements, and never have, we do guide stakeholders through the analytical process to ensure they have the right level of understanding to aid in key decision making. This may involve motivating stakeholders to take ownership in their part of the initiative by ensuring they understand their role and are provided with the necessary support to fulfill it successfully. This goes from the end user right up to the C Level execs. If we take pride in the delivery of successful outcomes, then we must focus attention on the key stakeholders necessary for the delivery of said outcomes. Whether you stand at the front and direct, or at the back and guide, will be determined by the environment and situation. But if the outcomes are at risk, we must take a level of responsibility in ensuring each stakeholder is aware, have traceability in our analysis to identify this and clarify this risk objectively, and detail what can be done to address this.

Teamwork: If they can’t work with you, they won’t work with you. This does tie back to adaptability in some way as how we accept changes will impact how others will approach us in future. But it is more than putting on a smile in the face of change or ambiguity. Business, and particularly IT is the most diverse industry in the world. We work with people from all over, with varying levels of experience. And as BAs, we play a pivotal role in how productively that team works together. Working collaboratively, being open to different points of view, being considerate when providing feedback, remaining objective in our analysis and depersonalizing the requirements. All of these will assist us in working with the different stakeholders on a day to day basis. But when the pressure builds, the deadlines approach, and the change is still constant, we must remember that our reactions can have a positive or detrimental impact on the team. Although work is very important to us, it is just that, work. We are delivering business improvements. We are not in the business of saving lives; we are in the business of saving or generating money. That isn’t to diminish the importance of what we do, but we must remain objective, take challenges it in our stride, keep calm and carry on.

The Gentle Art of Facilitation

by Gareth Jones,

Business Analysts Pty Ltd Consultant

 

Having been a BA for well over 10 years now, and having facilitated session in various situations, I feel that one of my strengths is facilitation. Whether this be workshops, training sessions, interviews, ‘negotiations’, I feel accomplished in most if not all of these facets. As so, on a recent need to facilitate a large group I approached it in my usual way expecting the usual result…Enter complacency.

 

On this particular occasion, I had in the room a number of brilliant people. Brilliant not just in the sense of personality but most definitely in capability. At the same time, I had a number of people in the room that were fresh to business analysis and as so, in the very early part of their learning journey.

 

My room was prepped. The materials were out. Everything was going according to plan. And so, after getting to know some of the early participants as they entered, I thought it best to get my presentation up and ready prior to the scheduled doors open. Enter problem number one, the projector was broken. I quickly asked facilities for assistance to which they informed me that they are aware of the problem and have left a spare projector under the table. Problem #2 – the backup projector was also broken. As I fluffed around trying to get this to work to no avail and was informed that the main projector would be broken for the first half of the day, I decided to push on minus the projection as I had printed copies the material for all participants (always have a backup!). This was not ideal but was sufficient enough to enable me to commence and for them to follow. However, we had lost some time already, and this was a slower process to follow.

 

The discussions were broad in view and varied in depth. I love to let discussions continue as this is where the interesting perspectives come from, and it also distracted the participants from some of the technical difficulties. Just after lunch the technical difficulties were finally resolved and we continued the day all be it a little behind. I was conscious of this but had 3 other days to catch up. I adjusted lunch time lengths slightly to cater for this.

 Day 2: More great discussions, more strong personalities, exercises that enabled team members to collaborate (yay), but the time lost on day 1 was creeping in to day 2. The agenda was out so I had to rearrange the exercises so larger exercises were not being started at the end of the day.

 

Day 3: I knew I was in a bit of trouble. However, we were also at the most important part of the session, so I couldn’t ‘rush’ through any of this. We finished the day 3 a number of key components behind and with one day to go (this was going to be tight, yikes!).

 

Day 4: Make or break. I had never been this behind. I had to adapt, and I needed a plan. We had agreed on day 3 to start earlier and finish slightly later if needs be (though some participants needed to leave at the previously specified time).

 

 

 

 

 

 

 

 

I got in very early to ensure the room had been re-set to reduce and lag time between exercise suggestion and commencement. All materials were in front of the participants, we had sweets (the important part of course) water etc. I had set a new agenda and communicated this out to the group at the start of the day. It included topics, exercises and then scheduled breaks. I allocated specific question time for the group to ensure questions were not being asked about information yet to be covered. Session by session we moved back on track. The group was more focused, more engaged, and got more out of the day. We made it!

 

Why am I sharing this? Facilitation is not a set and forget activity. And through everyday activity and a little complacency, I was reminded of this. So, as the last point below will attest, I wanted to learn from it and by sharing, maybe help someone avoid this situation. For me facilitation comes down to 6 main points. The T’s and C’s if you will.

 

Time Management vs outcomes: This is where facilitation can difficult. If you have a multitude of things to cover in your agenda, and a constrained amount of time you can ensure you meet all the items, but it may come at the cost of the quality of the session. Facilitation is about enabling and guiding a discussion, not lecturing or dictating. Don’t overload your agenda!

 

Communication: Communicating at the start of each session what needs to be covered, why we are covering it, and what we are then to do once it is finished. I.E. this morning we will focus on Customer Journey Mapping after which time we will break for morning tea.  Ensuring the participants know what needs to be covered, the time allocated to doing so, and the benefit for staying focused works brilliantly.

 

Control: Control is much like the accelerator pedal. You like to maintain a constant gentle approach, but sometimes it is safer to back off whilst other times it is necessary to power through. Control is very much linked to Time Management vs Outcomes. If you are not going to meet your agenda and must cover those items, you will need to implement stronger control measures. In my case it was more strict timeboxed activities, halting questions until allocated times, and achieving outcomes before scheduled breaks. If I ran the entire session this way, we would have finished early, the participants would have had low satisfaction, and the outcomes of learning would not have been achieved. If I had adjusted my control measures early, but with less severity, we would have maintained a constant pace throughout.

 

Confidence: Confidence in facilitation is key. If you are uncomfortable with leading groups and presenting, facilitating discussions will always be difficult. You build confidence through practice and preparation. Preparation eases the mind and gives you a plan, practice makes perfect. So always nominate for opportunities to stand-up in front of groups. The reward outweighs the nerves – back yourself!

 

Continuous Improvement: Always take the time to reflect, adjust and improve. There will  be times where something hits you out of left field, but learning from those times so you can react better the next time, is where the value lies in it for the facilitator.

 

To find out more about what’s happening in the world of Business Analysis follow us on LinkedIn

Linking Process and Data

by Vivek  Venkatraman,

Business Analysts Pty Ltd Consultant

 

I would like to discuss the importance of understanding the link between process and data while performing business analysis. Process and data are the fundamental elements of any business. It is critical to understand how they are linked to understand the product or service delivery because almost every business process has data linked to or flowing through it. Understanding the linkage helps gain better understanding of new domains and/or complex processes and helps to elicit requirements more effectively. It also helps uncover essential processes or links that may otherwise be overlooked. Insufficient understanding of the linkage between process and data might lead to incorrect and or incomplete requirements.

 

Identifying the linkage pattern can be quite useful when:

  • creating a new business process
  • analysing an existing process to understand the overall business process
  • understanding the terminologies of the existing business process
  • creating new data models from process flows
  • defining epics and user stories
  • writing effective acceptance criteria for user stories

 

There are a few steps which can be followed to help understand the linkage between process and data. Following steps can be followed for analysing existing business process to understand the business:

  • Begin with the process flow diagram to understand the sequence of tasks in a process.
  • Identify the data elements that passes through every task in a process.
  • Use these data elements to understand more about the data models and how it links back to different tasks in the process.
  • An in-depth understanding of the data model would help identify other processes that may relate to the current process.
  • Understanding the business processes that are related or linked to the current process would help gain a holistic view of the product/application.

 

Creating a new process to a level of detail requires an in-depth understanding of the process and data flows. This involves asking a lot of questions while charting out the business process flow diagrams and this is an iterative process. As we gain better understanding of the process and data, the quality of questions and the level of details would significantly improve.

  • From the initial elicitation information available, create a high-level process flow diagram.
  • Within each of the tasks, determine what data would flow through it.
  • From the identified data, create data models by liaising with the stakeholders.
  • This is an iterative process and as we gain better and better understanding of the data and process models, more questions would pop up till we are satisfied with the level of detail in the process flow diagram.

Later, I will discuss with examples on how the quality of questions would improve as we understand process and data together.

A few techniques can be used for this purpose:

  • The question that we need to ask to identify data when looking at the process flow is – “what data flows through this task and how does it relate to my process?”
  • From the data modelling, we can ask questions like “is this data used in any other task in the process and if so, how does is it used?”
  • For understanding the data and in turn the application as a whole, we can ask “what are the other processes this data is used in?”

 

Leveraging the English language

  • A well written process task is written in “Verb Adjective Noun” format.
  • The “Adjective Noun” in the process would help identify the data element which could then be used to understand the data.

 

I will discuss a couple of examples on how understanding data and process as a whole can help analyse or create better business processes.

An example of a customer order – Designing a new process to allow the user to create, edit and submit an order.  The system validates the order and confirms the order.

 

The process flow in the previous slide is quite simple but understanding the data might help understand the underlying business objective for writing better requirements. A few questions that would then help model the data are

  • What is the customer trying to order?
  • What are the attributes of a customer order?
  • Are the attributes linked to any other data source and what is the relationship?
  • If there is a relationship with other data elements, are those elements linked to the current process?

We can then create a data model once we have the above questions answered and relationships defined

 

 

A better understanding of process and data helps ask better questions which directly benefits in writing better requirements. It is by our understanding of process and data that we are able to ask the below questions:

  • Does the customer have a registered account and if not, does it have to be linked?
  • Does the asset exist and if so, do we have all the necessary details?
  • Has the validation for the asset and account been done already or does it have to be done as part of the order validation?

These are very valuables questions that help create the process flow in a detail that we need. Failing to get these questions answered may lead to missing details from the process flow diagrams. Understanding the process and data together thus helps writing better requirements, user stories and acceptance criteria.

Another example I would like to discuss is that of an Income process where we only have a high-level process flow.

 

The above high-level process doesn’t help understanding the entire business process. Let us try to use some techniques we discussed earlier to help understand the business process.

  • Looking at the process flow, let’s try to identify the data by using the “Verb Adjective Noun” technique.
  • Using this technique, “Income Announcement” will have to be the data for the first task.
  • Similarly, “Client Holdings” and “Customer Payment” should have to be the data for the subsequent tasks.

Let’s look at the data models to gain a better understanding

 

 

From the above diagram, it is evident that

  • For an “Announcement” to exist, there needs to be an “Asset”.
  • To gain better understanding of the “Capture Income Announcement” task, ask “how do we get the payable and record date information” and if there is a process for that, understand that process as well.
  • For a “Create Customer Payment” task, we can understand from the data that a Payment needs to have an announcement, Asset, Holding and Account.
  • Since we can see that Announcement is created from an Asset and Holding is created from Asset & Account, a payment can be created from the announcement and holding information which is in the previous two tasks.

This linkage between data and process thus helps understand what the business process is and what the outputs of the process are.

 

From the examples, we can conclude that linking data and process is essential for:

  • In-depth understanding of any business process
  • Understanding new domains quickly
  • Understanding the terminologies used in different domains
  • Developing better requirements
  • Improving quality of user stories and acceptance criteria

 

To find out more about what’s happening in the world of Business Analysis follow us on LinkedIn

How do you become a Business Analyst?

by Justin Balina,

Business Analysts Pty Ltd Consultant

A couple of my colleagues have asked me this question and I couldn’t really give them a concrete answer. Later that day, I had time to reflect on the question – how does a person actually become a Business Analyst? Unlike teachers, doctors or architects, there isn’t really a degree in Australia that you can do specifically to become a BA. All the BA’s I’ve met in the past followed fairly different journeys. In this blog, I’ll share my journey to becoming a BA and some interesting stories from current/ex-colleagues too!

 

My BA journey

When I finished my IT degree, young me already knew that I did not want to be a full time tester. Maybe I was too impatient or just didn’t enjoy doing repetitive tasks. I thought about being a developer so added that to my shortlist. I also wanted to be a Database Admin so I added that too. I didn’t really want to be a Business Analyst as young me thought it wasn’t technical enough aka wasn’t ‘IT’ so I didn’t really apply for BA roles.

Fast forward a few weeks later, and after about 50 job applications – I’ve finally secured my first role as System Administrator! I was really excited as it was my first job out of university! There were heaps of technical systems, techniques and concepts that I needed to learn. It was a mix between a technical and business role and the thing that I really enjoyed was being the conduit between the business and IT. I felt like I was this translator that knew 2 separate languages! The other key thing that I liked in my role was a day was never the same! Every day of the week I had a different task to do! After speaking about it to my manager, he suggested that I consider being a BA as the things I enjoyed doing were in line with what BAs do!

After a year in my first IT job, I decided to move on and work as a Telecommunications Business Analyst for a financial institution. Yes it was tough. It was a learning curve for me but it helped me kick start my BA career!!

 

BA stories from colleagues

During my short career, I’ve met and worked with a lot of Business Analysts from different specialisations and backgrounds. I was quite surprised to figure out that everyone had a different journey than me.

I worked with a senior BA who finished chemical engineering in university and worked as a lab technician for 10 years before he became a BA. He was originally part of a project as a stakeholder and enjoyed the investigation/requirement activities with in business analysis, so he switched careers!

I’ve worked alongside a call centre representative who was in their role for 2 years working as an SME for a project I was part of. She really enjoyed the various project activities and challenges. For her, there was never a dull day when doing project work and we encouraged her to start her career as a BA. A year later and after doing a BA training course, the company decided to give her a promotion as a Junior BA to kick start her career!

I also had a colleague who, with 15 years of testing experience behind him, decided to move to become a BA. He said that BAs usually have multiple roles behind that job title. BAs can also be Project Managers, Testers, Data Analysts, Change Manager or even Network Engineers on some projects. It was that flexibility and ‘wearing many hats’ that attracted him to shift from the testing.

 

Some Guidance 

Some of the things I and my BA colleagues believe will help a person start a career in business analysis, or transition their career in this direction are:

  • Building a network – if you want to be a BA, talk to other BAs. Learn from them and build the chance of opportunities through this network.
  • Training – Business Analysis is not a cookie cutter role, but there are definitely some great courses that will get you well on your way. Business Analysts Pty Ltd provide amazing courses that have helped people transition into BA roles.
  • Become a part of the industry. The International Institute of Business Analysis (IIBA) provides a wealth of information, public events, and networks. If being a BA is what you want to do, connecting with an organisation focused on it is a great start.

 

To sum it up, everyone has different adventures they have to go through to become a BA. Being a BA doesn’t mean that you have a list of set tasks, but doing whatever is needed for the success of the project.

To find out more about what’s happening in the world of Business Analysis follow us on LinkedIn

Bridging the Gap Between IT & OT Security

by Henry Elisher,

Business Analysts Pty Ltd Consultant

 

Many industrial organisations still view IT (Information Technology) and OT (Operational Technology) security as unique issues to be addressed in isolation. Even though IT & OT environments are foundationally and functionally different, the need for convergence between the two in the new world of increased and pervasive cyber risk can no longer be labelled as a consideration or option, convergence between the two spheres needs to be a mission critical objective.

A recent report by the World Economic Forum identified cyberattacks on critical infrastructure and strategic industrial assets as now being one of the top five global risks. Knowing that, it beckons reason that the typical view many industrial companies take when it comes to the security of their IT & OT spheres is that each still pose their own unique set of challenges which need to be handled in isolation. The reasoning being that the differing concerns and practices of each are justification enough to warrant a siloed approach to security.

Siloed approaches in themselves mean a disparate and non-cohesive structure. Gaps in the cyber defence of organisations as a result from the lack of cohesion are inevitable.

Attackers understand where the vulnerabilities lie and have the expertise to exploit the security gaps between IT & OT technologies. They understand full well that those responsible for organisational cyber defence can have different priorities and practices. Specifically, within the business there can be differing, functional requirements, different working cultures and risk appetites. It’s no surprise then that these environments also have the propensity to be dissimilar and divergent when it comes to their own security requirements.

In industrial organisations security has traditionally been divided across three silos, IT security, OT security and additionally, physical security (plant security and system integrity). This divide has made it difficult for operators to identify and respond to incidents when they’ve occurred. Coupled with the historical aspect of siloed priorities in terms of security requirements, with IT security focusing primarily on confidentiality and OT security on integrity and availability, modern day operations have been placed under immense pressure and scrutiny. New challenges have now arisen from the complexities formed out of elaborate IT and OT infrastructures, which typically include thousands of devices, all being connected via the IIoT (Industrial Internet of Things). These complexities have changed the game yet again, making it even more difficult to detect, investigate and remediate cyber security threats and incidents.

From the perspective of critical infrastructure providers, the potential societal consequences from a cyberattack requires that their operations take place in a certain manner. The priority of an operator, such as in the electricity market, is to ensure the safe and reliable delivery of that service, it’s their primary concern. Having this as their key responsibility in turn leads to other differences across areas, from component lifetimes and patching practices to audit timelines and additional functions. Reliability of service in the electricity sector is of utmost importance and becomes an overarching goal.

These security challenges are also often exacerbated by the communication barriers between the two groups & the fact that they quite likely have different reporting and governance structures.

This lack of coordination and communication becomes especially risky in times of emergency where the organisation has been the target of a cyber-attack and needs to formulate a cohesive, comprehensive response to, or in fact recover from, a cyber incident.

Protection of the various spheres in an organisation is obligatory. However, in order to protect a complex surface attack, the way many industrial organisations are acting recently has been to devise ways to converge their IT & OT working groups. A more than onerous task in itself as each group has a tendency to believe that security vulnerabilities are inheritedby them usually due the blatant ignorance of the other. This finger pointing tends to entrench an eternal battle that centres on each domain playing a defensive roll and devising mitigation strategies against risks posed by the other side. The issue is of course not internal. However, the area of conflict that exists between the two groups is just the space required for attackers to utilise and exploit it.

The difference in the IT & OT environments highlights one of two fundamental barriers that need to be overcome. IT environments are dynamic and IT systems are often patched, upgraded and replaced regularly. IT personnel have their concerns centred on the confidentiality of data, data integrity and availability. As knowledgeable as IT staff may be in their fields and as up to date they may be on trends & threats, their propensity to operate outside their sphere is limited. IT personnel are often lacklustre and typically unfamiliar with OT networks and control systems.

 

OT staff work in a world where stability, reliability and safety are the top priorities. Their remit is to maintain the stability of complex and sensitive environments, quiet often with legacy systems that have not been upgraded in decades.

This inherent environment difference due to business priorities and culture can be pervasive and quite often divisive without pointed remediation.

Also, the different technologies utilised within each domain has the propensity to cause unnecessary tension. Within the realm of IT, personnel are used to working with the latest hardware and software, including of course the very best security available to protect their network. Their time is spent patching, upgrading and replacing systems. Whilst IT has ownership of their ‘sphere’ the disparity between what they see as their world and the responsibility & accountability they should have is altogether different.

OT on the other hand has the propensity to function with legacy technologies, many of which pre-date the internet era. Common features of the IT environment are lost in the OT world, and the lack of basic security controls such as authentication and encryption are often disregarded in terms of importance to the ire of IT who in turn can be both incredulous and dismissive in their contempt.

C-level support is the primary step to being able to instigate IT/OT convergence, and ultimately, bring about the success of forming a harmonious unification of practices in IT & OT. In order to unify strategy, security thinking and practices, the objective of organisations is to create a culture of collaboration between the disciplines.

Despite the divide there are organisations that have successfully facilitated deep collaboration between IT & OT, the importance and driving factor of which rested within the remit of the C-suite and the support provided.

In order to facilitate convergence some organisations have created C-level roles to bridge the gap between the two. For example, it is not uncommon to known see a Chief Digital Officer whose role it is to be bridge the divide between IT & OT through the merging of culture, and by the establishment of incident management responsiveness that spans both groups.

To make this happen, more and more organisations are taking senior, experienced engineers from OT units, and assigning them to support incident response within the Security Operations Centre (SOC). This in itself helps to create an environment where people, knowledge, processes and technologies straddle and work to unify the IT/OT fence.

What consolidating IT & OT cybersecurity efforts achieves first and foremost is that it clarifies responsibilities, but more importantly, moves to eliminate security gaps. It also ensures that there is a consistency of security levels across the entire organisation and leads to reductions in the overall cyber risk. The key objectives set within this form of consolidation are therefore to entrench a shared responsibility for end-to-end cybersecurity, ensure global corporate governance of all cybersecurity policies, procedures, technologies and guidelines, and supports global visibility and management of all cyber assets, vulnerabilities and threats.

The elimination of the IT & OT silos is critical for the goal of reducing risk. The aim should be for the creation of a single digital security and risk management function/structure, with a direct report into IT but having a responsibility that spans all of the requirements for IT & OT security.

In order to be effective therefore, a converged IT-OT cybersecurity program needs to ensure a centralised oversight of the entire organisation’s cyber security efforts and additionally, have the authority invested in the group to be able to implement key objectives. Implementation of key objectives can be through formal organisational changes or via virtual teams that work in IT groups, OT groups, and security operation centres (SOC’s). The integration of third parties with specific capabilities should also be a consideration in order to address the ongoing shortages in cybersecurity professionals.

Any organisation going through changes will inevitably encounter varying degrees of resistance. Even though the benefits derived from the convergence of IT/OT cyber security strategies may seem to be obvious, the transition is likely to be arduous due to personnel implacability and the complexity of two stand-alone operating functions being subsumed into one cohesive structure.

Some of the initiatives that companies utilise to ease the transitions are:

  • Establish cross-trained site teams in order to handle routine security hygiene
  • Create a global support network within IT & OT experts in order to deal with more complex cyber issues such as malware intrusions and anomalous behaviour
  • Update key IT/OT cybersecurity processes from vulnerability management to incident management
  • Ensure compliance with corporate policies
  • Integrate cybersecurity technology to enable coordinated cybersecurity management

Also, there needs to be the understanding that whilst the tools required by IT & OT might need to be different, they do in themselves need to be compatible and fully integrated within key areas such as asset inventory, endpoint and network protection, security monitoring & reporting, and secure remote access.

Beyond the technical challenges, posed inherent cultural issues also need to be addressed. Quite commonly distrust between the two groups may be the biggest hurdle to overcome on its own. Methods that might aid in the easing of transition in this regard might include workshops to reconcile perspectives, and the cross-pollination of groups in order to build bridges and re-establish trust between the groups.

The challenges posed in bridging the gap between IT & OT security exist, are real, but, are not insurmountable. As both IT & OT infrastructures increase in complexity and their dependencies increase accordingly, ownership of cyber security issues cannot take place in isolation. A siloed approach will not work in environments of interdependency because aside from the internal disruption and inefficiencies of this viewpoint, the gaps and ‘grey’ area of ownership create the opportunity for attackers to take advantage.

Convergence of the IT & OT security realms needs to have C-level support and a framework set by which security for both resides in a single location under a single remit. Once a cohesive plan is in place and once collaboration occurs between both domains then effective strategies for mitigation in a holistic sense can be made possible.

 

To find out more about what’s happening in the world of Business Analysis follow us on LinkedIn

 

 

Building Cyber Resilience – The New Challenge For Business Leaders

by Henry Elisher,

Business Analysts Pty Ltd Consultant

 

Cyber threats can and will affect all industries. The most current wave of digital transformation to hit the global economy has brought to us the IOT, (Internet of Things), which means now that nearly all organisations operate in a digitally interconnected ecosystem.  Cyber security can therefore no longer be regarded as an individualised problem that can be fought at the digital and physical frontier of a single organisation. The cyber security vulnerability of anyone you do business with can now also be your vulnerability also, you too can inherit the risk.  

Successful cyber-attacks on critical infrastructure have the potential to immediately threaten both national security and economic stability. The degree and nature of attacks now have the potential to cripple not just industries, but can also do untold damage to nations, as dependencies have risen through interconnectedness. One only needs to look at the NoTPetya cyber-attack on the Ukraine in 2017 to witness the ferocity, scale and damage of a cyber event with magnitude[i]. The scale and potential to create damage and harm is not lost on cyber threat actors either. Criminal groups, hacktivists with the aim of causing civil unrest, and even state-sponsored groups performing espionage activities, all understand the vulnerabilities of operating in an interconnected and interdependent environment where the consequences of a cyber-attack can easily cascade from one to many in an instant. The Ukrainian event will not be the last, and even though the degrees of attacks may vary it cannot be assumed that anyone is immune.

Combatting and managing this growing risk must now become the onus of business leaders. To understand, identify and build a robust and pervasive cyber resilience culture and further, ensure it is instilled within every person of an organisation means that actions and the activity of knowledge transfer, defence and culture needs to commence from the top down. Board members and chief executives are now obligated to take it upon themselves to proactively formulate strategies and ensure cyber resilience is interwoven into the fabric of their organisation.

The new interconnected world in which organisations operate necessitates leaders to fundamentally shift their mindset in two distinct ways[ii]:

  1. There needs to be the understanding that cyber-risk is a business and ecosystem-wide risk and not simply a component that fits within the remit of IT risk. Cyber risk management decisions must be integrated into all business decisions.
  2. Awareness that managing cyber-risk in an interconnected environment means that leaders need to look well beyond the boundaries of their own houses and understand their broader neighbourhoods of suppliers, customers, competitors, peers and regulators, amongst others[iii].

 

Knowing what needs to be protected is the first step in addressing the challenges of cyber resilience in a complex and interdependent operational universe.

Organisations usually have interdependent relationships with numerous stakeholders that can span multiple degrees of separation within an organisation. In order to ensure that cyber security and resilience are effectively adopted within the context of business strategy, leaders have the obligation to grasp both the breadth and depth of the connections within their operational sphere.

Being able to produce a logistical map of interconnected stakeholders is also of utmost importance. The identification has to start within the core value chain, specifically, identifying the connected infrastructure, and then, expanding that sphere of reference to the surrounding business ecosystem of suppliers, customers and peers. This then needs to be encapsulated and buttressed by a clear picture of what the extended ecosystemis.

The extended ecosystem is also known as the strategic layer and comprises policy makers, regulators, law enforcement, insurers and standards bodies.

As the digitisation increases so too does the complexity and interdependencies of the network layer, i.e., the computer systems[i] that interact with one another. Coming to an understanding of this layer early in the piece and getting ahead of the development will allow a better insight into obvious cyber vulnerabilities and will highlight how this layer can be utilised as a highway to propagate cyber-attacks, and further, how the effects can easily cascade across the ecosystem.

Understanding the network layer and also working both adeptly and with agility in the strategic layer is critical in becoming cyber resilient. Cyber security and resilience cannot be allowed to simply be regarded in isolation. Leaders must now take it upon themselves to recognise that a lack of security in their broader neighbourhood means that their own cyber integrity has the ability to be undermined. Cooperation is a key aspect to heightening cyber resilience. It is essential between members of a neighbourhood, from oversight bodies to suppliers, customers and employees, that cooperation through all operational spheres needs to take place in order to inform, identify and combat all perceived threats.

 

How to secure systems that will become increasingly more complex will inevitably be the ongoing challenge for any market. The ever-changing nature of technology and the shifting sands on which both the network layer and strategic layer are founded will mean collaborative and collective efforts will need to be sustained, indefinitely.    

In 2017, to help facilitate board oversight and action in support of organisational cyber resilience, the World Economic Forum (WEC)[i], in collaboration with leading academics, developed 10 overarching principles[ii] for organisational cyber governance. The principles were put in place to assist boards in promoting cyber resilience as a key component of their overall organisational strategy.

The key cyber resilience principles are restated below in this blog. These principles have been lifted exactly as stipulated by the WEC

Principle 1 – Responsibility for cyber resilience – The board as a whole need to take ultimate responsibility for the oversight of cyber risk and resilience. This primary oversight may be delegated to an existing committee or new, dedicated committee.

Principle 2 – Command of the subject – Board members need to receive cyber resilience training upon joining the board and are regularly updated on threats and trends – with advice from independent external experts when requested.

Principle 3 – Accountable Officer – The board ensures that one corporate office is accountable for reporting on the organisations capability to manage cyber resilience and progress in completing cyber resilience goals.

Principle 4 – Integration of cyber resilience – The board ensures that management integrates cyber resilience and cyber risk assessments into the overall business strategy as and enterprise wide risk management, as well as budgeting decisions and resource allocation.

Principle 5 – Risk appetite – The board annually defines and quantifies business risk tolerance relative to cyber resilience and ensures that it is consistent with corporate strategy and risk appetite.

Principle 6 – Risk assessment and reporting The board holds management accountable for reporting a quantified and understandable assessment of cyber risks, threats and events as a standing agenda item during its meetings.

Principle 7 – Resilience plans The board ensures that management supports the officer for cyber resilience by creation, implementation, testing and ongoing cyber resilience plans, which are harmonized across the business.

Principle 8 – Community The board encourages management to collaborate with stakeholders, as relevant and appropriate, in order to ensure systemic cyber resilience.

Principle 9 – Review The board ensures that a formal, independent cyber resilience review of the organisation is carried out annually.

Principle 10 – Effectiveness The board periodically reviews its own performance on implementation of these principles and seeks independent advice for continuous improvement.

 

To find out more about what’s happening in the world of Business Analysis follow us on LinkedIn

[I]‘The untold story of NoTPetya, the most devastating cyberattack in history’,accessed 23 APR 2019, https://www.wired.com/story/notpetya-cyberattack-ukraine-russia-code-crashed-the-world/

[II]Boston Consulting Group, Whitepaper, accessed 12 APR 2019,’ Building cyberresilience into the electricity ecosystem’, https://www.bcg.com/publications/2019/building-cyberresilience-electricity-ecoysystem.aspx

 

[III]World Economic Forum, Whitepaper, accessed 15 April 2019, ‘Cyber resilience in the electricity ecosystem: Principles and guidance for boards’, https://www.weforum.org/whitepapers/cyber-resilience-in-the-electricity-ecosystem-principles-and-guidance-for-boards

 

Confessions of an Agile convert

by Nikesh Parbhoo,

Business Analysts Pty Ltd Consultant

 

 

 

Confessions of an Agile convert

Having to work in an agile environment for the first time can be a daunting challenge, particularly if you’ve done work in waterfall environments for most of your career. Agile is being adopted to a greater degree in IT delivery. You will find that each country, city, industry or client/employer will either be more mature or less mature at effectively applying Agile techniques. Ensure that you understand where you need to operate at in this maturity continuum.

What does it take to make that leap across the chasm into the world of agile?

Firstly, read up on agile as much as you can. The IIBA has the Agile extension to the BABOK which is useful.  Speak to as many professional agile practitioners as possible. Some cities have Agile meetup groups that you can leverage off.           

If you have a decision to make regarding accepting a piece of work in an Agile project, your preparation should give you the confidence to say yes. All your analysis skills developed in your Waterfall life is fully transferable in Agile. Agile is just a method of work – the skills associated with being a business analyst remain the same. Attention to detail, people skills, business acumen and all other good BA skillsets will be to your advantage in any Agile space.

Know your new tools and artefacts

Gant charts, Microsoft project, requirements specification documents and business process management tools/artefacts are some the assets of knowledge you would have built up during your waterfall career. Agile is less structured, and so you need to understand your new paradigm of working and the tools that go with it.

The Atlassian suite (Jira and Confluence) is widely used in agile IT implementation projects.  The good news is that using these tools are intuitive and nota mountain to overcome to become productive quickly.

‘Let go’ of your artefacts

Typical Waterfall BAs have a very close, sometimes emotional relationship with their artefacts, be it the requirements specification document, business process maps, etc. This ownership mentality is something that must loosen up in an Agile environment where the team owns the artefacts through co-creation and collaboration.

The BA takes primary accountability for an agile artefact (like a User Story), but it is ultimately a product of the greater team. Don’t feel like your space is being intruded upon when the product owner or the SMEs make a change to your User Story on Jira.

Agile is more human

Agile offers teams the ability to think and produce value like we do natively as human beings.  We naturally operate on a try-fail-try again basis as humans. Think babies or children and you soon realise that they essentially operate on an agile basis. They are never perfect, but they are constantly trying and eventually get it right. The frustrations that accompany the ‘throw it over the wall’ mentality of Waterfall evaporate quickly in a well-run Agile team. Remember: Fail fast to get to ‘goodenough’ quicker.

Information Crosshairs

For all its goodness, Agile also presents some challenges. Information flow is one of those that Agile cannot necessarily fix. Too much communication, too little absorption by all the relevant stakeholders can lead to rework, distractions and duplication. When important decisions are being made on the fly (which is a strength of agile), it is critical that these get communicated effectively to the team. Use the daily stand-ups to facilitate this.

Get everything into Jira & Confluence

Your agile project is probably using Jira/Confluence as its tool. Ensure that Jira (or any other tool of choice) is the one and only source of truth. A half-baked attempt at using Jira does not help the project move forward, and only serves to intensify the problems associated with information crosshairs.

Jira is great, but Kanban boards can be better 

Tools like Jira are fantastic to keep track of all your user stories. Physical Kanban boards where team members update their stories at daily stand-ups form part of powerful agile rituals that can congeal a team. There is something inherently primitive about having a tactile experience of moving a card to ‘feel’ progress. More so, a physical Kanban board is a prevailing communication tool to sponsors, program managers and similar management stakeholders that have a constant visual report they can access at any point in time.

Physical Kanban boards however, do not work very well when you have distributed teams located across the globe. In these circumstances, a Kanban board can work better for a localised team that is working on a stream within a larger project.

Getting the best people in the room

This concept is not unique to Agile. Having the best people in the room increases your chances of working in any environment. I have found that two key agile roles can have a huge positive effect on the life of a BA in an agile project are:

  • •          The Product Owner:  This person needs to be a strong advocate for the system and should be empowered to make substantial decisions on behalf of the business.  All team members (business analysts included) will turn to the product owner when making critical decisions about the solution.
  • •          The Scrum Master:  A good scrum master should be able to facilitate momentum on the project and clear any obstacles. A good scrum master connects the dots between all project disciplines and overlays this with his/her deep insights about agile practices.

Most importantly … play and have fun

Kids in a playground manufacture fun in a way that might be observed as chaos to an outsider.  An agile project has similar traits. Leave the shackles of your waterfall past behind and embrace a more collaborative (sometimes messy), but ultimately more energetic, adaptable and fun way of working.

 

 

To find out more about what’s happening in the world of Business Analysis follow us on LinkedIn

 

 

‘A Typical Day with AI’

by Esther Herzog,

Business Analysts Pty Ltd Consultant

 

The purpose of this blog is to observe how AI is currently able to assist our everyday activities from sunrise to sundown.

AI should be augmenting the tasks and activities we already complete in our everyday lives, rather than creating completely different ways of completing simple processes.

Let’s explore AI and how it is leveraged to ensure maximum benefits.

Here is a look at an AI timeline journey on a typical weekday, a look into the everyday journey of a busy working family.

 

 

 

5am

  • Using the home speaker device to program the alarm to wake the family by sending a signal to all connected smart devices to tell everyone to wake up and shuts the children’s access to the internet off until they reach school.
  • The smart home energy control IoT that is incorporated into the home, opens the shut-out blinds automatically, the air-conditioning is switched to off and the lights are monitored according to the time of day and natural light capacity.

6am

  • The scheduled activities are notified to all family members via smart devices. Scheduling has been completed at the weekend with an automated virtual scheduling assistant (VSA). VSA identifies the planned activities and tasks for each day and the required attire or apparatuses.
  • The AM news is automatically switched to on using IoT smart tv.
  • The AI based voice recognition fridge is activated for school lunch recipes. Suggestions are produced to the group and the ability to purchase groceries if required.

7am

  • The IoT home speaker device is making clothing recommendations based on the weather forecast for the day and also identifying if rain is a high possibility to necessitate the use of an umbrella.

7:50am

  • An automated alert via the home connectivity technology is sounded to make sure everyone is on track for departure at 8am.
  • A reminder is set to collect bus passes and to ensure the sporting and music apparatuses for after school activities are organized, And a reminder as to whether it is bin day, or recycling bin week.
  • Everyone in the house has their wearable device, as emotion AI uses voice analysis beyond natural language processing (NLP) to detect the user’s emotion to better predict suggested treatments. Utilising machine learning, emotion AI technology is lent anthropomorphic qualities to collate data on human individuals to learn their specific emotive behaviors, thereby formulating a personalized experience.

8am

  • The IoT blinds are shut and all not vital power is switched to off.
  • The smart phone is able to alert you to the best route to school and work, alerting you to possible areas of dense traffic or vehicle related incidents.
  • Leaving the house, using security technology, enabled with machine learning and biometrics.
  • Jumping into the car which has emotional processing capability using computer vision, and audio sensors to cater and adapt to the needs of the persons within the vehicle, such as detecting blue lips indicting that the temperature control is to be adjusted automatically. And the ability to monitor safe driving behavior.
  • During the day if any parcels are to be delivered the delivery man has access to a parcel door (the size of a cat door) that requires an access code and is monitored by smart security and surveillance cameras.

9am

  • Access to your work building is via facial recognition security technology using deep sensory cameras to gain access to the lifts, the smart security knows which floor you want to be dropped at.
  • To gain access to your company’s network; the security technology uses your face, and this also grants multi-application access.
  • You open your tasks for the day as these have been categorized by your AI virtual personal assistant (VPA), which also determines your meetings scheduled into your calendar for the day and is able to send these through to your smart phone, which is attached to your wrist. This enables an understanding of your location requirements for all meetings. Your VPA can automatically set meetings up when required.
  • Your VPA can also help with providing research to solve business problems, or business analysis approach suggestions, by sourcing data from the BABOK or Agile extension.
  • Through-out the day your smart watch is reminding you to stand up, because it knows when you have seated too long, your body temperature is also monitored to assess your water consumption requirements through-out the day.

12pm

  • It’s lunch time, you tell your VPA you want lunch within close proximity of your office, with a specific price point and the cuisine type. The assistant researches options and returns the top three results. If you are having a social work gathering, it may be applicable to ensure delivery which can be arranged by your VPA, however if the meal is individually focused, then the smart watch will advise of the time it will be estimated to reach the destination. And that walking is the best option to take in terms of retrieving your lunch meal.

3pm

  • A healthy snack reminder is sent to your smart watch and remaining tasks that are outstanding for the day.

5pm

  • Home time; send a check message to the smart appliance fridge to identify any movement with milk or bread supplies. The ability to automatically order online for a click and collect at the supermarket.

6pm

  • 3D deep sensing camera technology for facial recognition will allow all members of the family to easily access the home, however non authorized persons will be denied access.
  • Time to seat everyone for a meal and then off to scheduled sporting activities.

 

With the adoption of wearable tech, advancements in home smart devices and improvements in facial recognition, combining these avenues currently provides a significant avenue for AI to simplify our lives.

Imagine what the future holds…

 

To find out more about what’s happening in the world of Business Analysis follow us on LinkedIn

 

 

 

Relative Estimation: A Simple Yet Effective Method of Estimation.

by Shanil Wiratunga,

Business Analysts Pty Ltd Consultant

 

Many moons ago as a young techy I spent numerous hours and days with my teammates, working in laborious estimation sessions, trying to arrive at the most accurate estimate to develop features of a Software solution. From here we created Gantt charts and plans so detailed and lengthy, that they ended up looking like bowls of noodles. It didn’t stop there, as scope and requirement changes would creep in, we’d have to rework these estimates, and the lengthy, stripy charts all over again. But did this help to deliver our projects on time? Well the answer to that question is quite complicated. Yes, we delivered on time, but that is after having toiled away many weekends, public holidays and after office hours to ensure all the remaining work was squeezed in.

This pain staking process went on for many years to come until one day I had the opportunity to attend a seminar on Agile. That was my very first sneak peek at this wonderful world. I learnt many concepts, techniques, theories and most importantly a different way of estimating called ‘Relative Estimation’. I started my quest to learn more about this technique as much as I did on the other Agile concepts. The more I learnt through research and experience, the more I realised how simple, yet effective relative estimation is. It is something we always do. It second nature to us, and hence, the reason why it works so well too.

Before we delve deeper into this, let’s have a look at what estimation in is in the first place. Why it is so challenging?  If then, what is relative estimation? Why I think relative estimation is a more conducive and simple way of estimating in software development projects, as opposed to the conventional absolute estimation.

 

 

What Is estimation or absolute estimation?

In Software development projects estimation is used for predicting the most realistic amount of effort required to develop or maintain software, based on incomplete, uncertain, and clouded inputs. One of the key attributes that is predicted in the process of estimation is the time to pursue a course of action. From this teams estimate the cost associated to the time and the value associated with the suggested course of action.

There are many methods that are used for estimation as well. Some of them are:

  • Top down
  • Bottom up
  • Rough Order of Magnitude (ROM)
  • Rolling wave
  • Delphi
  • PERT

Why is absolute estimating so challenging?

Firstly, it must be said that we humans were not designed for absolute estimations. Our brain alone does not have the capability of doing absolute measurements and estimates. We tend to be optimistic or pessimistic more than realistic most of the time. However, it’s easier for humans to relate to similar items than to guess the actual size of things. Humans are designed to look at things comparatively, and relatively.

Secondly, in a world of rapidly changing technology, requirements and scope changes are inevitable. There are so many unknowns and moving parts in a typical project, which makes estimating with an acceptable level of accuracy a nightmare.

What is relative estimation?

Relative estimation is the process of estimating items, not by units of time or size separately, but rather by comparing how they are similar to each other in terms of complexity.  Agile alliance defines relative estimation as one of the several distinct flavours of estimation used in Agile teams, and consists of estimating tasks or user stories, not separately and in absolute units of time, but by comparison or by grouping of items of equivalent difficulty. Basically, relative estimation applies the principle that comparing is much quicker and more accurate than absolute estimation.

Let’s look at an example from what we do almost every day. Buying coffee.  When we go to a coffee shop to get a coffee the Barista asks us to choose the size of the coffee. Assuming we have never been to the coffee shop before we would not know the sizes of the cups, as large, medium or small. Either we could make a lucky guess thinking large would be too large or a small would be too small and settle for the medium, or we could look at the coffee cups kept on the coffee machine to determine the size required, thinking of the sizes of cups we have had in the past. It is very unlikely that we would think in absolute terms whether the small cup is 40 ml or 50 ml or the large is 100 ml before a decision is made. So, what have we done here? We have looked at the relative sizes of the coffee cups and made a relative estimate, to predict what might satisfy our coffee cravings for that moment in time.

Now let’s bake some cakes with relative estimation. Suppose you as a participant is required to bake 3 cakes for a Master Chef competition. The types of cakes to be baked are given by the judges, with 3 sample cakes already made in front of you. The three cakes are of three different sizes. You are supposed to make the 3 cakes exactly the same way as the sample cakes including the same dimensions, colours, flavours etc.  The judges say that there is however one condition that you need to be aware of. That is, you need to let them know how long it would take to bake the 3 cakes beforehand, and you need to stick to the time you commit to. The estimated time frame given would be validated by the expert judges, to ascertain if it’s realistic or too blown up.

 

 

So how can you do this? In the past you have made one of the cakes, which is the smallest out of the three, therefore you know how long it would take to make it.  Let say it’s one hour. That could be considered the length of the sprint. You have no idea how to make the other 2 cakes, and how long it would take, the ingredients required etc. But, can assume that the medium sized cake is three times the size of the small one, and the largest is about 5 times the size of the small one. Let’s classify these cakes using a unit of measurement called ‘Cake points’ looking at their relative sizes. The smallest cake could be given 10 cake points. Therefore, the medium sized cake could be given 30 cake points and the large cake 50 cake points. These numbers are just arbitrary numbers, and do not relate to a specific unit of size or time. Since it was said that the smallest cake i.e. 10 Cake points cake can be made in one hour which is the sprint duration, we could easily say that the velocity is 10 Cake points per Sprint. So what’s the total amount of work required for all 3 cakes looking at their relative sizes? It would be 10+30+50=90 Cake points. Given the velocity as 10 Cake points, a little bit of math can show you that you will need 9 sprints to make all 3 cakes. With one sprint being an hour’s duration, it could be determined that all these cakes would take 9 hours to make.   This is the essence of relative estimation. This theory can be applied to Software development projects as well. You could look at a feature and say “I think the feature A is twice as complex as feature B“, with the given knowledge by completing feature A in the past. There is no mention of time requirement, just that it is more complex than the other. Therefore, if feature A took 3 weeks to complete, it is reasonable to think that feature B would take 6 weeks. Isn’t that simple.

Estimation, whether relative or absolute, can be very challenging especially in the world of software development. Even though no estimation technique may be perfect, by comparison relative estimation is a simple, effective and ‘relatively’ accurate method of estimation.

To find out more about what’s happening in the world of Business Analysis follow us on LinkedIn