Category Archives: Team Dynamics

How Long Should my Sprints be?

black_green_black_thin_2Author: Ram Srinivasan

When organizations are adopting Scrum, they are always confronted with how long their Sprints should be. Scrum merely provides guidelines that Sprints can be anywhere from 1 week to 4
weeks long. The Sprint is a feedback loop, providing an opportunity for the  stakeholders and the Scrum Team to Inspect and Adapt (the product, and the way they work together, respectively).  The Sprint ends with a Sprint Review, an opportunity for the stakeholders to see what the Development Teams have built during the Sprint (i.e. the Product Increment, built as per the “Definition of Done” is made “transparent”), and discuss what might be built in the subsequent Sprint (“Inspect the artifact i.e. Product Increment, and Adapt the Product Backlog).

There are various factors which determine how long the Sprint should be. Shorter sprints have a higher transaction cost associated with them (e.g. – if the team has one week sprints, they may have four planning, review and retrospective meetings in four weeks, but if they have a four week sprint, they may only have one planning, review and retrospective meeting). Longer Sprints have a higher holding cost, and possibly also increase the risk by decreasing the frequency of feedback the team could get from its stakeholders. Also, longer Sprints will be associated with knowledge decay, if all “how to build the increment” is done during Sprint planning, not to mention that a team doing that will fail to capitalize on the knowledge that they have gained during the sprint.   It is hard to quantify “knowledge decay” and “knowledge gained” so for the sake of simplicity, let us just consider the transaction cost and holding cost alone in determining the duration of the Sprint.

This is a “U-Curve” optimization problem and for most teams a two week cycle optimizes the transaction cost and the holding cost associated with Sprints. However a two-week cycle may not work well for everyone. These are some of the factors that you may have to consider before deciding on the duration of your Sprint

  1. Stakeholder’s Risk Tolerance: How long can the stakeholders wait before getting anxious to see the working Product Increment? Lesser the risk tolerance, shorter the sprints.
  2. Market competition and market demands: Are you in an industry where your competitor is releasing a new version of their product every week, or may be multiple times a week? Not only should you have a robust “Definition of Done”, but you should also consider a shorter time frame for your Sprints. If you are in an industry where you have specific launch windows (e.g. educational industry, where the launch window is typically the Summer and Winter breaks), may be you can afford longer Sprints
  3. Complexity of your product: Scrum tries to mitigate risk by making the Product Increment transparent at the end of the Sprint. It might be tempting to think that more complex the product is, the longer the Sprint should be. More complex the product, greater the risk, and contrary to the popular belief, shorter Sprints provide better risk management opportunities. It may sound like it would be challenging for the team to build a meaningful Product Increment with a short sprint, but with a good Product Owner, big features can be sliced to multiple “micro-functionalities” and with that, the teams should be able to build a meaningful Product Increment.
  4. Size of the team/number of teams working on the product: Scrum does scale to multiple teams, and it is definitely possible to have multiple teams working on the same Product (Backlog) to create one Product Increment at the end of the Sprint. More teams working on the same product need a tighter feedback loop and again, contrary to the common belief, a shorter Sprint would give them a tighter feedback loop and would help them build the right product. Beyond shorter sprints, good technical practices (like Test Driven Development, Continuous Integration, etc) should also be followed to make sure that the product being built is a high quality product.

Coach’s Experience Report: Putting LeSS Teachings to Work

black_green_black_thin_2

craig_gene_reducedThe following Coach’s Experience Report describes various teachings of Large Scale Scrum (LeSS) framework in the context of their practical use by Agile Coach. What is below does not represent a single case with a single organization or company. Rather, experiences with multiple organizations, under different conditions are being described. By the same reasoning, not for every organization, whose experience is being drawn upon in this report, all of LeSS teachings that are described below, have been experimented.


Coach’s Discovery: Scrum teams have been struggling to gain autonomy and independence due to close monitoring and constant involvement of line management. Teams’ decisions, made during sprint planning were continuously overruled by management. Mandatory requests coming from management were frequently in conflict with priorities coming from Product Owners. Teams – were unable to conduct sprint retrospectives privately and safely, with management insisting on its presence in ceremonies and/or reviewing retrospectives’ outcome.

