I get the opportunity to interact with a lot of people and teams trying to figure out the intersection of analysis and agile, and through the course of those interactions I get a lot of questions such as “who does what in agile?”, or “what does agile ‘say’ about this?”, or “how do you go about doing this type of thing?” About 90% of those questions I can (and often do) answer “It Depends” though not always with a straight face. It Depends is an almost universal answer because it implies that every situation is different and what works well in one case does not necessarily work well in another. This is especially true of analysis, where in there are many perfectly reasonable ways to attack a particular analysis challenge (and just as many unreasonable ones). It is this reliance on context that makes analysis so interesting, and makes Best Practices about as common as silver bullets, four leaf clovers, dodo birds, and the Cubs in the World Series.
When I first started doing business analysis back in the day, I wanted to know specifically how to do it. I figured that once I got that set of instructions, I could just repeat them in every situation and be successful every time. That’s how it worked in school. That’s not how analysis works in real life. I soon found out that every situation is different. Granted many situations have a lot of similarities so I could apply techniques learned in previous situations to new situations with reasonable success. However, for as many times as that happened, I’d find myself in a situation that was completely different than any I had found before, and I had to learn new techniques to address the current challenge.
One example burned into my memory from several years ago (for a variety of reasons) is a very large project at a financial services company. The project team was larger than some mid sized companies and there were several different groups of business analysts focused on a very specific piece of the overall solution. I worked on the team trying to determine business rules from a consolidated credit policy (so called because the credit policies of three separate operating units had been combined into a single document). The main focus was identifying business rules that would be enforced via a rules engine. When I joined the group the rules portion of the project had just started, and the team I joined was in the process of identifying use cases to identify the various aspects of the decisioning functionality. Wait… use cases? For a business rules focused project? It didn’t feel right, but it was my first rules focused project, so I wasn’t going to judge.
We stumbled on for a little bit until an experienced (and quite outspoken) rules architect joined the team and helped us see the error of our ways. While use cases can certainly be helpful in many situations, the part of a system focused entirely on using a set of rules to automate decision-making is not one of them. We found a much better approach was to establish a rules catalog (we actually built a “home grown” application to keep track of our rules before they were coded into the rules engine) and to identify a set of rule flows. Uses cases were frankly not very useful in this situation.
So why did the team start with use cases and spend several weeks trying to force fit them into the project even though there were nagging doubts among many on the project team? Primarily, the team thought that use cases were required by the corporate SDLC. Several on the team didn’t think the SDLC allowed for contextual selection of techniques and process based on the nature of the project, and so standard “best practices” were force fitted into projects where they really didn’t fit. To make matters worse, the team consisted primarily of contractors selected specifically for this project who were skilled in applying use cases – so we spent more time that we probably should have trying to make use cases work. Fortunately, most of the contractors were fairly experienced, so once we realized, and accepted the fact that we needed to change the techniques, we were able to adapt fairly quickly, but we did lose a bit of time.
This type of scenario plays itself out more often than I care to admit, and this is the problem with Best Practices. People, such as me right out of school and the team on the rules project, look for the one way that they can learn, get real good at, and use over and over again. Unfortunately where analysis is concerned that approach only works if you are working on the same type of project. And even then, there can be enough differences between two web application projects, for example, that the techniques useful in one are not the best idea for another. Best Practices are only “Best” for a given context. It follows then, that simply learning a technique is not enough, you also need to learn when you should use it, and why.
As I think back to the title of the post, I realize that I may be guilty of a little bit of hyperbole. There is in fact one best practice – always consider context when deciding what techniques you are going to use on your projects, regardless of approach.
- Looking Back and Looking Forward - January 6, 2016
- TA DA! Beyond Requirements Excerpt - September 21, 2015
- Implement Decision Filters for Organizational Alignment - June 22, 2015
- Using the Purpose Based Alignment Model - June 8, 2015
- Value Management is about Building the Right Thing - February 18, 2015
- 2015 Predictions for Business Analysis - January 8, 2015
- How did Kent do on his 2014 Predictions? - December 9, 2014
- Reflections from Kent: BBC 2014 - November 20, 2014
- Reflections from Kent: ACORD Implementation Forum - November 20, 2014
- Learning Delivers Value - November 7, 2014