How BRM Makes Agile Software Development & Management Theory Even More Successful
Agile Software Development Theory
Originally a set of management best practices for software development, Agile is now a worldwide movement that is transforming the ways professionals, teams, and entire organizations operate.
The Agile Manifesto has four core values:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
When applied beyond the realm of software development, this framework can help organizations adapt to change. As the business world has become more complex and volatile, the need for speed, accuracy, and measurable value are more paramount than ever.
There are similarities and differences between the Agile movement and business relationship management (BRM). But when they both work together, they can drive lasting business value.
The Differences Between Agile and BRM
The key difference between Agile and BRM rests in how they deliver business value. Namely, BRM delivers value by translating the executive leadership strategy into a shared strategy that ensures results and innovation across an entire organization. However, success in BRM is not necessarily measured by the speed by which incremental changes are delivered. Instead, success is measured by the overall value delivered.
Conversely, agile translates business strategies into deliverable value through creating small, incremental successes that are fast, accurate, and of high quality. Together, these wins, and understanding thereof, foster continuous team improvement.
The Similarities Between Agile and BRM
The similarities between these two philosophies can be found in their core values and disciplines. For example, the four core BRM disciplines are:
- Demand shaping – optimizing business value
- Exploring – identifying business value initiatives
- Servicing – facilitating business strategy and business capability roadmapping
- Value realization – providing stakeholders with insights into the results of business initiatives
Although BRM and Agile serve different purposes, they are both disciplines for optimizing business value. Whereas Agile delivers value through value creation, BRM delivers value through value identification and realization.
BRM and Agile Work Together for Success
Despite widespread adoption of Agile management and software development, many organizations are still dependent upon bureaucratic organizational structures, at least in some form. Moreover, these types of legacy structures remain inward-focused and maintain a fixed mindset regarding business operations and value optimization.
In surveys conducted by Scrum Alliance, the largest professional certification organization in the Agile community, 80-90 percent of Agile teams said they saw tension between the way the Agile team ran and the way their whole organization ran.
BRM offers a solution to this problem. The focus of BRM is to break down silos and create shared ownership within an entire organization of both strategy and results.
Using Agile
With Agile, organizations can accelerate the delivery of business value and adapt rapidly to changes.
Using BRM
With the creation of the Business Relationship Manager role, organizations can close the gaps between departments in the organization, eliminate silos, and create a shared, long-term roadmap for success.
Learn More About Agile and BRM
Whether your organization is practicing Agile or BRM, you have an opportunity to deliver both short- and long-term business value. Consequently, you can adapt to a rapidly changing business environment by combining and implementing both methodologies.
To learn more about how BRM and Agile can work together, join the global BRM community today. As a professional member, you’ll tap into a network of other BRM professionals, receive access to BRM Institute’s Online Campus, and acquire many other benefits.
Once requirements were complete and development had begun, change was just not something that was easily entertained. Let’s keep in mind that concepts such as Continuous Integration and Configuration Management were unknown and use of source control repositories was not as mainstream as it is now. A change in requirements was just quite difficult to accommodate and was generally frowned upon.