LeSS Teaching by Coach: Tylorian Carrots & Sticks used to be effective during American Industrial Revolution, when they were applied towards people that performed mundane, unskilled, manual labor. But in modern work settings of the 21st century (for the most part) don’t work, if applied toward intellectual workers. Command & Control behaviors suppress individuals’ willingness to explore and innovate, discover and experiment; they demotivate and demoralize workers, and therefore lower productivity.

Senior management needs to order fist-level line management to step back and allow teams norm and gain autonomy and independence. Close oversight and supervision will not allow teams to fully explore their potentials and achieve higher productivity.

Overall Result: Positive. Many teams have been liberated from Management Type X and have been treated with Management Type Y, instead.


Coach’s Discovery: Team members were expected to work closely together, share knowledge, help each other grow complimentary expertize. Teams were also asked to deliver together, “as a whole”, at the end of each sprint, and demonstrate shared ownership and swarming during sprints.   Team members were expected to take turns in a driver’s seat during showcases, to equally gain visibility in the eyes of Product Owners and customers.

But at the same time, each team member was being stack-ranked, during an individual performance appraisal, against his/her own team members, as well as against members of other, neighboring teams. Each ranked individual understood that he/she competed with other team mates for discretionary money that would have to come in the form of a bonus at the end of year. As it came closer to mid-year reviews and end-year reviews, teams dynamics worsened and bad behaviors were observed, practically, inside every team: less collaboration, emphasis on private ownership and individual deliverables, selfishness, blame-gaming and finger-pointing. As a result, teams’ velocities dropped, quality went down, and customer satisfaction was lowered.

LeSS Teaching by Coach: “The idea of a merit rating is alluring (as per S. Deming)”. Individual performance appraisals, linked to monetary incentives lead to demotivation, loss of enthusiasm and bad behaviors, such as internal competition, rivalry, selfishness and organizational degradation. Having individual performance appraisals, linked to distribution of discretionary monetary incentives, such as bonuses and salary increases, worsen a situation even further.

Overall Result: Mostly Negative. Line management did not except the fact that merit rating and individual appraisals had such harmful downstream effect on teams’ dynamics and cause organizational degradation. Senior management seemed to understand that the problem existed and was serious, but was still too hesitant to ‘rock the boat’, as many fundamental organizational norms and policies, many of which set by HR, would be challenged. In rare situations, however, management was able to emphasize team performance and collective results as main attributes of individual performance/results.


Coach’s Discovery: Recently trained teams fell under close surveillance and scrutiny by line management. Line management viewed agile/scrum, as a magic wand that would miraculously resolve all their existing problems. Management started paying too much attention to metrics (e.g. Velocity) and set unreasonable expectations for teams’ productivity during initial sprints. When teams initially failed, management blamed agile/scrum for failures, instead of treating it as a “mirror” that just painfully reflected existing broken processes.

 

LeSS Teaching by Coach: In Scrum, when a team just gets trained and is set sail, Private Sprints with “Fake” Product Owners (if a real one is identified yet) are recommended. Why? A team may want to practice/dry run scrum dynamics (roles, artifacts, ceremonies, feedback loops) but may not necessarily want this information be publicly disseminated across an organization, to avoid premature judgments and “mis-measurements of success”. A team is not obligated to announce to the rest of the world that they are experimenting new ways of working UNTIL everyone who is involved is ready and comfortable.

Overall Result: Positive. Teams no longer viewed the last day of scrum training as a commitment point, at which they had to announce to the rest of the organization that “they were agile now”. Teams became more comfortable to transition into new dynamics, and did it gradually, while “playing it safe”, before publicizing their intentions or results. In cases, when a real Product Owner was not immediately available, teams used another surrogate to play this role (e.g. Senior BA or SME).


