Tag: Validation

Pareto and You – Separating the Wheat from the Chaff

Written by Robert Galen on January 14, 2014. Posted in Articles.

I can’t recall when I first came upon the Pareto Principle. I think it might have been when I was studying for my Six Sigma Green Belt. But I’m unsure. I know I was operating as a QA Director at the time, because most of my example uses for it surrounded testing and defects. Nonetheless, it’s probably been over 15 years.

That being said, I don’t think I hear people “considering” Pareto enough in their day-to-day activity, so I thought I’d bring it up and remind everyone of the Pareto Principle or 80:20 Rule and it’s implications for software engineering in general and agile teams in particular.

Basics

In 1906, Italian economist Vilfredo Pareto created a mathematical formula to describe the unequal distribution of wealth in his country, observing that twenty percent of the people owned eighty percent of the wealth. In the late 1940s, Dr. Joseph M. Juran inaccurately attributed the 80/20 Rule to Pareto, calling it Pareto’s Principle. While it may be misnamed, Pareto’s Principle or Pareto’s Law as it is sometimes called, can be a very effective tool to help you manage effectively.

Where It Came From

After Pareto made his observation and created his formula, many others observed similar phenomena in their own areas of expertise. Quality Management pioneer, Dr. Joseph Juran, working in the US in the 1930s and 40s recognized a universal principle he called the “vital few and trivial many” and reduced it to writing. In an early work, a lack of precision on Juran’s part made it appear that he was applying Pareto’s observations about economics to a broader body of work. The name Pareto’s Principle stuck, probably because it sounded better than Juran’s Principle.

As a result, Dr. Juran’s observation of the “vital few and trivial many”, the principle that 20 percent of something always are responsible for 80 percent of the results, became known as Pareto’s Principle or the 80/20 Rule.

–Quoted from About.com

Implications

Let me give you a couple of scenarios that illustrate “80/20 in action”:

If you’re testing a software application, then 80% of the bugs will reside/surface from 20% of the applications components.
If you’re counting costs, then 80% of the cost of a Toyota Prius, will be contained in 20% of the component parts.
Continuing the Prius example, 80% of the weight, will be contained in 20% of the component parts as well. And if we’re putting them in storage, there will be a warehouse space equivalent.
Back to software, 80% of the technical complexity (perhaps call it risk as well) resides in 20% of an applications components.
And so on…

I really like Juran’s wording around “the vital few”. The 20% turns out to be the interesting case and, once we find it, we can adjust our views to handle it much differently than the 80%.

Disclaimer

Now of course the numbers aren’t quite that precise and I don’t want you to build your every action around or upon Pareto. But making it a part of your analysis and thinking has served me well for years in focusing towards what truly matters.

Agile Implications

Now let’s get around to some of the implications or examples within agile teams:

Backlogs & Product Ownership

20% of the User Stories probably need some sort of “research spike” in order to sort through the technical implications and ambiguity.
20% of the User Stories (functional work) probably contain 80% of the customer value. So find them and do those first.
20% of the User Stories (non-functional work) probably need expanded Acceptance Criteria to better guide the confirmation of completeness.
20% of the User Stories need to be groomed multiple times (discussed, broken down, estimated, explored) before they become “ready” for sprint-execution.
20% of the Features drive probably 80% of the customer usage.
20% of the Features will contain 80% of the stakeholder & customer driven change.

Technical Risk

80% of the technical complexity is in 20% of the component work a team is taking on. Find it and handle it differently: designs and design reviews for example, teamwork and pairing.
The estimates for 20% of the more complex User Stories will be inaccurate or contain more variance. Consider this when estimating.
20% of the backlog will have strong architectural implications.
20% of the backlog will have cross-team technical dependencies.
20% of the application will contain 80% of the technical debt. Or will be attractive targets for refactoring.
20% of the application will require 80% of the maintenance activity.

Planning

20% of the Release Plan will contain 80% of the risk.
20% of a Sprint Plan (backlog) will contain 80% of the value, 80% of the risk, 80% of the swarming opportunity.
20% of the Sprint Plan (backlog) will contain 80% of the testing activity, testing work, testing risk, bugs/rework.
20% of the overall work will take up 80% of the time; I wonder if that has anything to do with “90% Done Syndrome”?
20% of the teams work will result in 80% of the “blocking issues”.

