Author: Robert Galen

The Agile BA: Predicting the Death of Micro–Management

Written by Robert Galen on February 19, 2013. Posted in Articles.

I was teaching a class a few weeks ago on Agile Methods. One of the crucial aspects of an introductory course, at least from my perspective, is an introduction to agile requirements. I usually start the discussion by trying to explain the large differences between traditional requirements and their agile equivalents.

Now the end results each tries to steer towards are the same. But how they approach providing functional direction can be very, very different. Here is a table that tries to illustrate the primary differences:

One of the students really had a problem with this. We were doing a simulation around an iPad application. We developed a Minimal Marketable Product definition for an R1 release of the product. I then asked the student teams to write user stories in a story writing workshop. These stories were intended to align with the MMP they had defined. The next step in the class was to do a bit of release planning.

One of the teams pulled me aside and said that they were having a lot of difficulty with the exercise. In essence, they were struggling with the ambiguity and the lack of finely grained requirements. They were incredibly uncomfortable with aligning high-level stories with their MMP. Essentially—they wanted to be told what to do. Thinking and ideating on their own was simply too hard. It was also fraught with risk and responsibility.

In the class, I ‘forced’ them to try and deal with the ambiguity and complete the exercise. But it struck me that all they wanted was to be micro-managed.

Micro-Management

You all know what micro-management is from a leadership perspective. You’ve all probably worked for a micro-manager. They get involved in everything you do—looking over your shoulder, assessing your progress, and giving you advice at every turn. Usually the advice is staid and conservative. Aligning with how things have “always been done this way”. They don’t like anything that is risky or performed outside of their comfort zone. And usually, consistency in execution is very important to them.

Why don’t people typically like working for a micro-manager?

I think some actually do. Those employees with little experience, or drive, or desire to take ownership of their work. They embrace simply being told what to do, then do it, and then go home; satisfied that they met their boss’s expectations.

But in my experience, many more find this dissatisfying. It’s constrains them; limits their innovation, creativity, learning, risk-taking, experimentation, and yes, fun. Quite often it doesn’t drive the best results either.

But I need to get back to requirements. So what does micro-management have to do with requirements?

I think quite a bit. I think of traditional requirements as having many of the same attributes of micro-managers. They simply tell you what to do—in excruciating detail. There is no wiggle room, little area for thinking or discussion, and certainly there is no room for discussing option with the customers or creatively solving their problems.

Often, Business Analysts are the bosses with respect to traditional requirements. Sure, they try to be collaborative. But in the end, it’s their job to figure the direction out and describe it to the team. Then it’s the teams’ job to implement the product…as described and directed.

Agile or Not…Let’s Stop the Insanity

Whether you’re operating in traditional or agile environments or something in between, I’m now predicting the demise of this pattern of Requirement Micro-Management. And I hope it’s a ruthless, quick, perhaps painless, but permanent death. No matter how we approach it, it does need to stop.

Why?

Because it doesn’t work! You might ask what’s wrong with the traditional approaches to requirements. In answer, I might offer the following (non-exhaustive) list:

They presume that a few can figure everything out
They don’t easily adapt to change or discovery
They don’t communicative well; writing being the primary medium
They constrain innovation and creativity to only a few
They imply that solutions are fixed
They imply that teams simply follow the recipe; fostering little true collaboration
They often miss the mark; disappointing customers
They can be confusing; but impede asking questions
They work more poorly as complexity rises
They should be continuous rather than a leading activity

So, whether you’re agile or not, please consider adopting the mindset of agile requirements and putting behind the notion micro-managing requirements.

The world will be a better place for it and we’ll certainly create better products.

Thanks for listening!
Bob.

Don’t forget to leave your comments below.

The Agile BA: In Search of the Elusive MMF

Written by Robert Galen on January 15, 2013. Posted in Articles.

Many agile teams are familiar with the requirement artifact called the User Story. I often teach agile requirements in organizations and my favorite analogy for the user story is a lightweight use case on a 3×5 card. I tell everyone it’s not a ‘good’ analogy, but it does work for envisioning. Another way to look at a user story is that it defines an “executable chunk” of functionality that can be completed within a team’s sprint interval. So that bounds the story in size and complexity. It also dictates that it needs to be demonstrable in the sprints’ review; supporting a done-done state.

