Building Stronger Partnerships between Business and IT with Agile

If you’ve ever gotten the sense that a big wall exists between your IT organization and the Business, and you are looking for ways to remove it, then keep reading!

On one side of the wall are your IT developers, gifted technicians – folks that are essential but under-utilized in one very real sense: there is always the possibility that any one of them could come up with a breakthrough idea, but only if they had a better sense of the big picture, the broader business problem their often overly-focused and specialized work would ultimately address. Who better to provide that perspective than the business folks who work on the other side of the wall and would ultimately apply the systems in question?

On the other side of the wall are your business users – similarly operating with limited knowledge of what goes on in the other side. What if these experts in your company’s core competencies had a better sense for the strengths and weaknesses of the available technology? Couldn’t any one of them come up with a creative new take on a vexing problem by adjusting a requirement here or coming up with a business process solution there, if only they understood more about the technical challenges that stand in the way, as only your development team could properly explain?

Often, the wall goes hand in hand with the Waterfall style of project management – requirements are thrown over the wall and months later, the resulting IT work product gets thrown back, often to dissatisfaction, as requirements evolve beyond when they were originally captured.

Bringing the Business and IT Together

There are many ways to penetrate the wall. Getting the business involved in more IT meetings, using active listening techniques during requirements-gathering sessions, providing frequent project reviews and readouts not just to senior management but also to your broader user community, and continuously surveying or otherwise soliciting feedback from those same users are just some of the ways to penetrate the wall.

However, if you’re an Agile shop, you have some powerful tools to work with. And if you’re not Agile yet, this might give you a reason to try it!

In Scrum, the regular cadence of two- or three-week sprints provides ample opportunity for regular business participation, allowing our business partners to contribute meaningfully without having to abandon their day jobs.

Often, the best initial step is to recruit a willing product owner from the Business. Yes, it involves a significant commitment, and the business manager must stand ready to allocate the necessary time. But usually, this is the same business manager who funds your Agile project, and what better insurance policy on those funds than to put one of your trusted lieutenants in such an influential position. When things go well (and odds are that they will, with this critical step having been taken), it’s a win-win for everyone involved.

Why?

For one, the role of product owner is not only highly rewarding for the business partner who is given that role, but when undertaken with enthusiasm, determination and personal empowerment, the product owner role can be seen as one of the most potent drivers of project success.

I can honestly say that a strong product owner from the Business, working side by side with the team, managing the backlog, running sprint planning, retrospectives, and grooming sessions, and actively participating in daily scrums, does more for a positive outcome than just about any other single factor I can think of.  Such product owners are world-class wall busters.

How?

There is this sense among the team that we are all in it together, everyone with a great sense of mission. The product owner champions the project with management, working closely with other business peers, keeping everyone informed of progress, setting expectations, negotiating difficult requirements, representing, and thereby gaining the respect and admiration of the team.

By the same token, the product owner, seeing the team’s day-to-day efforts first hand, acquires an appreciation for the hard work of each team member, creating this virtuous cycle of mutual admiration and respect that naturally contributes to the “whole is greater than the sum of the parts” dynamic that is the hallmark of a high-performance team.

Beyond choosing the right product owner from your user community, you can encourage active business participation in the key sprint meetings:

• Sprint Planning
• Grooming
• Demo
• Sprint Retrospective (or maybe not…I’ll explain below)

Sprint Planning

Typically, sprint planning is attended by the Product Owner, Scrum Master and the scrum team, and is where backlogged user stories are pulled into the upcoming sprint and broken down into workable tasks. It is primarily a prioritization exercise.

Business stakeholders may attend by invitation, but while this is rare in most companies, the more well-informed and enthusiastic stakeholders (for example, power users), should be given the opportunity, if not strongly encouraged, to attend.

These are potentially some of your most effective allies, contributors, and mentors – the source of high-impact user stories that will make your product that much better. These are the people who can best break those often abstract and complex concepts down into concrete terms, teaching things about the business (often the undocumented tribal knowledge stuff) that will only make your team stronger.

Grooming sessions

The most detailed interaction between development and the business occurs during the grooming sessions. When properly managed by a good scrum manager and strong product owner, grooming allows interested parties in the business community – those who will ultimately be your users – to have their voices heard. This is where they can directly interact with your development team to clarify key requirements and negotiate compromises that inevitably must be made to address challenging realities and constraints.

The more people are given a chance to participate in these sometimes difficult negotiations, the greater the likelihood that your product will be eagerly accepted. But keep in mind that the outcome of these clarification and problem-solving sessions is not always a compromise; more often than you’d expect, it’s a wonderfully creative, out-of-the-box solution – the kind that’s only possible when users and developers are given the chance to closely collaborate in their day-to-day work to deliver breakthrough results…wall nowhere to be found!

Demo

One of the most valuable aspects of Scrum is the end-of-sprint Demo, where the development team puts the results of their hard work on display, explaining in business terms where possible, the outcome of the last two or three weeks of work. Ideally, things align nicely with what was introduced in Sprint Planning and refined as part of Grooming.

When those same business stakeholders who participated in planning and grooming attend the demo, they get the progress readout they need and yet another opportunity to become further engaged in the effort, feel a greater sense of ownership and empowerment, and provide constructive, well-informed feedback to further refine the product in subsequent sprints.

Sprint Retrospective

The Sprint Retrospective/Review is a discussion about what worked well during the prior sprint and what needs improvement. It’s a feedback loop to the next sprint to help incorporate any lessons learned. In my opinion, the Retro is optional – much of the feedback is effectively communicated during the scrums, grooming sessions, and especially the demos. But with the more challenging sprints, the Retro can be a valuable channel for honest communication between the team itself and possibly the business as well, although I can definitely see where it may be inappropriate to invite your business partners to these sometimes frank discussions, so use your judgement!

Final Thoughts

The wall between your IT organization and the business community it serves is an unfortunate reality for many companies, but there are things you can do to break it down to transform your shop into a true partner to the business. Agile teams in particular have powerful options at their disposal to make this happen. As with any change of the type described here, some inertia will need to be overcome, but the rewards are well worth the effort.