PM Articles > Kent McDonald > Analysis in Agile - It's About Asking the Right Questions

Analysis in Agile - It's About Asking the Right Questions

by Kent McDonald

The agile movement has matured quite a bit in the past 12 years. The immediate outcome of the Agile Manifesto was that people adopted approaches that helped them build software right -- the focus was on how to build the software. While not all teams have managed to master the "how" portion of software development, many teams are place a bigger focus on building the right thing (the what), and perhaps most importantly -- whether it's right to build anything at all (the why). At the same time, some in the business analysis community have realized that there's much more to analysis than documenting requirements. They now understand that it's about knowing which questions to ask, actually asking them, and not being satisfied with weak answers. Here are some of those questions.

What Need(s) Are We Trying to Satisfy?

The first thing every team should ask themselves when starting a new endeavor is "Why are we doing this?" (Often expressed as "what problem are you trying to solve," or "What need are we trying to satisfy?")

This should be a no-brainer, but surprisingly, it isn't. I have lost track of the number of projects I have run across where people working on the project did not know why it existed, and were only doing the work because their boss told them to. In other cases, the projects exist because someone high enough in the organization said there was a need and everyone else believed it (or didn't want to get between an exec and their pet project).

Not all project ideas are poorly thought out. Many are supported by good reasoning that makes sense in isolation, but that reasoning is never properly communicated to the people working on the effort. Many times when I point this out I hear, "But we wrote a project charter, and it's out on the SharePoint site for people to read." Reflect back on your project history. In your experience, do people actually read those documents, remember them, and understand what they said? That's assuming that the document does in fact provide a clear description of why the effort exists.

So how do you make sure you answer this question, and get it answered in a way that is meaningful to those doing the work? Get everyone together in the same room -- including the person who instigated the effort -- and ask the question. Then give everyone a chance to take a part in answering the question, or at least coming up with a concise representation of what it means. This does not mean that everyone will be able to push their view of the project without direction. Rather, team members will come in with their own perspectives on what the effort is about, and will come away from the discussion with a convergent understanding of the need the project is trying to satisfy. The value is not in any statement, model, or diagram that gets generated, it's in the conversation that ensues during the building of that model. Through discussing the need with the person who raised it, teams acquire a much better understanding of the actual need.

I am the product owner for the Agile 2013 Conference submission system. This past year we found out that the system we had been using was no longer maintainable. To check the understanding of our needs, I discussed with the conference steering committee whether a unique submission system was still necessary. We concluded that it was, and the conversation provided some helpful context around different perspectives on the submission process. We determined that, in this case, the need we were trying to satisfy was a submission system that appropriately supported our unique submission process. Going with an off-the-shelf system would have forced us to forgo the review and feedback cycle that we believe provides a more open review process.

Why don't more teams do this? Some fear that it will delay the effort. But this type of discussion can be held in a day, and the lasting benefits (shared understanding, team members get a chance to meet each other and get to know one another) will more than pay back the expense of getting everyone together. Shared understanding will prevent so many incorrect assumptions and bad decisions over the course of the project that the team will more than make up for the time spent having these early discussions.

Of course, the other reason teams may not hold these discussions is because the sponsor is afraid of the next question.

Is This Need Worth Satisfying?

A pet project is one that is pursued because it's a personal favorite of someone (usually someone important), not necessarily because it's a good or important expenditure of time and money. Not all pet projects start out that way, though. In many cases, people begin a project honestly believing that it's a good and valuable thing to do based on the information they have at that time. They continue to believe that, even as evidence to the contrary piles up during project investigation work.

A key business analysis skill is asking, "Why is the Why important?" In other words, we understand why we are doing something, but is that a good enough reason to do it? A good way to broach this subject once you understand the need is to ask "So what?" or "What happens if we do nothing about it?"

In the submission system example, we discussed whether it was worth building a new submission system. We determined that it was because we did not foresee changing the selection process in any way that would not require a system, or that would allow us to use an existing system. If, as a purely hypothetical example, the Agile Alliance were to go to an invite-only method of selecting conference presenters, we probably would not need a submission system like the one we built this year.

What Should We Build to Satisfy That Need?

Once you decide that the need is worth satisfying, the next question is how to satisfy it. Answering this question may mean determining the many different ways of satisfying the need, picking the most attractive one, and determining the aspects of that solution. It also means defining the specific aspects of a given solution. A technique that can be helpful here is impact mapping, which helps teams identify multiple ways of impacting a goal and testing assumptions to find the best approaches. When you know a specific solution, identifying what needs to be built based on models of the underlying data or processes can help your team focus on the key areas to build.

