Tag: Methodologies

Can You Really Play Agile SAFe?

Written by Paul Oppong on September 5, 2019. Posted in Articles.

Agile SAFe has been touted by some as being a good solution for the implementation of agile in larger organisations.

However, ever since the idea was first initiated it has been a cause of controversy and disagreement in the agile community. It is helpful to assess whether organisations can really play agile SAFe, considering its benefits and challenges. It is also useful to think about practical factors associated with its implementation, to try and make any use of agile SAFe as beneficial as possible for organisations. These points are considered below.

What is Agile SAFe?

Before progressing, it is important to understand what is meant by agile SAFe. SAFe is an approach that was put forward in 2011, with a view to aiding software development teams to get improved products to market at a greater speed. SAFe stands for Scaled Agile Framework, and since its conception, organisations have been working to build tools that can help with its implementation within larger organisations. SAFe is a framework that aims to help in situations where scale is a factor. Working within SAFe, there is thought to be improved collaboration, especially across different teams, and the making of decisions is centralised. SAFe generally works with a Scrum central to the process, but there is a larger sprint which operates across several teams. Each of these teams use smaller sprints.

Benefits of SAFe

Advocates of the SAFe approach argue that this framework allows its users to use agile at scale. It is suggested that SAFe offers an increased level of agility and a more thorough agile implementation. Proponents of the approach argue that while SAFe may not be as effective as putting a pure agile system in place, in fact it does at least offer a starting point for bigger organisations to put in place more of an agile system. It is therefore suggested that SAFe is not really an absolute target, but rather that it may be used to get organisations moving in a direction towards real agility. It provides an opportunity for large organisations to gain some of the benefits of agile, when they otherwise might not be able to. This may be considered benefit enough by some organisations.

Challenges with SAFe

While SAFe appeared at first to offer an excellent solution as a scaled approach, in fact, evidence suggests that it has not delivered the hoped-for benefits. One of the problems with it has been unrealistic expectations within organisations. It is tempting to believe that SAFe can deliver magical results with little energy expended to achieve this. This is not the case. SAFe requires a transformation of mindsets, not just a few days of training. In fact, in 2017 the Association for Project Management found that mindset change is more important than changing methods. As such, SAFe requires fundamental change to organisational activities and behaviour to make it a success. This takes years rather than months to bring about, so it requires significant commitment and effort. It is not a wonder drug that can suddenly deliver tremendous results. In my experience, business leaders do not necessarily appreciate this. Those who believe SAFe is not helpful also argue that no organisation has ever said that it has been hugely beneficial for them. This is problematic.

Thoughts on Adopting Agile SAFe

Many agile experts argue that SAFe should not be adopted as it is not bona fide agile. Further, SAFe has been dubbed “unSAFe” by some of these same individuals. It is felt that SAFe works against one of the fundamental principles of an agile approach, that of focusing on people and their interactions rather than tools and processes. While on paper it might seem that this framework will offer flexibility, it goes against this when it is aimed to implement it from a practical perspective.

On the other hand, it cannot be ignored that agile SAFe may offer some benefits for organisations that want to start along the journey to true agility, and that this framework does offer an important opportunity for larger organisations that might otherwise not be able to make agile work. While SAFe may be a very imperfect solution, it does help with starting to address some of the challenges of project management within larger organisations.

At best however, it is worth noting that agile SAFe is likely to only work in some organisations, and even then, only some of the time. Each organisation will need to consider its own circumstances and the extent to which it can work on transformation towards an agile mindset as an end goal, for this to be of benefit.

For those that do want to play agile SAFe, it is highly recommended to put in place monitoring and measurement of certain goals. After all, any change ought to deliver benefits including some sort of return on investment. It is worth considering metrics that measure customer satisfaction, productivity, quality (fewer defects), cycle time and release time, stabilisation and employee satisfaction to identify if any of these have improved as a result of putting in place agile SAFe. If not, then the program is not worthwhile.

Summary