Quality & Testing

20% of the User Stories will contain 80% of the bugs.
20% of the User Stories will contain 80% of the testing complexity and/or repeated testing risk.
80% of the User Stories or Features need less testing than you might originally think—think risk-based testing here.
You’re test strategies and plans ought to include the 80/20 Rule.
20% of the defect repairs will contain 80% of the defect rework.
20% of your tests will take 80% of the time to run; find these and automate them…then go to the beach.

These were not intended as “exhaustive” lists. More so, they are intended to get you thinking of the implications of the Pareto Principle in your daily agile journey.

Wrapping Up

Now all of that being said, there IS a challenge in using the 80/20 Rule.

It’s finding the 20%! It’s not always evident where it is.

Let’s take the bug example. It clearly aligns with my experience that 80% of the bugs “cluster” around a small percentage of the code in every application I’ve ever tested. Let’s call that 20%. So from a testing strategy and planning perspective, 80% of my effort (testing hours) should be focused there. However, finding or predicting those defect clusters isn’t that easy. If I’m presumptuous and think that I can predict them all, then I will most likely have wasted some time and missed some critical areas. So blind use of Pareto isn’t in your best interest nor is it prudent.

However, you should constantly be thinking of Pareto sweet spots in your daily work. It aligns nicely with the Agile Manifesto principles, Lean thinking, and common sense.

One final request: please add comments to this post with other “Pareto scenarios” that you can think of within agile contexts. I’d love to build on the examples I provided.

Stay agile my friends,
Bob.

Don’t forget to leave your comments below.

Quick references:
1. The photo is from Wikipedia article on Vilfredo Pareto.
2. http://management.about.com/cs/generalmanagement/a/Pareto081202.htm
3. http://betterexplained.com/articles/understanding-the-pareto-principle-the-8020-rule/

Demonstrate Your Value

Written by Adriana Beal on January 7, 2014. Posted in Articles. 1 Comment on Demonstrate Your Value

In 2013, I received many questions about how business analysts can demonstrate the value they add to their organization. I’ve also seen an increased interest in performance measurement for BAs. These two topics are tightly connected, as we are going to see in this article.

The inability to demonstrate the value BAs add to their projects limits what analysts can achieve in their organizations and reduces the opportunities they get to continue to develop their skills. Many BAs find it hard to convince management that they should be involved earlier in business and IT initiatives, so they can help influence direction and reduce risks associated with project scope. Some experience obstacles to even being involved at all in certain projects, which forge ahead without the benefit of a skilled BA to ensure the right problem is being addressed and the right solution is being built. Laura Brandenburg, in this article, mentions another challenge: the lack of funding for professional development, in the form of training, access to conferences and other high-cost learning opportunities.

All these problems share a common root cause: lack of concrete evidence of the value a skilled business analyst brings to organizational initiatives. For example, if you join a company that previously only hired weak BAs who never contributed substantially to the outcomes of software projects, stakeholders might forget to invite you to the discussions during the early phases of your projects. They may also decide to talk directly to developers to define the solution without seeking your contributions, and deny your requests for training, certification, or conference attendance, because they don’t see the potential return on that investment.

But BAs have a powerful tool on their side to help influence management to elevate their role and increase their exposure to enterprise analysis, high-profile projects, and professional development opportunities: performance measurement.

Even if your company doesn’t measure the performance of individual BAs, or does it poorly (measuring things that aren’t directly related to value creation, such as time spent by BAs on each task, number of requirements, requirements volatility), you can establish your own effective performance measurement system. Then, with the performance data collected, you’ll be able to provide solid evidence of the value you bring to your projects and demonstrate the benefits that further investments in your skill development can bring to your organization.

Here’s an example, drawn from my own experience:

Several years ago, I was asked to return to one my clients, a financial institution, to help bring one of their software projects back on track. In the course of the new project, I happened to find, lying on a shelf, a copy of the requirements document I had produced for my previous project. At the time the document was approved, the business stakeholders had offered high praise for my work, but when I opened that copy of the document, I saw many questions from the development team, hired only after I had left for another assignment.

For instance, while the business stakeholders had been satisfied with my requirements describing the “happy path” of a wire transfer being successfully completed, the development and testing teams also needed to know what should happen when an attempt by a customer to submit a wire transfer failed. The expected behavior could be anything from just presenting an error message to the user, to sending an alert to the appropriate account manager so he could immediately follow up with the customer to fix the issue. The right solution could not be built until the desired behavior was clarified.

