Stable, long-lived, Teams: between myths and reality

stabe

Competing as a protagonist in the digital, global market, means delivering actual value to customer, always striving to improve speed, quality and adaptation. The performance of the work teams that produce those results, is obviously one of the key factor in achieving these standards. Agile suggests, to reach that objective, to design teams which are self-managing, cross-functional, co-located, and long-lived. In this post we want to reason about stable teams, their advantages and, if any, difficulties or myths.

No alt text provided for this image

We strongly believe that creating stable and long-lasting agile teams, is a key-competitive element for companies, who want to deliver continuous stream of value to their customers.

Stable teams develop, over time, stronger behavioral and working dynamics, higher levels of transparency that favor trust and collaboration among its members; when facing complexity, trust within the team actually drives increased levels of performance, creativity and intrinsic quality of the product the team is dealing with.

To reach this state, a team needs to pass through a series of developing steps. A model that is largely used to describe this evolution, is the Tuckman Stages model.

This post, then, will also go through some weakness areas of that model, and how to assure performance for agile teams in contexts where stability is not assured, by exploring the 60-30-10 heuristic.

Tuckman Stages Model

In 1965, Bruce Tuckman, developed and published a research about the interactions between the people belonging to a group, and its following development as a team; this study eventually led to the creation of a model that took his name.

That model involves the following phases:

No alt text provided for this image
  • Forming: it represents the initial phase where, among the team members, the development of a first sense of belonging takes place; they share common values, align to the corporate mission, live first joint experiences and prepare themselves to trust each other, as the foundation to be successful
  • Storming: phase in which conflicts can occur due to the attempt of individual team members to find their place and “impose” their individuality and leadership
  • Norming: having successfully passed the previous step (which shouldn’t be taken for granted), the team defines proper norms, working methods, and refines roles and responsibilities. The sense of unity initially only perceived, is now established and individuals feel themselves actually part of a whole: the team
  • Performing: finally the team has achieved sufficient stability to deliver continuous business value and achieve results. The team is now able to manage itself in improving its process and working practices

The model presents a logical sequence of phases and clearly shows the impact of each one on productivity.

In practice, though, it has some weakness areas. First of all we could think that the phases are discrete and linear in their development. However, that’s not the reality.

“Scientific community emphasized that this model should be considered more a conceptual declaration”

According to the context, the people involved and the work that must be done, the team can pass from one phase to the other more or less quickly, and have regressions. Performance trends are not always that “smooth” in their descending and ascending, but could have continuous up and down peaks.

It is worth noting that in the following years, the scientific community emphasized that this model should be considered more a “conceptual declaration” than a fact; it was conceptualized and brought to life by the data collected by the author’s studies, which actually lacked, and seems still lacks, an empirical validation on the ground.

Getting rid of Tuckman’s Model

study conducted by the US Defense Ministry in collaboration with the Defense Acquisition University, shows that in teams formed by a few members, with strong competence and motivation, the phases described by the Tuckman model, actually strongly overlap.

No alt text provided for this image

The Storming stage would be very limited in its wideness but extended in time, so as to be called “Brainstorming“: moments in which the team reflects productively on how to become more effective and evolve its ways of working. Additionally, it seems that the Norming phase continues to happen until the end of the measured endeavor.

Agile Teams: acrobats on uncertainty

Agile teams are small ones (no more than ten), technically and business competent and, by design, they are given the autonomy to decide their ways of working. Furthermore, they are cross-functional, which increases the overall internal competence and, finally, they are physically or “digitally” co-located, which definitely favors communication and adaptation among members.

They systematically hold retrospectives which helps to adapt and adjust their process in order to become more effective over time (see Brainstorming phase observed in the previous example).

Additionally, these teams are open and transparent enough to review and amend their norms and rules, as soon as they are no more effective, actually confirming that the Norming phase lasts until the very end of the project.

It seems, indeed, that Agile teams naturally fit very well in that situation. But, what about stability and not changing their composition?

“Due to the high volatility and fluidity of the markets, team stability is strongly challenged”

We know that adding or moving team members breaks stability and forces the team to review its dynamics and create new ones: this produces inefficiencies, reducing motivation.

We know, however, that due to the high volatility and fluidity of the markets, team stability could be strongly challenged for the following reasons:

  • new skills can be necessary to teams,
  • ans/or necessity to increase capacity of the team,
  • and/or people change job more frequently
  • and/or re-organizations could take place with a smaller cadence than in the past;