Agile SAFe has created a lot of controversy in the agile community. While SAFe does have the potential to bring about some change in working towards a scaled agile approach in larger organisations, there are serious concerns that it may be seen as a “wonder drug” and that many organisations do not put the time or effort required into delivering the transformation of mindsets needed to be truly agile. This can lead to SAFe being considered “unSAFe”. Those large organisations that do want to implement SAFe should perhaps view it as an important starting point along the road to eventually becoming truly agile, realising that the journey will take years rather than months. Having in place a system of measurements to ensure that return on investment is achieved through the use of such a program is highly recommended for those organisations that want to play agile SAFe.

Business Analyst Role in COTS Projects

Written by Maksym Lysikov on August 8, 2019. Posted in Articles. 1 Comment on Business Analyst Role in COTS Projects

Many tech companies offer commercial off-the-shelf (COTS) products.

Such products allow to meet their clients’ business needs relatively fast, comparing to the development of the new IT solutions from scratch. However, a COTS product for a complex solution such as ERP, CRM, laboratory or hospital information systems requires considerable time and effort to be invested into the configuration. Hence organizations usually involve a separate implementation team of professionals familiar with the COTS product to adapt it for the company’s needs.

COTS vendors normally provide the implementation service to their clients. This can vary from company to company, but oftentimes it includes discovery phase, configuration or customization of the system according to the business needs, user training and making sure the project goes live.

This article describes the BA role in the implementation of the COTS projects and cooperation between a COTS product team and BA from an implementation team.

BA in Implementation Project

One might say that COTS projects do not require business analysis since there seem to be no significant development activities. However, COTS projects could vary from completely out-of-the-box to complex solutions with lots of configuration and additional customization (codding) involved. In the latter case we can and shall involve the standard business analysis activities:

Plan your business analysis work. Ask yourself what is your business analysis approach (adaptive vs predictive)? Who are your stakeholders? Do you have a requirements governance process in place?
Requirements elicitation and analysis. This covers discovering the current and desirable states, conducting workshops and interviews, document analysis, etc. Don’t forget to elicit and document any gaps if a COTS solution is not capable to meet some of the business needs.
Requirements modeling. COTS projects normally do not require the complete functional specification since the solution is predefined already. However, there are many other requirement views which can be useful for the configuration project. We will discuss that in the section that follows.
Solution evaluation. Define your KPI and measure if they improved compared to the legacy solution.
Configuration. System configuration is normally out of business analysis scope, but some companies tend to involve business analysts in such activities. In any case, the BA should know how the system works and understand the solution limitations.

Requirements Modeling

As mentioned before, it might not be required to document all the functional requirements for the already predefined solution like COTS product. However, not documenting requirements at all could result in certain drawbacks:

Apparently, external stakeholders, like end users, and internal stakeholders, like testing or support teams, will need at least some documentation that describes how the system behaves.
Without modeled requirements, there is no way to validate the requirements before they are actually implemented and the system is demoed for users. What if you only validate your assumptions by demoing already configured piece of functionality? That is right, you will most likely need to reconfigure the system again once you receive the feedback, and then again and again. Nevertheless, you still can present out-of-the-box functionality which doesn’t require any configuration efforts and use it as a starting point to collect the initial feedback from your users.
The change management process can suffer. Imagine that you documented the requirements for the billing module in the bunch of meeting notes, and now 4 weeks after the requirements were implemented the clients insists that some of the billing transactions are not calculated correctly. Would it be easier to refer to the SRS part where all business rules are documented, or try to find the relevant emails?

To address the above issues, the BA can use a variety of the business analysis techniques which will be applicable for the project and audience. For example:

