Connexion
Connexion

Galerie de cartes mentales Professional Agile Leadership(PAL)

Professional Agile Leadership(PAL)

Dans l'environnement commercial en évolution rapide d'aujourd'hui, le leadership Agile professionnel (PAL) est de plus en plus important. Pourquoi devrions - nous être agiles? Parce que l'agilité signifie diriger l'action vers la livraison du produit de travail, créant ainsi un maximum de valeur pour les parties prenantes. Cela exige que nous abandonnions les modèles rigides traditionnels et que la livraison de valeur soit au cœur de notre travail. Être agile, c’est aussi être conscient qu’il n’y a pas de plan parfait pour construire les choses, que les marchés et les circonstances changent à tout moment et qu’il faut donc être capable de réagir rapidement aux changements. Dans un environnement agile, le rôle du manager est profondément transformé et se distingue nettement des managers traditionnels. Les managers traditionnels se concentrent davantage sur la planification et le contrôle, tandis que les managers agiles se concentrent davantage sur le guidage et l'autonomisation, en stimulant la motivation et la créativité des membres de l'équipe, en poussant l'équipe à réagir de manière flexible dans un environnement en constante évolution, en veillant à ce que les projets progressent efficacement dans la direction de la création de valeur, en itérant et en optimisant constamment pour permettre la croissance conjointe de l'Organisation et des individus.

Modifié à 2021-08-16 17:56:58

Scrummer Senschool

Œuvres récentes Afficher plus d'œuvres>>

Professional Agile Leadership(PAL)

Scrummer Senschool

Œuvres récentes Afficher plus d'œuvres>>

Recommandé pour vous
Contour

MULTIMODALITES
- 16
veronique.brlls@gmail.com
Gesteentses
- 9
Josephine
Positive Impact missions domains
- 8
Eric-Jean Pankowski
formation professionnelle
- 9
fatimazohrachaouki14@gmail.com
Qualiopi
- 12
SystOrga
ERP Launching Schedule
- 11
Julien de LAUZUN
Modernisation DB2 : BGEN
- 10
Pisope
Ma gestion du stress
- 13
ninadeluigi@gmail.com
SA touristique
- 9
Pierre-Yves Debons
L’entreprise et l’administration fiscale
- 11
Solène Boff

Professional Agile Leadership(PAL)

Why should we be agile ?

Agile means directing your actions toward generating maximum value for your stakeholders by delivering working products.

requires close collaboration with those stakeholders throughout the process of product development.

Agile furthermore means acknowledging that a perfect plan to build something cannot exist, and thus, it must be possible to quickly react to changes.

requires feedback to be gathered frequently and inspection and adaptation of all aspects of the development to be possible.

deliver products frequently to our customers and other stakeholders,

deliver value to them.

value is actualized only once the product is released to the user and leads to an improved outcome for them,

gather feedback on the product(every time we have a new version of the product)

present to the customer and release to the user,

evaluate its performance,

get inputs for further development and evaluate the next steps to take.

allows us to better understand the stakeholders needs and develop even more value for them.

incremental development

each increment that is delivered to the user in an agile approach has to be usable,

Each delivery offers the chance to inspect and adapt.

Traditional development approaches such as that of waterfall development

Budget

Schedule

Scope

A project under this schema is considered successful if all of these parameters remained within the defined boundaries.

All these parameters, however, say little about the value generated by the product that was developed this way.

An agile approach defines the creation of value as the highest priority.

The traditional factors of scope, budget, and time are negotiable and frequently revisited in an agile approach..

Rather than committing to fixed goals, agile development has the flexibility to frequently inspect and adapt its results, determine if what they are doing is generating value by satisfying customers, users, and other stakeholders, and planning their next steps accordingly.

A common misconception is that agile approaches lead to an increase in development speed.

While it is true that in many cases, practices associated with agile development, such as self-management of teams and frequent inspection and adaptation of development processes via retrospectives, may lead to an increase in speed, this is not guaranteed.

the priority is value generation.