With the submission system, we knew generally what we needed to build. The challenge came in identifying the relevant aspects of the solution. It would have been easy to replicate the functionality of the existing submission system and call it good, but we knew some of that functionality was a relic of the underlying platform. We focused on the activities the new submission system had to support, using the existing system only as an example of one possible solution, and built a backlog with a few hours of discussion.

What Should We Not Build to Satisfy That Need?

Knowing what to build is essential, but knowing what not to build is equally important. A crucial way of thinking about this question is to deliver the optimal outcome for the stakeholder by building the minimum amount. The more you build, the more you have to maintain, and the less time you have to continue to add capabilities in the future. A great solution is one that provides the outcome the stakeholders are looking for without building anything at all.

Analysis plays a big role in this process, by always describing things in terms of what stakeholders want to accomplish, letting the people who best understand the capabilities of the technology figure out the simplest way to make that happen.

We described the submission system backlog in terms of things people needed to accomplish so we could be creative in how we delivered functionality. The user experience of reviewers and program team members was more important than that of the administrator, so most administrative functions were handled using an already developed administration module. We got that set up fairly quickly and were able to focus our time on features for submitters and program teams. We also did not develop reporting. Instead, I generated the necessary information directly from the database. We figured that based on my experiences this year, we'd know what reports we'd need in future years.

When Should We Build It?

In some cases the question about what we should and should not build really becomes a question of what should we build now, and what should we build "later." The prevalence of iterative development (and delivery) in agile approaches gives teams another tool to provide stakeholders maximum impact as soon as possible. The trick here is making (often difficult) decisions about what should be delivered sooner rather than later, and willingness to wait for things that may prove useful eventually.

Given our tight time frame for the submission system, we made some hard decisions about what was included in the first release, or developed at all this year at all. Several of those discussions involved a member of the team asking "What are you trying to accomplish with that?" or some variant. It was a little ironic that I was on the receiving end of those questions, because usually I am the one asking them. If anything, it's a reminder to never assume that the person making the decisions has thought through the reasoning for a given change. This helped us to focus on the essential functionality for the first release -- enough to support accepting submissions and providing reviews.

Can You Give Me An Example of That?

As the "When to build" gets closer, it's often helpful to describe the next small bit in more detail. The trick is doing this in just enough detail that you don't spend too much time describing it, but it is sufficient for the person building it to know when they have built it correctly. Ideally most of that information is conveyed in the various conversations that go on amongst a team, but you may find that you can't get away from writing something down, if for no other reason that you need help remembering what you talked about. Backlog items are best described by a combination of acceptance criteria, examples, and models, all used judiciously.

As the team started work on the submission system, they would pick an item from the backlog, ask me for some clarification on the specifics (such data collected and rules enforced), and identify a set of examples to explain the expected functionality. They would then develop tests based on those examples, and finally develop the code to make those tests pass. In some cases they would mock up a new page to get my feedback, often taking an ingenious new approach to an old problem.

Several other questions will come up in the course of an agile project, but the questions above (or some variant of them) are the ones you will see asked most often. Knowing when to ask these questions, and which techniques to use in the asking and answering, are where mature analysis skill sets come in.




Comments
Not all comments are posted. Posted comments are subject to editing for clarity and length.

I agree strongly with the pre-eminent importance of accurately understanding the problem before progressing to a solution. However, the article describes typical projects where the project/solution is defined before asking what the problem is. Instead of discovering the REAL problem that provides value when addressed adequately, one is simply finding some presumed problem that may not be the REAL problem but that the project/solution supposedly solves.


Robin,
Thanks for your comment. Yes, the first thing to do is figure out what the REAL problem is. That's the purpose of the "What need(s) are we trying to satisfy?"question. It so happens that the example I chose to use in this story is one where we had a good idea about the real problem.

I could have just as easily talked about another case where we did dig into the real problem and figured out that the original intent of the project - a student information system - was much more than the private school I was working with needed. We found out that the real need was a better way for the parents and teachers to communicate, so we looked into better use of existing communication mechanisms instead of investing in an entirely new student information system.


Post a comment




(Not displayed with comment.)









©Copyright 2000-2017 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail info@projectconnections.com
Terms of Service and Privacy Policy

Stay Connected
Get our latest content delivered to your inbox, every other week. New case studies, articles, templates, online courses, and more. Check out our Newsletter Archive for past issues. Sign Up Now

Got a Question?
Drop us an email or call us toll free:
888-722-5235
7am-5pm Pacific
Monday - Friday
We'd love to talk to you.

Learn more about ProjectConnections and who writes our content. Want to learn more? Compare our membership levels.