Roles and Permission Matrix: most of the COTS solutions allow roles configuration and assigning permissions. Start with defining and documenting user roles and their permissions. The organization chart can come in handy to define the roles.
Process Modeling: you can elicit and model the current processes using either the standard notations such as BPMN, UML or come up with a simple drawing which doesn’t follow any notation standard but clear for the audience. The next step will be to review the models with stakeholders, define if anything should be changed in the process and update the model. Once done, you can supplement the model with the additional requirements view, e.g. use cases.
Gap Analysis: as the BA on the implementation project you need to identify the areas in your client’s business which are not covered by the COTS package and address it to the product team. Bear in mind that it is always a good idea to think about the potential workarounds you can offer to the client, before escalating the gap to the product team. That way the client can access the desired functionality earlier, the product backlog will not be overloaded and there will be no need to overengineer the product with the functionality potentially used by only 1 client. So at first always assess if it is possible to configure the system in an alternative way or if the client can agree to do certain steps manually.
User Stories: this is a simple and popular way of specifying the requirements, especially if you follow the agile approach and need to deploy the COTS solution incrementally. It is also quite convenient to prioritize the requirements using the user story form.
Use Case and Scenarios: you can document each separate business flow in the use case. Use cases can easily be converted into the test scripts and serve for validation purposes.
Business Rules Analysis: it is always a good idea to elicit and document business rules. Make sure you have a process in place to update business rules due to external or internal changes.
Interface Analysis: your COTS product will most likely not be used as a standalone solution and will communicate with other components. Define and document interfaces specific to your client.
Data requirements: usually a COTS solution replaces an outdated legacy solution and you need to take care of the historical data. And it is better to define data requirements upfront before you realize you cannot import 256 characters long text into the address column for one of the top customer’s client. Ask yourself the following questions: do you need to import the historical data into your brand new COTS solution? will the legacy data fit the new system? how will you handle the cases when the data doesn’t fit the new COTS product?

Provide Feedback to your Product Team

A good way to improve the product is to listen to your user’s feedback. And when it comes to COTS project who is the best candidate to elicit, analyze and document all the client’s concerns and frustrations? Yes, you’ve got it right! It is the implementation BA or anyone else who fulfills this role in an organization. And thus the BA is the one who should establish a process to communicate all business concerns and client gaps to COTS product team.

For example, the BA can create a separate Wiki page per a client where they can list all gaps discovered during the project and communicate them to the product team. The product team can then collect the feedback from all clients, prioritize the gaps for the future releases and share the roadmap with the implementation team.

Conclusion

COTS implementation projects can be a challenge for the BA as they differ from the traditional IT development projects. However, with the right attitude and a bit of creative thinking, we can adopt the BA techniques and establish the process which will bring value to the implementation projects and help improve the COTS product.

Your Agile Might be Fake

Written by Paul Oppong on July 3, 2019. Posted in Articles.

“Agile” is a term commonly used in organisations of all shapes and sizes these days.

When I go into organisations, I hear leaders saying, “We use agile”, yet digging deeper, I find things aren’t quite, well, agile, in fact sometimes not at all. A fake idea of agile implementation is commonplace, and managers say the agile words without really understanding the principles and concepts behind them. This means that the team is not truly agile at all, and not reaping the rewards of being agile either. But what does fake agile look like, and how can this be diagnosed in an organisation?

Symptoms and Signs of “Fake Agile”

There are numerous signs and symptoms that an organisation is not being genuinely agile. One of the most common is perhaps the idea that a team can take the elements of agile that they like and use only these, discarding the rest. People who have implemented this approach will make comments saying that they use agile techniques while then going on to say, “Well, it’s not quite agile, we used what we liked from a few different models.”

Another common challenge is not really understanding the core concepts of agile, while still believing the team is working within them. For example, agile is fast, meetings should be fairly quick, while covering the activities of yesterday and today, and discussing barriers. The idea of a daily Stand-up meeting for instance in a Scrum or Kanban agile implementation is to keep it concise and to the point. Some teams find they are having stand-ups that last multiple hours. This indicates the agile implementation might be what it is meant to be and not really working. It might mean that the meeting probably has too many attendees, and in which case it might be possible to work in smaller groups instead. Alternatively it can mean the team is working in a hierarchical manner, which is not the point of agile.

When a team is truly agile it will continuously deliver value to customers. This is a critical underpinning principle of agile. The reason for introducing this concept to agile, was that in the past, developers would work on a project for months, deliver it to the end customer, and by the time it was delivered, requirements would have moved on, or it would not do quite what the customer needed. This means that there is a need to understand customer needs throughout the development process. This is an idea that agile is built around, and hence the principle of continuously delivering value. This leads to the ability to pinpoint other clear indicators of fake agile. It follows that if teams are not securing feedback from customers regularly, and looking at it quickly, then they are not continuously delivering value to them. Feedback is a regular and integral part of agile. What is more, if no time or money is budgeted for change to the project then the team is probably not agile. This is because continuously providing value will invariably require looking at ways to change the development, so it more closely aligns with customer needs, once feedback is received.