Often in agile teams, singular stories don’t have sufficient mass or impact to effectively be VALUE-ated by the team or customer. I frame things in terms of themes of stories, which is a common way of bundling stories together that have value and meaning as a collection. Not only does it help in developing sets of meaningful functionality, but if you prioritize at the thematic or collection level, it greatly simplifies your prioritization. It also has more meaning from the customers’ perspective; since they tend to think in terms of features or workflows and not the more granular stories[1].

A variation on this theme (pun intended) is the Minimal Marketable Feature/Product or MMF/MMP. This concept originated in the Kanban and Lean communities. Eric Ries also explore it quite a bit in his Lean Startup [2] book. Essentially, it’s the same as a theme, but it brings to bear the notion of deliverability, marketability, and overall customer usage.

Quite often an MMF/P is larger than a theme. It could be equivalent to a Larger-scale Epic Story and require many sprints and/or teams to complete. However, once completed, the team will usually physically deliver the MMF/P to the customer; for example, pushing it into a production environment.

MMF Driving Synchronization and Clarity

Recently, I’ve been coaching teams that are struggling with their focus. There’s an anti-pattern that affects many teams where they start sprinting before they understand the business case and intent for their release(s). Sure, they’re delivering a continuous flow of stories. But they don’t necessarily understand the minimal set of functionality that their customers are looking for so the usability and cohesive value can be missing.

Not having this clearly articulated up-front becomes a fundamental problem for them. Quite often their customers have an expectation of delivery that are quite different from what the team is sprinting towards delivering. Consequently, there’s no collaborative clarity around what the MMF or MMP is between the team and the stakeholder.

One nice way to connect the two back together is to establish a view towards each releases’ MMF. Part of defining the MMF is the round-trip discussions that occur as the teams estimate and/or size up the stories and features within the MMF. The customer reevaluates whether they truly need that functionality given the investment of time. This collaboration dove-tails quite nicely into release planning, which I’ll be discussing in more detail in future articles, as the team narrows into fitting the MMF into a specific release window.

I’ve even seen multiple sorts of MMF’s developed for release planning; for example, a UX MMF that tries to capture usability and interaction flows vs. the cost of implementing them. Or, similarly, an Architecture / Refactoring MMF that tries to guide these sorts of trade-offs within a single or series of planned software releases.

MMF or MMP Simplicity

When a team is defining their minimal marketable feature or product, I want it to fit on a single sheet of paper. I’m looking for the elevator pitch or ‘essence’ of the product to be described.

I often ask for what needs to be in the product to be defined, but also what doesn’t need to be in the product. Occasionally, I use a “What’s IN versus What’s OUT” chart to get the point across. It defines the must haves and the must not haves for the MMF (or MMP). It turns out the crucial part of the chart is the gray area in between these two dimensions and the discussions that surround understanding the minimal set of functionality.

Often features will move back and forth. Features will get broken down and some aspects move from one column or the other or they are removed entirely. These are usually quite dynamic and potentially heated discussions as the teams are pushing back on what’s feasible and the stakeholders are demanding more. The common denominator in the discussions is priority and value; trying to keep everyone focused on what’s truly important to solve the customers challenges.

So, no Gold Plating or Wishful Thinking allowed!

Let me give you an example to help illustrate this concept. If we were doing a simple collaborative white-boarding tool for agile teams, the following example in Figure 1 might be a reasonable MMP definition to start discussions across your team.
Visually as we added something to the left, we’d need to either de-scope something or move it off to the (white) or (gray area) for further discussion. They are an implied BALANCE within the chart; that is the work detailed within the MMF is feasible for the team to deliver. And you might ask—who determines where it’s feasible? Why, the team themselves!

Caution: There is Minimum. Then there is Viable

There’s a wonderful Harvard Business Review blog article where David Aycan discusses additional nuances associated with the notion of an MMF. He makes the point that quite often today, in our fervor to hit the ‘minimum’, we over-simplify features and products and lose customer and business viability.

