Monday, April 12, 2021

Subscribe to the RSS Feed

Our agile manager… Supports projects and agile self-organized teams

Posted by jc-Qualitystreet on 2011/02/21

The job of manager is evolving… between opportunity and necessity

After « Our agile manager initiates and supports communities of practice« , this is the second article devoted to the responsibilities of the agile manager.

#2 Support projects and agile self-organized teams… which means:

To promote autonomy, empowerment and self-organization
To remove impediments that the team (broadly defined) cannot raise
To protect the Team
To manage logistics (including setting up an Agile Environment for the team)
To challenge the Team and help improve it to improve its knowledge of the product, technology, methods or tools

In short, it consists in supporting the success of the team, its self-organization and its quest to create value and delight the customer…

You said « self-organizing teams »?

Self-organization is the ability of a team to decide how to organize its own activities to achieve the goals set or solve the problems it faces. The effectiveness of Self-organization has been proven … and in good conditions (mainly depending on management), self-organizing teams naturally evolve into HIGH PERFORMANCE TEAMS.

Self-organization belongs to the foundation of agile… It is one of the 12 principles of the Agile Manifesto (2001): « The best architectures, requirements and designs emerge from self-organizing teams. »

But « the self-organized project team » is also a winning practice, one of the 6 characteristics of leading companies, discovered in 1986 by Takeushi and Nonaka. In The New Product Development Game, the authors pointed out the benefits (speed, flexibility and innovation) of self-organizing teams at Toyota, Honda, Fuji-Xerox, HP or 3M. The article was a source of inspiration for agile methods like Scrum…

Managers, we need you to encourage self-organization

Self-organization is a « common » behavior of any system (related to the fabulous ability to adapt), but to be optimal, self-organization should be both bordered and supported.  Agile development teams are no exception to the rule…

To ensure it, the role of the organization is to give a direction, to share a VISION. And managers should define the context by setting limits and constraints and support self-organizing agile teams, to enable them to flourish and perform. Unfortunately, only few managers are able to do it today…

It is clear that the agile self-organized teams must align and evolve with organizational goals. Managers need to articulate what the team does and its own objectives with those of the organization. In parallel and to maintain a successful self-organization, managers will have to know each team member and his work but also provide recognition and appropriate feedback.

In short, without the involvement and commitment of middle management, self-organized teams will… fail.

A new managerial posture is required

Within the population of managers working with agile teams, some are already adapting, for others it is more difficult…

Now in all cases, middle management must show leadership, and leaves behind habits inherited from the past that have little meaning today: command and control, micro-management, or conversely total absence, ignorance and indifference…

Challenging and supporting projects and self-organizing Agile teams will be an important part of the agile manager activity. The Lean & Agile organization offers managers the best opportunity to delegate, to empower people (for real), and to give them the autonomy.  It’s a new and positive perspective but that can only work with the presence of the two pillars of Agile Management:  (mutual) trust and authenticity.

Agile Coaching Tips: My Action Plan is visual, simple and SMART!

Posted by jc-Qualitystreet on 2011/02/14

I usually say to Agile teams that the most important outcome of a sprint (or release) retrospective (but also important workshops), is the Action Plan.

Scrum Retrospective Action Plan. A crucial element of facilitation.

Scrum Retrospective Action Plan. A crucial element of facilitation.

Both past and future oriented, the SCRUM retrospective meeting aims to discover what the team did well, understand what went wrong, and to find ways to improve. It’s an important and intense exchange and communication event.

But completing an action plan, at the end of the retrospective, is the only way to make it fully successful and to engage the team in a continuous improvement approach (Inspect & Adapt) for better performance.

Simple

Concise and just enough…

Only a short list of actions (4 max) and three columns that make it simple and effective.

  • What (the action: task-oriented, smart and with a verb)
  • Who (the owner of the action)
  • When (the agreed due-date)

Visual and visible

Build in collaboration on a large sheet of paper. At the end of the meeting, the action plan will join the team’s information radiator, into the team’s workplace to make it visible every day by everybody’s eyes. Communication is crucial for continuous improvement, and visual management is an effective strategy to make the follow up and to maintain engagement.

At the end of the next sprint, actions items of the previous plan will be reviewed: Done or KO

SMART

Of course, the actions included in the « what » column are SMART:

  • Specific
  • Measurable
  • Achievable
  • Realistic
  • Time-bound