Three Key Questions to Diagnose “Fake Agile”

There are some questions that can be posed to those leading so-called agile programs to determine if they really are embracing agile concepts. You might ask, “Do real users see iterative working version of the product, and if so, how often?” If the answer is no, agile is not in place. It is also a problem if customers only see iterations every few months. This is not agile project management either. The end users should be seeing and feeding back on iterations with regularity.

Another question that you could ask is, “How frequently is feedback from users converted into work activities for teams?” If the answer is never, the team is clearly not agile. If the leader responds that this happens within time frames of less than one month, then it is possible that agile is operating as it should. After all, as we have seen above, agile operating is all about meeting customer requirements by taking on board feedback and incorporating it into the project.

A third key question to ask is about team empowerment. You may ask, “What level of empowerment do team members have? Can they change processes and requirements based on user feedback and on what they learn?” Empowerment of team members is a core principle of agile operating. Leaders that say any answer that includes, “Yes they are empowered but…” are probably not following agile methodology. Any indication of hierarchical, top-down decision making goes against the agile way of working.

Summary

Many business leaders think they are being agile. They also like to say it, because agile is a popular buzz word. That does not mean they actually are agile. Any so-called “agile” approach that just takes the parts of agile the leader likes and ignores the rest is not truly agile. Underlying agile is fast, iterative development, with feedback taken on board along the way, to continuously deliver value to customers. Where an “agile” solution does not do this – beware! It is almost certainly going to be fake agile.

Yet another enquiry to make is whether the whole project operation is agile. This will help pick out those leaders that think they have got the best of both worlds by using some agile principles combined with other more traditional forms of project management because these are more palatable with their idea of control and command. If the answer is no, then the team is not working in an agile manner. In fact, if the answer is “Partly”, this is also still true. When agile teams work in an agile way to start with, and then use bureaucracy later on in the process, this is not agile operating. The only correct answer to this type of question is, “Yes” without any caveats being applied.

Why Agile isn’t Enough Part 3: Lean Startup Measure Phase and BA Techniques that Enhance it

Written by Richard Larson on July 3, 2019. Posted in Articles.

In previous parts of this article, we covered an overview of Lean Startups and its Build-Measure-Learn (BML) methodology.

We also detailed the Build portion of the cycle, including the Minimum Viable Product and its importance to the Lean Startup approach.

To summarize Lean Startup, the method was created by Eric Ries and detailed in his groundbreaking book The Lean Startup[1] back in 2011. Lean Startup can guide product development, shorten development cycles, and help us deliver the products and features customers need, not just what they tell us they need.

In this part we’ll examine the next portion of the B-M-L cycle, Measure and why it is crucial to success.

MEASURE

After building a product or features of a product, the second part of the Lean Startup method is measuring how that product is adopted and used. Tools such as focus groups and surveys are useful measuring tools. But beware of over-relying on them since focus groups only reveal how people feel and surveys only tell us what they think.

Beware also of so-called “Vanity Metrics” since they tend to make us feel good and don’t lead to the kind of learning we need. These metrics tend to be easy to capture, such as number of users or site visits, and may show false progress. For example:

The number of visitors to a web site is easy to measure and seeing an increase after a product launch feels good.
Let’s say your team uses a strategy of offering a free version of a product to attract potential paying customers. A large spike in new product users is a vanity metric since it masks how people like the product or how likely they are to become paying members.

Instead, we need to find what I call “Metrics that Matter.” Those are usually harder to obtain, but typically more meaningful. For the above two examples:

Measuring the number of site visitors who return to the website and how quickly they return is harder to measure but gives a better sense of meaningful customer interest.
Tracking the free members who convert to paying customers is harder than just measuring the new members. But those conversions are a much more meaningful measurement – just ask any digital marketing person about the importance of conversions.

To focus on metrics that matter, Eric Ries suggests we use AAA metrics¹, which are:

Actionable – these must prove a clear cause and effect otherwise they are vanity metrics. They should also be significant enough to base a decision on. Example: discovering a new feature that is not used much and then dropping it or deciding not to enhance it.
Accessible – the product team needs to be able to access the measures to gather, analyze, and learn from them. For example, Google Analytics is useful for web site measurements and is highly accessible. But, that tool can provide plenty of vanity metrics such as number of site visits per month. More significant would be to measure the number of people returning in subsequent months and then doing “cohort analysis” on groups of returning customers using Google Analytics.