I haven’t seen this pattern that much myself; I usually see the reverse, or teams incessantly trying to build “too much”. But, he connects it to Eric Ries’s Lean Startup work and I have been around enough people who are passionate about those ideas that I can see it happening. Regardless, I’d recommend you read his post.

I think the key is for us to focus on minimal and viable as much as possible when we’re framing reactions to our customers’ needs.

Finally, a Trip to MoSCoW

I first encountered the MoSCoW method for prioritization within the DSDM agile methodology . DSDM lies within the agile family of methods, but is nearly unused in North America. It is much more popular in Europe and leveraged mostly for traditional, larger-scale projects. It has some interesting dynamics that are similar to RUP-style methods.

MoSCoW prioritization is a technique for breaking requirements, or stories & features, down into four specific categories for consideration, discussion, and execution. They are:

Must Haves – will not release without these features and capabilities being present
Should Haves – high priority features
Could Haves – moderate priority, fit if time allows, but deferrable
And Won’t Haves – features negotiated out of this release for now

When prioritizing your backlog, it helps to place these four ‘buckets’ on a wall or table and to visually discuss and move stories around from one to the other.

Many groups come up with some sort of ratio that helps with this. For example, out of 100 stories, perhaps only 10-20% should effectively be Must Haves and 20-30% might be valid Should Haves. This gives you some general guidance on how to compose stories into an MMF or, more often, an MMP definition.

You might want to try Moscow as a facilitative technique when you’re prioritizing. My experience is that it helps to drive discussion and encourages the team to wrestle with truly “must haves” versus everything else.

Wrapping Up

There is never enough time nor sufficient team capacity to do everything. Yet, today’s leaders always seem to be pushing teams beyond their abilities; creating unhealthy tension and the possibility of team’s disastrously committing to more than they are capable of delivering.

Instead, the notions of Minimal and Marketable help teams and stakeholders define a clear set of value-based functionality that can be negotiated before committing to a release plan. Another attractive aspect is that they form a ‘baseline’ understanding that can be adjusted based on the teams challenges and changing business needs.
Whether you are part of an agile project or not, consider leveraging MMF’s as part of your project chartering and commitment processes to focus in on the minimal set of customer expectations that still provide high value.

Thanks for listening,
Bob.

Note: parts of this article are inspired by Bob’s forthcoming 2’nd Edition to Scrum Product Ownership: Balancing Value from the Inside Out, which will be available on Amazon in early March 2013.

Don’t forget to leave your comments below.

[1] A common anti-pattern is for teams to break stories down into too finely grained units. For example, only having 1-2-3 point stories. The intent is to have fine visibility, but the effect is to get lost in the ‘weeds’ and lose the big picture of the sprint and release.
[2] Eric Ries, Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses

Agile Genesis Questions— Why? and What’s the Value?

Written by Robert Galen on January 17, 2012. Posted in Articles. 2 Comments on Agile Genesis Questions— Why? and What’s the Value?

An advantage to self-publishing a book is that you can decide when you want to do publish a second edition, not the publisher. I’ve been entertaining the idea of updating my Product Ownership book of late. Mostly because I’ve learned so much since I first published it in 2009. I’ve also changed some of my views since then—so I’ve got quite a bit of ‘content’ floating about my head that is looking for a home.

One of the ideas that I’ve been thinking about a lot lately surrounds the notion of feature value in agile teams. It’s driven by this typical value flow of agile work—

The Product Owner drives the highest priority User Stories (Features)
The team delivers these to the ‘Business’ and gains sign-off that they’ve met their commitment
These features are then pushed to the Customer for use

Agile is terribly wrapped around the axel of value-driving functionality. It is one of the primary responsibilities of the Product Owner, Business Analyst, and Tester (among others) to write stories that connect the described needs to customer value.

The Product Owner is continuously considering the usefulness, the popularity, the compelling-ness of features. They are gathering insights from stakeholders as they craft the definition of each User Story and how it relates to the overall feature they’re defining. One of the reasons for this is simply due-diligence from a business perspective. Another revolves around the base needs of their team.