A slow development generating high value is better than a fast development generating low value.

Agile development requires not only agile developers but an entire organization’s gradual shift towards agility.

In pursuit of a more agile organization, many roles will need to change over time, perhaps most significantly that of leadership.

Managers in Agile Environments

Traditional vs Agile Manager

A wide-spread misconception about agile environments is that they fully eliminate the role of managers.

there is no major case in which large-scale institutions exist without people in management roles

In most traditional environments, a manager is managing people and their work. .

Lead to

Long chains of command

turn lowers the ability to react to change rapidly in pursuit of value delivery,

The longer the chain, the larger the delay and the longer the reaction time..

Lowers the organization's agility

Scrum addresses this problem of large hierarchies by placing the decision-making power over most aspects within the Scrum Team.

When a problem occurs, the Scrum Team should, in most cases, be able to resolve it on its own.

They should be structured and empowered to have this capability..

a Scrum Team does not only conduct development work, but also holds a certain level of management responsibilities, which Scrum refers to as self-management.

Scrum Teams create their own Product Backlogs, Sprint Backlog, measure their own progress within Sprints, and work to improve their own processes through Sprint Retrospectives.

With many decisions being made by the team and no longer by a manager, the role of the manager changes.

Managing people -> micro-management

manager in an agile environment takes on different responsibilities -> more modern way of leadership.

An agile manager is primarily concerned with supporting the teams they are responsible for.

Leading througth shared goals

Every organization and every product should have a vision it strives to fulfill.

Broad visions can and must be broken down into realizable goals..

Agile Leadership means driving the process of turning common visions into common goals and leading people in this way

Developing people

Agile Leadership means taking an active stake in one’s own development and that of others.

Removing impediments and empowering individuals and teams

Even great self-managing Scrum Teams will face issues that exceed their self-management abilities

These are the points where Agile Leaders step up and support the teams by empowering them and removing the issues that are stopping them from succeeding

Agile Leadership is not a position but rather an attitude

can be held by managers, as well as Developers, Scrum Masters, Product Owners or any other person in an agile environment.

managers must use their special position within their organization, i.e., the empowerment that they have been given, to empower those they are responsible for.

None of these actions are necessarily unique to managers

Agile Managers and Scrum Teams

The Scrum Guide defines Scrum Teams as self-managing. This requires a mindset shift from conventional management

“true leadership”

shift from (micro-)managing the individual members of the teams towards leading teams through support.

dramatic implications on the interactions between managers and the Scrum Teams they are responsible for.

The biggest conflict most people from non-agile backgrounds imagine is that between managers and the Product Owner..

While it is possible that the role of a Product Owner is fulfilled by somebody with a formal management position, this is neither common nor recommendable.

Manager: direction teams top-down

PO: providing a direction

Product Owner role being a non-managerial one in the conventional sense

Mythe: managers above the Product Owner in the corporate hierarchy may give orders to the Product Owner regarding the direction of their product.

The Scrum Guide makes it clear that for a Product Owner to be successful, everybody in the organization must respect their decisions.

The Product Owner is the person who is most knowledgeable on the product and is hence defined as the one to be accountable for its value increasing.

A manager may, of course, appeal to the Product Owner, as any other stakeholder may do and try to affect changes to the Product Backlog.

Should support the decisions made by the Product Owner, even if they are contrary to the manager’s own beliefs.

Agile Leadership in this regard means trusting and supporting somebody, even if one does not agree with the decision

A classic anti-pattern in environments whose management has not yet truly embraced agility is lobbying through management.

Not rarely does this person approach the Product Owner’s manager and try to force their desired changes into the Product Backlog through the manager. In situations like this, it is crucial for Agile Leaders to stand firm and reject such requests.

The Product Owner makes their decisions based upon what they know, so the more they know, the better decisions they will likely make

it is the responsibility of an Agile Leader to ensure that a Product Owner has as much relevant information as possible.

providing them relevant internal data

ensuring direct access to important stakeholders

