iWorks’ Tips for Successful Agile Communication

By: David Pradko

In a traditional software development approach, such as waterfall, different roles are responsible for different types of information. Developers and database administrators communicate in the technical terms needed to build the system; business analysts convert business rules into logic and workflows; and project managers deal with expectations, risks, and schedules. Everyone might be on the same team but speaking about the project from a different perspective.

Blind men trying to identify an elephant by various parts

The parable of the Blind Men and the Elephant is much older than software development, but it’s a useful metaphor to understand how challenging it is to assign a group of people different parts of a project – describing an elephant – and expect success.

With Agile, and other iterative methodologies, the traditional roles of a team have been replaced with a single role: team member. A team must still collectively possess all the skills needed to complete its work, but the traditional silos and handoffs are eliminated. Agile requires team members to communicate with different types of stakeholders and about the full range of development activities. Because of this, many people introduced to Agile for the first time are suddenly exposed to new perspectives and terms for which they haven’t previously been responsible.

Team members don’t need to become experts in every area of software development. However, the team member and the larger team will benefit from gaining a better understanding of the different types of perspectives that exist across the team. Rather than using traditional software development life cycle (SDLC) roles as the basis for understanding Agile communication, it is more helpful to think about communication that is aligned into three different perspectives: business, management, and technical.

The business perspective is communication about the “why” of the software and trade-offs. It often involves end users and other stakeholders, and it puts the software into the context of how it helps the organization meet its goals and deliver value.

The management perspective is communication around the team – how the team manages its time, its members, and its commitments and priorities for a given sprint or iteration.

The technical perspective is communication about the software itself. It describes the software, how it’s built, and the decisions that go into its design and execution.

Below is a list of common scenarios that team members will have within their team or with the Product Owner. They’re broken down into three categories, Business, Management, and Technical, based on the type of perspective that’s most useful to frame them. There’s also a list of external stakeholders, based on what type of scenarios are most common for them to be involved.

For instance, there will likely be more communication with an end user (Business Perspective) about understanding what roles can execute a business rule. But an end user probably won’t participate in the code review when that business rule has been developed (Technical Perspective).

Business Perspective

  • Defining and quantifying value to end users of a change
  • Knowing business terminology – as well as acronyms and lingo
  • Quantifying and explaining technical limitations to non-technical end users or other stakeholders
  • Asking questions to draw out root causes
  • Converting written or unwritten business rules to code-able logic
  • Modeling business processes

Common Outside Stakeholders:

  • Senior Product Owner
  • End Users
  • User Acceptance Testers

Management Perspective

  • How will a change affect scope? Both the scope of system capabilities and the amount of work that needs to be done
  • Prioritizing (or, more commonly, re-prioritizing) – balancing how much time/money it takes to deliver functionality versus how much value it delivers to end users
  • Resource management – who is available that can do the work, and how long will it take him/her to do it?

Common Outside Stakeholders:

  • Senior Executive Staff
  • Program Managers
  • Senior Product Owner
  • Release Manager
  • Other teams

Technical Perspective

  • Talking about the system from how it operates on the back end; white box instead of black box
  • Deciding on the type of method for implementing a requirement
  • Communicating in pseudo-code or Structured Query Language (SQL) queries
  • Code reviews
  • Design-related discussions
  • Reviewing relational data model, such as the dependencies, primary and foreign keys, etc.
  • Identifying and installing necessary security patches
  • Monitoring system performance
  • Reviewing network architecture diagrams and specifications

Common Outside Stakeholders:

  • Vendor representatives
  • Technical or Architecture Review Board
  • Quality Assurance Audits
  • Release Manager
  • Other teams

A Very Common Scenario

Here is an example of a common scenario in an Agile environment. Following a demo, an end user identifies a problem with the organization’s existing business rules. However, the change impacts functionality the team is currently developing, so it’s not as simple as adding a new story to the backlog. The team then needs to engage stakeholders to confirm what the change is, how high of a priority it is, and also understand how it affects their current work.

Business Perspective: Defining and quantifying value to end users of a change

  • Other stakeholders: end users
  • Questions: Who requested the change? What end users does this affect? What’s the value to the organization of making the change? Do we have the business knowledge we need to make the change?

Management Perspective: How will a change affect scope? Both the scope of system capabilities and the amount of work that needs to be done

  • Other stakeholders: Release Manager, other teams
  • Questions: Are we able to make this change and complete our other commitments? What team members does this affect? Does other work need to be re-prioritized?

Technical Perspective: Deciding on the design for implementing a requirement; identifying dependencies

  • Other stakeholders: Release Manager, other teams
  • Questions: How does our design change to implement the change? Do we have the technical skills to implement the change? Do we need to involve other team members or other teams?

As a practice, Agile requires broader and more varied communication than traditional software development to be effective. Communication with stakeholders, other teams, or even within the team can cover the full spectrum of perspectives and touch on work performed by multiple roles in a traditional SDLC team. Agile teams and its members are most effective when they understand and can contribute to discussions in several of the perspectives explained above.

Resources

Kerner, Lou. “Why Everyone Who Sees The Crypto Light Sees Something Different.” AlleyWatch. September 25, 2020. https://www.alleywatch.com/2019/03/why-everyone-who-sees-the-crypto-light-sees-something-different/.

“The Tower of Babel”. Bukowskis. September 25, 2020. https://www.bukowskis.com/en/auctions/617/445-maurits-cornelis-escher-the-tower-of-babel-turm-von-babel.