Introduction

This article offers some personal reflections on why the Business Motivation Model (BMM) (BRG, 2010) in general — and an abridged graphical representation, in particular — may help make Agile projects more successful.  A Scrum-based project is used to illustrate this and how, at the same time, the need for big-picture thinking is satisfied.  I briefly discuss some conceptual modelling and representation issues including concept mapping, and provide a concept map for an abridged overview of the BRG's BMM itself. The article concludes with a summary of what was omitted from the concept map and why.

Motivation For Using The Model

The Business Motivation Model has the subtitle "Business Governance in a Volatile World" (ibid) and this perspective of the world as an intrinsically-volatile place is one shared by the Agile software development community.  Jim Highsmith, one of the authors of the Agile Manifesto back in 2002, defined Agility as:

"the ability to both create and respond to change in order to profit in a turbulent business environment" (Highsmith, 2002).

Of course, turbulence, volatility, and rapid change are not new phenomena, just more significant given our abilities to create systems that are increasingly complex, interconnected, and interdependent.

It can be argued that most of the 20th century's socio-technical system developments (Emery and Trist, 1960) have required us to solve, or at least attempt to solve, what Horst Rittel classified as "wicked problems" — these are problems that (for example) have no definitive formulation, require insights into a solution in order to understand the problem, have no clear point at which the problem can be considered 'solved', and are essentially unique (Rittel and Webber, 1973).

Conversely, Rittel described those problems that cannot be classified as 'wicked' as tame problems and observed that attempts to tame 'wicked problems' more often than not leads to failure.  One reason we fail to recognise wicked problems stems from our commitment to, and inappropriate use of, reductionist principles and methods (Russell, 1946, p. 462-3).  However, this should come as no surprise to us since, appropriately applied, reductionism has been responsible for so many of the world's greatest advances.

I'm sure that most of you are aware of the poor success rates for IT projects around the world.  The often-quoted example from the Standish Group estimated success rates in the US at only 34% — although that represented a significant improvement on the 16% success rate recorded in their first survey in 1995 (RAE and BCS, 2004, p. 8).

In many respects, the emergence of the Agile movement can be seen as a response to the failure of reductionist and predictive approaches to socio-technical system development.  For those of you who may not be familiar with the more esoteric principles of the Agile movement, it is underpinned by the realisations that:

• our world is more stochastic than deterministic,
• our abilities to plan and predict future events are very limited, and
• we should instead try to improve our capacity to adapt to change rather than strive to control it (Highsmith, 2002, p. 110). 

One practical implication of this is to reduce the time it takes to see the results of any interventions we make (whatever they are).  Agile projects try to achieve this by developing systems incrementally, which could be caricatured as minimising the feedback delay by keeping work-in-progress queues as short as possible. 

But here is the challenge that probably comes as no surprise to subscribers to this site — a wholesale and dogmatic application of this incremental approach to even moderately-complex systems — particularly those having a significant socio-technical component — is also likely to fail.  The paradox is a consequence of the inherent complexity of socio-technical systems and their high degree of intra and interconnectedness (Ackoff, 1999).  Hence, it is essential to temper the incremental approach with appropriately-applied 'big picture', synthetic (cf. analytic), holistic thinking — collectively described in the system sciences as 'system thinking' (Jackson, 2003, p. 272-3).

So, what has this to do with the Business Motivation Model?  I would argue that use of the Model helps connect a system's development more firmly to the business that is motivating its development, as well as giving Agile projects a deeper system science-based rationale for adopting more-holistic approaches to their development.

A scenario in which this need can be more clearly seen is as follows:

The project is a fully 'Scrum' one, with a sprint duration of two weeks.  There is no explicit analysis phase, and requirements are refined only as needed to deliver a specific increment of working software.  There are opportunities for so-called 'spikes' to undertake investigations or analysis, but these reduce the 'velocity' of the team and are not viewed very positively by most Agilistas.  Hence, any refinement or redefinition of a prioritised requirement (i.e., an item in the 'sprint' backlog, in Scrum speak) takes place iteratively during the sprint, as dialogue between the development team members and the product owner.  The product owner is perhaps a Business Analyst (BA) or Requirement Engineer (RE), or perhaps a BA or RE is facilitating a collaborative requirement elicitation and analysis process alongside the product owner.  Alternatively, the BA or RE might be combining his or her role with the ScrumMaster role (Scrum Alliance, 2011).

