Author: Angela Wick

The Business Analyst’s Accountability in Scope Creep and Changing Requirements

Written by Angela Wick on August 17, 2015. Posted in Articles. 1 Comment on The Business Analyst’s Accountability in Scope Creep and Changing Requirements

In my classes and consulting work I get the same complaints when I ask teams about the biggest roadblocks in requirements work:

“My stakeholders keep adding features.”
“My stakeholders keep changing the requirements.”
“My stakeholders don’t know what they want.”

BAs, PMs, and even developers point frustrated fingers at stakeholders who constantly add or change requirements, priorities, features, and needs. They quickly cast blame on stakeholders who don’t really know what they want and can’t define and protect the boundaries of the project: the impulsive sponsor, assuming business manager, the indecisive subject matter expert, the ambiguous architect or the distracted CIO.

Who’s the worst offender? Who’s the biggest scope creep on your projects? Well, I am sad to say, it might be you!

No matter if you work on traditional or Agile projects, your role is to facilitate the discovery of requirements, with an approach that assumes your stakeholders do not know what they want or need. Your role is to help them figure that out. Scope creep and requirements changes often come from a lack of discovery and analysis of the originally stated requirements.

If your role includes requirements elicitation and requirements management, you may need to step back and take a long, hard look at your mindset when working with stakeholders. If your stakeholders seem confused, frustrated, indecisive, bored, unavailable, demanding, then you might be the root cause of the scope creep problem!

Do you expect your stakeholders to know their requirements? Do you expect them to know all the details, data, rules, processes, people, and systems impacted? Do you expect them to tell you all of this in an organized manner? Stakeholders have ideas visions, pain points, and needs. It is up to us as BAs to help them express and discover how it all comes together as part of a solution.

BAs and PMs often blame stakeholders for constant changes in scope and requirements when the true fault often lies in the quality of the requirements processes, tasks, and techniques. The quality of how well we elicit and draw out the very details and requirements, the quality of the dialogue and analysis we stimulate in stakeholders, the team, and ourselves later becomes scope creep and change if we do not draw out the requirements that creep up on us later.

In Agile projects, we elicit requirements based on value management principles and priorities rather than scope management. Value management principles are similar in that we need to constantly facilitate what features add the most value to the organization and prioritize the backlog accordingly. Scope management, when done well, also facilitates value management by ensuring we have analyzed and elicited requirements of the most value to the organization. These are often assumed and unstated requirements of our stakeholders.

We need to change our perspective and approach requirements differently. We need to approach requirements as a learning and discovery process. We need to help our teams uncover, discover and model scope. We need to develop and maintain our team’s shared understanding of scope, vision, and priorities throughout the project.

I see two types of scope creep and requirements change:

Something external or internal to the project changes and it impacts the scope and requirements of the project and/or solution
Requirements and scope are discovered as stakeholders and project team members evolve their thoughts and work together to uncover the details and impacts of the solution.

The first one is common to all projects, regardless if they are agile or traditional and we need to be ready for changes. The second type is where we can influence things dramatically as BAs.

How can you do your part to prevent scope creep and create shared understanding?

1. Check in with yourself on mindset: Are you approaching the requirements process expecting your stakeholders to tell you what they want? Or are you approaching it with a mindset that you are a facilitator of discovery? Don’t gather, elicit. There are always exceptions, but most scope creep and requirement changes are due to a “gathering” mentality instead of an “elicitation” mentality.

When a BA “gathers” requirements it implies a passive approach where stakeholders spoon-feed requirements to the BA. This passive approach, which does not include any analysis, leads to many missed requirements and fluctuations in scope.

When we “elicit” requirements, we iteratively extract and analyze stakeholder knowledge. We use probing and high impact questions and interactive elicitation techniques to help stakeholders discover and explore requirements. We use facilitation skills that promote meaningful dialogue and inspire active collaboration. Strategic elicitation minimizes scope creep by helping teams uncover assumptions, risks, and constraints.

2. Customize Your Approach. Do not assume you can use the same techniques for every project! This assumption will eventually lead to scope creep, erratic requirements, rework, defects and failed projects. Instead, be thoughtful in planning the requirements approach for your project. Every project is different. Every stakeholder group is different. Plan your approach based on what you know at the beginning of the project and refine the approach as you go.