Find AAA metrics:

· Actionable

· Accessible

· Auditable

Auditable – ensure the data is credible and can be verified. Often this means spot-checking the data with real customers. Auditable also means to keep reporting processes simple, preferably with data directly from operational data (vs. manual manipulation). What this means is that the process by which measures are obtained is simple and can be independently verified. Example: surveying customers directly to verify their purchase decisions.

Measure – 9 techniques

Figure 1 below shows a list of nine standard Business Analysis techniques that will assist in the Measurement part of the B-M-L cycle. In addition, below are two that are not yet in the IIBA or PMI standards, but are still important in the Measuring phase

Cohort Analysis – important for a startup to track how groups of related customers or customer segments are acquired and retained. Cohorts can help us determine which features will be valued by different segments. Google Analytics has a new cohort analysis tool that can help. Cohort analysis is like the use of personas which group users by various characteristics. But the two differ in that cohorts are established by their current and past behavior, not by projected traits, and we can measure cohort behavior.

A/B Split testing – is a simple and effective way to run an experiment to learn which features are used, which marketing messages appeal better, even which kinds of web pages are more effective at promoting a product.

Two test groups are given different product versions to see which group adopts and uses which version to determine the one that is most effective. The differences are usually controlled to see which feature(s) made the biggest difference. Often the versions are tested in a live, production environment to not slow down progress.

It is not an official technique in any BA standard but is referred to as part of experiments.

Figure 1: Techniques for Measuring

In summary, the Measure stage of the Lean Startup methodology lays the groundwork for us to learn what worked and what didn’t with what we built. The measures and the learning from those measures are what separates an ordinary Agile effort from a Lean Startup. I also feel the “M-L” work we do contributes to greater – and faster – success with products we release than with typical delivery cycles.

Some important facets to remember about measuring are to avoid “vanity metrics,” which are easy-to-capture measures that are inclined to make the team feel better about making progress. It is far better to discover “metrics that matter” using AAA metrics –Actionable, Accessible, and Auditable. These are often harder to obtain but will enable the greatest learning.

Speaking of learning, the final part of this series covers the Learn portion of the B-M-L methodology of Lean Startup.

[1] Eric Ries, The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses, New York: Crown Business Books, 2011

Business analysis canvas – The ultimate enterprise architecture

Written by LN Mishra on June 19, 2019. Posted in Articles. 1 Comment on Business analysis canvas – The ultimate enterprise architecture

Business analysis is a fascinating subject.

As business analysts, we need to understand enterprises very well. However, when we look at different frameworks available for business analysis, they seem to be somewhat limited in their scope. Some of them are good in strategic thinking (like SWOT), some of them are good in tactical thinking (Business model canvas, SIPOC, VSM etc.), but there are no frameworks which give us an idea which covers both strategy and tactical aspects.

Business analysis canvas is an attempt to fulfill this need. In this, we are going to start with strategy and go down to the operational level.

Essentially it has 10 core elements and each core element, of course, has sub-elements which we need to understand. Here, we shall go through one by one:

1. Vision / Goal / Objectives
2. External environment
3. Internal environment
4. Strategies
5. Customer management
6. Cost management
7. Stakeholder management
8. Product and services management
9. Risk management
10. Resources

1. Vision / Goal / Objectives

(Financial, Customer, People, Societal, Environmental, Process)
Vision / goal / objectives are essential for any organization to have long-term sustainable growth. Without a vision, it may be difficult for an enterprise to maintain focus. Organizations that do not develop a proper vision or goal usually underperform in the long term.
The organization can set goals and objectives with respect to various aspects such as financial, customer, people, societal, environmental, process etc.

2. External environment

(Competition, Customer, Macroeconomic environment, Regulation, Technology)
The second key element that business analysts must pay attention to is what is happening in the external environment. All businesses operate within an economic environment, which is changing constantly.
Environment essentially comprises of factors like competitors, customers, macroeconomic factors, regulation, and technology.This offers tremendous opportunity, as well as posing threats to the organization. So business analysts must figure out what is happening in the external environment, and how can the organization take benefit of the changes in the environment, or protect itself from the threats arising from the external environment.