to such an extent, Agile teams need to be adaptive and fast also in rearranging themselves.

No alt text provided for this image

Said and acknowledged that, are there any prerequisites to check or good practices to put in place, to help teams remaining effective even when stability is at risk?

Getting off, on the right foot

It seems, actually, that there is another important element which influence the stability of teams: how teams are designed. A bad design could lead to significant problems in efficiency, quality of work and conflicts between members.

Richard Hackman and Ruth Wageman coined a heuristic which helps to think on how to start with the right foot from the very beginning; this is the “60-30-10 Rule for Coaching Teams“.

The heuristic explains the percentages of time/energies that should be dedicated to the following activities:

  • 60% on how a team is designed,
  • 30% on how it is launched,
  • 10% on how the team is coached.

Team Design, Launching and Coaching

When it’s time to design a team, it is necessary to focus on some pre-work.

“Bad performance of a team could lead to eventually re-shuffle it, which brings us to hit the same problem we are trying to solve: instability of teams”

It is firstly necessary to understand if there’s enough of homogeneous work in the portfolio, to create a stable team. The suggestion is to create teams which are dedicated to one or more products that belong to the same stream of value for the selected category of client.

Then, it is necessary to create a first draft mission for that team (which will be reviewed and refined by the actual team when formed), delineate what business objectives it needs to achieve, appoint a Product Owner, understand what skills are necessary and roughly estimate (range) how many of people should be involved.

Usually happens that teams are designed by managers, who move people around according to their actual capacity, competence and also speculating on personal relationship among them. The risk here, is that managers do not actually have all the relevant information to make the right decision and, also, they could have any biases which has the potential to badly influence their conclusions.

We know that bad performance of a team could lead to eventually re-shuffle it, which brings us to hit the same problem we are trying to solve: instability of teams.

One good practice is self-selecting teams. The idea is to let the people select the teams to which they want to belong, through attending to dedicated workshops.

“Even when the team stability is at risk, they self-arrange and look for the best solutions to find another status of balance and remain effective”

During these workshops, flip-charts are hung to the walls containing all the relevant information about the mission/objectives and the constraints (a few) that must be respected for each team (e.g. max number of people, any diversity factors, end-to-end delivery capability, etc.). Product Owners stand beside them, ready to reply to any questions.

People walk around, talk to the Product Owners, discuss to each other in order to look for the best team where, each one, can deliver value and then they stick their image/avatar on the respective team flip-chart. Product Owners and mangers, then, facilitate the discussion in order to arrive to the final refinement and adjustments of teams composition.

This approach considerably increments the accountabilitymotivation and resilience of the team members. One positive result is that, even when the team stability is at risk, they self-arrange and look for the best solutions to find another status of balance and remain effective.

Once the team is designed, the next stream of energy must be devoted to team launching.

In that moment it is paramount to clarify any doubts the team has according to the mission and vision, with the relevant stakeholders. During these workshops product/project dimensions like scope, technicalities, stakeholders community, estimations, risks, are discussed high level.

This phase is not successful finished, until the team has clearly and transparently defined its working agreements and ways of working and consolidated everything in a charter which is hung in the team room.

When teams are well designed and launched, we finally posed the basis for their stability and long-term value creation.

During the team journey, however, managers shall not forget to stay close to the team, supporting and coaching it to help passing through the process of transforming a group of people in a great team.

Being Agile Disciplined in managing Risks

bd1

Every time a new initiative is starting, it’s intrinsically risky. This is even more true when the solution you need to develop, is a big one. An approach that is able, if well executed, to drastically reduce risks from the very beginning is the Agile Inception. Want to know more?!

No alt text provided for this image

Agile manages risk by design. In two of my previous posts, I wrote about how risks are managed, both at team and program levels, in an agile way:

Thanks to iterative and incremental development, rapid feedback cycles and closeness with the customer, Agile lowers risks since from the first iterations. The graph below clearly shows how risks decrease rapidly, compared to what waterfall does instead.

No alt text provided for this image

The primary reason which explains that effect is because the Agile team and the whole stakeholder community involved in that development endeavor, learn faster about the product and the context, testing earlier their assumptions, which in general decreases the overall uncertainty.

No alt text provided for this image

