Agile retrospectives: a simple framework

Retrospectives are an important Agile ceremony (and actually they are part of many other disciplines, just think about the project post-mortem analyses) were the team gets together and “looks back on or dealing with past events or situations” with the goal of achieving a continuous improvement.

But they are also one of the most complex ceremony to set up and facilitate and many teams tend to skip them.

One of the most useful framework for a successful retrospective is the one described by Esther Derby and Diana Larsen in their book Agile Retrospective.

Their focus is on short retrospectives, the ones occurring after a sprint, so typically after one to four weeks of work. While continuous builds, automated unit tests and frequent demos are all ways to focus attention on the product, retrospectives focus attention on how the team works and interacts.

The framework is organised in 5 stages:

  • Set the Stage
  • Gather Data
  • Generate Insights
  • Decide what to do
  • Close the retrospective

Continue reading “Agile retrospectives: a simple framework”

Advertisements

What makes an effective team?

Google has always been a data-driven company, not only for its businesses but also for nearly every aspect of its employees’ professional lives.

A few years ago, the project Aristotle was started to assess what it takes to build the perfect team. A dedicated work group of researchers measured many Google’s teams effectiveness using a combination of different qualitative evaluations and quantitative metrics, with the goal of finding the comprehensive definition of team effectiveness.

You can read the story in this New York Times article, here are the results of the project.

A quick summary

The researchers found soon that what really mattered was NOT WHO is on the team, BUT HOW the team worked together. Which makes sense: teams are highly interdependent – team members need one another to get work done.

Continue reading “What makes an effective team?”

Product Owner conversion from other roles

After the Scrum Master role, we look at the Product Owner.

First of all, let’s clarify what is exactly the role of a Product Owner (PO) and how is different / similar to the one of a Product Manager (PdM).
Generally in Agile the PO is intended as the customer proxy for the team: express the work to be done to achieve a goal, order and organise it into a Product Backlog and ensure that is visible and understood by everyone in the team.

This is the definition reported by the Scrum guide:

The Product Owner is the sole person responsible for managing the Product Backlog.

The Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.

Note the emphasis in the last sentence about how this can greatly vary.

Not only every team, every individual, every product, every organisation are different but this definition is based on a single team, where the PO is responsible for the scope (backlog) of that team work; when you scale up and you add more teams, the PO will soon become overloaded and you will need to add more POs, even adding a “hierarchy” of roles (well, more a collaborative network).
See for example the Less framework where you have a Product Owner who ensures a cohesive vision and several Area-POs to manage each individual area in the product.

This complexity exists also in organisations using the classic PM roles: you can have one or more Product Managers (product), one or more Marketing PdMs (market/business) , one or more Business Analysts (BA, functional details) and they are fluid: the three can be one, two or three roles, dependent on the size or complexity of the challenge.

 

Keeping that in mind, let’s see what are the skills and responsibilities of a Product Owner (in broad terms) compared to a Product Manager. Continue reading “Product Owner conversion from other roles”

Scrum Master skills conversion from other roles

The roles of Product Owner (PO) and especially of Scrum Master (SM) can be quite difficult to define when you are first approaching Agile and assigning this position or searching someone for the role.

Notably many companies just tend to copy&paste the descriptions for classic PMs or even re-assigning people with these roles to the new Scrum titles.

Nothing is written in stone and of course every company can tailor its processes but if you are going to use Scrum as a framework to be agile, you need to be aware of the differences and nuances.

Especially converting Project Managers (PjM) to Scrum Masters is filled with problems. They are all different roles, are not even superficially similar and they all require different skills but notably different mindsets; as such any “automatic conversion” will not always work.

Moreover, SM is a role not a job title. A team member of a cross-functional team can have multiple roles, being sometime a developer, some time an architect and a tester and also acting as a SM. Not easy for a classically trained PjM to immerse in such a team.

Agile shift all responsibility from a project manager to a team, in such case many organisations ponder how best they can make their project managers useful enough.

Converting PjM to PO might be easier than PjM to SM, there is more overlap between the former two than between the latter two.
PjM can become PO if they have domain knowledge.

But if an organisation is Agile and still need a PjM with title “Agile PjM” then it is a big question mark on their Agile correct adoption and mindset.

The same reasoning applies to a Business Analyst (BA) or Product Manager (PdM) though that’s an easier transition.
Let’s first have a look at the Scrum Master transition and in the next post at the Product Owner transition. Continue reading “Scrum Master skills conversion from other roles”

Effective military corps are Agile

I never read it but I have been told that the Marine’s Corp “Warfighting” manual  contains several similarities with how Agile projects and teams should be.
If you also don’t feel to read the dense 100+ pages document here is my shorter take, inspired from what I learnt during my mandatory military service time (well, I was not in the Marine’s but still in a rapid response force).

Embrace changes

Traditionally you associate military to huge command-and-control structures but that is not always the case.

Continue reading “Effective military corps are Agile”

Agile for managing a research data team

 

An interesting read: Lessons learned managing a research data science team on the ACMqueue magazine by Kate Matsudaira.

The author described how she managed a data science team in her role as VP engineering at a data mining startup.

When you have a team of people working on hard data science problems, the things that work in traditional software don’t always apply. When you are doing research and experiments, the work can be ambiguous, unpredictable, and the results can be hard to measure.

These are the changes that the team implemented in the process: Continue reading “Agile for managing a research data team”