That experience opened my eyes to an important aspect of my performance that I had been overlooking: writing requirements that not only the business stakeholders found to be in excellent shape, but also the development and testing teams considered to have enough information for them to be able to to build and test the right solution. Providing incomplete or vague information to development and testing teams may cause unnecessary delays when the teams have to list the questions they have and wait for someone to analyze these questions and provide a suitable answer. For that reason, when I saw that annotated document full of questions, I decided to start monitoring my performance in this area.

One of my professional goals became: “reduce the number of questions my requirements documents elicit from development and testing teams”. I defined a target of no more than 3 questions per document for year one and 1 question per document for year two. (This would give me some time to identify the patterns that caused developers to need clarification of my requirements and fix the issues before I started to hold myself to a higher standard.)

With my new goal in mind, I started thinking about requirements not just from the perspective of the business stakeholders (who already were very satisfied with the quality of my work), but also from the perspective of developers and testers. After writing each section of a requirements document, I’d ask myself: “If I were writing the code for this capability myself, would there be something else I needed to know?” And, “If I were in charge of testing this set of requirements, would I know the expected results for all relevant test scenarios, such as entering an out-of-range number, or skipping a required field?” These questions helped me find the omissions in my documents before they were released, drastically improving the quality of the final products from a perspective of the delivery team.

By the end of year two, I had exceeded my goal, with most projects yielding zero questions from developers. From time to time, I still get questions posted to the wiki page reserved for questions about requirements, but I can always map them to one of the following scenarios, which don’t affect my individual performance:

The question isn’t about requirements (e.g., “How many search results should be displayed in each page?” when the decision about how to display search results had been left for the UX designer, who might even design a solution with “infinite scrolling”, so there isn’t pagination to worry about);
The question has been answered in the document already (e.g., “Do we need to worry about different levels of permission for different user roles?” when the Table of Contents of the wiki space that stores the requirements already has a section titled “User Roles”);
The question is about a gap in requirements that is known and noted in the appropriate section of the requirements document (e.g., “Pending definition of which file formats the import capability will have to support”).

Now, how can this approach of setting goals and measuring your performance help you demonstrate your value to the organization and justify more investments in your professional development? Here are some steps that you can follow:

Show the results of your performance measurement and improvement efforts to management, accompanied by an analysis of the impact these results have in project outcomes. Example:
“Because our development team is in India, each question raised by a developer may cause a delay of up to 24 hours in completing a portion of the code, due to time zone differences. Clear requirements that eliminate the need to ask questions and wait for the answers mean more productivity for the developers working on the implementation of new capabilities.”
Describe the goals you are pursuing next, accompanied by what value reaching this goal will add to the overall performance. Example:
“My goal for Q1-2014 is to become fully knowledgeable on the business aspects of creating and maintaining promotional discounts for our webstore. This knowledge will help me better understand the business and user scenarios our tools must support, so I can propose better solutions and avoid the change requests that we keep receiving at the end of each development cycle to accommodate missing functionality.”
Ask for whatever resources you need to reach your goals. Examples:
“In order to help me achieve this goal, I’d like to ask permission to start spending 20% of my time in the marketing department, so I can observe their work when they are creating and updating promotions.”
“There’s a conference coming up about new trends in web analytics that I’d like to attend so I can bring some new ideas to the marketing team about how they can better track the results of their promotions. Based on better analytical data, I can help the business stakeholders prioritize future enhancements to our promotions engine to reduce the backlog of our projects by cutting scope that isn’t going to contribute to the bottom line.”

The main pitfall to avoid when discussing the value you bring to your organization is what many professionals do in their resumes and cover letters: talk about alleged personal traits (e.g., “I solve puzzles and fix problems better than most”, “I’m good at taking complex ideas and making them digestible”). You want your discussion about value to focus on clear and objective data that highlight recent accomplishments and show the benefits that your current performance and future improvement efforts can bring to the organization.

If you are a business analyst working on the IT space, you’ll probably be looking for evidence of how your work improves the quality of requirements artifacts, lowers the number of defects and change requests, increases user adoption rates, and/or saves time and money by helping the business focus on high-value features. For a process improvement BA, good measures would provide evidence of the return on investment of your recommendations on quality improvement and process modernization, the number of problems affecting customers or employees that have been fixed by your change proposals, and so on.