Use powerful techniques to engage stakeholders and get them talking about the solution in ways that bring out more impacts, angles, and details. Techniques like collaborative games, prototyping, creative facilitation, and bringing analysis frameworks into facilitated sessions to bring out engaging dialogue.

Use techniques that create a framework for dialog that help stakeholders fill in the pieces that they would not have known to tell you. Techniques like Process Modeling, SIPOC, Business Model Canvas, Business Rules analysis, User Story Mapping, to name a few.

3. Focus on the Why and the Value. One of the best ways to start your scope management process is to help your team define WHY:

What problem is your team trying to solve?
What need are you trying to fulfill?
• What opportunity are you trying to exploit?
• Why are the stated requirements important to the stakeholder?

Once you create a shared understanding of why, then maintain it and use it to focus your stakeholders when defining the value the requirements bring.

4. Find the Gaps. There are always gaps! Why? Well, it’s the nature of project work. You just can’t know everything at the beginning—so keep your eyes open and help your team find the gaps. As a project evolves, gaps appear in many shapes and sizes, so challenge your team to find/uncover/unearth all: stakeholders, dependencies, constraints, assumptions, systems, processes, end users, personas, etc.

Warning: Don’t expect to locate all gaps in one big brainstorming effort at the beginning of the project. We need to approach requirements as a learning and discovery process. The discovery is iterative—it evolves over time. Be sure to systematically analyze, integrate and share each new piece that lands in the puzzle.

5. Draw Pictures. Visual models are often the best way to get conversations started and highlight gaps in shared understanding. Pictures prevent scope creep and missed requirements by providing context for discussions. They illuminate gaps and assumptions in ways that words/text can’t. Pictures also improve engagement and interaction by moving multitasking eyes away from other distractions and devices.

You can create pictures by gathering information from stakeholders one-on-one before a large group session or you can use facilitation techniques that help stakeholder groups create pictures for you. Just present a basic model or informal drawing and let the stakeholders react and learn and then update the model collaboratively.

6. Let people think. You can’t expect to hammer out solid, complete, stable requirements in a single session. Even if the session is a full day or a full week, you will miss requirements and/or you will miscalculate user needs if you do not give yourself and others time to step away and think.

Your team will make better decisions and will be able to more clearly define what they want if they get time to reflect in between elicitation sessions. They will be able to share information with their team, bounce ideas off others, and evaluate ideas in the context of their daily work, rather than being sequestered in a marathon, one-and-done workshop.

This iterative elicit and analyze approach also gives BAs the time they need to evaluate stakeholder input and refine the requirements approach as the project evolves:

7. Expect Change. Here’s the bad news…change happens! Even teams with awesome collaboration, expertise and shared understanding will experience changes in requirements and scope. So, plan for it! Change will be less disruptive if it’s an expected and accepted part of your approach.
BAs need to accept at least partial responsibility for scope creep and requirement changes. The quality of a BA’s elicitation, facilitation, modelling and analysis skills has a significant impact on the project. BAs who strategically engage stakeholders to create meaningful collaboration and shared understanding will experience significantly less scope creep, requirements changes, defects and rework.

Don’t Skip the Analysis When Moving to Shorter Iterations

Written by Angela Wick on July 6, 2015. Posted in Articles.

In most organizations, the days of multi-year, single release, all-or-nothing waterfall projects have come to an end. Instead, teams (agile, waterfall and everything in between) are trending toward smaller, shorter iterations. They hope smaller iterations will reduce cost, shrink time-to-market and improve quality.

Though speed may seem to get better, unfortunately very few organizations see the expected benefits. In fact, increased costs and huge quality issues seem to be the norm for teams transitioning to shorter iterations.

Why aren’t teams finding benefits in shorter iterations? It’s a lack of analysis!

Shorter iterations (agile or not) seem to add time pressure to all components of a project. As teams try to deliver faster, they take shortcuts—thinking analysis is not needed with such small changes. Many teams mistakenly think the iterations are so small that the solution is understandable without the analysis. They try to work faster and in smaller chunks. Analysis gets lost in the shuffle of shorter iterations.