3. Internal environment

(Culture, Structure, Products, Capabilities)
After external environment, the next element that business analysts must pay close attention to is the internal environment of the organization. Some the key factors that we look for in an internal environment are the culture of the organization, structure of the organization, the products that the organization has, services it provides, capabilities it has. If the internal environment becomes weak for an organization, it will also lead to the downfall of the organization. Organizations those do not develop capabilities continually or stop innovating or their culture becomes toxic, will for sure lead to organization’s failure.

4. Strategies

(Innovation, Cost leadership, Quality, Focus, Customer intimacy)
Based on the organizational vision, goal, objectives, understanding of the external and internal environments, the organization must develop suitable strategies to be successful in the marketplace. Common strategies that most organizations follow are innovation, cost, leadership, quality, focus, and customer intimacy. There can be multiple strategies playing together in the organization.
However, the organization must figure out what strategy works well for the given size and maturity of the organization and act accordingly. Strategy affects organizational operations as well as sets the direction for the organization. One must be very careful in choosing strategy but at the same time, not get paranoid regarding it. This is because the strategies may work or may not, and one must figure out and adjust the organization strategy as it moves forward in the organizational journey.

5. Customer management

(Segments, value propositions)
Though customers are stakeholders as well, we must differentiate them as they are the most valuable stakeholder in the organization. Customers are the only source of revenue for any organization and understanding customer needs is extremely vital for any organization to be successful. The organization should identify the different kinds of segments and then develop propositions of the right value, which will attract potential customers to the organization. At the same time, the organization also must understand profitability aspects for each of the customer segments and figure out a way to serve each customer segment profitably.

6. Cost management

(Structure, Optimization)
If costs are not managed well in an organization, it will lead to a drop in the profitability and finally leading to shutdown of the organization. As business analysts, we should understand the different elements of the cost structure, and which elements of the structure can be optimized for organizational benefit. At the same time, one must be careful that the lowest cost is not necessarily the optimized cost because the lowest cost could compromise on the product or service quality. This, in turn, would affect organization’s customer satisfaction and ability to earn revenue from its customers.

7. Stakeholder management

(Identification, Analysis, Engagement)
Business analysts need to understand stakeholders for the organization, initiative or project as everything that business analysts do must add value to the stakeholders. Effective stakeholder management is essential for the success of any change. Stakeholders could be internal or external to the organization.
Key steps that we would follow for stakeholder management would be to identify stakeholders, analyze stakeholders for the criticality and contribution. Of course, business analysts must engage with stakeholders to reap benefits from the initiative.

8. Product and services management

(Portfolio, Contribution, Improvement, Processes)
Next element that we business analysts need to understand is product and services of the organization. Most organizations offer multiple products and services. It is essential for the organizations to understand the portfolio that they would like to maintain, contributions coming from different product and service lines, what kind of improvements or innovations are possible in existing products and services, and to develop new products and services, and bring about improvements to the processes carried out in the organizations.

9. Risk management

(Identification, Analysis, Mitigation)
Any organization has multiple risks from different sources including external and internal sources. Organizations must be cognizant of the sources of risks that it faces and develop suitable mitigations for managing business risks. Some activities can put the organization at a serious loss (even leading to the closure of the organization). All of us know the story of Enron and Arthur Andersen when they violated government regulations and finally leading to the closure of both these organizations. Not understanding risks coming from technological or demographic changes of customers can lead to companies going bankrupt because their products no longer have demand in the marketplace.

10. Resource management

(People, Financial, Technological, Physical)
The last element we discuss is resource management. Resources are essential for delivering any product and services to customers. Different kinds of resources that the organization must develop, maintain, and improve include people resources, financial resources, technological resources, and physical resources.

Nature of resources that an organization should possess is changing dramatically over the time. For many services organization in the olden days, having physical assets was very helpful. Today, in certain segments, it’s probably better not to have physical assets, but rather have digital assets. Physical assets require a significant amount of money to be maintained. In future, organizations will develop more and more digital assets as maintaining digital assets cost less, and can earn revenue across the globe, whereas physical resources mostly earn revenue from a specific geography.