A key difference resulting from the changing relationship between managers and their teams is how managers in agile environments keep track of what and how their teams are doing

while managers should be informed about what and how their teams are doing, the intention is different.

Decisions about individual actions are to be made by the teams, not the managers, and therefore an agile manager doesn’t need to concern themselves with them in most cases.

Similar to how managers, especially ones who have not strongly embraced agility yet, do not necessarily make good Product Owners, they also don’t necessarily make good Scrum Masters either.

While both Scrum Master and manager are leadership positions in their own way, the skills and approach required are very different

An agile manager is interested in outputs and outcomes, rather than individual actions.

Agile Scrum Teams

In an agile environment that decides to embrace Scrum, the heart of value generation lies in the Scrum Teams.

Supporting and empowering them is the best way for leaders to support the creation of products with increased value

key characteristics that set a Scrum Team apart from most conventional teams

Scrum Teams can vary widely depending on the context.

Scrum Teams vary as widely as the uses of Scrum.

All Scrum Teams, however, share four characteristics in common:

Cross-functional

team has all the skills necessary to deliver value in a Sprint.

Each Scrum Team should act as flexibly as possible to allow for rapid inspection and adaptation and, consequently, better value creation.

there should be as few dependencies on people outside of the team as possible.

Often, the field of expertise that needs to be covered by the Scrum Team is quite large

Scrum Teams approach this challenge differently.

Members of the Scrum Team are expected to step out of their comfort zones and embrace learning new skills, both from outside sources and especially from each other.

Rather than having extreme individual specializations, everybody on the team ideally has a broad skill set.

Agile Leaders can support the members of Scrum Teams by creating conditions that allow for new learning,

Agile Leaders can work towards creating a culture that embraces learning and in which teams feel safe to make mistakes while learning

Self-managing

team manages its work on its own,

“they internally decide who does what, when, and how”.

The Product Owner decides on the direction of the development, determining what is currently best suited to create value.

The Developers self-organize around the work, creating a plan on how work is best to be accomplished.

The Scrum Master supports the Scrum Team by facilitating, coaching and working to remove impediments

For most of the daily business, the Scrum Teams work autonomously without the need for managers.

The Scrum Team together decides how to conduct the work and is responsible for the outcome of their work.

changes the role of the manager to deal with larger issues, such as helping to remove impediments, develop organizational visions, creating a corporate culture, etc.

Lack internal hierarchies or sub-teams

closely to Scrum’s understanding of self-management..

Self-management in Scrum does not mean that one person on the team manages the whole team, and therefore, the team is managed.

The team is also not broken down into smaller sub-teams, each only responsible for a subset of the work.

all members of a Scrum Team are equal, and all of them share the responsibility for all of the outputs and outcomes they generate

requires a strong level of commitment from all members of the team.

This notion of hierarchy- and sub-team-free self-organization reflects the agile idea of value generation

If a team fails to deliver a product, value is not delivered.

What the customer cares about is value

to focus on value delivery, all members share the responsibility for the work as they are all collectively responsible for the outcome.

Scrum Teams differentiate between “accountabilities”("roles")

One person needs to fulfill the accountabilities of the Product Owner, one those of the Scrum Master.

Multiple people need to fulfill the accountabilities of Developers.

The Product Owner does not “manage” the Developers,

the Scrum Master doesn’t “manage” the team

These roles merely ensure that all the necessary things needed within a self-organizing Scrum Team are covered.

The lack of hierarchies, especially among the Developers, necessitates new ways of working

In Scrum, the Developers need to resolve such conflicts internally, which they can do empirically

If multiple ways of solving problems are available, rather than having lengthy arguments about which one to choose, the Developers should run small experiments, evaluate the outcomes and then follow the data.

Supporting this mindset and helping provide the necessary infrastructure to easily run experiments are things that an Agile Leader can do to support Scrum Teams

Small Scrum Teams

provide the benefit of having easier communication and greater flexibility.

makes decision-making processes faster and, therefore, inspection and adaptation more efficient and effective.

