Business analysis in classical, hybrid and agile project contexts
What does the BABOK® Agile Extension v2 achieve?
This post will explore how business analysis changes in the context of projects with different degrees of agility and has to be adapted to real-world situations to achieve the best possible results. The second version of the agile extension of the IIBA®, which is based on the current BABOK® v3[1] introduces new structures for agile principles and the concept of planning horizons. I will briefly introduce them here and evaluate their practical relevance.
How agile is the project?
By this, we mean the amount of agility that can be found in the project. These days, projects are normally neither purely “classical” nor purely “agile”. Even the often-used concept “hybrid” as a mixed form reflects reality imprecisely. Rather, agility in real-world projects has more of the character of an analog variable, it doesn’t have levels, from classic to agile and with countless manifestations between.
Can one project be a “bit” agile and another project a bit more? We think the answer is yes, absolutely! Most businesses have successfully introduced agility into their project management with a step-by-step approach. They have experimented with smaller projects, continually learned through experience and have successfully introduced more agility as time goes on. Project organization therefore becomes more and more agile from an inner mindset, and the degree of agility increases bit-by-bit in larger projects. Agility is a value system that unavoidably changes the culture of a business and takes some time. A quick and rushed introduction of agility in one large step is a cause of failure, especially in large businesses with lots of differently ranked stakeholders and a complex, multi-layered culture. Through failed attempts at agility, the term “agile” has been scorched in many businesses, and further attempts are often noticeably more difficult to design, or the lack of internal support is not addressed first.
What does this mean for business analysis in projects? How far does the project’s degree of agility influence the business analysts’ word? The answer here is: substantially! Successful business analysis techniques and procedures are certainly dependent on those in project management and must be carefully, and as far as possible, individually adapted and tailored to projects. And that particularly concerns radical agile elements like renouncing finely-detailed requirement specifications. What works in one project can fail in another. That is the sobering knowledge that comes from years of experience and the reason that every project brings with it new challenges for business analysts.
What does the agile extension of the BABOK® achieve for the customization of suitable agile business analysis?
To answer this question, I will briefly introduce the BABOK® v3 agile extension[2]. The extension introduces the seven principles of agile business analysis that are based on the Agile Manifesto[3] and the business analysis core concept model from BABOK v3. The Agile Manifesto for software development was developed in 2001 by leading experts in the USA and is recognized worldwide as the foundation of the agile body of thought. It values the characteristics on the left side higher than those on the right side.
The seven principles of business analysis seize on these values in three different context levels, the planning horizons, that I will now introduce before the seven principles. Put simply, this means that the three customary project phases, initiation, planning and execution have different characteristics. Here, the first phase often takes place before the main project in the form of strategy analysis, pre-project studies, feasibility studies and can result in no investment being made in the project. Here, the comparison of the planning horizon with project phases or PMBOK® process groups[4] wanes, but makes sense for a simple introduction to the topic. The identification of the three planning horizons fits into our general understanding:
Strategy – Often outside of the project, on the strategy or portfolio level
Initiative – Normally early in the project context when an initiative (a project) has been planned concretely
Delivery – Output at the end, but above all also during the project
The seven principles are:
See the Whole
Seeing the whole means better understanding the business need in the existing context and to evaluate feasible solutions in this environment and then to compare then according to the planning horizon. The emphasis here is on customer collaboration from the agile manifesto.
Think as a Customer
Business analysts often work as product owners for work with or for POs in agile environments. In these functions, a voice of the customer attitude is important to represent the customers’ interests effectively and to develop solutions in tight and constant cooperation that achieve the highest possible value in the customer’s branch.
Analyze to Determine What is Valuable
This principle aims strongly toward benefit-orientated prioritization. In agile environments, a business analyst is normally responsible for backlog prioritization, or at least be able to influence the managers. Here, the focus should be on delivery items that provide the customer with certain value. The phrase “maximizing the work not done” sounds paradoxical, but it means that work that does not provide any value to the customer should be minimized.
Get Real Using Examples
“Be concrete and explain your ideas visibly with the help of models” is a good understanding of this principle. Explaining complex dependencies to stakeholders is not easy, communication must be carefully prepared and designed, otherwise it is difficult to reach a common understanding of the value that the planned product and solutions should offer.
Understand What is Doable
Business analysts must have a good understanding of which solutions or solution components can be realized within the scope of the project. Limitations in terms of capacities, time or finances often play a large role and limit the scope of possibilities.
Stimulate Collaboration and Continuous Improvement
Ongoing improvement and learning is a core element of agile procedures. Business analysts are required to support agile elements like empiricals or retrospectives (an agile form of the classic Lessons Learned) and therefore to encourage constant development of customer and delivery teams.
Avoid Waste
This principle goes back to the Japanese philosophy of Kaizen and lean management, which was strongly influenced by Toyota. Though there are things that the customer does not always perceive as valuable, although they are necessary for the solution architecture, there is also work done for things that do not provide any value. These should, of course, be avoided. But even the so-called re-work, the re-working of supposedly already finished components, can be minimized. An aspect of the work that is not first completely obvious is that decisions should only be made when they have to be made. Or that documentation should only supplied when it is also needed.
Conclusion
The agile extension of the existing Version 2 is an enrichment for every business analyst, especially those who have not worked in many agile environments. Many businesses find themselves in the transfer phase between classical and agile procedures and will likely not be able to complete this phase because they continue to accept the status quo. From this background, it is important that business analysts understand the agile principles and can continue to progress and develop them in their work. As a supplement to BABOK® 3, the agile extension is certainly very helpful, but it is not enough. Studying more advanced literature on the theme of agility and learning from experts are indispensable. Here, you should not be governed by the fallacy that examining the agile project management method of Scrum is enough. It is far more important to understand that Scrum is an internalization of agile values. In my opinion, this is very well implemented in the “Agile Extension to the BABOK® Guide”, compliments to the authors!
Sources:
[1] Business Analysis Body of Knowledge BABOK® v3, International Institute of Business Analysis IIBA®, Toronto 2015, http://www.iiba.org/babok-guide.aspx
[2] Agile Extension to the BABOK® Guide v2, International Institute of Business Analysis IIBA®, 2017, http://www.iiba.org/babok-guide/Agile-Extension-to-the-BABOK-Guide-IIBA.aspx
[3] Agile Manifesto, 2001, http://agilemanifesto.org/iso/de/manifesto.html
[4] More about the Project Management Body of Knowledge on Wikipedia: https://en.wikipedia.org/wiki/Project_Management_Body_of_Knowledge
This discussion is missing your voice.