With a list of accomplishments backed by objective measures, you’ll be able to offer concrete evidence of the value you bring to your team and develop solid arguments to convince decision-makers to elevate your role and give you access to better information and training resources.

Don’t forget to leave your comments below.

Effective Scrum Product Organizational Patterns Part 1

Written by Robert Galen on November 26, 2013. Posted in Articles. 1 Comment on Effective Scrum Product Organizational Patterns Part 1

Roughly fifty percent of the organizations I visit who are “going Agile” struggle with the Product Owner role. I regularly encounter questions like:

Do we really need a Product Owner per team?
Why can’t our Scrum Masters also serve as the Product Owner?
Since our Product Managers are way too busy, why can’t we simply make our Business Analysts the Product Owner?
Can’t the team simply create its own work? Especially since they’re self-directed.

The first hurdle these organizations are encountering is the investment it takes to provide adequate vision and clarity for their technical teams operating in an Agile/Scrum environment. Often they want to describe things very early on (traditional software requirements) and then walk away until the team delivers exactly what they asked for or need.

And they want a minimal level of interruptions from the team. Since their Product Managers (Owners) are customer and stakeholder facing, with simply no time to engage the team as they work. Simply put—the teams need to correctly interpret the requirements, as defined, and get on with building the products. Continuous collaboration, while it sounds good theoretically, is not possible given their real world constraints.

This role trivialization and denial surrounding the engagement and importance of the Product Owner role pervades many of these organizations. They’re constantly looking for short cuts and workarounds so as to minimize team contact. For the life of me, I don’t understand why.

In this two-part article I want to discuss the organizational posture surrounding effective support of Scrum and the Product Owner role. I might go as far as to say that if you’re unwilling to make these investments, then don’t bother “going Agile or Scrum” as your results will certainly suffer.

My goal is to explain how many organizations should invest in their adaptation towards Scrum Product Ownership. But in the end, each organization must be willing to “pay the price” of agility done well…

Where do Product Owners come from?

I think this is the first question you should be asking when you’re contemplating moving to Scrum. As part of forming your Scrum teams you’ll need to find one Product Owner for each of your teams. Where in your ranks do they come from? Well, typically I see them as part of your Product Organization, so Product Managers become Product Owners. Other team members in Product Marketing and Product Management organization are ‘converted’ as well.

In some organizations, the Product Organization is “lagging behind” the Technical Organizations’ agile adoption. In these cases, the technical organization often provides the Scrum roles of Scrum Master and Product Owner. I’ve seen Business Analysts and other requirement facing designers tapped as Product Owners. Also, architects and testers are selected because of their breadth of understanding of the product functionality and customer landscape.

All of these individuals can BE a Product Owner as long as they have the requisite skills for the role. We’ll explore the 4 quadrants of the role next to illustrate the skill set.

However, beyond skills, there’s an important connection when the Product Owner is not in the Product Organization proper. They need to be strongly empowered and connected to that organization. You can’t be a decisive, empowered Product Owner when you always have to ask permission or run something by another organization for every decision. It simply doesn’t work.

So strong “dotted lines” for communication, inclusion in strategy & tactics, and empowered trust are important aspects of the Product Organization extending towards these liaison Product Owners. And beyond this, I view this as a temporary state. At some point in your strategy, the Product Organization needs to be finding, staffing, and directly guiding the Scrum Product Owners.

In a phrase, they need to have “skin in the game” in the agile transformation; and the sooner the better.

Skills Sets

In a previous article, a 2-part series actually, I explained the 4 Quadrants of Effective Product Ownership as a way of identifying the core skill areas for the role. I’ll briefly run over them here, but I would recommend you read that series.

There are four critical skill areas for the Scrum Product Owner, including:

They are part Product Manager, in the Pragmatic Marketing sense
They are part Project Manager, in the PMI sense
They are part Leader, in the Leader vs. Manager sense
And they are part Business Analyst, in the IIBA sense

The first thing you should notice is the breadth of skill required for effective product ownership. The Product Manager, Project Manager, and Business Analyst are all common, full-time positions in regular teams. So, the amount of work a Product Owner is responsible for may exceed one person’s capabilities to deliver. Often Product Owners only have some of these skills and it’s up to the Product Organization to supplement them in some way, but more on that later.