A terrific tool that helps to visualize the uncertainty (thus indirect exposure to risks/opportunities) which characterizes the envisioning and further (waterfall) development of a product or solution, is the cone of uncertainty. That diagram well describes the variation of the degree of uncertainty over time, when developing a new product; this is reflected by the error factor that teams do usually make, when estimating the effort necessary.

No alt text provided for this image

We notice from the picture above that most part of the uncertainty stays with the initial period, when the vision of the product, features necessary and how they could be built, are not that clear. This is even huge and risky, when the solution to develop is a big one, in a big enterprise, which involves several teams.

In such cases a good choice which helps to face that uncertainty, and inherently to lower risks, is represented by the DAD Inception. The main objective of this approach is to spend a few time, in the initial phase, to iteratively explore the main dimensions of the initiative (e.g vision, scope, architecture, quality, team, cost, time), in order to create a common high level picture among all the key stakeholders.

DAD summarizes the goals of this phase as follows: Develop Common VisionAlign with Enterprise DirectionExplore ScopeIdentify Architecture StrategyForm TeamPlan the ReleaseDevelop Test StrategySecure Funding.

It is important to clarify that this is not and must not be confused with Big Design Up Front.

Indeed, it is worth noting that, in order to avoid any misunderstandings, the authors stress on purpose, words like “align“, “explore“, “identify” and “strategy” when describing the inception goals, which are intended to be high level activities and outcomes, detailed further on during the development, through the usual Agile iterative approach. In this article, the authors make that point crystal clear.

Additionally if you go through the tools and techniques suggested, they are all about lightweight ones based on collaborative working, sketching, agile modeling, etc.

Usually, those goals are achieved by running a series of workshops. A good practice is to use the first sprint (Sprint 0) to execute them.

An interesting picture (adapted from DAD disciplined agile consortium – risk-value lifecycle) that explains the impact of the Inception on risks and business value is the following.

disciplined agile consortium - risk-value lifecycle)

There are some interesting things to notice.

Due to the fact that the inception brings all the relevant stakeholders together, exploring the main product dimensions, misunderstandings or misalignment are managed immediately, allowing risks to decrease as well (P1).

Additionally, as soon as the vision is consolidated among the stakeholders, there’s another sudden drop (P2). Finally, thanks to the agile iterative approach, risk are manged proactively and thus it should not happen to have a growing trend, however this decreases till the end of the initiative.

It is interesting noting that business value starts to be created only when the inception is finished. Actually, nothing is delivered to the customer during that phase. Even if this could be seen as a sort of violation of the Agile principles, when facing a big project it could be acceptable to trade some time (money) initially, to drastically improve the probability of final success.

How can we wrap-up and represent the previous concepts all together?!

No alt text provided for this image

What are you saying?^ Your project is not that big and you have only one team involved?!

Well, the Agile Inception Deck from the Agile Samurai is what you need. Enjoy! :o)

Article “The Spotify approach: more reactive and agile organizations” [italian]

Digital revolution and technological innovation have spread to every sector of the world of work.
Only companies able to listen to their customers thoroughly and respond quickly to their requests, redesigning business models and constantly innovating their products and services, are destined to play a leading role in their target markets.
How can companies be made more responsive and close to the customer and, at the same time, increase engagement and satisfaction of their employees?

Let’s see how Spotify is organized and what can be applied to every organization who wants to be successful nowadays. Here the link to my article (italian).

Agile Risk Management @ Scale

If managing risks with Agile could seem trivial in case of just one team, what are the good practices when multiple teams are working together building the same solution?

No alt text provided for this image

In the first part of this post, I explored how great is Agile at its core and, more specifically, how Scrum implicitly and by design, takes risks into high account.

We know that risk management is mainly about culture. Whatever is the approach, technique, methodology used to handle risks, people shall be predisposed, educated and sensitive to it.

Risk culture is a term describing the values, beliefs, knowledge, attitudes and understanding about risks, shared by a group of people with a common purpose. This applies to all organizations. An effective risk culture, is one that enables and rewards individuals and groups for managing and taking care of the risks in an informed manner.

So, the first thing to do when in need of improving the way risks are managed within your organization, is to teach and train people on risks and how to manage them, then evolve the mindset by increasing transparencytrust and fostering a disciplined approach to risk management, again, whatever is the methodology applied.

