Architectural manifesto: Adopting agile development, Part 3

The role of agile stakeholders

In Part 3 of this series, learn about the role of stakeholders in an agile process. This article discusses different types of traditional roles, as well as the types of roles in the agile processes of extreme programming and Scrum.


Mikko Kontio, Partner, Dazid

Mikko Kontio has a background in software development and consulting. Formerly a director with Softera, a software development company focusing on business portals and telecom-billing solutions, Mikko is currently a partner at Dazid.

20 May 2008

Also available in Vietnamese


Part 1 of this series introduced agile processes, the benefits of using them, and the requirements placed on the organization that uses them. Part 2 discussed how different types of organizations, such as start-ups, product companies, and small and large organizations, adapt to agile development.

In this article, I'll discuss the different types of stakeholders in an agile process and what their roles entail. Stakeholders in the Srum process are highlighted.

In software development, a stakeholder is a party who affects, or can be affected by, an organization's actions. The stakeholders are the entities within or outside of an organization that sponsor a project, have an interest in it, or stand to gain from the results of the project. Customers and members of the development organization are all stakeholders.

I'll describe the traditional roles in a software development project, then I'll describe the same in an agile process, such as extreme programming (XP). I'll introduce the basics of Scrum and explain the stakeholders (or roles) in a Scrum project. Finally, I'll compare the team dynamics of the traditional and Scrum processes.

The traditional roles

The traditional software development organization, hereafter called provider, has several roles. In the more detailed processes, there are several roles for all possible tasks and needed knowledge, such as software architect, requirements analyst, software designer, test engineer, and so on. But if you examine all the roles in a more general way, you won't have that many different types.

External customer environment
In an external customer environment, the customer side has business decision makers and technical staff. The provider (software development organization) has sales people, a project manager, and development team members. The actual business problem gets communicated first from the customer's business people to the provider's sales people. Then the sales people communicate it to the development team, which in turn tries to understand the problem so that they can craft a proposal. Typically, the development team and the customer's business people never meet; the business requirements are communicated in documents.

Communication between the two parties can be very complex. The more complex the software problem becomes, the more likely it is that the proposal is not what the customer's business people wanted.
Internal customer environment
In an internal customer environment, the customer side has the business people (or the project managers), and the development organization provides the technical side. On the development team, the project manager is a key role because the project manager communicates with the business people and explains the possibilities. In this situation, the parties are not against each other, but in no way are they particularly working together. They are just working on the same issue.

In both situations, the software architect on the development team has a huge role in translating the business requirements into technical solutions. The success of the project is dependent on how well the software architect has understood the present requirements and the possible future environment of the project.

The traditional processes might seem quite bureaucratic. But for large projects or situations with complex chains of system providers or hardware, they might be the only reasonable processes to use.

Stakeholders in agile processes

Different agile methods have different types of solutions to address the customer-developer relationship. Typically, the roles are simple and there are just a few of them. The customer side is very simple, with the focus on getting access to the people who know the business requirements and can make decisions on the spot, instead of waiting days or weeks.

Extreme programming (XP)

XP involves an onsite customer. One or more people—likely full-time members of the development team—work closely together to give critical information about the business context of the application and make decisions in a timely manner. In Scrum, the decision maker is the product owner whom the development team goes to for critical information.

On the development side , XP focuses on planning, designing, coding, and testing. XP also emphasizes moving people around, so the roles on the team do not remain static. All the developers on the team can and must fill more than one role. Because all production code should be done in pair programming, the roles do mix a lot. Each team member is more or less involved in most of the activities. Nevertheless, there are certain defined roles, in addition to the onsite customer, in XP. The roles are:

ProgrammerThe heart of the XP team
TesterMakes sure the customer knows, and has time to write and choose, the correct functional tests
TrackerKeeps record of the estimated and actual time spent in development so the team learns to estimate more accurately
CoachMakes sure that the process is working
Big bossGives courage and confidence to the team and occasionally insists that the team do what they say they are going to do

The following sections describe Scrum, and the roles of stakeholders in a Scrum process.

Scrum overview

This section provides only a very high-level overview of Scrum. See Resources for more information.

Scrum is an iterative software development process commonly used with agile development. Scrum aims to deliver the highest business value in the shortest time. Because of the short iteration cycles, the business can rapidly and repeatedly inspect working software.

Scrum includes a set of practices that synchronize the project and predefined roles that set rules on who does what in the development process. Each of the iterations, called a sprint, typically lasts between 15 and 30 days. The project is composed of one or more sprints.

Features that get implemented in the sprint come from a product backlog, and the features get picked in the sprint planning meeting. In the meeting, the development team gets to say which of the desired features they think they can implement in the next sprint. During the sprint, the backlog for the sprint is frozen—nobody can change the requirements (unless the sprint is aborted and started again with a new goal).

Stakeholders and roles in Scrum

With Scrum the stakeholders are called "roles." There are three roles: product owner, ScrumMaster, and the team. The roles are quite similar to XP, if only a bit simpler.

