Agile Business Analysis – avoid waste

Posted on by

Business analysis in an ever changing environment creates many challenges for an analyst. To be able to tackle this challenge effectively, the analyst must implement several rules to the analysis process to make it more agile. One of these rules is the Avoid Waste one described in the Agile Extension to the BABOKv2® Guide. In this post, we will see how an analyst can avoid generating waste and eradicate empty runs. We will also find out if it is worth doing so?

What creates value?

It is good to start with the analysis of your current process. The process usually consists of all activities you participate in (including all kinds of team meetings, tasks related to reviewing documentation or reporting process) along with the artefacts which are a result of your work (describing requirements, creating models, mockups, reports, ect.). It is worth to consider and appreciate the value brought by each of these process components.

The following questions may be helpful when scrutinizing the components of your activities and processes:

  • Who benefits from the value being created? (Business analyst, dev team, management, clients, other entities?)
  • What type of value is being delivered? (Enhanced communication, knowledge retention, deeper understanding of needs or requirements, ect.)
  • How big is the value which is being delivered? (This one is, off course, very subjective measure.)

If you go through your activities and artefacts one by one checking them against these questions, it will be much easier to sift out the ones that do not bring any value or if they do, it is of modest impact. It is then immediately obvious that all identified elements of the process delivering minimum or no value, or elements presenting unsatisfactory cost (understood as, for example, the time it consumes) to gain ratio, should be cut out.

By eliminating unnecessary activities and artefacts you can dedicate the time you have saved to those which are crucial to your project, maximizing delivered value.

Optimize the amount of documentation and keep it up to date

Documentation adds value only when it is up to date. This is a simple rule but you can use it to adjust the amount of documentation you create to your ability of keeping it up to date later on in the process. It goes without saying that accurate and detailed documentation is useful, but if it is not maintained appropriately, the value it brings decreases rapidly with time. It so happens that the outdated documentation may generate misunderstandings or even errors. This is when it actually starts being a strain on your project. After all, it is better not to be sure what is the capital of France and establish it somehow later on, than to be informed that it is London…

The up to date documentation is essential. It requires selecting proper tools and techniques which will help you manage this process and be effective at it. The thing is to maximize the value added by documentation while minimizing the costs related to its maintenance. An experienced Business Analyst who knows many documentation techniques and tools should be able to select and recommend the most appropriate one for a given project environment. The analyst’s task here is to be able to chose the most suitable techniques and manage the level of detail of artifacts he or she creates, to be able to balance two factors: the need to have documentation as accurate as possible on one hand, with the need for continuous maintenance of that documentation on the other.

Delay decisions

It may be an unpopular view, but at times, procrastination seems to be a good approach to Business Analysis. Decisions on final solution which cut down available options and direct the implementation to a particular rut are sometimes worth to be made at the last possible moment. The shift in requirements may come up at any time in the dynamic ever-changing environment. As a result, the solutions you have already adopted may turn out unacceptable or sub-optimal. When you delay the decision moment, especially when you delay the moment you write it down in detail for documentation purposes, you limit the risk of applying changes. This way you limit the risk of wasting your time.

Another argument in support of delaying decision-making moment is a fact that people tend to get used to the resolutions they have already made. Then, any change to the plan may be treated as a potential threat and its implementation (for example, convincing a client or dev team to a different solution) requires extra effort. Which is exactly what you want to avoid.

Play the quality card

A frequent cause of creating waste is debt. The debt may be technical, functional or it may relate to quality. When you consciously decide to lower certain standards in one of these areas, you put yourself at a risk of applying changes and fixes at a later date. Taking short-cuts is tempting. However, by running on low quality requirements, lowering the standards of quality or unnecessary complicating the solution for a short term gain, you make the risk imminent. It may result in creating a debt which will have to be repaid in future and may potentially impact the quality of your solution. Worse even, it may negatively impact the effectiveness of the entire process, its development and maintenance.

In this context some may ask: why do I have to think about it when my focus is the MVP (Minimum Viable Product) and so the quality and potential debt are not paramount. I strongly disagree with such view. MVP means product of a minimum set of features and functionalities (which are based on a minimum set of requirements) adding value to the recipient. What it does not mean is that the quality of it can be compromised.

My recommendations

  • Check the value delivered by given activities and artefacts, and if they fail to deliver on satisfactory level drop them
  • Create only as much documentation as you are able to maintain
  • Select appropriate techniques and tools for the documentation creation process so you are able to maximize its value while minimizing the time spent on creating it
  • Delay decisions, do not commit to any solution too early if the fact of you making an early decision does not generate value
  • Don’t cut corners on quality, it will lead to waste in the long run

Sources

Agile Extension to the BABOK® Guide. Version 2. 2017.