The time pressure of short iterations causes teams to forego analysis on multiple levels:

They don’t want to “waste time” outlining the big picture at the beginning of the project.
They push to solution without understanding user needs and without evaluating multiple options.
As teams “chunk” the project into tiny iterations, they lose track of the relationships between the whole and the parts.
As the “chunks” are defined and developed teams forget how the chunks relate to each other.
Feedback loops between and across iterations do not exist.

When organizations operate without shared understanding of the big picture and the interdependencies between iterations, they miss some really big stuff! Those big misses result in:

grumpy sponsors, users, CEOs, CIOs
a huge overwhelming backlog of defects/enhancements/rework
increased cost
increased time

We still need analysis! We need the big picture! We need to understand relationships, dependencies, upstream, and downstream. We need to analyze, inputs, outputs, data relationships, user goals, exceptions, business rules, scenarios and data flow—even if we’re agile. We need to move the business forward strategically with every release instead of spending our days beating down the backlog like it is a to-do list.

How do organizations shorten iterations successfully?

On a recent flight, I witnessed great analysis in action. A gentleman sitting in front of me had his laptop open in a way that I could clearly see a requirements spreadsheet on his screen. The spreadsheet listed all of his requirements, traced requirements to releases, and traced requirements to user value points/key functions.

He was working hard on this flight! He built and analyzed graphs showing where releases, requirements and value points intersected, and where defects through various testing phases were impacting releases and the key functions of value. He was slicing and dicing all the data and looking back at process flows to analyze the impacts.

I was so impressed! My primary thought was: “Wow, imagine how much better off organizations would be if they could develop and utilize this type of analysis! We used to do this as BAs on larger projects, but it seems to have been lost in smaller iterations.” What was really cool about this guy’s work—I could tell by the number of releases and the release dates that he was working with smaller iterations. Call me a total BA nerd with how I spend “me time” in flight!

So, here are a few things to keep in mind if your team is one of the many struggling with the transition to shorter iterations:

1. Analysis happens in all phases of a project. Agile projects, waterfall projects, big projects, small projects, ALL projects require analysis. Most projects begin with high-level conceptual analysis and gradually dig deeper as the project evolves. The guy on the airplane, for example, was in the middle of a testing phase – which explains the depth of detail.

2. Chunk outside in. When your team starts defining iterations, be an advocate for slicing and dicing based on user needs and value. Every iteration should deliver value to the user. You should not have iterations that deliver databases or interfaces or protocols. You should have iterations that deliver credit card processing, customer account balance reports, and password change notifications.

If your projects are divided into technical components that are not value focused, be an advocate for cross-team analysis with other projects to identify the user value streams and analyze as a team. If you are using an agile approach with user stories, don’t neglect User Story Maps and many of the old-fashioned analysis techniques to help analyze the data, rule, and process dependencies between user stories.

3. Manage change. Projects need enough up-front, big picture analysis to understand how the users and downstream functions are impacted. So many teams have defaulted to processes that chunk work out in tiny non-value added pieces with no traceability to customer value, solutions or downstream impacts. As the project evolves and changes, no one understands who or what will be affected by changes. This lack of analysis causes a TON of rework and defects (some teams calling them “enhancements”).

4. Evaluate your backlog. If you have a giant backlog of defects & enhancements, you probably have an analysis problem. Analyze the backlog! In many cases, the origin of an enhancement/defect is 5 layers back…the original requirement still has not been met after 5 attempts!

You should be able to locate the source of your analysis problem and make adjustments for future projects. Here are a few tips:

Take time to trace the enhancements/defects backwards through your process.
Look at all the items in the backlog and analyze how they are all related.
Group items that impact the same user groups.
Group items related to the same processes.
Analyze the backlog as a whole vs. peeling off each item in isolation.

5. Advocate for analysis time. Our primary goal should always be producing a high-value product for our stakeholders. Sometimes that means we need to educate others about the importance of certain project tasks. Effective analysis minimizes project risk. We need to make time for analysis, or at least do a high-level analysis to show others that more is needed. Use visual models to help others understand why analysis is important. Help the team understand how the right techniques and models make analysis efficient.