Product owner
The product owner represents the interest of everyone with a stake in the project and its outcome. This role provides funding (or is responsible for the funding) during the project's lifetime and creates the initial overall requirements, ROI objectives, and release plans. The list of requirements is the product backlog. The product owner is responsible for prioritizing the product backlog to make sure the most valuable features are built first.
The ScrumMaster is responsible for the Scrum process, making sure everyone in the team knows Scrum, and making sure that Scrum is implemented in a way that best fits the organization. The role is also responsible for assuring that everyone follows Scrum rules and practices.

The ScrumMaster removes any obstacles the team might have and makes sure the business-related questions reach the product owner. And the ScrumMaster helps the product owner build and prioritize the product backlog.
The team is responsible for developing functions to implement the features. Teams are self-organizing, self-managing, and cross-functional. Team members are responsible for turning requirements in the sprint backlog into working software.

The team members are all responsible for delivering the results. There are not specific architects, test managers, programmers, and so on. The team should have a good mix of experienced, talented professionals who have knowledge of all the tasks. The team itself manages the tasks and decides who does what, and when.

At another level, there are two groups of people in Scrum: those involved in the project (chickens), and those who just have an interest in the project or the outcome (pigs). The animal names are from an old joke that's often told while describing Scrum, and it illustrates the groups well:

A chicken and a pig are walking down the road. The chicken asks "Do you want to open a restaurant with me?" The pig thinks about it for a moment and replies, "Yes, I think I'd like that. What do you want to call it?" The chicken replies, "Ham and Eggs!" The pig stops, thinks for a moment again and says, "I don't think I want to open a restaurant with you. I'd be committed and you'd only be involved."

In Scrum, the people who are committed (the pigs) to the project are the team members, the ScrumMaster, and the product owner. These people have agreed on the features they will build in that sprint, and they are accountable for the results. The others (such as managers, vendors, users) are chickens who might have an interest in the project, the outcome, and the ROI—but who are not accountable.

The daily Scrum meeting is an important part of the sprint. Everybody is welcome, being late is often punished, and only the committed (ScrumMaster, team members, and product owner) are allowed to speak. Chickens can come and listen, but they are not allowed to participate. The meeting is short. The ScrumMaster asks each team member three questions:

  • What did you do yesterday?
  • What will you do today?
  • Is there anything in your way?

The daily Scrum meeting is not to solve or discuss issues in detail. Team members may agree to hold a meeting later to deal with issues. Notice that the questions don't necessarily provide status for the ScrumMaster. Rather, they are commitments to the other team members.


In this article, you learned about roles and stakeholders in agile development processes. The roles are much simpler than in other, more traditional processes. Traditional processes are typically more complex, and they focus on identifying all the different roles in the development project. With large projects that might work well—if you have one or more full-time people for each role. Even though traditional processes might seem quite bureaucratic, sometimes they might be the only reasonable processes to use.

On smaller projects with less than 20 people, simpler methods are possible, and they can make managing the development process easier and more efficient.

Roles in agile processes are much simpler, and teams are cross-functional. In Scrum there are only three roles (product owner, ScrumMaster, and the team), which makes working by the Scrum rules and practices quite simple. The teams are self-organizing, and team members can pick up the tasks they want to work on, so the traditional project management task of keeping an eye on the developers is minimized.



  • Check out the other parts of this series on adopting agile development:
    • Part 1, "Is agile development right for your organization?" (developerWorks, Mar 2008)
    • Part 2, "Understanding the different facets" (developerWorks, Apr 2008)
  • "An Introduction to Agile Methods" (David Cohen, Mikael Lindvall, Patricia Costa, 2004) discusses what it means to be agile, the role of management, the more popular agile methods, and guidelines for deciding where an agile approach is applicable.
  • Read Wikipedia's discussion on agile software development.
  • Learn about Scrum, an agile process that can be used to manage and control complex software and product development using iterative, incremental practices.
  • "Why Fixed Bids Are Bad for Clients" (ScrumAlliance, Sep 2007) discusses agile projects and fixed price bids.
  • "OpenUP In a Nutshell" (developerWorks, Sep 2007) explores OpenUP, a recently developed process framework for software development that focuses on agile practices derived from the Rational Unified Process®.
  • Read "Effective agile delivery toward globalization" (developerWorks, Oct 2007) if you have overseas markets that require considerable planning in the development lifecycle to accommodate cultural and language differences.
  • developerWorks Interviews: Scott Ambler on agile development (developerWorks, Apr 2007) explains this iterative and incremental approach to development, lays out the business case for it, and dispels some myths in the process.
  • Make use of IBM on demand demos to learn about various software products and technologies from IBM.
  • Stay current with developerWorks Live! webcasts.
  • Check out developerWorks Live! technical events and briefings.

Get products and technologies

  • Download IBM product evaluation versions and get your hands on application development tools and middleware products from IBM® DB2®, Lotus®, Rational®, Tivoli®, and WebSphere®.



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into Rational software on developerWorks

ArticleTitle=Architectural manifesto: Adopting agile development, Part 3