Blog


What the V Model Can Teach Agilists

Last month, a client and I were sitting in a nondescript conference room in downtown New York.

My client was relatively new to software development, and I was explaining that, in traditional software development life cycles (SDLCs), it is absolutely critical to get requirements right. Why? Because if requirement errors and omissions are not caught until very late in the process, they can cost a lot of money and rework down the road.

To illustrate my point, I showed him a typical V Model illustration (focusing on requirements elements):

The V Model is certainly not new to the world of software development. It can be viewed as a simple evolution of a typical waterfall model that has the testing and verification phases bent up to form the shape of the letter V. When this is done, there is a correspondence between the phases on the left (that elaborate the product) and the phases on the right (that validate those earlier phases).

The conversation ended with my client saying, “All of this is good for you to know, but if you’re working in an agile environment, you won’t have to worry about it.” But, on the long train ride back to Washington, it occurred to me that this isn’t exactly the case.

Indeed, the V Model has a few things to show us agilists.

It Highlights the Importance of Testing

The most obvious characteristic of the V Model is that it strongly favors testing and validation of all the work done earlier in the project. Yes, all the work, whether you are talking about unit tests validating a module’s code or project acceptance validating that the project delivered the business requirements.

But what is our real day-to-day consideration of (non-unit) testing? At most, it will usually be a quick “let’s run it by a couple (actual) users.” More often, we have testers (or even just the product owner) poking around at it and making sure it works. And that makes sense, because our next iteration is coming out in two weeks anyway, so we can effectively just have our users test the product in production. Right?

No! Not right! Remember that we are not just tasked with delivering software frequently, but also with “deliver[ing] working software frequently.” Too often, we can take an expedient view of getting the product out the door, and this can have a massive impact on our customers’ impressions of the product and indeed on our businesses.

It Encourages Us to Question Test Coverage

Here’s the deal: There are two different definitions of “working,” and we need to hit them both.

What do we usually consider it to mean? First, that it’s bug-free, or at least has a low defect count. I’m certainly not going to challenge our traditional concept of quality, but this definition is less important that the second criterion, namely:

Does the product do what the customers want it to do?

Most of our agile teams don’t have any process in place to verify that the next release will pass this test. And that’s why we are frequently surprised when a particular version isn’t well received. We met our definition of done and acceptance criteria, after all.

Make no mistake: rapid iteration is not a solution to mediocre quality.

It Shows Us Why We Do Agile

Have I talked enough about quality? Good! Let’s shift gears to focus on the V Model as the most effective marketing tool for agile development ever created.

The next time a customer or CTO asks you why they should switch to agile methods, pull out a copy of the trusty V Model, and you can’t go wrong. Simply follow this three-step process:

Point out the lateral distance between “business requirements” and “project acceptance.” Tell them that represents time. Not project time, but real-world time in which their customers’ needs are changing and their competitors are working to beat them. Mention that, unfortunately, the project’s scope will be frozen during this period, unless they want write a new statement of work (SOW). Point out the distance between “functional requirements” and “user acceptance testing.” Tell them this represents the time gap between their providing requirements and their seeing the first version of the system. Business-technology collaboration isn’t written into waterfall processes during this time (although, it does kind of show up for non-agile iterative methods).

As you can see, the V Model has a lot to teach us – or at least to remind us. Good product development practices can often be found in the last place we’d expect to find them, and it’s worth taking a fresh look from time to time.

How about you? Do you see any other leverage points for the V Model in agile? Let me know in the comments below.

Sprint Zero for Product Owners

This is the second in a three-part series of blog posts addressing the biggest challenges faced by business analysts (and product owners) on agile teams.

The concept of “Sprint Zero” or “Iteration Zero” has been around for decades. It serves as a container for all those activities that need to be done before the first sprint or iteration is begun. Typically, these activities will include team on-boarding, infrastructure setup, location logistics and the like. Rarely does this “sprint” actually deliver a releasable product.

It’s a very contentious subject. Many authors have argued that Sprint Zero is detrimental to the agile process. In some cases, it may lead to the watering down of team commitment to each sprint’s releasability (see Bowes, Cohn and Leong). In other cases, it might lend itself to the development of a team hierarchy that is inconsistent with agile’s traditionally flat organization structure (Prakash). It is often inconsistent with Lean JIT principles (Leong again). The arguments go on, and I won’t rehash them here.