Your ‘A’ Team

You see, a primary responsibility for the Product Owner in this sense is to treat their teams as a highly-skilled and specialized resource. For example, a high-caliber swat team. You don’t send a swat team out to police burned out traffic signals or guard child crossings. Not that those activities aren’t important, but the world has many who can do those jobs well.

No, your team is a highly trained and highly skilled group. You need to be considerate of their time and energy. You need to give them work that will challenge them, delight them, stretch them, grow them, and encourage them. In a word, you simply can’t waste them on the mundane or more importantly the non-valuable.

So every choice you make in seeding work into their backlog needs to be carefully considered. Many if not all Product Owners, solely consider the business-side when it comes to developing and prioritizing stories and features. But what about their team’s needs? They also need to consider the impact that the features will have on their teams’ morale, trust of you and your skills, and overall understanding of your strategy.

Too Laissez-Faire

I see the definition of Feature Value to be a much richer landscape than simply saying this feature or story is #23 on the Product Backlog hit parade. Trust me, that’s where it belongs…so now go and execute it.

And I see way too many Product Owners not taking a holistic view towards their prioritization and selection of stories. It’s unfortunate really, because adding an appropriate level of nuance is their job.

There are two key areas that I want the Product Owner’s to improve in—

Explaining the WHY behind each and every Feature. Why is it important? To the organization? And their core business strategies? Why is this team being asked to deliver the Feature? Why has this specific set of User Stories behind the Feature been selected as crucial for delivery?

And

How will the Feature success be MEASURED? How will the Product Organization and Product Owner be measured on the Features worth estimation? What are the critical KPI’s for this feature? How was this data derived? Will usage data be collected from the Product to confirm?

Let’s explore each of these in turn…

What about WHY?

So, I think the first question our Product Owners need to start answering is ‘Why’. Why are we picking this feature? Why do we have to implement the described functionality? Why is the customer asking for it—what problem are they trying to solve? Why have you prioritized it this way—over these other five features? Why is it important? Why can’t we “skip it” and work on technical debt—as the application is becoming impossible to support?

And beyond the questions, which are certainly segues into insight, what’s really important here are the answers. Giving the team the ‘Why’ behind your decision-making and trade-offs is crucial to helping build great applications.

The answer to why can be un-compelling and demoralizing, for example, we’re doing this because our Group VP Bob said to do it. Period! Sure, that’s the answer, but it gives no insights that the team can leverage in producing great products or feeling good about said activity.

Or you can give the team competitive landscape insights and insights into your customer needs analysis that have led you to the conclusion that this feature is in the Top 10 of high-impact needs for your customers. And you can communicate this to your team in the context of the customers’ problem—so that they approach the requirement from a solutions design perspective and not simply implementing what you asked for.

A wonderful resource to help inspire you to the importance of Why is Simon Sinek’s TED talk on the subject of ‘Why’. It’s only 18 minutes, so take a peek…

Value Estimated…and…Measured

Beyond why, the second question to be answered relates to value and measuring it. How do we as Product Owners plan on measuring the value of this feature once deployed? What are the critical success factors in customer usage, customer acceptance, and quality levels? Do non-functional requirements come into play—such as performance and security considerations? And if so, how specifically will we measure sufficient support levels both prior to release and then late, in the customers’ hands?

I find that many Product Owners don’t sufficiently define measures for their acceptance criteria. Very typically this will result in ROI, i.e. in raw sales or in usage & adoption metrics. This is particularly easy to do if you’re product is delivered as a SaaS. But it’s possible to do no matter your product delivery mechanism.

Why do it?

First, it indicates how well the team is truly achieving their business value goals. It’s not some sort of guess, but it’s derived from real usage, adoption, and sales data. And the team should pay attention to this when developing (the target) and when delivering (actuals) functionality.

But more importantly, it also is a report card for how well each Product Owner’s decision-making is determining and driving their valuable team towards delivering business value. Just as the team needs to be accountable for their estimates and efforts, each Product Owner should be estimating (placing items on the Backlog) and being critiqued on how well they guessed at ultimate customer value.

