Skip to main content

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:wick april28 img001

Or they get chucked out in the rain like this:wick april28 img002

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:wick april28 img003

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?wick april28 img004

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.

Comments (2)