Coach’s Discovery: A team was experiencing a lot of distraction, coming from stakeholders and customers. Instead of going to Product Owner with requests, customers went directly to the team. Frequently, competing priorities arose: a solution that addressed one request conflicted with a solution that addressed another request. Product Owner, took advantage of his overly proactive clients, stepped back and did not do his job.

LeSS Teaching by Coach: When it comes to feature (scrum) team communication, there are three main types exist:

  • Requests: From Customers/Users and Product Owner
  • Prioritization: From Product Owner to Team
  • Clarification: Between Customers/Users and Team (also can come from PO)

Effectively, this allows for business requests to flow from various areas/departments of an organization to Product Owner but then to be prioritized and fed to a team/backlog by Product Owner himself, in a controlled fashion. While a team is shielded from Customers’/Users’ ad hoc requests, sometimes competing, it still has a right to go to Customers/Users for clarifications.

Overall Result: Positive. The Team learned how to say ‘NO’ to customers and defer their requests to stakeholders. Product Owner was ‘forced’ to step up to the plate and practicing one of his key responsibilities – being voice of a customer, facing a team.


Coach’s Discovery: An organization had wide geographic distribution, with technology resources present in India, Eastern Europe and South America. The long-standing goal of outsourcing was to find the cheapest resources for a single specialty. For example, front-end Java developers were all sourced from India, Flash and UI experts – from Eastern Europe, architects – from Argentina. This has caused a lot broken communication and unnecessary coordination between feature team members: language barriers, geo- time-zone distribution, etc.  Also, end-customers were from the US, and this further added to complexity. Inefficiency of highly distributed teams, trying to coordinate ceremonies and optimize time overlap, was painfully noticeable.

LeSS Teaching: Given today’s global market place, geographical distribution of skilled workers is practically inevitable, for most companies. However, when it comes to teaming it is critical to avoid geographical distribution within a single team. Companies should support collocation of members of the same cross-functional team (note: even with the latter approach, doing this with componentized teams presents other problems). Also, bringing business (stakeholders, SMEs, Product Owners) closer to teams, is highly desirable.

Overall Result: Partially Positive. The leadership agreed to reconsider the current geographic collocation strategy. Having a group of single specialty experts located in one place, communicating across many time zones, with another group of single specialty experts, became a less preferred option. The leadership started to see more value in collocating individuals, based on their needs to work together, on same features. At first, it became more expensive, to procure certain expertise, where it was not as abundant and its cost was higher (e.g. Flash developer in India), but over time, increased efficiency and higher rate of business value output by each team made changes worthwhile.


Coach’s Discovery: During initial stages of agile transformation, senior leadership came to realization that by restructuring their organization to improve overall organizational performance, some internal “waste management” activities had to be done. Specifically, it became clear that certain processes, artifacts and roles were redundant, unnecessary and costly. As such they had to be reduced or removed from the system, altogether. This raised a particular concern for senior management, as removing certain elements of organizational structure could become too politically inflaming. For example, an excessive amount of business analysts and project managers (PMO) represented two pretty thick organizational layers that were primarily focused on producing heavy documentation and less- than-reliable reporting, respectively. Reducing these two layers would effectively mean downsizing certain individuals – something that could loudly resonate across the rest of the organization.

LeSS Teaching: Organizational Leadership needs to understand the difference between Local Optimization (e.g. improving performance of a single organizational layer, functional silo, reporting structure) and System Optimization (e.g. improving performance of an entire system). Looking at an organization from a stand point of System Optimization, an organization should care to provide Job Security to its employees, not Role Security. Ultimately, the goal of any organization is to continuously strive towards improving its efficiency, not providing safe haven for roles that make it [organization] less efficient.

Further, from System Optimization perspective, it is wiser to support the idea of not having individuals that are all just Specialists in a particular field or domain; an organization needs to have a good amount of Generalists to avoid workflow management dysfunctions and workflow bottlenecks. Presence of T-shaped individuals are highly desirable.