Now I want to move into the core of this series. Let’s explore some patterns that surround agile product organizations.

Agile Product Organizational Patterns

Next I want to explore a few successful patterns that I’ve seen emerge from organizations that understand the proper balance between the technology and product organizations when they’re implementing Agile / Scrum. Mostly these apply to larger scale or distributed organizations, but many of them apply equally well to smaller organizations or start-ups. And while they aren’t guarantees for success, they certainly improve your odds of a successful agile transformation.

Supplementing Product Owners

It’s an often assumed position that there can be only one Product Owner per team. The logic goes that there needs to be a single deciding voice guiding each Product Backlog and therefore team. I agree on the ‘voice’ part, but I think it’s incredibly difficult to find an individual that can meet all of the requirements of the 4 Quadrants. In my experience, it’s virtually impossible. So then, how do we fill the role?

I’d say in aggregate. We need to have a lead Product Owner for each team, but we can certainly complement their skill areas where necessary. A common complement is to attach a Business Analyst to Product Owners (actually they’re part of the team) to help them in crafting User Stories for their Backlogs. Now the BA might be ‘shared’ across multiple Product Owners, but the effect is to create more consistent and better backlogs.

I’ve seen the same approach taken when augmenting the planning aspects of the Backlog, with either the Scrum Master helping out or assigning a ‘shared’ Project Manager across a set of Product Owners. Typically, the alignment revolves around multiple teams working on a singular product or project. Where cross team integration and planning, across the Backlogs and the team, can be a challenge.

The key is for the Product organization to supplement their Product Owner skills so that they can actively support their teams across the 4 Quadrants. Making this investment important is a hallmark of this pattern.

It’s a Full-time Role

Effective Product Ownership is a craft, a profession, and a discipline. It’s not a part-time, do it when I feel like it, role. I believe it starts with crafting job descriptions for the Product Owner role. That’s why I wrote the 4 Quadrants in the first place, to help describe the broad nuance of the role. Effective organizations look at their current product management and marketing roles and hierarchy and then craft a new role for the Product Owner.

In many cases, this means you’ll need to go out into the market place and hire some experienced Product Owners to complement your existing staff. It also means you’ll work with the technical organization to identify others to serve in a supplemental role as I described earlier. Often these folks are Business Analysts, Designers, and Project Managers.

And it means that by and large, you’ll have one Product Owner per Scrum team. I’ve successfully overloaded the role to two teams, but carefully and with the permission of the Product Owners. A prime directive for the successful Product Owner is to “feed their team well”, and they need the time and skills to do so.

The core of this pattern is honoring the complexity and importance of the role and remembering that it’s full-time!

Outward – Product Manager vs. Inward – Product Owner

At iContact we tried several variations of organizing our Product Owner team over time. When we first implemented Scrum, we simply “converted” our Product Managers to Product Owner roles. We didn’t reframe any of their responsibilities, so they quickly became overloaded—essentially with two distinct jobs.

We initially handled this overload by supplementing them with “help”. For example, giving them Business Analyst or Project Management help, so that they had more bandwidth to do all of the requisite aspects of their roles. This worked relatively well, but they were still quite overloaded, which affected their focus.

After a few years we hit on a recipe that seemed to work best for us. I’ve also seen it as an increasing pattern in many other organizations. We split up our Product organization into Product Owners, who faced the team, and Product Managers, who faced the organization and the customer. We created a reporting relationship where:

A Chief Product Owner would own many Products or Product Lines.
A Product Manager would own a Product Line or Product; Product Managers would focus primarily on roadmaps, product strategy, external communication, and release planning.
One or several Product Owners would “report to” each Product Manager; Product Owners would focus on their Product Backlogs at they supported the Roadmaps and cross-team dependency management.
Teams would be aligned around Product Owners; then to each Product

This allowed us the focus we needed between the internal and external demands of the agile product organization. It also allowed us to create better “career paths” for our product managers & owners. While on the surface this may seem “wasteful” from a headcount investment perspective, please don’t look at it that way. It turned out to drive great products and solid growth, so it was an investment well spent.

Wrapping Up