Whether or not we like the concept of Sprint Zero, however, we can all agree that there is usually work that must be done to prepare for the first iteration that doesn’t quite belong in that first iteration. Whether we call it “Sprint Zero” or the “Project before the Project” or even just “pre-work,” it’s important to get it done.

Unfortunately, almost all of the writing on this pre-work phase is oriented towards development team members. “What about me, the product owner,” you may ask? Don’t worry; this blog post is for you.

While the team is conducting all its pre-project tasks, the product owner needs to focus on doing five key things. Here they are:

#1: Develop the Product Vision

If you don’t have a solid vision of the product, how it will improve the firm’s standing and what value it will provide to the marketplace, then it’s not a good idea to start the first sprint. Whether it is done intentionally or not, your first sprint will indeed have some implicit vision, and it’s best for it to be one that is purposely developed.

Just remember not to invest too much in this initial vision, either with time or emotional commitment. Early visions are almost always wrong to some extent, and it will be your job as the product owner to ensure that the team is building the right product for the market. This will often demand that you set aside your initial assumptions.

#2: Socialize the Product Vision

Once you have the initial vision in place, it is critical that you socialize it among your key stakeholders. In a simple environment, this might only include various customer representatives and technology implementation stakeholders. If you are in a scaled environment, you will also have a product management team and many other functional teams that you’ll need to work with in lockstep.

Why is this work so critical? Because soon the project itself will begin, and by then you won’t have time to defend the product’s vision to cantankerous stakeholders with their own opinions. If you end up in this predicament, it will become supremely obvious to other stakeholders, your management and, most importantly, the team. You must maintain their respect for your product ownership, and socializing the vision will be one of the easiest ways to accomplish this.

#3: Truly Understand Your Stakeholders’ Problems

At face value, this task sounds enormous. Can we ever truly understand their problems to the extent that we’d like? No, of course not. But, it’s still imperative that we understand them well enough at the beginning to start delivering a product that will meet their needs. After all, you’ll soon be making decisions on their behalf.

What does this bare minimum of understanding consist of? I’d suggest the following:

An understanding of who your customers (or end users) are, the various categories they fall under and how you expect them to interact with your product An understanding of their motivations for buying (or adopting) your product, how and why their needs have been unfulfilled so far and how similar products fall short A good idea of what they value and how they see themselves

If you can have an intelligent conversation about the above, you’re in good enough shape to start your first sprint. Remember to continue to learn about your stakeholders as time goes on.

#4: Generate Some Ideas for the Sprint One Product

Determining the scope of any sprint is the job of the team (at least in Scrum), and there is good reason for this: If we product owners determined what was in scope, every sprint would be a year-long project. Instead, we let the team do this, and that’s good because they’re the ones who know what they’re doing. But every team must start somewhere, typically with the product backlog, and you need to have some list of items on the backlog so the team can figure out what can be delivered.

What you need prior to your first planning meeting is a collection of small ideas (please) that will provide some minimum level of value to the business on their own…

#5: Write Just Enough User Stories to Support a Probable First Release

… And, once you have that list of small ideas, pick a few and turn them into user stories. You’ll have plenty of time to elaborate on these stories later, but if you have a few picked out and written up, you’ll be in a great position to have a solid planning meeting when the sprint begins.

A few tips here:

Don’t go crazy with stories. It’s a good idea to meet with the team before you spend any significant amount of time on them. Keep them short, sweet and not overly detailed. You’ll flesh everything out with the team later. Don’t worry about bigger topics (such as story maps or road maps) at this stage. You won’t have enough content to fill them, and that lack of content will induce you to make more content, which at this point would be a bad thing. Wrap-Up

Performing the above activities will help you to have a solid first iteration of your new agile project. As always, maintain an agile mindset as you do them.

What about you? How have you been preparing for new agile projects? Let us know in the comments below.

Creating Your Agile Business Analyst Role

This is the first in a three-part series of blog posts addressing the biggest challenges faced by business analysts on agile teams.

As a business analysis consultant, trainer and coach, there is a single question that wins the prize for being most commonly asked:

“What is my role as a business analyst on an agile team?”

And I universally have bad news for them, and perhaps for you, dear reader.

There is no business analyst (BA) role on agile teams.

At least, not straight out of the box. Let’s look at the basic role-set in agile.

Roles in Agile

An agile environment consists, at minimum, of two participants: the customer and the developer. The customer has the need, and the developer has the means to fulfill it. It’s a match made in heaven.

But, since development is a lot of work, it usually takes a team of developers to build the product that the customer wants.

This is because most development teams have many times more customers than developers. Since each of these customers has diverse needs, characteristics and preferences, we end up needing a person (the product owner, or PO) to understand and coalesce this aggregate demand into a single product that the team can build. Cool.

And, since development teams will run into plenty of problems, many teams hire someone (the Scrum Master) to overcome obstacles, make sure that everyone knows what’s going on and interface with management.

So, let’s recap: customers, developers, product owners and Scrum Masters. While the last two are Scrum terms, even non-Scrum teams will have something similar.

And here we have the basic agile team, although it is sometimes expanded to include non-development roles as needed by our enterprises, such as testers, architects and even business analysts.

The Problem for Business Analysts

The problem is that, in agile, we business analysts are not responsible for our usual bread and butter, requirements. Instead, the implicit requirements of the customers are managed by the product owner, who is also responsible for creating written requirements, in the form of user stories, and conveying the understanding of the requirements to the development team.

This leaves business analysts to flounder. We end up helping the PO, development team and testers, but we have no direct responsibilities of our own.

This problem, as we’ve seen, is baked into the fundamentals of agile development in at least two ways.

First, the product owner role absorbs all responsibility for the business analysis work typically performed by BAs. However, this is not a business analysis role. Historically, product owners have come out of the product management function, and they have only performed analysis incidental to their positions. Product management professionals are focused on:

Developing products that appeal to customers  Monetizing that appeal. Certainly, business analysis will play a role in achieving these goals, but it takes a backseat.

Second, and more fundamentally, agile deprivileges team roles in general. In calling the team the “development team,” I’ve been fudging. It’s really a cross-functional team of professionals working together to build the product. The team includes developers, certainly, but also any other miscellaneous professionals needed to most effectively deliver a high-quality product.

Given the ad hoc nature of the situations that business analysts find themselves in, combined with the fact that we’re not completing backlog items ourselves, we find ourselves craving some understanding of our role on the team. Are we helping the PO to better understand his or her customer base? Are we floating from desk to desk helping the developers understand what needs to be built? What exactly are we supposed to be doing?

The Solution is Not to Find Your Role

The solution is not to try to figure out what our role is, but rather to create a role customized to the needs of our team, product owner and customers.

In working with numerous coaching clients, I’ve found a straightforward three-step process to most effectively help create a Business Analyst role that will make the biggest impact.

Step 1: Understand the (probably significant) Conflict Between the Values of Your Company and the Values of Agile

You probably didn't see this one coming. The fact is, no company is perfectly agile, not even the ones run by the people who invented agile. Every company has a culture, and every company is comprised of individuals with competing personal values, goals, beliefs, perspectives and egos, and these can all get in the way of collaboration.

The first step is to realistically and non-judgmentally understand what your company’s culture is. Until you understand that your company is not a perfect agile wonderland, you won't be in a position to design your role.

Step 2: Determine What Your Company Needs of You

Establish what not just your company, but also your team, your management, your product owner, your stakeholders and your customers need of you. Sure, what you yourself want to do is important, but it won't be sustainable or effective if you're not also meeting the needs of everyone else. We Business Analysts fortunately tend to be good at figuring out what our stakeholders need, but it's often harder to turn our analytical eye inwards.

Step 3: Design and Implement Your Role

For people like us, this is the fun part. In this step, you'll essentially put the techniques we use to create products to use in creating your role. No, you are not a product yourself; you're a human being. But there is a lot to learn (and leverage) by going through the same process.

By determining what specific features, values and benefits your role will possess, validating that role within your company, and implementing that role with an eye to regular fine-tuning and improvement, the BA role problem can be successfully overcome.

How about you? What role problems have you been facing either as a BA yourself or as someone working with them? Feel free to share your thoughts and experiences in the comments section below.