Overall Result: Positive but WIP. While removing organizational waste, senior leadership tried to strike a happy balance between simplifying organizational structure and removing redundant/unnecessary roles on one end, while trying to provide job security and alternative career paths for some knowledgeable and highly qualified individuals.


Coach’s Discovery: After more than a dozen of sprints, a group of feature teams still could not show any progress in their ability to deliver potentially working software at sprint-end.   At the end of each sprint, teams still produced code that needed additional testing, test automation activities, integration with code of other teams, extensive UAT, and other “Udone” activities. The initially proposed Definition of Done (DoD), at the time when teams got trained, did not change much and before releasing to production, teams still required at least one ‘hardening’ sprint.

LeSS Teaching: As a feature team matures, gradually, it should extend it definition of “Done”, to bring itself closer to a point, where, upon finishing a sprint, it makes its deliverable production-ready.

Overall Result: Partial Success. The teams was encouraged to identify during retrospectives at least one or two elements of DoD that were either missing or needed an improvement. Based on this, the teams were able to gain some momentum and with every subsequent sprint improved production readiness of their code.   However, there were certain organizational impediments that still prevented teams from delivering faster: certain external dependencies on organizational layers that were “outside of agile sphere of influence” – they prevented DoD to become fully inclusive.


Coach’s Discovery: Individuals that have been elected (or appointed) to the role of Product Owner, did not have time to do the job. They were either too senior within an organization “to deal with IT directly” or had already too much on their plate to take on, yet another full time role of Product Owner. This created a serious gap that made scrum extremely ineffective and overall agility low. To fill this gap, Product Owners found other people, other person within their own reporting structure to fulfill this role. They delegated most of PO responsibilities to this new, artificially created role of Product Owner “proxy”.   This brought about a lot of dysfunction and hindrance to the process as “proxy” did not have the same level of empowerment as a real PO.

In some situations, existing terminology that had a completely different purpose and meaning was overloaded. For example, Area Product Owner (LeSS term) was used to describe a role that did not fit the definition of Area PO. Effectively, Area PO term was used to describe the role and behavior of PO “proxy”.

LeSS Teaching: A business person that represents a single area of a complex product is called Area Product Owner. Area PO is in close communication with other Area POs, responsible for other areas of the same product, as well as with Product Owner (main person) that oversees an entire product. Area Product Owner is not to be confused with an ill-defined role of Product Owner Proxy. The latter term is not really defined in Scrum. This term exists in places, where a real PO is not able or not willing to do his job (no time, not enough interest/motivation). PO-proxy, is PO’s surrogate that interfaces with team(s) to mimic PO (minus authority) – it is an unnecessary organizational layer.

Overall Result: Situational Success. In situations, where organizational structure (on business side) was relatively flat, the success of identifying an effective Product Owner and bringing him closer to teams was much higher.   In situations, where business organizational structure was more complex, with multiple reporting layers, the success of identifying Product Owner that would be equally knowledgeable, empowered and engaged were lower. Another consistent observation was that every time Product Owner came from middle organizational tier (e.g. Operations, a.k.a. not true end-customer) chances were higher that the role of “proxy” would emerge.


Coach’s Discovery: This was a large organization, with complex structure, heavy tooling and internal processes that was looking for scaled agile solutions to accommodate its “internet historic complexity”. The organization was looking for agile frameworks that would seamlessly fit its existing dynamics, while not requiring too many changes. The organization was not really trying to improve existing dysfunctions and repair problems. Instead, the organization was trying to look for ways to “improve” its existing condition by overlaying agile norms, terms and principles on the top of its current system. This included introducing more agile roles, ceremonies, processes, organizational layers, handovers and bureaucracy on the top of what existed already. Over time, it worsened the situation even further, not improved it.

LeSS Teaching: In order to improve organizational agility and be able to implement agile at scale (e.g. have more teams being involved in the same large scale Scrum, as opposed to having many unrelated teams attempting to do their own scrum), organizational De-Scaling is required first. This includes: removing organizational waste, lowering bureaucracy, flattening organizational structure, removing non-value adding roles, reassigning responsibilities to key roles, discontinuing norms and behaviors that have been statistically proved as harmful.

