The Agile Leadership Trio: the 3 pillars of a scrum team • Slash

articles

The Agile Leadership Trio: the 3 pillars of a scrum team

April 15, 2022

In ancient Rome, a group of three notable or powerful people with the most important positions were called Triumvirate, like Julius Cesar, Crassus, and Pompey in 60 BC. Together they ruled the Roman empire.

Likewise, in a scrum team you need a triumvirate of leaders to deliver a scrum project successfully, each serving a key role and looking at the project through their particular specialist lens: 

  1. Product Owner (PO). Role: building the right product.
  2. Iteration Manager (IM) or Scrum Master – we prefer to call it an iteration manager. Role: building the product fast.
  3. Lead Developer (LD) or tech lead. Role: building the product right. 

Whatsapp Image 2022 04 11 At 3.05.28 Pm

Let’s talk about what exactly are PO, IM, and LD, and their respective responsibilities.

Who is Who? PO, IM, and LD

Product Owner (PO) and Its Responsibilities

The Product Owner (PO) is an important pillar of an Agile or Scrum team. The Agile PO is responsible for maximizing the product’s value through the following responsibilities:

Managing Product Backlog

The first and foremost priority of a PO is to manage the backlog of tasks. That means the person is responsible for administering the scope of work that is necessary to be done in a planned duration.

Keeping the Team Informed

Likewise, it is the PO’s responsibility to explain and represent the backlog to the entire team, especially to the Iteration Manager and Lead Developer during print planning and sprint grooming.

Product Clarification and Acceptance Criteria

After the sprint has begun, the PO must assure their availability to provide clarification for any questions or decisions related to the product by any team member. As such, the PO acts as an internal client to the team and a proxy to the actual client or product owner. In the same way, PO needs to communicate with the client the product acceptance criteria which define when a user story [see article on Agile] is considered delivered. 

Allocating the Right Person for the Right Job (Project Resources)

A PO must ensure that the expected project timeline and phases match the sprint and planning. To do that, they must think well about the project resources, which include the composition and strength of the team, as well as the distribution of tasks during the sprint for successful product development, and expectation setting with client if needed.

Iteration Manager (IM) and Its Responsibilities

The Iteration Manager is the second pillar of the Agile team. While a PO is there to enhance the value of the product, the IM internally focuses on the team. The IM is an “impediment manager” who ensures the team is never stuck and the team delivers at a predictable pace (in scrum or agile, we call this velocity), even if the backlog evolves sprint by sprint.

One of the most important roles of the Iteration Manager is to maintain Scrum or Agile practices within the team. Additionally, they are also responsible to facilitate solutions for any problems the team faces in the sprint.

The IM plays an important part when it comes to advocating the team to all the external parties and helping them to achieve the sprint goals. Therefore, IM has to keep up with several responsibilities, such as:

Hosting All Scrum or Agile Ceremonies

Just like the PO is responsible for sprint grooming, IM has the responsibility of sprint planning. That means they have to supervise the team to break down the sprint stories and estimate each story using ‘story points’ as a measure of effort. [see article on Agile].

This helps the IM and the LD to make sure the entire team has understood the expected story. With each sprint cycle, it also helps improve the accuracy level of story estimates.

So how are these estimations done? One popular way is to use the “poker planning” method, where individuals blindly vote on stories and estimate them with the help of story points.

Calling for Regular Stand-Ups

The Iteration Manager calls for regular stand-up meetings so that the teams can share the progress of their assigned tasks and identify any blockers they may have to execute their tasks. These meetings are also important for product development as teams also share their thoughts on choosing the next task to work on. Typically these stand-up meetings are held daily and are kept short (15min).

Sprint Retrospective and Review

The IM is responsible for the sprint retrospective, which means allowing the team to share their feedback about what went well and didn’t go well in the previous sprint, and identify strategies as a team to improve velocity and eliminate performance friction or blockers. 

Likewise, the Iteration Manager is responsible for the sprint review where the team demonstrates the achievements from the previous sprints to the clients, as well as highlights problems, blockers, or gaps.

Lead Developer (LD) and Its Responsibilities

A Lead Developer (LD) combines the ability and skills of a senior software engineer who “has been there and done that”, with the team leadership skills required to resolve technical complexities and consult non-technical roles on engineering topics.