6. Analyze while eliciting. Analysis and elicitation go hand in hand. It’s up to us to make sure we are enabling ourselves and stakeholders to analyze requirements as we discuss them. This is done through probing questions, using visual models, and effective facilitation techniques. When we elicit information we must go back and analyze it in order to know what else to ask. Analysis and elicitation are not separate phases, we do them together. For example, we might draw models and pictures while eliciting to get deeper dialog. We analyze as we go, by adding to our visuals and pausing to ask probing questions. We use collaborative elicitation techniques that make our stakeholders pause, think and analyze too.

When it comes down to it, no matter how agile, or how small a release or project is… it still needs proper analysis to get results!

Don’t forget to leave your comments below.

User Stories: You Don’t Have to Be Agile to Use Them!

Written by Angela Wick on June 2, 2015. Posted in Articles. 1 Comment on User Stories: You Don’t Have to Be Agile to Use Them!

In past articles, I’ve spent lots of time asking you to find common ground between waterfall and agile. Not to discount either approach, but in realization, when done well, they have more in common than we often recognize. This call to find bridges between approaches comes from my experience with organizations working hard to manage a melting pot of methodologies, approaches, and leadership mandates. Organizations value adaptability, flexibility, and experimentation while hanging on to patterns that are traditional and comfortable, so teams (and their vendors) include pockets of traditional, hybrid, and agile approaches.

Shifting leader mandates along with a rotation of new tools and templates for each approach, leave many project teams churning in the wake. It’s rare that a team or organization fully implements a new methodology or approach. Instead they just grab bits and pieces—creating a hodgepodge of terms, techniques, and deliverables. Done strategically, a Swiss-Army-Knife approach might not be a bad thing, but without basic standards and principles across an organization, collaboration between teams can become difficult.

So, how do we create consistency and alignment? How do we help teams collaborate without forcing them to modify their methodology or approach? It’s really about communication—using techniques that generate dialogue and create shared understanding.

User stories are one technique that can provide context for great conversations regardless of methodology. They can align waterfall and agile practices a bit more and still leave timing and level of detail up to the approach. User stories are often done poorly, and must be done well to get the results!

Here’s an overview of the primary benefits of user stories for all projects:

User Stories are a “Placeholder for Conversation”

Most agile gurus define user stories as a “placeholder for a conversation” or a “promise of a future conversation.” This user story mindset aligns well with waterfall and agile and everything in between, because meaningful dialogue is the key to project success!

User stories promote meaningful dialogue by:

Providing a great way to organize and prioritize your conversations
Allowing work to begin without getting stuck in the muck of details
Providing a dialogue centered around value to a user
Creating a project parking lot: a simple way to let stakeholders see what is in the queue and reassure them that their needs will be met.

User Stories are the Tip of the Requirements Iceberg

Are user stories just a placeholder or a promise? Or are they requirements? It’s a great debate in some circles, but in my mind it’s clear; user stories provide high-level stakeholder requirements that give context needed to build shared understanding among stakeholders. Once a project team establishes business objectives and goals, they can create user stories to define the tip of the requirements iceberg.

Over time, BAs explore each user story, chipping away the iceberg and diving into the details. User stories help teams organize requirements in functional “chunks,” which simplifies:

The end-to-end slices of value to the user
Decomposition and elaboration
Prioritization of requirements, releases or iterations
Visual modeling
Gap analysis
Analysis of constraints and dependencies
Testing

User stories become a valuable elicitation and analysis technique for all project teams, but the timing, documentation and level of detail can be adjusted to fit in a traditional, agile or hybrid model.

User Stories Focus Outside In

The obvious and most important benefit of user stories is user focus. When a team creates a basic set of user stories at the beginning of a project or iteration, the team’s time and talent tend to focus on the user’s point of view instead of the project team’s point of view. This outside-in focus offers many advantages including:

Clearer Context: The user perspective provides a common language for stakeholder discussions. It allows each stakeholder to understand how and why they will be affected by the project.
Integrated Approach: Many projects get into trouble when they work in silos by function or application (stand-alone systems or components of systems). User stories, written correctly, force an integrated approach because a user perspective ignores artificial project team boundaries. When a user makes an online purchase, they do not see separate applications. They browse items, make a purchase, pay, and receive items. Users do not get value from the web page alone, the product database alone, or the payment processor alone — the user gets value from the integrated experience.
Added Value: Project teams with user-focus deliver more value to users. Why? The outside-in approach establishes a core value that guides decision-making throughout a project. User focus minimizes distractions and complexity when every work product begins and ends with, “How does this bring value to the user?”
Increased Innovation: The basic format of user stories (defining role, task and reason) offers something unique that other techniques rarely include—the WHY! When teams understand user motivations, innovation comes naturally. Teams can quickly brainstorm many new and creative ways to solve the user’s problem.

Maximizing the Benefits

Just like any technique, user stories provide maximum benefit when applied strategically. The project team needs to be conscious of the WHY. Why are we using this technique? What value will it bring? What depth, scope, and timing will bring us the most value with the least amount of work?

Consider the law of diminishing returns. Where should the user story effort fit on this curve?

The answer will vary by project, probably depending on the value of the opportunity or level of risk or consequences of failure:

Do you need a user story for every possible user interaction with the system?
Do you need to include every value gained from the user perspective?
Do you need a user story for every possible type of user?
Is perfection critical? You might need to hit the high point of the curve?
Is budget or time to market critical? You might stay in the range that maximizes your ROI.

Also, remember that user stories are not meant to be comprehensive—they will not lead us to every detail or task required to deliver a work product. Regardless of your project approach, you will need to supplement user stories with additional BA techniques that elicit detailed requirements, acceptance criteria or more dialog.

Don’t forget to leave your comments below.

Why Are We Still Talking About the Role of the BA and PM on Agile Projects?

Written by Angela Wick on May 12, 2015. Posted in Articles.

It seems like we have been talking about this for 10+ years! We probably will continue the discussion for another 10!

Titles cause confusion. As Kupe’s blog talked about last month, confusion still exists regarding the PM and BA roles in general. The industry works hard to clearly define these roles, but the real-life challenges of organizations make perfect alignment to industry role definitions impossible. And, more recently, agile roles have been added to the mix.

As more and more organizations transition to an agile mindset, new roles get added to the mix, causing even more confusion. When I work with emerging agile teams, common title and role-related questions include:

Do agile projects & teams have BAs?
Do PMs become Scrum Masters?
What is the BA’s role on an agile project?
Is the Scrum Master the same as a PM?
Do BAs become Product Owners?
Is the Product Owner a SME or a sponsor?
Is QA part of the agile team or are they separate?

We really need to stop asking these questions! When organizations all define these titles differently to begin with, how can the industry answer this for everyone? We need to stop trying to draw lines from traditional titles to agile titles. It doesn’t work—there is no direct translation—no 1:1 conversion. We get frustrated because this is the mess going on in our minds:

Real people work on agile teams, not titles. What strikes me when I hear the role confusion questions about agile is: Did we have hiring managers searching for Scrum Masters and Product Owners before? No, these are simply new titles that have been popularized by the common agile team member roles.

These may be newer roles or titles for organizations implementing agile, but that does not mean that they are completely new people. So, where have we been getting the real people for these roles? From PMs, BAs, Tech Leads, Solution Architects, Business Managers and Product Managers—people with experience in traditional roles. Many times, their titles are not changing! So, by formal title I can be a Business Manager and play the role of a Product Owner on an agile team. I can be a BA by title and be part of an agile team, where my role depends on what the team needs and what talents I bring to the team.

The same tasks need to be completed on agile and traditional projects, but the timing, format, and accountability changes as well as the definition of “done.” The agile team determines these aspects by applying agile principles to determine what will add the most value to the process and the customer.

As BAs and PMs we always ask our stakeholders “why is something done” and we dread the common “we have always done it that way” response. We need to ask ourselves the same question about our work. Why do we do what we do? Can it or should it be done at a different time, in a different format, at a different level of detail, as a team instead of as individuals, to get even better results?

If we can let go of titles and focus on skills, techniques, and continuous improvement, we can minimize the confusion involved in the transition to agility. Let’s stop asking where the BA or PM fits into agile and start looking at real people who have a mindset needed to collaborate and successfully deliver value to our organizations!

Our mindset needs to shift to something like this:

The same basic skills are required for every software development effort—it’s how and when you apply them that varies. How can you apply agile principles to your organization to inspire innovation and maximize value?

Review the agile manifesto and the agile principles. Don’t ask where the BA fits or how the PM role changes. Focus on building a team with skills that align with agile principles and question how your approach to work aligns with the principles:

How do we promote consistent and continuous teamwork and collaboration?
Are we constantly focusing on value in everything we do?
Are we focusing on dialog and discovery over process and documentation?
How do we encourage people to let go of job descriptions and empower them to jump in and help as needed with a variety of roles and responsibilities?
Do we have team members with facilitation skills that create a sense of shared understanding and make stakeholders feel safe, knowing prototyping, iterations, and collaboration often can replace reams of paper?
Do we have team members who can elicit, identify and communicate requirements?
How do we manage and adapt to change? Do we have team members who are rigid or flexible?
Who are the people in our organization with strong vision?
Which people in our organization can help groups simplify, prioritize and make progress?
Do our team members have the leadership skills needed to self-organize?

This transition to an agile mindset can be difficult for traditional organizations.

Why? Organizations, especially large ones, are defined by their structure. Titles and processes provide the foundation for accountability (job descriptions, hiring, performance evaluation, termination, etc.). So, the real driver of difference here is that agile commands us to think differently about accountability and structure, and how we deliver value. The agile mindset demands:

Flexibility: With a focus on continuous improvement, the roles and responsibilities of agile team members need to change with the needs of the customer, the team, and the business environment.
Equality: Agile principles limit hierarchy and job descriptions. The team rolls up their sleeves and works together providing whatever skills are needed to bring value to the customer.
Continuous Collaboration: To consistently deliver working software in short timeframes, agile team members need to stay focused. Job titles and responsibilities outside of this focus might need to be restructured if they divide the attention of a team member.
Customer Satisfaction: Customers need to be available to consistently collaborate, preferably face-to-face, with the agile team and to review regular releases of working software/products.

The more we try to place accountability on individuals/roles/titles the less agile we really are. This does not mean there is not a role for BAs and PMs on agile teams. Instead, it means we need to rethink how we define role or title. We need to define them by focus, mindset, and objectives, not by documents and individual accountability. Agile is a transformation, at an organizational level, that challenges teams and organizations to think, act, behave and lead differently.

We also need to understand what tasks and processes should remain outside of the core team. Too many organizations try to fit every project task into an agile framework, which often limits their agility. Supporting and overhead tasks like audit, governance, documentation, training, etc … if needed, can be done by a supporting or partner team. This allows the core team to remain focused on product value and delivery.

What do you think? Are titles getting in the way of your organization’s transition to agile? How do you find the right people/skills for your agile teams? Please leave your comments below.

Don’t forget to leave your comments below.

Can You Develop Standards That Embrace Both Agile and Traditional Approaches?

Written by Angela Wick on April 28, 2015. Posted in Articles. 2 Comments on Can You Develop Standards That Embrace Both Agile and Traditional Approaches?

In recent years, we’ve seen even the most conservative, tightly-structured organizations begin to experiment with agile and hybrid approaches. These organizations have a long and comfortable relationship with the traditional waterfall approach, but their curiosity leads them to dabble in agile. Where does this leave their well-defined and well-protected organizational templates, standards, and best practices?

When these traditionally waterfall organizations add agile teams or transition to an agile approach, interesting things happen. I have seen and heard all of the following:

Teams say, “We don’t need templates because we are agile.”
Team leaders say, “We just need a waiver for agile projects to skip the templates.”
PMO Leaders say, “But we need standards and consistency!”
BAs are confused about their role and responsibilities!
Traditional BAs start projects with standard templates and then re-shape details into user stories.
Agile BAs build story maps and user stories with the team and then re-shape details into traditional requirements templates.

The confusion about governance, templates, standards, best practices, roles, etc. turns most agile teams into castaways, isolated from the rest of the organization or PMO like this:

Or they get chucked out in the rain like this:

The move to agile causes everyone to question the importance of standards, templates, and project processes. Are they still relevant? If we don’t use templates, where do we document details? Do we need to document? Can we have the same standards for all project approaches?