Overall Result: Partial Success. The organization understood principles of LeSS, especially, it core Lean Thinking. The organization understood that organization descaling (removing what exists, instead of adding more to it) should come before any attempts to scale agility across broader organizational boundaries. However…the organization was still not fully prepared to deal with all consequences of waste removal. There were concerns with political and legal implications of such bold actions.


To Be Continued:

TBD – more Coach’s Discoveries and respective LeSS Teachings that were used to remedy problems:

  • LeSS Teaching: The following elements and attributes lead to “The Contract Game”: componentized organizational structure, heavy/non-negotiable documentation, bureaucracy, functional silos, lack of cross-functional experts (T-shaped people), merit ratings/performance appraisals/bonuses or other forms of local optimization (e.g. harboring teams of BAs, PMs)
  • LeSS Teaching: Lack of proper understanding of cross-functional, customer-centric feature development, leads to creating fake “products” or “projects” (e.g. server-side work, back-end coding, database, UI). This further leads to creating fake project portfolios and fake project portfolios. This further creates needs for excessive coordination that mandates unnecessary roles of fake portfolio managers and alike.
  • LeSS Teaching: By analyzing system’s Feedback Loops: Velocity, Bugs, # of Developers, Budget Supply – it becomes clear that, for example, the increase in funding (budget) does not necessarily translate into increased velocity or improved product quality. Negative Feedback Loops are just as important to consider as Positive Feedback Loops: more money may help hire more developers that will produce more bugs.

Agile Coaching – Lessons from the Trenches

black_green_black_thin_2Authors: Gene Gendel and Erin Perry

High performing organizations, high performing teams, and high performing people do not often happen organically. They are a return on investment.

We’ve spent time in the trenches, both giving and receiving coaching, at organisations of all sizes: from small startups to large enterprises. In this article, we will use our hard fought experience to shed light onto Agile Coaching. First, we will take a step back, helping define what being an Agile Coach means and what skills are necessary to be successful in an organization. Then, we’ll examine patterns and anti-patterns for both in-house coaches and coach-consultants. We will shine light on how to enable coaches to be successful in your organization…

Read the rest of this post: http://www.infoq.com/articles/agile-coaching-lessons

Unspoken Agile Topics

black_green_black_thin_2Author: Gene Gendel

This paper, originally written in February 2013, brings to light some of the least-discussed topics and consequences of “broadband agilization” that currently take place in the industry. The materials of this paper are subdivided into two general sections:

  • The first section describes certain impacts that Agile has on individuals and their personal career advancements.
  • The second section describes organizational-level Agile impacts that pertain more to client companies that undergo Agile transformation, as well as service-providing vendor companies that deliver Agile-transforming expertise to their respective clients.

The reader will most likely focus on the section that best represents his primary interests and concerns. However, it is recommended that both sections are read in full, as in unison they create a better holistic perspective of the industry changes brought about by Agile-mania.

The reader will be taken out of his comfort zone and forced to think more uninhibitedly and realistically about those aspects of Agile that may not be as obvious and are not explicitly covered in other literature…

– See more at: https://www.scrumalliance.org/community/articles/2014/july/unspoken-agile-topics#sthash.OczxUhvv.dpuf

Scrum and Kanban at the Enterprise and Team Levels

black_green_black_thin_2

Author: Gene Gendel

Scrum, as the most structured of all Agile frameworks, is a great way to ensure predictable, strategically planned, incremental product delivery. Scrum ensures good responsiveness to frequently changing market demands. Although nonprescriptive, Scrum clearly defines certain roles, responsibilities, and ceremonies.

Kanban, for the most part, is silent about certain aspects that Scrum suggests explicitly (e.g., team size, velocity, story point estimation, timeboxing, Scrum ceremonies, etc.). Kanban is less structured than Scrum. Being a true pull-based system, Kanban is a great work-flow visualization tool that can be effectively used for WIP management. It is a great tool to use in production support or the gradual redesign of legacy systems; business priority-driven new product development is not the main goal….