The team needs to self-manage to find a proper balance between being small enough to remain flexible and large enough to remain cross-functional

If the team determines it has grown too large, it should consider splitting into two teams working on the same product

An Agile Leader can help their team by supporting the decision and defending it towards others in the organization.

Often underestimated are the aspects of focused work and teamwork.

In organizations that measure actions rather than outputs, managers may keep track of how many hours in the day a single worker is busy working on some project.

Context switches

lower the individual’s and therefore the team’s ability to focus and create value.

+1 project -> losing around 20% of their effectiveness

The ideal set-up for a Scrum Team is one in which all members can focus on one product development in one team

An Agile Leader can support this by working with the team to ensure that as many external disturbances as possible, such as support and maintenance requests or staffing requests from other teams, are minimized

Many conventional organizations also underestimate the benefits that teamwork can bring along, instead expecting the combined output to be merely the sum of the individual skills.

The lack of direct face-to-face communication as well as difficulties associated with vastly different time zones make teamwork, knowledge sharing, and empirical process control less effective and less efficient

The ideal set-up for a Scrum Team is one in which the members are co-located.

members should at least be located in similar time zones and visit each other frequently, despite the costs this may entail.

once a team is created, it should be as long-lived as possible.

If changes to the staffing are needed, they should take place, but it must be kept in mind that each such change temporarily reduces the ability to deliver value and introduces new risks.

this is particularly true for Developers, somewhat less so for Scrum Masters and Product Owners

The Product Owner

Value maximizer

Value optimizer

it is their task to understand what would likely increase the value of the product they are responsible for

work with different parties inside and outside of their own organization to create this value.

The role of the Product Owner differs greatly from that of a project manager in a non-agile environment.

Unlike a project manager, a Product Owner is not in charge of the Developers they work with

The Product Owner is a fellow, peer team member, on eye level with the Developers.

The distinction between Developers and Product Owner is one of different accountabilities and different specializations, but not of different relative levels in a hierarchy.

The key tool of the Product Owner is the Product Backlog.

the only source from which the Developers pull their work into their Sprints.

make the current priorities in the product development transparent to those that see it

Product Owner may delegate some activities of Product Backlog management to others,

ultimately the ones accountable

for the PB

the value delivered by the product

All work conducted by the Product Owner can be understood as revolving around the Product Backlog:

New requirements are gathered from stakeholders and placed in the Product Backlog.

As more is learned, the priorities of the development effort may change, which is reflected in the Product Backlog’s order, which may change as often as necessary.

The Developers need to understand the items in the Product Backlog to be able to implement them, thus a Product Owner refines the Product Backlog with the Developers.

With a new Sprint starting, the Product Owner collaborates with the Developers to create a Sprint Backlog, with items from the Product Backlog, that should deliver the highest value possible.

key benefit of a well-maintained and transparent Product Backlog

It acts as an understandable source of requirements for the Developers, replacing lengthy requirement documents in non-agile environments.

It displays the current priorities to external stakeholders, helping them to understand the direction the product development will go into in the near future.

It displays the current plans to internal stakeholders, such as the management, helping them to understand the current state of the product and removing the need for extensive status reporting normally found in non-agile environments

Different approach: The specific actions of an individual Product Owner differ greatly between cases.

Product Ownership at its core is not about specific methodologies but about an understanding and application of empirical product management to maximize value.

Product development usually deals with complex problems, meaning problems where the causality between a specific action and its subsequent reaction cannot be known beforehand.

empirical approach is necessary.

An empirical approach means that we base our actions on what we know from experience..

market conditions may change, customer requirements may change, our original predictions about the development speed or the value specific features deliver may turn out to be wrong. It is therefore better to take small steps, gather feedback often, and incorporate that feedback into the next steps.

This approach is not only limited to the reactions of customers towards a product, but virtually every aspect of product development.

experiments can be used by Developers to determine what will likely be the best way of implementing a new feature.

As the one ultimately making the decisions on the direction of the product, they need. to use experiments to learn about the customers and the market.