The critical issue here is that the entire team must frequently be called on to rapidly make requirement decisions that need to be informed by what we would recognise as the Business Motivation Model.  The individuals concerned must rapidly construct their own conceptual model(s) for their specific business if they are to make sound development decisions (although few would explicitly recognise that they were doing this).  This is, in the vernacular, "a big ask" for the type of multi-disciplinary team envisaged here.

To summarise, having an easily- and rapidly-understood model of the fundamental relationships between a business's vision, mission, policies, rules, strategies, and tactics — and of the desired results as assessed by the goals and objectives — is invaluable for framing the requirement dialogue and decision making that is needed.  In fact, requirement-modelling research suggests that establishing a common frame of reference may reduce some of the "socio-cognitive" problems that are inherent in conceptual modelling activities (Siau and Tan, 2005, p350).

Modelling and Representation Issues

The Business Motivation Model is comprehensively documented but needs more than eighty pages to do it (BRG, 2010).  In an ideal world, most of the stakeholders, and certainly everyone in the development team, would be sufficiently familiar with the Model to be able to use it to understand their specific business domain and make good requirement decisions.  But because I believe this is an unrealistic expectation, I began looking for ways to summarise the key elements of the Model, with the goal of making them more accessible to a wider range of people.  I also have a long-standing interest in knowledge-representation and saw this as an opportunity to explore representations that might contribute toward that increased accessibility goal.

The BRG's BMM document includes both textual and diagrammatic representations and includes an overview diagram (ibid, Appendix A) that uses non-normative constructs^[1] to summarise the Model.  Although this representation has many merits, all representations involve trade-offs of various kinds — for example, trading off simplicity for completeness, scope for depth, formal for informal, expert for novice users, and high cognitive load for low.  All representations are to a greater or lesser extent the product of conceptual modelling, an activity that is considered by many to be at the heart of the Information System (IS) discipline (Frank, 1999) and, fortunately, is the subject of much research.

Krogstie and Sølvberg (2003, cited by Siau and Tan, 2005) provide a valuable framework for discussing the quality of conceptual modelling, which I'll briefly outline here to give some rationale for the graphical representation that I'm offering in Figure 1.  You may think of Figure 1 as an alternative representation to that provided in Appendix A of the BMM (BRG, 2010) although Figure 1 was actually developed from the textual model and not a re-work of the graphical summary.

Figure 1.  Business Motivation Model (abridged) — Concept map representation 

The Krogstie (et al) framework exposes some of the complexity that is inherent in any requirement modelling activity.  For example, it characterises quality as having the following dimensions:

• semantic,
• perceived semantic,
• social,
• syntactic,
• pragmatic,
• physical,
• empirical.

And underpinning all of this is recognition of the cognitive difficulties that people experience as information processors and problem solvers (Siau and Tan, 2005, p. 349).

Obviously, a detailed exploration of these ideas are beyond the scope of this article but nevertheless, I'd like to briefly mention two qualities (in the context of the earlier Agile scenario) that can be useful as pointers to what might make the Business Motivation Model more accessible to a wider range of people.

