[White Paper] A Perfect Union: BRM and Agile Development and Delivery
Both business relationship management (BRM) professionals and iterative development practitioners are frequently faced with the same question: “Do we really need both BRM and Agile? Can you find a way to tweak your team and have them do both?”
The popular answer is, “Sure, let’s give it a shot!” The realistic answer, however, is “Probably not,” because success looks very different for BRM practices and Agile methodologies.
In the following pages, leading industry professionals present a position that goes beyond loose support for a BRM/Agile pairing, instead asserting that a strategic union of the two capabilities in an organization provides industry-leading results.
In this piece, the term “Agile” refers to all development and delivery methods that have roots in iterative delivery and development and have evolved. Examples include Agile, Scrum, Extreme Programming, Test Driven Development and the like. While prior development models—often known as “waterfall” or “projects”—focus on delivering a final result as a single or tiered event, Agile methods focus on continuous delivery of value to the organization. Agile development and delivery methods are useful as business execution models—an expansion of traditional use in technology departments.
Things that are confusing: teenagers, tax policy, and those times when people from different teams are scheduling appointments to discuss the same or similar topics. “Why do I need to discuss the same things with all these people? If their questions are the same, their work is probably the same—so why do we have people doing the same work?”
This question is common in organizations in which both BRM and Agile teams exist. Because both teams have “face time” with business functions (and because their questions can be somewhat similar), it is easy to see where there might be confusion. In fact, Business Relationship Management Institute (BRM Institute) is frequently contacted with the following types of questions:
- What are the differences between BRM and Agile methods?
- What is Agile Software Development vs. Agile Delivery?
- Can I just have one team do both BRM and Agile?
- If you have good BRM, you do not need Agile methods, and if you have strong iterative development and continuous delivery, BRM is irrelevant—right?
BRM VS. AGILE SOFTWARE DEVELOPMENT: WHAT IS THE BIG DIFFERENCE?
Put simply, business relationship management (BRM) is the practice of shaping and translating executive and business function leadership strategy to a shared roadmap, thus ensuring business value results. On the other hand, Agile development is the practice of translating user needs and anticipating their desires to improve their work (the “how”) to process improvements and delivered software. Lastly, Agile delivery is the practice of translating the needs of a group and its members to process improvements and provide new offerings that result in delivered change to the organization. Agile delivery methods can be used to complete work that does or does not involve technology.
Without diving into intricate details, BRM is measured by the quality of strategy and overall value delivery to a business function. Agile is measured by the speed, accuracy, and quality of value delivered.
A BRM team’s effectiveness is measured by leadership in both the enabling business function (IT, HR, Finance) and respective partner areas. An effective BRM team owns value for investment at the highest levels of business functions and on behalf of executive leaders and investors of the organization.
Alternatively, an Agile team’s effectiveness is commonly measured by managers and those within the impacted value stream. As consumers of delivered changes see boosts to their performance metrics and decreases in operational costs for various value streams, they can see visible ties to incrementally introduced system enhancements and process improvements.
CAN ONE TEAM DO BOTH?
Rarely. Some organizations try, but the logic just is not there.
- BRMs are generally assigned to a line (or lines) of business or to specific value streams such as digital, customer experience, etc.
- Agile teams are typically “stood up” around technology, value streams, work efforts, or groups. Most systems are built around a value stream, which commonly touches several business functions. Agile Delivery teams can be built around a family of common work, a business unit, a cross-functional team, etc.
- With differing logic for BRM team assignment vs. Agile software development team assignment, different stakeholders and varying measurements for success (strategic and value vs. features/functions and delivery), a single team working to do both will struggle to be successful.
WE HAVE GREAT BRM. DO WE NEED AGILE TEAMS?
Strong business relationship management will ensure that your ship is moving in the right direction. When focusing on the direction, however, it is not advisable to leverage the same team to achieve optimum speed.
Why? Most organizations want both: a roadmap to achieve the company vision as well as quick navigation of the map. Successful BRM teams partnered with effective Agile teams will produce the best results.
WE HAVE GREAT AGILE SOFTWARE DEVELOPMENT TEAMS. DO WE NEED BRM?
Strong Agile will ensure that your ship is moving further during each “sprint.” With focus on speed, quality, and delivery of incremental change in the “now,” however, there are no promises that the delivered changes will sync with longterm organizational strategy. The organization risks fast, forward motion—in the wrong direction.
An effective Agile team’s work aligns to company strategy (often a challenge for Product Owners in many organizations). Product Owners correctly focus on successful delivery by their team, but there is a need for focus on the delivery of longer-term roadmaps. BRMs are able to span Agile software development teams to ensure the delivery of roadmaps and blueprints, keeping that work off the executive team and in the hands of value-focused relationship managers.
BOILING IT DOWN
Does an organization need to have BRM and Agile under one roof?
That depends. Do you aim to:
- Ensure that business function strategy can translate into actionable guidance for partner teams?
- Deliver value to system users more quickly?
- Deliver new features and functions in smaller “bites” that are easier for system users to handle? (20-minute trainings vs. the four-day training offsite?)
- Minimize the time required by executives to discuss strategy with partner business functions, as someone is dedicated to that role on their behalf?
- Minimize the time required by organization members to assist in the development and delivery of needed changes, since a team is dedicated to understanding that work?
- Positively impact the bottom line more quickly and frequently?
- Support healthy and effective teams by reducing the number of “hats” they wear?
- Save money on development?
- Make money by delivering what matters?
- Communicate the value achieved by business functions and aggregated across the organization coming out of converged teams through a BRM capability?
If the answer to these questions is, “Yes,” then it may be time for your organization to consider an Agile/business relationship management pairing.
READY TO TAKE THE NEXT STEP?
Interested in building out a BRM/Agile organization, but unsure of where to start?
- Set up a pilot. Choose the most progressive and change-welcoming business function you have.
- Take the time to invest in BRM training, as well as Agile/Scrum training.
- Bring in professionals to help get things rolling.
- Give the business function time to be successful (18-24 months).
- Build relationships outside of the organization to better understand lessons learned and best practices.
- Consider mentoring as a means of providing the business function with necessary support.
IN CLOSING: THE BIG PICTURE
Building a successful organization—the kind that can grow and evolve quickly according to the needs of ever-changing customers, clients, partners, and patients—is complex. The picture of a successful organization redefines itself daily. It has depth. It has a vast array of colors. All the individuals, the teams they form, the processes they complete, and the innovation that stems from them feed into the picture.
The addition of business relationship management and Agile methods like Scrum, XP, etc. alone will not create a successful organization. What these capabilities will add is a greater sense of winning in the foreground—and a greater sense of shared destination in the background.
Agile development and delivery allows for quick wins. The mantra of Agile teams might well be Walt Disney’s quote, “If you can dream it, you can do it.” By cutting work down into manageable pieces and introducing lower-impact changes more frequently, Agile teams convert dreams of process improvements and new features and functions to working reality, quickly and at a lesser cost than in the past.
Business relationship management serves as a compass and sextant for technology, human resources, finance, and other areas of the business. The question, “Where are we going and how will we know we are on track?” teams with, “Did our decisions and investments deliver us to the destination that we imagined?” For business relationship management teams, delivering the dream is achieved with a healthy connection to the organization’s executive leaders. When engagement is high between leaders and BRMs, executive vision translates to strategy in respective business areas.
When business relationship management and Agile teams work together, they provide organizations with the magic combination of strategy and quick value delivery. In today’s competitive world, organizations must step beyond perfect strategy sans frequent wins, or multiple wins that unintentionally pull the organization in the wrong direction. A BRM and Agile organization can provide the best of both worlds and help to deliver the most vibrant picture of success.
Jim Brusnahan is a Corporate IT BRM for global manufacturing and engineering initiatives within Johnson Controls, Inc., a Fortune 100 company. His background focuses on strategic systems thinking, strategic initiative development and deployment, root cause analysis, and program management. Jim has a degree in Materials Engineering and was a 101st Airborne Infantryman in the U.S. Army.
Aaron Monroe is a vice president in the Enterprise Lean Agile group at T. Rowe Price. He leads the Lean Agile Transformation efforts for the Investments and Retirement Planning Services divisions and is also responsible for development of the enterprise-wide Lean Agile methodology. Aaron is a subject matter expert in Lean, Agile, Organizational Agility, Methodology Development, Project Management and Business Relationship Management. Aaron holds B.A. and M.A. degrees in English, an M.S. degree in Project Management, and an MBA in Entrepreneurship and Innovation. He also holds Project Management Professional (PMP), Certified Scrum Master (CSM), and SAFe Program Consultant (SPC) certifications.
Aaron Barnes is an expert business executive with first-hand experience in performing successfully as a strategic business partner, leading BRM teams, and instilling the BRM discipline in organizations. Aaron’s passion for business partnering comes from his years of consulting service in the U.S. and Europe, leading converged business teams, designing strategy, and implementing business systems with a constant focus on delivering business value results. Aaron cofounded and serves as the CEO of Business Relationship Management Institute (BRM Institute).
Starla Borges is an independent consultant with experience in leadership education, change management, and business relationship management. Known as a “creativity builder,” Starla works with select Fortune 1000 companies to identify and evolve creativity potential in different company cultures, bringing imagination to life. Starla holds a B.A. degree in Business and Marketing and an M.S. degree in Strategic Leadership. She is also a Certified Business Relationship Manager (CBRM®).
Leave a Reply
You must be logged in to post a comment.