Feb 1-3, 2016. Certified LeSS Practitioner in New York

black_green_black_thin_2

Author: Gene Gendel

IMG_0336

Event Details

 Large-Scale Scrum (LeSS) is a framework for scaling agile development to multiple teams. LeSS builds on top of the Scrum principles such as empiricism, cross-functional, self-managing teams and provides a framework for applying that at scale. It provides simple structural rules and guidelines on how to adopt Scrum in large product development.

The Certified LeSS Practitioner course is an in-depth course covering the LeSS principles, framework, rules, and guides. It provides essential information for adopting and continuously improving LeSS in your product development group using various thinking tools, organizational tools and action tools. The course contains an overview of LeSS, stories on LeSS adoptions, exercises and extensive Q&A sessions to ensure we discuss the topics most of interest to the participants.

The Certified LeSS Practitioner course is for anyone who is involved a large agile adoption. Basic Scrum knowledge is expected. This can be achieved by attending a Certified ScrumMaster courseProfessional ScrumMaster course, or by thoroughly reading Scrum introduction material such as the Scrum Primer and practicing Scrum.

(To view photos and summary of the previous LeSS course (September, 2015) in NYC please click here.)


Registration:


Agenda

In this highly interactive course, participants will get a thorough introduction to LeSS, a deep understanding of the underlying principles and the concrete practices to help them to implement LeSS in their own organization.

Day 1

  • Introduction
  • The History and Overview of LeSS
  • LeSS Principles
  • Organising by Customer Value

Day 2

  • Organisational Impact
  • Feature Teams
  • What is Your Product?
  • The Product Owner Role in LeSS
  • Defining Done
  • Product Backlog

Day 3

  • The role of Management
  • Adoption in your Organisation
  • The ScrumMaster Role in LeSS
  • LeSS Sprint
  • Product Backlog Refinement
  • Sprint Planning
  • Sprint Review & Retrospective
  • Coordination & Integration
  • Technical Excellence
  • Working with multiple sites

There will also be multiple opportunities for participant-driven Q&A sessions.

After course completion

All participants will be a Certified LeSS Practitioner and will get an account on the less.works website. Here they can find additional information about LeSS, share course information and stay in contact with the other course participants.

All participants get access to the draft of the new upcoming book: Large-Scale Scrum: More with LeSS.

About the trainer

This workshop will be led by Karim Harbott.  Karim is an experienced enterprise Agile Coach and trainer. He has guided many large organizations through ‘Agile transformations’ and helped them on their journey to continuous improvement in their product development capability.

As a former Head of Scaled Agile at McKinsey & Co. Karim is comfortable operating at all levels of the organization, but specialists in the enterprise level and organizational redesign.

A trained business and executive coach, Karim is well placed to build internal capabilities in an organization; be it developing Agile Coaches, ScrumMasters, Product Owners, Developers or working at the C-level to help leaders make the changes necessary to enable true, large-scale business agility.

Karim is a Certified Scrum Coach, Certified LeSS Trainer, SAFe Program Consultant and Accredited Kanban Trainer.

  IMG_2289 IMG_2307 IMG_2304 IMG_2293 IMG_2292 IMG_2291 IMG_2290 IMG_2296 IMG_2298

Fallacies of RAG Reports

black_green_black_thin_2Author: Gene Gendel

How Much Can You Trust Your Navigation Instruments?

1944…Imagine you are flying back home from a risky military mission…If you are not able to vividly imagine what this experience is like, please follow this link:  http://www.keystepstosuccess.com/2016/01/b-17e-bomber-tight-coupling-of-color-coding-with-numerical-data/

RAG System in Conventional Project Management

Today, the RAG system is still widely used in conventional project management, as the method of rating   issues or reporting on status. The approach is based on the same basic colors: Red, Amber (or Yellow) and Green…

See more at http://www.projectmanagement.com/articles/315648/The-Fallacy-of-Red–Amber–Green-Reporting