Wrapping Up

I apologize for meandering a bit in this post. The critical points relate to Product Owners having two critical responsibilities—explaining the why behind their decisions (their thinking) and measuring the effectiveness (value realized) of their decisions. And then having the responsibility to learn from their measures and decision-making results, reflect on their actual performance and continuously improve.

And by Product Owners, I don’t just mean the PO proper. I also mean the Business Analyst, Tester, virtually anyone who contributes User Stories describing what will be built and how we’ll measure it.

Simply put: Focus on the Why and Measure the Value

Thanks for listening,

Bob.

Don’t forget to leave your comments below.

BA’s of the World…What is your Worth?

Written by Robert Galen on November 21, 2011. Posted in Articles. 1 Comment on BA’s of the World…What is your Worth?

I want to discuss your value in this blog post. But in order to make the point and get your attention, I’ll shine the light initially elsewhere and then circle back around. We’ll see how this goes…

What I want to talk about is testing and testers…of the agile variety. I often ask new agile testers what is their value proposition? How do they earn their keep—so to speak? Quite often I get some of the following responses:

Testing
Writing test cases
Finding & reporting bugs
Triaging bugs
Running test cases
Smiling and frowning – depending on the applications’ state
Writing status reports
More testing

Usually the answer aggregates toward—I need to be testing 100% of the time to earn my paycheck and prove my worth. No, make that 125% of the time.

So Sad!

This essentially makes me sad. Why? Because within an agile context I consider testing to be the least valuable contribution that a tester can make to their team and project context.

It’s by rote. It’s proverbially trying to “test in” quality. It’s a late binding exercise that is intended to only find faults. It normally provides feedback too late. And it’s not collaborative—with developers and testers throwing the code / bugs back and forth over their functional walls.

And it uncovers only small percentage of those faults that can be found. There are always many bugs that are quite simply never found.

So…where IS the Value?

So, if the value isn’t in testing, where is it?

I firmly believe it’s at the front of the line or the front of the process. By helping the customer define their User Stories…incredibly beautiful and well-crafted user stories. By helping define & refine acceptance tests as part of each Story. By influencing the Customer + Developer + Tester collaboration around the Story to ensure that everyone is on the same page. So that the problem they’re trying to solve is clear and the approach is on-target.

By collaborating around:

The Story definition
The Story acceptance
The Story story (Conversations)
The Story example(s)

What a wonderful approach towards providing high value and creative solutions. We work as a team and talk to each other. Instead of sending email or writing expansive documents or scheduling countless meetings. We collaborate around the software and fine-tune it until it meets the customers’ needs.

So…what does…

So what does this have to do with the Business Analyst and value? As a BA, I want to reinforce that your primary value proposition is not:

Writing requirements
Reviewing requirements
Verifying requirements
Eliciting requirements
Decomposing requirements
Aggregating requirements
Establishing Functional vs. Non-functional requirements
Etc.

In an agile context.

All of those actions or activities are perfectly fine. But I’d like to reframe your value proposition around driving collaboration in what Ken Pugh defines as the Triad and George Dinwiddie defines as the 3 Amigos.

Wrapping Up

That you view your Prime Directive as helping to establish a collaborative culture where THE CUSTOMER, THE DEVELOPER, THE TESTER AND NOW…THE BA collaborate around working software and stories and examples and conversations—

until the customer yells—By George, I Think We’ve Got It!

Now there is a value proposition that, while quite a challenge to nurture and establish, is truly worth its weight in gold!

Thanks for listening,

Bob.

STOP the Software Requirement Insanity

Written by Robert Galen on October 25, 2011. Posted in Articles.

I attended the Agiles 2011 conference in Buenos Aires, Argentina in early October. Jeff Patton was a keynote speaker at the event. In his keynote, one of the remarkable (at least to me) points that Jeff made was that he really hated the term requirements.