Then, I like to get the team’s commitment to the plan before closing the meeting and doing the ROTI (Return On Time Invested).

What is Agility? The definition of the agile organization

Posted by jc-Qualitystreet on 2011/02/08

The question arises regularly… so here’s my own definition of agility:

« Agility is the ability of an organization to create value and to continuously delight the customer, while promoting and responding to change in its environment »

This broader definition completes a recent quote of my fellow french blogger Claude Aubry* on Twitter, and adds  to Jim Highsmith’s definition ( »Agility is the ability to both create and respond to change in order to profit in a turbulent business environment » 2002) or Craig Larman’s definition (« Rapid and flexible response to change » 2004). While I found these good definitions very inspiring, I was missing something…

I was missing the CLIENT, the primary goal and core foundation of an organization, the means to align employees to a common vision and the key differentiator against competitors. Indeed, in today’s world of complexity and competition, the challenge is not only to deliver value early but mostly to continuously delight his primary customer.

This is the only viable purpose to be successful in the long term. For this, the agile organization must be both proactive, active and reactive, supported both by lean, agile and user eXperience practices.

Of course « being agile » is also a mindset based on core values: communication, feedback, courage, simplicity, respect and the four from the Agile Manifesto.

* « L’Agilité est la capacité d’une organisation à créer de la valeur, tout en s’adaptant -à temps- aux changements dans son environnement » 2010

My Product Backlog is DEEP… and PHYSICAL!

Posted by jc-Qualitystreet on 2011/02/01

The product backlog is a prioritized list of everything that might be needed in the product. This is the thread of a Scrum Agile project.

My Product Backlog is DEEP…

My Product Backlog is DEEP...

My Product Backlog is DEEP…

The acronym D.E. E. P. (detailed appropriately, estimated, emergent and prioritized) summarizes key attributes of a good product backlog.

Unfortunately among agile teams, few product backlogs now meet these criteria, but surprisingly (or not), the question of the tools to manage it seems to be more « exiting » … From dedicated tools, to Excel or Google spreadsheet; from Sharepoint to Jira or even QualityCenter 🙂 … which tool to choose? That’s forgotten pretty quickly, another key characteristic of the product backlog: its physical aspect!

My Product Backlog is DEEP… and PHYSICAL

Having a physical version of the product backlog, visible and easily accessible is crucial. Associated to the burnup chart, it’s a key element within the information radiator of the project.

We see the end!

We see the end!

Indeed, unlike a virtual (electronic) product backlog, the physical product backlog:

  • offers to everyone (belonging to the Scrum team or not) a real time visibility on the progress of the product development: what we’re doing, what we did and what we need to do to finish the product;
  • is a strong sign of transparency and openness
  • gives a meaning to the work of the team (source of motivation and engagement);
  • provides each team member with a clear idea of the big picture.

An agile state of mind and some prerequisites

The cost of initialization of a physical product backlog (for example the writing effort) is minimal.  However, its effectiveness requires that:

  • the physical product backlog belongs to the information radiator located where the team works (closed to the Product Owner in a collocated environment);
  • the physical product backlog becomes a real meeting point for the team and the Product Owner;
  • the product backlog is groomed and managed continuously: leaving a product backlog abandoned in a corner of the wall is the sign that something goes wrong.

Obviously, electronic versions of the product backlog remain essential for distributed teams operating in remote environments. Yet even in these contexts, a return to simplicity and value is often useful. Tools must only exist to make processes more efficient and to facilitate the work of people.

So a virtual product backlog tool should remain a source of value, and should be neither a constraint nor a waste.

Agile Marketing Team: We stand up daily!

Posted by jc-Qualitystreet on 2011/01/29

Marketing teams now who want to become Agile

At Valtech (FR), marketers have already taken the opportunity to adopt agility in their own business.

AgileMarketing-The Daily Scrum
AgileMarketing-The Daily Scrum

The team is small. Agile planning and visual management around a « beautiful » taskboard are the first agile elements the team wanted to experiment.

Every day in the morning, no more than 10 minutes, the team does its « Daily Scrum » to synchronize, measure progress and identify impediments. For them, Agile is a good way to work together and to build a relation of trust based on FEEDBACK, TRANSPARENCY and RESPECT.

And you know what? They like it!