Back to Agile, we know that Scrum teams manage actively impediments and are able to better foresee risks and implications. But how does this scale through a program of several teams working together on the same product? How risks are managed and escalated to the upper level?

It all starts with firstly enforcing the way risks are managed at team level.

Agile Risk Management Tools at Team Level

Scrum teams manage risks daily through the Daily Scrum. Additionally all the other events and practices (PlanningReviewRetrospectiveBacklog Refinement) help them to identify, asses, evaluate and manage risks proactively and consistently, thanks to cadence and clarity of events, transparency of roles and responsibilities, team collaborative behaviors, etc.

Additionally, Scrum teams handle risks through lightweight approaches by using visual management and radiators, which maintain the information always visible and present to the whole team, asking for action.

No alt text provided for this image

The board above reported, helps teams to manage in their resolution and physically in one place both impediments and risks; for the latter, keeping also into consideration the different levels of attention.

However, in case of very risky and critical programs, a more robust approach in managing risks shall be applied; in those cases, the most disciplined agile teams used to measure, for each risk, two additional dimensions: Likelihood and Size of Loss.

Likelihood regards the likelihood that a risk can actually happen. Size of Loss measures the number of estimated days needed to recover and to get back on track if that risk eventually materialize.

The result of multiplying these two numbers, gives back the exposure for each risk, which can be added and accumulated for each sprint and, thus, reported over time. This assessment is done every iteration, according to Scrum events (Retrospective is a good one), in order to identify what actions can be put in place to mitigate if not definitely solve the risk.

The results of such actions, should lower, over time, the risk exposure. Risk Exposure trend can be then visualized through the Risk Burndown chart,

No alt text provided for this image

As we know, Agile teams are self-managing and self-organizing.

This means that they should always try to solve impediments and face risks, autonomously. When working in a program, it happens though, that some of these risks are more systematicorganizational and cannot be directly solved by themselves.

This is the time when teams shall escalate risks (in an agile way) to the upper program level. Let’s see how 🙂

Agile Risk Management at Program Level

Whatever is the Agile Scaling Framework chosen, Risk Management at program level follows similar rules described for Agile teams (fractal mode). Usually, when having teams working together to produce the same product/solution, we should have at least the following events (whatever the chosen framework):

  • Inception and Release Planning
  • Sync Events between team representative and Program roles during execution (e.g. Scrum of Scrums, Tribe/Train Sync, Nexus Daily Scrum, etc.)
  • Program Demo and Retrospective

Risks are actively managed through this events.

One of the tool used which can be used is the same board above described for teams. Risks coming from that level and which relate to program, are pulled and here managed.

No alt text provided for this image

Risks are usually identified and assessed also during one of the events above reported. The Threat Matrix is also used at this level; this helps in assessing the likelihood and Impact of the risk…but always done in a collaboratively way by the teams and program roles:

No alt text provided for this image

Then every risk, according to its threat level, is discussed and managed by deciding which action must be taken. A good tool which can be used is the ROAM Board which groups risks into four categories:

  • Resolved: no more a threat
  • Owned: risks which need further investigation. An owner is assigned
  • Accepted: risks whose level of threatness is very low, thus even if happening won’t impact seriously the program
  • Mitigate: risks who are serious and thus are mitigated through punctual actions
No alt text provided for this image

…again visual management, involvement and cooperation between teams and program roles are key for the success of the activity and in general for risk management practice when you are playing the game in an Agile way.

No alt text provided for this image

Once a “traditional” guy told me: “when it’s time to manage projects and product development, Agilists like you are just cowboys which hug trees and hung post-its on walls”.

Well, we Agilists create the space where individuals and their great interactions meet lightweight processes and tools; this is when actually magic happens.

Wasn’t this the reason why Agile has been created?! :o)

On Risks and Agile approaches

What if some sarcastic guys would challenge us by asserting that Agile/Scrum primarily are mainly great approaches to manage risks?! Should we feel offended by that? Well, let’s see how Agile addresses and manages risks, then we can decide :o)

No alt text provided for this image

Once I read, don’t remember where, that Scrum is not, at all, the best approach to develop products when facing complexity; rather, it’s the best known Risk Management approach in the world.

Well, I could not agree 100% (actually, you do develop great products when strongly challenged by uncertainty) but, putting aside the sarcasm of the author, which made me smile, I found myself in sympathy with it.

