The relationship between IT and Business teams has rarely been heralded as a model for organizations to follow. The relationship is typically strained with IT being too slow to respond, expecting business teams to “define ALL of their requirements upfront” and long lead times before a product can even launch.

Business teams struggled with understanding their role in a software project while trying to sort through all the technical jargon used to build a website. Add external consultants promising to do the job faster in an environment they don’t control and internal security and PMOs adding their processes, it isn’t a wonder the Business-IT relationship is challenged.

Given these challenges, how does applying Agile practices improve the relationship? IT and business teams speak entirely different languages and the recommendation is to introduce terms like scrum, product owner, sprints, backlog, user stories and story points?

Yep.

Adopting Agile practices introduces new terms and new ways to work as a team. As a result, the relationship is improved and trust is developed through frequent and demonstrable results. Below are two examples from past projects.

Example #1 : Failing to Deliver

The global marketing team had spent the past 18 months working with product, engineering and supply chain teams to develop a “best in class” website for online ordering, integration with ERP systems and marketing and sales functions. The project followed a waterfall methodology with 25-page documents describing each major feature and required scope.

The project scope continued to grow and the 18-month project became a 24-month project riddled with software defects. In order to make the mandated launch date, the team cut scope and launched a solution that only met the online ordering need.

Even though the project was outsourced to a 3rd party vendor, the business teams blamed IT for failing to deliver. Marketing was frustrated that none of the customer relationship management or marketing features were included in the launch. IT leadership changed and the software vendor ramped down their outsourced army of developers. The business was left with half developed features that no one really wanted.

Second Chance

With the following year’s budget cycle, additional funding was provided and a new business and IT team applied an Agile approach to add new features to meet marketing’s needs. The team included the business acting as a product owner, internal IT managing the project and a 3rd party development team who had expertise in Agile delivery. It took several sprints to establish a rhythm but the Agile process provided the transparency, demonstrated working software and provided flexibility for the business to change requirements.

Previously, the business team defended their position that they “provided all the requirements 9 months ago” and were quick to criticize. Using the Agile processes with a 2-week sprint, the business shifted to being more collaborative as their requirements evolved and changes were implemented. The key differentiators that improved the relationship included:

1. Transparency – All team members understood the work in progress and each product’s status
2. Metrics – Adopting user stories allowed the team to track individual features across sprints and software releases
3. Demonstrate working software – The team saw working software every two weeks instead of 25-page documents promising features in the future
4. Embracing change – The team had the flexibility to re-prioritize the work and the product owner knew they could get what they want in 2-week chunks

The end result was a successful project delivering features the business wanted while improving the trust and collaboration between the two teams.

Example #2: Struggling Software Project

This example occurred in a different company, yet shared the familiar story of a complex struggling software project. Project teams attempted rolling planning every quarter only to have the launch date continue to move with each quarter.

Teams tried the Big Design Up Front approach with management expecting the teams should know all the requirements after spending the past 12 months in analysis.

The core application team struggled with delivery as half the team worked off-shore and only had six overlapping hours of collaboration. The application team had a project schedule yet the project manager and the development team were not aligned on task status. The business was also frustrated and doubted the team’s competency and ability to deliver.   

Adding Agile

 A new project consultant joined the team and reintroduced the good Agile practices with a daily standup, prioritizing the product backlog and implementing in 2-week sprints. The project team collaboration with developers and the business improved due to: 

1. Reviewing the sprint board in the daily stand up
2. Holding team members accountable to their user stories in the sprint and in the daily stand up
3. Providing transparency, accountability and communication to the team
4. Confidence in the team increased by sharing burn down charts and demonstrating working software at the end of each sprint.

The end result was the project improved through the daily and bi-weekly feedback loops. Working with an offshore team presents time and communication challenges, but the Agile process improved the way the team worked to deliver the release.

The project manager still tracked the major features, sprints and releases in a project schedule, but the Agile process helped improve the team communication. Previously, the business had no visibility into the team’s progress and with Agile, the business had more transparency into the day to day activities.

Remember Agile Isn’t a Cure-All

Keep in mind incorporating Agile practices with your business partner and a delivery organization isn’t a magic cure-all or a silver bullet for project challenges. In the example above, the marketing customer was pleased with the result.

However, the executive marketing stakeholder was frustrated the team didn’t deliver everything. I was on a phone call when the leadership team expected a large feature to be delivered and it was the first time I had heard about it.

Agile won’t fix stakeholder management and properly managing expectations. You still need to ensure stakeholders at the project, management and executive level are all aligned on the product direction. If you start adopting more frequent feedback and demonstrating frequent delivery, the business relationships will improve!