He made the point that in the early parts of his career, he worked for small software companies that really didn’t refer to requirements as requirements. The used customer centric terms that connoted customer needs, business problems, and desired outcomes. There was no “requirements analysis” or “requirement sign-off” per se; there were only customer and business problems to solve.

When he changed jobs and first encountered true waterfall processes and the term requirements, he encountered the fixed, seemingly non-negotiable nature of requirements.

Software Requirements?

So the critical question that Jeff raised is that are software requirements truly REQUIREMENTS? Are they:

Absolutely required?
Non-negotiable?
Blindly followed?
Simply listed?
Taken verbatim?
Targeted as a whole?

In the interactions of the organization asking for them and in the minds of the teams tasked with implementing them.

In Jeff’s view and my own, they are. Organizations get wrapped around the “requirement axle” in demanding “a list” that they blindly follow to completion. Oh sure, requirements are discussed, clarified, negotiated, decomposed, written, and dissected. But they are, by and large, followed!

But what’s missing?

I think the key point is that demanding anything specifically limits our solutions, our creativity, our ability to innovate, and our thinking. Let me try to make this point with an example.

I love Maine. It’s one of my favorite states and since I moved from Connecticut to North Carolina many years ago, I don’t visit it often enough. One of the wonderful aspects of Maine is the cabins and cottages along its many lakes. Let’s pretend I have a little piece of property in Maine and I want to build a year-round cottage on the lake. I want to give my architect some directions towards designing my cottage, so here goes…I can say that my requirements are:

A 3 bedroom, 2 bath cottage
Somewhere around 1900 to 2200 sq. ft.
I want it to be a log cabin
Timber frame construction
The family room should look out over the lake
I want a sun room, encased in glass
The master bath needs to include a whirlpool and sauna
Granite, state of the art appliances, and Italian tile need to be in the kitchen
Wrap-around porch – 10’ for a porch swing
2 car garage, etc.

You get the idea, it’s a list of “requirements”, and I’m “the customer”. So, what will I get in my house design? I strongly suspect exactly what I asked for. Not bad, but what if I was mistaken? Nor am I an expert in house design—so what if I asked for the wrong things?

Perhaps something else…

Now let me try another approach. I want to simply describe the business situation, but not necessarily require anything. I’m not sure this will be the best example, but I hope you get the idea…So instead I describe for my architect some of my preferences, or things that I really enjoy. For example:

My wife and I are gourmet cooks and we’d really like a kitchen that would support the both of us cooking. It needs to be modern, with high-end appliances, but reflect the simple nature of a Maine kitchen.
We also entertain quite a lot, so we need space to support that. Most of the entertainment starts with dinner, again our cooking thing. And we’d like the ability to entertain inside & outside as the seasons and weather permit.
I personally love the water. I love seeing it in the morning when I get up and looking out over it at night with the moon reflecting off of it. Can we position the house to maximize the exposure to the water?
There’s just the two of us. Our children and friends visit infrequently, perhaps 4-5 times a year. So, we need some space for visitors…but, but not too much. Oh, and I’m a consultant, so I need a private office.
I plan on purchasing a boat, somewhere in the 22-27 ft. range, within the next 2-3 years. I’d love a place to store it in winter and something dock it on in the summer.
Oh and I hate, absolutely hate, doing yard work. Yet, I love a well groomed property and garden. It just needs to be ultra-easy to maintain.

I’d like to call this last list something other than requirements. I consider it insights, design goals, customer usage intentions, etc; almost anything other than requirements. What does this re-frame do?

My hope is that it communicates my home goals while leaving the flexibility for my architect to do their job. Then I hope it fosters review and communication while we refine the plans. Ultimately, I want my architect to “delight me” by interpreting my goals, collaborating with me, and leveraging their creativity to create something “just right”.

Wrapping Up

So enough of my ramblings… Do you feel the term requirement has become too restrictive? Or are Jeff and I simply overreacting? Please weigh-in with your comments. And please share your experiences, thoughts and ideas for how we might frame requirements to drive more innovation & creativity, team-based engagement, and simpler overall solutions.

It’s not required that you weigh-in, but it’s very, very welcome!

Bob.

Don’t forget to leave your comments below.