may be a valid idea to spend a limited time and budget on an experiment, the outcome of which will determine the further steps.

A consequence of an empirical approach is that the conventional understanding of predictions cannot be maintained

As a Product Owner it is thus important to understand and communicate to stakeholders that in a complex environment, predictions are (only) predictions and may change over time.

It is either possible to aim for on-time, in-scope and within-budget, or it is possible to deliver the highest possible value. It is usually not possible to have both. And agile development efforts simply choose the latter over the former.

In an agile development, we acknowledge from the start that deadlines are merely forecasts rather than 100% reliable predictions.

An agile approach to product development aims to maximize the value delivered to users and customers.

Metrics

Common Traditional Measurements

In a traditional approach, a starting point and a finish point are defined.

the path from start to finish is also defined before the work has begun..

success is understood as the progress toward the final state over time.

Velocity of the team

People outside of the team using velocity as a metric to evaluate a team is problematic, as Story Points are not a measurement of what an agile environment aims for: value delivery

If the primary goal of developing a product is to deliver value – which is axiomatic for an agile development effort – then using velocity or similar metrics to evaluate teams’ performances is not appropriate.

There are, however, legitimate uses of velocity

Utilization rate

i.e., how much time a specific person or team is busy, is questionable in an agile environment.

In a traditional understanding, time spent on a project is directly correlated with output

Measuring a person’s or a team’s utilization rate is ultimately meaningless if the goal is value delivery.

Metrics can be used to compare two different things.

different teams to each other

Comparing teams to each other is often used to assess whether a team is performing sufficiently or whether more pressure needs to be added to the team that is supposedly underperforming.

While from a short-term managerial perspective, this might make sense, the unintended consequences can be very problematic

Comparing teams may lead to rivalries at best and conspiracies at worst.

least productive team:

Increasingly frustrated

decrease motivation

increases internal conflicts

undetermines the formation of a real team

In the long run: cripples the team's ability to deliver value

maximize its performance in the metrics.

If lines of code are measured, they write unnecessarily long and unreadable code.

If features delivered are measured, little attention is paid to code quality and technical debt

most productive team

sympathizes with their colleagues

A gradually decreases their own performance until both teams meet at an equal level.

comparing teams with each other is often problematic

An Agile Leader should instead acknowledge that any team is likely doing the best it can.

Instead of comparing the team to another, the Agile Leader should support the team by removing impediments that limit the performance of the team.

different individuals to each other

Agile Leaders should abstain from measuring the individual performances of team members.

If internal performance differences need to be evaluated at all, this should be done by the team itself and not an outside manager.

allow us to observe changes over time.

Agile Metrics

metrics can have adverse effects if they measure things that are not directly relevant to the mission of delivering value

Value in the agile sense is primarily defined by the users and customers.

User

is understood as the person or persons using the product,.

Customer

is the person, persons or entity paying for the product.

These two may be the same

A Product Owner attempts to gain a good understanding of what would lead to an increase in value of the product, but ultimately, value is determined by the satisfaction of users and customers.

As value correlates strongly with the satisfaction of both users and customers, a valuable metric is the user and/or customer satisfaction over time.

Low

indicates the need to improve it

High

indicates that things are going well and that that high level is maintained

This metric falls into the category of metrics that define the Current Value (UV in EBM framework)

this metric's category includes among others

employee happiness trends

Revenue per employee

A product cannot deliver infinite value

Metric: Unrealized Value(UV)

Market share

user/customer satisfaction gap

keep track of what value the product could deliver, if more time and resources were dedicated to the further development

ex: the difference between what a user/customer expects and their actual experience with the product.

An agile approach seeks to increase value therefore useful metrics are those supporting the understanding of how well and how fast value can be delivered.

Ex metrics

Time to Market(T2M)

Ability to Innovate(A2I)

Time to Market describes the ability to quickly develop new responses to opportunity, Ability to Innovate describes the effectiveness of doing so.

ex metrics

Lead Time