• Specifically, semantic quality represents the correspondence between the domain (i.e., in this case, the business's vision, mission, and strategies, etc.) and the conceptual model.  In the Agile development scenario discussed earlier, the conceptual model is most likely only an informal mental model in the heads of each individual.  It has been created from their existing knowledge and experience, and framed by the Business Motivation model or, rather, by those elements of the model to which they've been exposed and have managed to successfully interpret.
  
  
• Similarly, the meaning of pragmatic quality includes, according to Siau and Tan, "interpreting a single meaning with the lowest possible cognitive effort" (ibid, p. 352).

One obvious conclusion to be drawn from these examples is to keep the model representation as simple as possible so that the cognitive load on users is as low as possible.

Finally, since cognitive mapping by definition recognises the significance of subjective beliefs (ibid), we should try to avoid representations that are known to have negative connotations for our users.  For example, many in the Agile community have negative associations with UML, arising from experience of its misuse (Bell, 2005) or simply because of its use in many traditional, "waterfall method" projects (Highsmith 2002, p. 2).  Unfortunately, how sound or unsound the notion is matters much less than the degree to which the associated emotion (i.e., the affective domain) impacts the individual's cognition (Ashby et al, 1999) to make their cognitive modelling activity more challenging.  In other words, using an inappropriate representation may operate as a distracter and add to the cognitive load of the user.

A Concept Map Model

Three commonly-used cognitive mapping techniques are causal mapping, semantic mapping, and concept mapping (ibid, p. 353).  The BRG's BMM diagrams share some of the features of concept maps as well as adding some unique features of their own — for example, the "Box-Within-A-Box" construct that models one concept containing another concept (BRG, 2010, Appendix C).

The approach that I choose to use for my rendering of an abridged version of the Business Motivation Model is also based on the concept mapping technique (Novak and Cañas, 2008).  The concept map diagram shown in Figure 1 was drawn with the aid of an open source tool called CMAP.

Concept maps are built with three simple components called nodes, link words or phrases, and links.

• Nodes represent concepts, with concepts defined as a "perceived regularity in events or objects, or records of events or objects" (Novak and Cañas, 2008, p. 1).  Concepts are designated by a label that is often a single word, although it may sometimes be appropriate to use a sentence.  The node is drawn as a box or oval shape.
  
  
• Concepts are connected by link words or phrases that express the relationship between two (or more) concepts.
  
  
• Links.  The link word or phrase is written between the two segments of a line that is drawn to connect two concepts.  The link line optionally has a direction of association, indicated with an arrow.  The arrow can indicate a one-way or both-ways association.

The combination of two nodes connected by a link word or phrase form a proposition.  Moreover, propositions may contain two or more concepts connected using linking words or phrases to form meaningful statements.  Concept maps can be used to represent procedural and/or declarative knowledge, and can be effective for facilitating communication between different types of users, particularly when those users collaborate with the support of a computer-based tool to create their own map.

The structure of concept maps is not highly prescribed, which has allowed me to add the "Box-Within-A-Box" construct to my map.  As a result, the map can more succinctly capture the concepts of means, ends, and directives, and display them as containers for the other concepts with which they have relationships (see Figure 1).

Using the Concept Map Model

My experience of using concept maps (mostly in educational contexts) has been very positive.  Anecdotally, I found concept maps to have the following two advantages over other representations:

• the small amount of prior learning that users need to interpret a map, and
• most users, when asked, describe the representation as intuitive. 

Now, exactly what intuitive means here is not clear, although it is probably related to an innate bias for symmetry and the presence of particular patterns.  The theory underpinning concept maps is well grounded in educational psychology (Ausubel et al, 1978).  Concept mapping techniques and tools have been researched extensively — mostly in education but also to a lesser extent in public and private sector Information System contexts (Cañas, 2003).

The concept map shown in Figure 1 is obviously a very much abridged overview of the full Motivation Model.  Similarly, the concept map also contains omissions and additions over the graphical representation given in the Business Motivation Model (BRG, 2010, Appendix A).

Mention of omissions inevitably raises questions about what has been left out and why?  I'll briefly summarise:

Although, the concepts of Influencer and Assessment are identified as "core concepts" in the BRG's BMM (ibid, Appendix A), I did not include them.  The main reason for omitting them was to improve the readability of the model.  It seems that these concepts are arguably of less immediate relevance to the target audience and so their omission is less likely to impair the model.  That said, more experience with using the map in real sprints will no doubt reveal how important this omission is.

The Process concept (although not identified as a "core" concept in the BRG model) was only reluctantly omitted because of difficulties with positioning it on the map.  Readability was effectively prioritised over completeness.  Since the relationship between the Process and the Directive concepts is a valuable one in understanding the business model, I hope it may be possible to find a way of adding it to the concept map in a future version.

Conclusions

The increasingly-volatile business environment and the failure of reductive, planning-based socio-technical system development led to the rise of the Agile movement, with its focus on iterative and incremental development.  However, the dogmatic and wholesale application of incremental approaches needs to be tempered with some holistic, big-picture thinking if we are to build successful systems.  Systems science offers Agile projects a deeper motive for doing this and the BRG's Business Motivation Model offers a means to do it.

While the BRG's BMM clearly offers an excellent framework for achieving these things, the viewpoint adopted here is that an abridged graphical representation is likely to be more readily accessible to Agile teams.  A graphical concept map (Figure 1) is proposed as the vehicle to help teams develop their own business-specific conceptual model and, in doing so, be better equipped to make sound decisions about both the requirements and the software that realises them.

Influence, Assessment, and Process concepts have been omitted from the concept map although it is hoped that ways can be found to include the Process-Directive relationship in a future version of the diagram.

Finally, I hope this article will encourage you to consider actively using the BRG Business Motivation Model (and possibly this concept map or something similar) in your own practice with Agile teams.

Notes

[1]  The graphical representations used by the BRG's Business Motivation Model are based on three non-normative conventions consisting of:  the Box, the Box-Within-A-Box, and Connection-Between-Boxes (BRG, 2010, Appendix C).  

References

Ackoff, R.L. (1999).  Re-creating the Corporation:  A Design of Organizations for the 21st Century, New York, Oxford University Press.

Ashby F G, Isen A. M., and Turken U. (1999).  "A Neuropsychological Theory of Positive Affect and its Influence on Cognition" in:  Psychological Review, 106, No 3, pp 529-550.

Ausubel, D. P., Novak, J. D., and Hanesian, H. (1978).  Educational Psychology:  A Cognitive View (2nd ed.), New York, Holt, Rinehart and Winston.

Bell, A.E. (2005).  "UML Fever — Diagnosis and Recovery," ACM QUEUE, available online at:  http://queue.acm.org/detail.cfm?id=1053347, last accessed 26th September 2009.

BRG (2010).  The Business Motivation Model — Business Governance in a Volatile World, available online at:  http://www.businessrulesgroup.org/second_paper/BRG-BMM.pdf, last accessed 3rd December 2011.

Cañas, A. J. ( 2003).  "A Summary of Literature Pertaining to the Use of Concept Mapping Techniques and Technologies for Education and Performance Support," Pensacola FL, The Institute for Human and Machine Cognition, available online at:  http://www.ihmc.us/users/acanas/Publications/ConceptMapLitReview/IHMC%20Literature%20Review%20on%20Concept%20Mapping.pdf, last accessed 15th February 2009.

Emery, F.E. and Trist, E.L. (1960).  "Socio-technical Systems" in:  Churchman, C.W., Verhulst, M. (Eds.), Management Science Models and Techniques, Vol. 2. Oxford, UK Pergamon, pp. 83–97.

Frank, U. (1999).  "Conceptual Modeling as the Core of the Information Systems Discipline — Perspectives and Epistemological Challenges" in:  Proceedings of Fifth Americas Conference on Information Systems AMCIS 99, Milwaukee, WI, pp. 695-697.

Highsmith, J. (2002).  Agile Software Development Ecosystems, Boston MA, Addison Wesley.

Jackson, M.J. (2003) Systems Thinking:  Creative Holism for Managers, Chichester England, John Wiley & Sons Ltd.

Krogstie, J. and Sølvberg, A. (2003).  Information Systems Engineering — Conceptual Modeling in a Quality Perspective, Trondheim, Norway, Kompendiumforlaget.

Novak, J. D. and  Cañas, A. J. (2008).  "The Theory Underlying Concept Maps and How to Construct and Use Them," Technical Report IHMC CmapTools 2006-01 Rev 01-2008, Pensacola FL, Institute for Human and Machine Cognition, available online at:  http://cmap.ihmc.us/Publications/ResearchPapers/TheoryUnderlyingConceptMaps.pdf, last accessed 3rd February 2012.

Rittel, H.W.J. and Webber, M.M. (1973).  "Dilemmas in a General Theory of Planning" in Policy Sciences 4 (1973), 155-169, Amsterdam, Elsevier Scientific Publishing Company, available online at:  http://www.thestudiony.com/ed/bfa/Rittel+Webber+Dilemmas.pdf, last accessed 3rd February 2012.

RAE & BCS (2004).  The Challenges of Complex IT Projects — The Report of a Working Group from The Royal Academy of Engineering and The British Computer Society, London, The Royal Academy of Engineering, available online at:  http://www.ceid.upatras.gr/tech_news/challengesIT.pdf, last accessed 3rd November 2007.

Russell, B. (1946).  History of Western Philosophy,  London, Allen and Unwin.

Scrum Alliance (2011).  Scrum Is an Innovative Approach to Getting Work Done, available online at:  http://www.scrumalliance.org/pages/what_is_scrum, last access 20th February 2012.

Siau, K. and Tan, X. (2005).  "Improving the Quality of Conceptual Modeling using Cognitive Mapping Techniques" in Data & Knowledge Engineering 55,  343–365.

# # #