I began this article talking about my frustrations with organizations trivializing the Product Owner role and Product Organization restructuring needs when adopting agile. In my experience, this is probably one of the “Top 3” problems I encounter while coaching.

Often the excuses flow when discussing this part of the transformation; from we have no additional headcount to we’re too busy to work closely with our technical teams to we want to write everything down because we’re the only ones who know what to do. Many of these connect back to an inherent resistance to change.

I want to challenge these excuses. The Product Owner role is crucial to your agile transformation. It’s central to the team and to the organizational. It’s the “glue” that binds high level strategy to low level execution. To short-shrift it, is to undermine your very goals.

In the second part of this series, we’ll explore more organizational scaling patterns for how the Product organization should respond to agile at-scale.

Thanks for listening,
Bob.

Don’t forget to leave your comments below.

THEY… Made Me Do It!

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

I was attending a Backlog Grooming session with one of our teams. I was simply observing as a coach, as the team had a solid Product Owner and Scrum Master in the meeting. It was generally my habit to “wander around” across our various teams and sit in on Scrum ceremonies as much as I could. Usually, as in this case, I just sat quietly. Observing the “goings on” and seeing if I could provide some offline guidance to our Scrum Masters.

In this particular session, the team was leveraging Planning Poker to estimate the amount of work in a series of User Stories on their backlogs. The discussions were going quite quickly, as the Scrum Master would put an egg timer on each story for 5 minutes of discussion, estimation, and “next step” decision-making. The point of examining each story was not to “complete it” in that one grooming session, but to advance the understanding of it and, if it was not a Sprint-Ready story, to decide what the next step in its evolution needed to be. The teams in general were quite good at staying on-point and not drilling too far into each story.

I did notice something though. There were two patterns “in the room” on a story by story basis. One was that the room seating layout was odd. The “developers” seemed clustered at one end of the conference table and the “testers” at the other. The developers seemed to be estimating as a group and the testers seemed to be following their lead. So if the developers gravitated towards a story being 3-5 points, the testers would most of the time wait a bit and then agree with the developer’s estimate.

On the rare occasion when the testers disagreed on points (level of effort, complexity, etc.) for a story, there would be heated debate across the two groups and quite often (almost always) the developers would drown out the testers concerns and they would acquiesce to the estimate. Then the timer would expire and the team would move on…

The other pattern surrounded Randy. Randy would often start out with an extremely high estimate, higher than everyone else in the room. When he discussed the ‘why’ behind his estimates, it was rarely driven by concrete experience or specific reasons. Typically, the rationale was simply:

This sounds like an awful lot of work and if I have to do it, it will take me a very long time!

As discussions unfolded, Randy would never move from his initial estimate. It seemed like he was simply ‘stuck’ there. Eventually the team would need to agree on an estimate and Randy would begrudgingly succumb to the estimate. Then the timer would expire and the team would move on…

Randy had another mode of operation. Often he would flip-flop and “go low” on his estimates. Often the language surrounded things like:

If we hack this together and skip testing these specific conditions, then I could see us doing this 20 point story in 2 points. In fact, if we work overtime, we could do it in 1 point.

When the team confronted Randy on his oscillation, his rationale was always driven by THEY. As in:

They’re going to cut my estimate or not listen to it anyway, so I need to go high. Or they’re not going to give me enough time or trust me to do a good job anyway, so why should I worry about doing things right?

No matter how hard the team tried to get Randy to be more “balanced” in his views, it never really helped. Then the timer would expire and the team would move on…

Who are THEY?

In the first example, the testers THEY were the developers on their team. The testers weren’t comfortable debating them on story scope or holding the line when they felt something was larger than the developers thought. In their retrospectives, it turned out that quite often the tester’s impressions of relative size, their instincts, were much more accurate than the developers. This was probably due to them considering all aspects of a story and not simply the development time.

In the second example, I believe Randy’s THEY was his historical experience with pleasing folks and dealing with demanding and poor leadership. I also believe the roots were well before he ever came to iContact. Randy was riddled with FUD – fear, uncertainty, and doubt regarding the organization and leadership. In the latter case, he would low ball the estimates because he felt that THEY couldn’t handle the truth of real estimates. He basically would say what he felt folks wanted to hear.

His oscillation was around frustration. So occasionally he would ramp up the estimates and try to hold the line—no matter what. So, he would fluctuate between too high and too low estimates, neither of which he believed to be true.