I realize some people think the words agile and standards should never be written in the same sentence. Standards may seem completely antithetical to the agile mindset. However, we need to consider the purpose of standards and challenge how they evolved to become so rigid and ill-suited for most projects.

We know that appropriate standards provide many benefits to organizations including:

efficiency, consistency, quality
a common path to shared understanding
shared lessons-learned and best practices
strengthened corporate culture and values
reduced legal and regulatory risks

So, how can we bring agile to the mainland? How can we get agile out of the rain? Many people would assume that agile projects need their own standards:

But why would we build, manage, track and apply two completely different sets of standards for requirements, especially considering it’s rare that modern-day projects align 100% with any one methodology? In fact, most projects exist in some type of limbo-hybrid, where each part of the project team does what makes the most sense, or more commonly, what they perceive as most comfortable. (We’ll save this topic for a future blog!)

Some will question if it’s okay to have a hybrid model. Is that really following agile? Are we getting the benefits if we are not really 100% agile? What is 100% agile? Manifesto, Principles, or following an agile methodology? Can we follow agile principles and uphold standard governance all at the same time? Is there a middle ground where we can leverage the best of multiple approaches while balancing organizational culture, risk, value and pace?

So here’s the challenge: Can we work toward a single set of organizational standards for requirements?

Can we build requirements standards that apply to all projects regardless of methodology? Yes and yes!

If we elevate our standards, we can identify core components for every project. Here are a few suggestions:

Identify universal truths. Elevate your standards by stripping away the details related to methodology and focusing on the purpose and goals of your solution development process. Review your current standards and templates and understand their function and value. What risk do they minimize? What regulatory requirement or corporate policy do they satisfy? Is the policy needed? Consider corporate culture and core values and how your requirement process should support them, accept what the cultural limitations are, and yet push the organization where it can be pushed for positive change. Look at the timing and detail required: question if they matter based on purpose and goals.
Identify universal constraints. Regardless of approach or methodology, every organization operates under at least a few widely accepted constraints. What are your financial, physical, political, cultural, regulatory constraints? Are they real or assumed, temporary or long-term? Use the real, long-term constraints to elevate your standards above the details related to methodology.
Decouple. Standards may not include details related to format and timing. Let go of standard assumptions about when and how tasks need to be completed. Remove standards that require specific deliverable created in a specific format or tool. Also, look at timing and stage gates. Stage gates are typically about a certain document, and perhaps level of detail, at a certain time. Stage gates could be about shared understanding and other attributes of decision making. Challenge what we currently view as the purpose of the stage gates and what is really needed to make good decisions. Good decisions are based on shared goals, shared understanding, and understood risk; they are not based on fear of something not getting done or someone not following through.
Redefine good requirements. Focus on quality, value, and purpose. Any requirements properly decomposed, organized, and elaborated can work. Good requirements communicate the context in terms of users, processes, and data. Standards should not define how and when requirements are written, instead standards should focus on users impacted, user goals, and decomposition of detail. Agile and waterfall requirements seem so different, but good requirements are fundamentally the same regardless of approach and methodology. Teams can deliver good requirements in many formats, and different levels of detail at different times. The more complex the projects and solutions are, the more adaptable we need our requirements process and standards to be.
Share techniques and tools. Don’t put limits on techniques and tools. Don’t categorize them by methodology. Be open to using the appropriate technique or tool needed to meet the needs or address the risks for each project. Story maps and user stories can be used for agile or traditional projects, and process modeling may be needed for both types of projects too. It’s only the timing and format that are different. Many traditional BA techniques (process modeling, scope modeling, etc . . .) need to be used in agile approaches as well. The timing, detail, and collaboration looks different, but the same technique in concept is used.

We use techniques and models in both waterfall and agile projects, but not at the same time or at the same level of detail. Though agile projects might present requirements in the form of sticky notes, whiteboards, a tool, or a SharePoint library of user stories, does that really require a unique set of standards vs. the waterfall word templates? The approaches seem so different, but fundamentally, the standards are the same.

So, what do you think?

Can you envision useful standards that apply regardless of methodology?
Do you think requirement standards are still relevant and important for organizations?
What are the consequences when we allow projects to operate outside of standards?

As always, please share your thoughts in the comments below!

Don’t forget to leave your comments below.