If we take a look to the Agile Manifesto and the Scrum framework, there are may practices and principles which, by design, help teams to actually manage proactively risks:

  • Fast feedback cycle: let you to discover in advance any bad variance between progress/value created, respect to client/user expectations. Furthermore, in case of bad surprises, you can recover pretty well and fast.
  • Continuous (re)planning: Agile is based on empirical process control. This means that every iteration ends with the inspection of the product (sprint review) and the underlying process (sprint retrospective). These are key events where agile teams discover, assess any risks and adapt their behaviors according to it.
  • Daily Scrum: every day the development team meet for 15 minutes in front of the board, discussing progress, plans for the new working day and impediments (risks that actually became facts) and any possible risks.
  • Small batch size: Agile suggests to work in iteration. During these ones the team shall design, build, test and deploy a potentially shippable product. Iteration must be small ones (2 to 4 weeks maximum) preferring the shorter timescale when uncertainty is high. Well, this implicitly means that the amount of work is limited, more manageable, dependencies are easier to visualize, uncertainty is limited and, thus, risks are inherently less “risky” in terms of probability of occurrence and impact on project objectives.
  • Team diversity and cross-functionality: teams like these ones are better equipped to explore solutions for complex problems and foreseen any possible risk in advance respect to other team typologies.
  • Backlog Prioritization: backlog is prioritized by the Product Owner. There are many techniques and approaches to do that (MoSCoWCost of delayWSJF, Kano, Relative Weighting); of course business value and effort (cost) are the primary factors to be considered, but also the risk is a key item that must be taken into large account when prioritizing backlog items. Why? What if we continue to deliver the most valuable backlog items (in the eye of the customer), while neglecting some very risky items that remains in the lower part of the backlog (mening low biz value) and which can derail the whole project because of tech problems or something? By the way the WSJF method from SAFe, is crystal clear on how to prioritize features and epics keeping in account risks (and opportunities as well).
No alt text provided for this image

If you are still reading this post, I am sure now you agree with the sarcastic guys mentioned in the introduction :o)

If we bring this one step further, by looking back on how traditional project management categorize risks, we find the following:

  • Known Knowns: things that we know that we know; it regards our general knowledge. Risks we know, which we can assess in terms of impact and probability and we can decide how to manage them (owning, transferring, mitigating o accepting).
  • Known Unknowns: things we know that we don’t know, or we don’t know their potential risks. They have not been accurately measured, but we are aware that in that area we could have problems or surprises and we need to monitor them accurately.
  • Unknown Unknowns: these are the most dangerous kind of risks; they are strongly linked with uncertainty and complexity. We actually don’t even know, that we don’t know that they exist. Any of this kind of risks, can hit seriously and unexpectedly our project.

Agile teams intrinsically are able to address any o these categories of risks.

Daily Scrums are the primary technique they have to manage the Known Knowns.

In addition to that event, backlog refinement, sprint planning, review and retrospective, are the tools agile teams have to address Known Unknowns.

And, what about the Unknown Unknowns? Well guys, aren’t Agile and the empirical approach be made exactly for exploring uncertainty and complexity, by incessantly lowering risks through iteration execution?

Article State of Flow: how to increase innovation, productivity and agility in organizations

Here one of my article (Italian) published by Leadership & Management magazine.

stateofflow aticle

Enjoy!

Leadership, agility and innovation in the digital era article (italian)

tecna1

Here one article of mine published by Tecna Editrice.

Enjoy!

Nexus: Agile its heart, Lean wings to scale-up

Nexus3

In one of my previous post “A feather for scaling Lean/Agile Product Development“, I presented the main characteristics of Nexus, the scaling framework created by Ken Schwaber and Scrum.org.

In this post I would like to share what are the strengths of this framework and what could be the attention points, according to my personal experience. Actually, the more I use it, the more I appreciate its concretenesssimplicity and “stubbornness” with agile and lean.

A very interesting given advantage, is that its learning curve is not that steep for someone who knows already Scrum, Agile principles and Lean.

My previous post gives you some of the basics of that framework if you are not familiar with, which I suggest before proceeding further with this one.

First of all, it is worth citing here the definition of Nexus, found in the official guide:

Nexus is a framework consisting of roles, events, artifacts, and rules that bind and weave together the work of approximately 3 to 9 Scrum Teams, working on a single Product Backlog to build an Integrated Increment that meets a goal