In the case of Slash, we prefer to have POs or IM profiles who come from software development backgrounds. Nonetheless LD typically acts as a bridge between the main engineering team and the rest of the scrum team or client. 

Common responsibilities of LD are:

Technology Assurance and Architecture Runway

A Lead Developer of the Agile project views the product through the lens of what it has to deliver today and what it may have to deliver in the future. Part of that includes considering the architecture runway of a particular engineering solution. 

Hence the LD has to reassure the client that the team is using all the appropriate technologies to develop a product by understanding given the current understanding of the technical requirements and constraints.

Research and Implementation

LDs are responsible for researching and implementing technical stories, as they are the most suitable role in the scrum team to understand technical implications of engineering choices.

Helping Overcome Obstacles

A Lead Developer is always there to guide the development team as they solve technical stories during the product development process.

Engineering Decision Making (They are in charge)

One of the chief roles of a lead developer is to decide what engineering solution should be included or excluded to deliver the product. They are responsible for releasing the application into various environments (from dev to staging to production) so they can see the consequences of the features once the product interacts. 

Dangers of Role-Mixing

Conflict of Interests:

Is it good to mix the roles of each pillar? No, it’s not recommended since it creates potential conflicts of interests for the same person.

Consider the following example:

Suppose, the PO is also the IM of a specific project and the client requests a change to a particular feature of the product mid-sprint. So how will this PO-cum-IM manage? Is he/she going to include this change request in the sprint to satisfy the client while risking the sprint goal?

If yes: the PO impacts the integrity of the IM Sprint and pressures the team to deliver something outside the sprint goals to make the client happy.

If no: the IM ringfences the sprint goal allowing the team to perform their tasks and deliver on the sprint objectives, and the PO is potentially sitting with a displeased client.

Other Common Side Effects of Role Mixing

The tale of consequences doesn’t end with conflict of interests. In fact, there could be many more disadvantages of mixing the roles, such as:

  • Pressure for the team to cut corners on delivery and quality to save time and squeeze in the change request inside the same sprint.
  • Underproductive teams due to the excess of work.
  • Challenge the integrity of the scrum roles to accommodate client.

In short by managing changes ad hoc, the integrity of the process and of every scrum role is put at risk. This can create unintended consequences which will ultimately negatively affect the product and the client. 

How do our scrum teams work at Slash?

At Slash, we know how the Triumvirate works. We understand that all three roles are required to be performed by different persons so that all best-in-class technical standards are applied in order to develop a successful product for our clients. We are well-informed about the benefits of Triumvirate, as it creates a triangle of discussion and balance, allowing each role to check the other to attain our sprint goals.

For certain smaller or ad hoc projects where we have to partner with other companies or where the timeline is very short, we sometimes deviate from the standard scrum process.

Conclusion

Building the right product (PO), building the product right (LD) and building the product fast (IM) are the three cornerstones of any agile software project and the drivers of business value for a client.

Tag Cloud

Agile - Agile Delivery - AI - amazonecommerce - Animal Framework - Attracting talent - Autonomous weapons - B2B - blockchain - businessbuilding - Business building - Clean code - Client consulting - cloud platform - Code Refactoring - coding - Company building - Computer Vision - Corporate startup - cryptocurrencies - de-risking business building - Deepfakes - Deep Learning - DeepMind - derisking business building - Design Research - Developer Path - DevOps - Digital Ownership - ecommerce - entrepreneurs - founder equality - founder equity - front end developer - Fullstack Engineer - Growth strategy - Hook model - Incubator - innovation - Manual Testing - Metaverse - methodology - Mobile Engineer - Natural Language Processing - NFT - NLP - online recruitment - playbooks - Podcast - product versions - project management - Prototyping early-stage ideas - Quantum Computing - Recruitments - Remote Work - Robotics - Sales machine - Self-Driving Cars - Serial entrepreneurs - Slash - Software Development - Software Engineering - teamwork - Tech Talks - tech teams - testing playbook - The Phoenix Project - Unit testing - VB Map podcast - Venture Building - Venture building strategies - Venture Capital - venturecapital - virtual retreat - Web3
This site uses cookies to offer you a better browsing experience. By browsing this website, you agree to our privacy policy.