I remember stopping Randy in the hall once and asking him to “tell more truth” around his estimates. And to trust me more, in that I meant what I said around agile principles. What I wanted, as the leader of the technical organization, was for team members to analyze the story and to estimate what it would take to do a well-engineered, high-quality job. A job that they could be proud of! I remember him telling me that leadership (THEY) didn’t want that. Instead, they wanted low ball, cut corners, do it as quickly as possible estimates.

I stopped him and said that, in this case, I am THEY. And I’m asking him to estimate with truth, quality, and craftsmanship in mind. So there is no THEY in this case; there is only ME and I’m asking you to do what I’m asking.

While we had this discussion on several occasions, I don’t think Randy ever got (or at least believed and trusted) that message. Whatever baggage he had—he continued to carry. I recall when he left iContact, I was hopeful that he would leave THEY behind him and start with a fresh perspective in his new team.

Other They’s

In the same grooming meetings as I mentioned in the beginning, often the Product Owners would have their own THEY. In their case, THEY were Product organizational leadership. And THEY were telling them to put pressure on their teams and themselves to “get more done”. That the leaders had prmised customers more features and this pressure then would cascade down to the Product Owners on the individual teams.

How would this emerge in grooming? In a wide variety of ways:

Often they would second guess the estimates of the team. Looking for ways to get them lower. They would apply questioning, pin one team member’s view against others, and simply keep asking for “better” estimates.
They would also put pressure on the team to take on “stretch items” as part of every sprint. Then, once the team accepted them as “stretch”, they became firm commitments for the sprint.
It created a sense of tension in the team, where the Product Owner would be very feature focused and not want to take on any bug fixes, refactoring, or other technical debt work within the sprint.
Keeping people busy was the overriding theme and not delivering high value, high quality work in a balanced fashion. So if anyone had an extra second, the Product Owner looked to “fill it up” with something.

What was most insidious about this interaction was the sense of distrust and lack of collaboration it created between the Product Owner and the team. In this case, Product Owners allowed the THEY to breakdown their team relationships, which was very sad.

Wrapping Up

One of the five core Scrum values is Courage. I wrote another blog post surrounding that attribute that you might find valuable. But I do think “courage” has something to play in the above scenarios. In these cases, you’ll hear me talk about:

“walking your talk”;
“telling truth”;
“sharing your gut feelings”;
“filtering less”;
and “telling it like it is” as the most congruent things you can do.

Often it can be extremely hard to be balanced within your teams. But it’s what they need most from each of you.

I want you to ask yourself if you’re doing things for them? Or are you doing it for yourself? Have the courage in your agile teams to speak the truth and tell it like it is. Don’t succumb to THEY, THEM or even ME. Simply be true to yourself. I hope that the testers, Randy, and Product Owners have discovered this in their paths.

As always, thanks for listening,

Bob.

Story Context
This is another in my series of stories from my days at iContact. I spent time there from 2009 – 2012 working as the Director of Software Development and Agile Coach at this wonderful and mature startup. During that time we grew to approximately 300 people in size, with roughly 100 in Technology. The product space was a SaaS, email marketing application. We had about 8-12 teams that were practicing Scrum and Kanban for roughly 4+ years, so a relatively mature agile instance. Since I’ve left the company, iContact was acquired by Vocus. These stories are rooted in the experiences I had coaching and collaborating with this wonderful group of agile practitioners.

Don’t forget to leave your comments below.

What’s Down with Agile Documentation?

Written by Ellen Gottesdiener on September 10, 2013. Posted in Articles.

Recently we worked with an Agile team that was building an FDA-regulated medical device. Some team members were worried about how to produce the required verification and validation documents. “What do we do?” they asked us. “We’re not supposed to do documentation in Agile.”

That’s a myth. In Agile, the question isn’t whether to document. It’s what kind of documentation to create, and when. Like everything else in Agile, those decisions are based on your assessment of value—in this case, the value of the documentation. More documentation is not necessarily better. In fact, the volume of product documentation often is inversely related to its value.

Figure 1: Potential Nonlinear Relationship between Documentation’s Volume and Value

Image Source: Discover to Deliver: Agile Product Planning and Analysis, Gottesdiener and Gorman, 2012

Process Versus Product Documentation