Well, Scrum scaled up to 9 teams, with one Product Owner and one Backlog. Cool! Wanting to make a very short-list, these are the strengths I appreciate the most:

  • Simple and Lean
  • Backlog Refinement and Interdependence Management
  • Obsessive focus on Integration
  • Tangible set of Tools and Techniques

Simple and Lean

When you read the Nexus Guide and the book “The Nexus Framework for Scaling Scrum: Continuously Delivering an Integrated Product with Multiple Scrum Teams“, you will read statements like these ones: “Nexus is consistent with Scrum“, “Nexus uses Scrum as its building block“, “Nexus is 100% derived from Scrum“.

The first form of simplicity is that Scrum pervades everything . Indeed, it is used as it is by the agile teams forming the Nexus, with some minor adjustments to accommodate its process flow at a higher level. Additionally, the “new things” Nexus brings, are fully built on top of Scrum, too (roles, events, artifacts, etc.).

It’s Lean because it fully adheres to the 7 guiding principles of lean development:

  1. Eliminate Waste
  2. Build Quality In
  3. Create Knowledge
  4. Defer Commitment
  5. Deliver Fast
  6. Respect People
  7. Optimize the Whole

To make one example, the way the “new” Nexus events have been introduced, witnesses how the creators wanted to minimize overhead and any additional waste by 1) not adding too many new entities (role, rules, events, artifacts, etc.), 2) normalizing responsibilities about product backlog management (only one Product Owner), 3) finding synergies and lean methods to incorporate events at team and Nexus levels (diverging-converging approach, team representatives, etc.), 4) avoiding waste and reduce as much as possible quality problems by tightening the way the teams coordinate to integrate and create a product increment, through the formation of a semi-virtual agile team (Nexus Integration Team).

Backlog Refinement and Interdependence Management

Many teams fail because do not correctly take into account the strategic importance of backlog refinement.

Starting from the basics, the following text is what the official Scrum guide reports about the Backlog Refinement practice:

Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. During Product Backlog refinement, items are reviewed and revised. The Scrum Team decides how and when refinement is done. Refinement usually consumes no more than 10% of the capacity of the Development Team. However, Product Backlog items can be updated at any time by the Product Owner or at the Product Owner’s discretion.

No alt text provided for this image

As you can read, generic guidelines are given about its execution, leaving teams to decide when and how to do it. Of course the authors did not want to be too much prescriptive because of the complexity and differences among the multitude of organizations which would have had adopted Scrum.

But, a bit of realism is needed. When launching new teams, they will struggle a lot to fully understand, interpret and finally adopt it, as a routine activity.

This gets more and more arduous when, the work of several teams needs to be orchestrated to produce every two weeks something valuable and potentially shippable to clients. Well, Nexus placed Backlog Refinement in the front row when describing its process flow.

No alt text provided for this image

As you can appreciate at the top left corner of the above image, backlog refinement has finally its own official place! Nexus identifies two primary objectives teams need to achieve through this practice. Here below an excerpt:

Refinement of the Product Backlog at scale serves a dual purpose. It helps the Scrum Teams forecast which team will deliver which Product Backlog items, and it identifiesdependencies across those teams. This transparency allows the teams to monitor and minimize dependencies.

From one side it guides the teams to decompose appropriately the backlog to make the whole Nexus being able to work and finish items within sprints. Additionally, it helps to make a forecast on what will be delivered in the next sprints.

(By the way, a small digression: in 2011, the Scrum Guide replaced the word “commitment” when selecting the backlog items during the sprint planning, with “forecast“. Here you can find an interesting, explanatory article which definitely sheds a light on this)

Back to Refinement.

Then, the inter-dependencies are addressed. Due to the important of this topic, it has been also developed accurately through another whitepaper developed by Scrum.org which you can find here:

Cross-team Refinement Whitepaper

The resulting cross-team refinement board is then reviewed and discussed every day, during the Nexus Daily Scrum.

Obsessive focus on Integration

The creators thought that, for integration stuff, coordination among teams would not be totally left to self-organization. Indeed, they identified the Nexus Integration Team (NIT) to be responsible for helping teams to integrate frequently, at least every sprint, into a common environment, where integration testing and acceptance can be performed.

