Kent McDonald has written a new book - Beyond Requirements: Analysis with an Agile Mindset. The book focuses on the analysis activities in an Information Technology product development project. It presents a set of principles which can be used to guide the analysis activities, some specific techniques with advice on when and how to use them and some case study examples of how the principles and techniques have been applied on real projects.
A sample of the book can be downloaded here.
InfoQ spoke to Kent about the book and his motivation for writing it:
InfoQ: Why did you write this book - what is the problem you were trying to address?
Kent McDonald: That’s a great question, and one I took a crack at answering in the preface to the book. So let me explain. No, there is too much. Let me sum up...
It seems like too many people that work on projects in general, especially IT projects focus on the outputs. The scope items they are supposed to deliver, the code that they write, the documents they produce, the requirements that they “gather”… I wanted to place the focus on outcomes - what change in the world is the project trying to introduce. So I wanted to provide people with some ideas and some techniques that they can use to determine if whatever it is they are working on is the right thing to do. Is it producing the desired outcome.
I also wanted to demonstrate practical ways to do analysis regardless of the approach you are using. Specifically, I wanted to show that it’s possible to use analysis techniques to build a shared understanding of the outcome you are trying to achieve without introducing a lot of overhead.
InfoQ: There is a lot of confusion about analysis in agile projects, what are the key characteristics of agile analysis? Are you advocating a return to big up front design?
Kent: Yes, I think the confusion comes as a result of many people’s past experience. Analysis was a label associated to the creation of stacks of requirements documents because people reasoned that they more they knew and specified up front, the more successful their project would be. What people failed to realize is that you can only know and understand so much without going through the entire development cycle, so it’s better to get through the entire cycle for a subset of what you are trying to deliver as quickly as possible. By doing so, you can learn from not only analysis, but also development, testing, and getting the result into the hands of your stakeholders, all in order to get feedback and to learn more.
I try not to use the term “agile analysis”. I’d prefer we all get to the point where the word agile as a modifier is no longer necessary. I’d rather talk about good ideas that work. From the perspective of analysis, I think key characteristics that make analysis work is that you use:
- the right techniques (those best suited to the domain in which you are working)
- to the right extent (as minimally as you need to in order to build that shared understanding)
- at the right time (very broad but not too deep to start, followed by deep dives on a very small portion, and repeat as necessary)
Are you advocating a return to big up front design?
No.
InfoQ: How does analysis on agile projects differ from traditional analysis?
Kent: Ok, I suppose I should probably expand on my previous answer a little bit to answer this one.
The problem with big up front design is that it requires doing a deep dive on all aspects of the solution before you have the chance to learn anything from actually building something. What I suggest is you establish a broad understanding of the overall need and possible solutions, then you do a deep dive into small aspects of that solution at any one given time.
Think of it like this, do a deep dive on a small part of the solution. Build that part of the solution and use what you learn to do an analysis deep dive on the next portion of the solution. Going this route prevents you from building up a requirements inventory that is guaranteed to get old and stale because they were established based on a lot of assumptions that have a good chance of being proved incorrect.
You need to have some idea of the problem you are trying to solve and what boundaries exist on the solution, otherwise you run the real risk of solving the wrong problem, or not solving any problem at all.
That’s also how analysis in an environment where the organization lives agile values and principles differs from “traditional” agile.
A lot of the techniques are the same. When you use them and to what extent differs greatly.
Another big difference is that analysis and the resulting requirements are viewed as means to an end, not the end in and of themselves. You want to focus on what analysis techniques will help you build a shared understanding of the outcome you’re looking for (what problem you are solving for the stakeholders). You don’t want to focus on making your requirements document as flawless as possible.
There’s a dirty little secret in the world of analysis. The longer and denser the requirements document, the less likely people are to read it, let alone try and understand it.
What is the agile mindset?
You are living the agile mindset when you follow these “guiding principles”:
- Deliver Value
- Collaborate
- Iterate
- Simplify
- Consider Context
- Decide Wisely
- Reflect and Adapt
InfoQ: What are the key activities or targets of analysis in agile projects?
Kent: I’d like to think that the following key activities apply to analysis regardless of the approach you are using (see my earlier answers):
- Understanding stakeholders - do you know whose problem(s) you are trying to solve
- Understanding context - do you know a sufficient amount of information about the domain and the organization in which you are trying to solve those problems.
- Understanding the need - Do you know what the problems are that you are trying to solve and why they are problems.
- Understanding the solution(s) - Do you know the different ways you could solve those problems and the advantages/disadvantages of each, and also what criteria your team should use to pick the right solution.
- Organizing and persisting solution information - How are you going to remember and communicate information about the solution to those who are using it and have to maintain it in an ongoing fashion.
InfoQ: Why did you restrict your focus to IT projects, can agile analysis be used outside of IT?
Kent: I chose that context for three reasons.
- Activities described as business analysis (at least the type of activities I cover in Beyond Requirements) tend to be heavily prevalent in IT Projects. Yes, I know that business analysis occurs in other types of activities (strategy, process improvement, business architecture, etc).
- Most of the existing literature about the type of business analysis I describe in Beyond Requirements assumes a domain of product development where the end result of the effort is being sold outside the organization. I felt there was a dearth of information about business analysis in an agile setting being done by teams building solutions for use inside their organizations. There are a lot of similarities between business analysis in the two contexts, but I thought it was important to describe these ideas with the IT Project context in mind so I could also discuss the subtle differences.
- This reason is probably the most important. It’s where my experience lies. I felt I owed it to the reader to write from a position of Plank knowledge rather than chauffeur knowledge.
Can analysis be used outside of IT? Sure. It’s usually called by different names, but the ideas are usually the same. In product development for example, you see many of the same activities (with different names) being done by product management or user experience practitioners.
When it comes to using the techniques I describe in Beyond Requirements, it’s not so important what you call them. It’s much more important to know how to use them in the right situation. Richard Feynman described this as the difference between knowing the name of something and knowing something.
InfoQ: Please can you describe a couple of the techniques you advocate and why they are useful?
Kent: Sure. I tried to stick to simple, yet powerful techniques. I find people are more likely to use techniques that are simple to use because they can focus more on the value they get out of using them rather than getting wrapped up in all the details of doing them perfectly (and hence losing site of why they are using them.)
The first technique is decision filters. Decision filters are simple questions used to guide decision making. They provide a quick way to communicate the desired outcome to everyone involved in realizing those outcome(s). In effect, they tell you when to say no to a project that does not truly align with strategy, or a requirement that does not lead toward progress of the desired outcome.
The second technique is the Purpose Based Alignment model (which has also found it’s way into the Agile Extension of the BABOK Guide). The Purpose Based Alignment Model, created by Niel Nickolaisen, is a method for aligning business decisions and process and feature designs around purpose. The purpose of some decisions and designs is to differentiate the organization in the market; the purpose of most other decisions is to achieve and maintain parity with the market. Those activities that do not require operational excellence either necessitate finding a partner to achieve differentiation or do not deserve much attention.
In practice, purpose alignment generates immediately usable, pragmatic decision filters that you can cascade through the organization to improve decisions and designs.
The Purpose Based Alignment Model provides a simple way to determine what activities to concentrate on, and how to deliver them. Through the characteristics of mission critical and market differentiating, it removes factors that merely act as distractions to decision making and helps the team focus.
In conjunction with the publishers, Pearson, I have prepared a set of video classes which go along with the book, called Analysis Techniques for Product Owners and can be found here.
About the Book Author
Kent J. McDonald uncovers better ways of delivering value by doing it and helping others do it. His 20 years of experience include work in product ownership, business analysis, strategic planning, project management, and product development in a variety of industries including financial services, health insurance, performance marketing, human services, nonprofit, and automotive. He is active in the business analysis and agile software development communities helping people share stories about what does and does not work. He shares those stories at beyondrequirements.com and curates a weekly newsletter about Product Ownership at product ownership.net. He also presents at and helps organize several local and international conferences.
Kent is author of Beyond Requirements: Analysis with an Agile Mindset and co-author of Stand Back and Deliver: Accelerating Business Agility.