You essentially have two types of documentation: process and product documentation. In either case, we urge teams to focus on the documentation’s consumers and look closely at their usage needs. Look at the documentation from the consumer’s perspective, and explore her usability needs to determine the minimum useful and usable documentation.

Process documentation describes the work-in-progress or handover information the stakeholders produce as they discover and deliver the product—the software application, system, or device containing software. Process documentation has less value for a co-located, domain-savvy team than for a team working in a distributed mode in different time zones and with varying degrees of domain expertise. On the other hand, even a co-located team may need process documentation if it’s building a regulated product and requires evidence of product verification, as in our client’s case.

Product documentation, which conveys information about the product, is an asset that tends to be valuable because it’s used to sell, service, and use the product. Consider that the consumer of your product documentation might be a validation analyst from a regulatory body, a product end user, an installer, a help desk technician, a field staffer, a maintenance programmer, and so on.

For our medical device client, the product documentation included scripts for a demo used to conduct validated learning to test the product idea itself. We took the perspective of the people going on-site to conduct the demos, and as a result we created a booklet in a slim, tabular format with abbreviated feature descriptions and demo steps. Not only was this booklet “just enough” to document the product, but also it was fast to produce. As a bonus, the delivery team found the format useful for onboarding new team members.

On Your Mark…

Teams, including the product owners, need to decide when to produce documentation. There are the two meta-patterns: build it incrementally in small bits as you build the software (and when you have the greatest knowledge for creating the documentation), or defer until prior to release (batching documentation as larger set, created all at once).

When the requirements are fairly well known, documenting early and often makes sense. On the other hand, our medical device client was essentially a start-up. The potentially lifesaving devices were being used experimentally with patients in the hospital, and the requirements were changing as the product itself was being tested. This meant that it would have been wasteful to document what the team was delivering at each iteration. They agreed to wait to document prior to each release throughout the experimental usage of the product (this is roughly equivalent to what a lean start-up calls “validated learning”). For this team, it made sense to defer documentation.

A good practice is to produce documentation as part of the acceptance criteria for completing a slice of the product, whether it’s a story, feature, or minimum marketable feature—whatever anchor you use to describe the requirements you’re delivering. When you make the necessary and sufficient documentation a part of the acceptance criteria, you’re gaining value for little added effort.

Sliding Along the Documentation Levers

Consider documentation formality and precision and the volatility of your requirements. Do you need documentation that conforms to a predefined format, sign-off, and so on? Will informal documentation good enough? How precise must the documentation be? Who will be consuming the documentation, and to what end? And as with our medical team, documenting too soon would have been wasteful because of the volatility of the requirements, and yet when it was produced, it needed to be precise and formal.

There is no one size fits all. As shown in Figure 2, different product and project situations influence how you will adapt your documentation plans.

Figure 2: Adapting Your Document for Different Products

Image Source: Discover to Deliver: Agile Product Planning and Analysis, Gottesdiener and Gorman, 2012

The Low Down on Documentation

Documentation boils down to knowledge transfer. Where possible, document in chunks, and deliver just enough to serve the needs of the specific consumer of the documentation. In that way, you maximize the value you create for the effort you invest.

Don’t forget to leave your comments below.

Reference:
Gottesdiener, Ellen and Mary Gorman. Discover to Deliver: Agile Product Planning and Analysis. EBG Consulting, Inc., 2012.

About the Authors:

Ellen Gottesdiener, Founder and Principal of EBG Consulting, is a leader in the collaborative convergence of requirements + product management + project management. Ellen coaches individuals and teams and facilitates discovery and planning workshops. A Certified Professional Facilitator and a Certified Scrum Master, she writes widely and keynotes and presents worldwide. In addition to co-authoring Discover to Deliver: Agile Product Planning and Analysis, Ellen is author of Requirements by Collaboration and The Software Requirements Memory Jogger.

Mary Gorman, a leader in business analysis and requirements, is Vice President of Quality & Delivery at EBG Consulting. Mary coaches product teams and facilitates discovery workshops, and she trains stakeholders in collaborative practices. She speaks and writes on Agile, business analysis, and project management. A Certified Business Analysis Professional™ and Certified Scrum Master, Mary helped develop the IIBA® Business Analysis Body of Knowledge® and certification exam, and the PMI® business analysis role delineation. Mary is co-author of Discover to Deliver: Agile Product Planning and Analysis.