That team is formed by people coming from other teams and any additional expert whose primary objective is to coachsupport and help teams in integration (preferably not doing the work itself).

The new Nexus Daily Scrum anticipates the teams’ one on purpose: the most important thing, during that event, is to inspect the state of the integrated work, assess any issues and then have teams working actively on these, by addressing them in their Daily Scrum events.

No alt text provided for this image

The NIT team is also responsible to raise any technical and non-technical issue.

This means that NIT has also managerial responsibilities: if the whole Nexus, for instance, has problems with missing knowledge or expertise, NIT has the responsibility to understand how this knowledge can be shared between teams, arranging dedicated sessions or bringing on board new people to ease bottlenecks and problems.

A final, special, mention must be made to the Definition of Done (DOD). Having a clear and rigorous DOD is a fundamental pillar for integrating smoothly.

In Nexus, the DOD is defined by the NIT and inherited by the agile teams. Of course this is a collaborative effort but it ends with teams that cannot modify it, unless they want to make it even more rigorous.

Haven’t I told you about their obsession and stubbornness?! :o)

Tangible set of Tools and Techniques

Another interesting thing is that the authors, when explaining the framework and its elements, do suggest optional practices and techniques to better support the work of the Nexus.

Some of them are new, others are not. Among the others, you can find techniques for: Team ScalingDe-scalingBacklog RefinementVisual ManagementEvents Facilitation.

Here the comprehensive list of suggested Nexus Practices.

Conclusion

Addressing agile at scale with Nexus could be generally less mentally strenuous. This, per se, is a great advantage. But, actually, putting in place a framework, whatever it is, does not mean that we are scaling Agile, being Agile.

Relying on values and principles should always guide our behaviors and actions….but, yes, relying on a good framework is good starting point. :o)

Some thoughts on what could be some difficulties in applying it on the ground.

  1. Having just one Product Owner increases transparency, reduce misunderstandings. Even though the work a PO needs to do when teams are more than 3 or 4 is huge. In these cases you need to think on how to scaled Product Ownership while maintaining the PO accountable
  2. When under pressure, the NIT team could tend to do the work by themselves, instead of coaching and facilitating the teams.
  3. By mentioning the Definition of Done, Nexus helps in fully understanding its relevance and importance. Due to the fact that Nexus stresses a lot the Backlog Refinement practices, my expectation was that also the Definition of Ready would have been cited and addressed. Unfortunately it was not. A pity.
  4. Adhering and always stick 100% to integration practices is hard. It is not only about the discipline of the people involved in applying Nexus, several times it has to do with issues like environments stability, teams’ knowledge of specific sw-eng practices (e.g. Test-Driven Development, Code Refactoring, Continuous Integration, Coding Reviews, etc.), external dependencies, delivery pressure; this can hinder, at least during the very first sprints, the effectiveness of frequently creating an integrated potentially shippable increment. But, persisting is a good advice: “if it hurts do it more often

Leading4Innovation Talk

March the 14th I had the possibility to talk to Agile For Innovation conference in Milan, with my talk “Leading4Innovation”.

—–

Agile has literally disrupted the meaning of many of the key principles on which organizations are based: culture and organizational structures, value creation, power management, innovation.
it did that by giving them new forms and meanings.

A4I

It makes clearly visible how companies are struggling to distinguish between complicatedness and complexity, leading them to apply incorrect tools and approaches. A recent study by the London School of Economics shows how, in the 55 years prior to 2011, the complexity has increased by a factor of 6X, while the complicatedness has increased 35 times.

This inability to interpret, instead of persuading the management to promote approaches aimed at simplification, collaboration, transparency, led them erroneously towards the addition of new procedures, roles and levels of coordination, rules and controls.
It is precisely this excess of complication that negatively impacts corporate culture, making the decision-making process slow and cumbersome and significantly hindering the innovation process.

Not only.
It is the whole meaning of leadership that has changed; even more so when it is applied to the creation of new solutions and services, for a constantly changing market.

This talk wants to make a point of the appropriate tools, approaches and methods available to leaders who want to drive change and innovation in the organizations in which they live, by living in a complex context.

How much those leaders must be more connected to the life of the teams in the field, transform themselves into true connectors of work groups placed in different corporate “suburbs”, creating social platforms aimed at integrating knowledge, experiences and skills.

Here the slides of my talk. Enjoy!

 

WordPress Themes