the time between coming up with an idea or learning a new important requirement from a stakeholder until the point at which this is delivered and value is realized

Release Stabilization Period

the time between when the developers say an increment is releasable and the actual release

Installed Version Index

the number of different versions of the product existing,

all of which may need different support and maintenance

creating a potentially unnecessary effort

Technical Debt

when a solution is implemented, sometimes this is done “quick and dirty”

if this happens too often, the product becomes harder to maintain and to develop further, slowing down the speed of value delivery

The EBM metrics are concerned with the product and the organization overall

On the level of individual teams, useful metrics are the achievement of Sprint Goals and teams’ velocities.

Every Sprint is driven by a Sprint Goal.

If a Scrum Team manages to achieve a Sprint Goal,

they are capable of planning their own Sprints,

properly planning their Sprint

if necessary, adjusting their Sprint Backlogs throughout their Sprints.

this metric is of course not inherently valuable on its own BUT can give managers and the team itself an indicator of the self-management abilities of the team.

velocity is a metric that can be both useful and misused, depending on what it is used for

Velocity is not necessarily correlated to value, therefore, it should not be used as a metric to evaluate performance

can, however, be useful as an internal metric of a team

Forecasts about how much work can be performed in an upcoming Sprint must be based on past experiences

it is useful for Developers to consider their past velocity as an indicator of likely future performances.

Product Owner can use past velocity to predict likely delivery dates of new value-delivering feature.

note that velocity is to be used as an indicator, not a certain predictor.

As conditions change, the velocity may change rapidly between Sprints and plans need to be flexible enough to be readjusted as necessary

the underlying intention between a traditional environment and an agile environment differs greatly

agile environment is concerned primarily with delivering the highest possible value

Along with this difference in intent comes a difference in measurements

Common Misconceptions

Sprint progress updates

Management updates the metrics about the progress of the Developers’ work throughout the development.

The Sprint Backlog is a tool of, for, and by the Developers. Updating the metrics is part of the self-management of the Developers.

Task Ownership

Individual items are often assigned to individual people, who are individually responsible for finishing.

The Developers are collectively responsible for the outcome of the Sprint and every item in the Sprint Backlog. No member of the Developers owns any item individually.

Hardening phase

Phases of feature development may be followed by hardening phases, in which the undone work of the feature development is taken care of, e.g., non-functional requirements such as scalability.

Every Sprint delivers an increment that is Done. Thus, there is no hardening phase. “Hardening Sprints”, as they are sometimes called, are not a valid construct in Scrum

Coordinate across teams

When multiple teams work together, the managers of these teams coordinate the collaboration

When multiple teams work together, all members of all Developers are responsible for finding a proper way to collaborate

Crunch time

When a deadline needs to be met or a quota fulfilled, it often happens that developers are ordered to work overtime.

Scrum aims for sustainable development. When plans, which in Scrum are merely forecasts, cannot be met, they need to be adjusted, and this change must be made transparent.

many people have misconceptions about Scrum, which are the result of applying conventional thinking to situations in the Scrum environment.

Relevant terminology

Technical debt

refers to the implied cost of additional rework caused by choosing an easy (limited) solution now, instead of using a better approach that would take longer.

Technical debts lower transparency, as the Product Owner and stakeholders receive a wrong assumption about the current state of the product.

Technical debt adding up will lead to development speed slowing down and the product potentially becoming unstable over time.

Story Points

A common format for Product Backlog items is that of the user story.

the requirement is typically provided in a format of “As an X, I want Y, so that I can Z”.

The Developers may estimate the effort needed for a user story in a relative unit called story points.

Value Stream Mapping(VSM)

referred to as “material- and information-flow mapping“,

tool for visualizing and subsequently optimizing a process of delivering value to a customer.

whole process from beginning to end is mapped with appropriate metrics

the flow of value is analyzed.

lean tool

identify waste and bottlenecks in the process,

increasing the overall productivity of a team, a unit or even an organization.

Velocity

refers to the number of story points delivered by the Developers during one Sprint.