Category Archives: Norms & Principles

NYC Salary History Ban – What Does it Mean?

On October 31st, 2017, the Mayor of NYC Bill de Blasio signed the new Law, prohibiting companies in New York City from asking, searching or verifying a job applicant’s salary history during the hiring process.  From now on, violation of this law, by any NYC-based employer, will be viewed as an “unlawful discriminatory practice.”
(Please, read more about the NYC Salary History Ban.)

Below are some potential, real-life consequences of this Law, as it applies to any employees-candidates and any NYC-based employing organizations:

  • If an individual has worked for a long time at the same company and, while there, has acquired a lot of practical experience/skill set, but unfortunately was not able to secure compensation that was a fair reflection of her capabilities/contribution, she may now seek an employment at another company with an increased self-confidence and without worrying that prior, unfairly low compensation, will be a low benchmark for her future offer.
  • If an individual is a self-starter/entrepreneur who has acquired a lot of knowledge/experience in ways, other than formal employment (e.g. self-paid study or research) and by doing so, has significantly increased her professional maturity, she may more confidently leverage these rightfully owned credentials , when negotiating a salary with her next employer.
  • If an individual’s goal has always been to remain as a hands-on contributor (she loved what she did, and did not want to lose her practical skills) and was never aspired to seek a promotional/managerial position – something that usually leads to higher compensation, she may do so more freely, without worrying that she will miss out on a “compensation-bargaining-chip”, at her next job interview.  This also means that employees will be more experience/knowledge-seeking and less promotion-seeking, as it is really an experience, not prior organizational position that define their true value.  (note: often, promotions are associated with loss of hands-on expertise, in favor of managerial/administrative responsibilities).
  • If an individual’s full compensation consists of base salary and discretionary bonus (the latter, often being too subjective, as it is based on individual performance appraisals, efficiency of which have been proven as ineffective for decades), with a bonus, representing a significant chunk of her full salary, she does not have to be concerned so much with her next employer, trying to count in only her base salary, as as a ‘benchmark’ , while making an offer.  This will also, hopefully, drive companies towards paying higher base salaries, and away from subjective bonuses.
  • Recruiting agencies and staffing firms will have fewer opportunities to ask unethical questions (“how much were/are you making at your prior/current job?”), something that is often delegated to them by companies’ HR departments, with the ladder not wanting to be directly associated with unethical behaviors.  Further, this may lead to more transparency and direct interaction between hiring managers and candidates.
  • Companies-employers would have to improve their vetting/interviewing/hiring approaches significantly, by incorporating validation methods and more reliable/objective assessments of candidates, to prevent under-qualified, low-skilled individuals (some of whom may have strong self-selling/negotiations skills and expertise with “talking the talk”) from slipping through companies’ doors and causing internal problems.  This may require conducting more practical tests, real-life simulations and hands-on exercises, administered directly by hiring areas and peers-coworkers. Further, this could also, reduce the amount of subjective/administrative, error-prone and often unnecessary screening processes, usually handled by companies’ departments that are least benefited from hiring high-quality candidates, and at the same time, most benefited from creating and administering actual processes.

In all the above situations, the main compensation-determining factors will be:

  • From an employee’s perspective: her professional competency, skill/mind set, ability to produce tangible results and deliver business value
  • From an employer’s perspective: ability to properly assess a candidate for what she is worth (not for what she was price-tagged in her past) AND clear understanding of how much an employer is willing to pay for a given job/to a given candidate

Lastly, does the new Law have any relevance to internal hiring situations (when employees move around a company)?  

According to the Employer Fact Sheet, the Law does not apply directly to internal re-employment (also, for most companies, employees’ compensation is transparent to hiring managers of the same company).

However….  There could be some indirect implication: NYC-based employers will probably realize that properly educated (know the Law) employees will have more confidence to ask for a more significant compensation increase, when they seek a new employment internally.  The new “compensation-bargaining chip” for employees will be their increased self-confidence and assurance that they will have a better chance of getting higher compensation elsewhere, irrespective of their current compensation, should their internal efforts not materialize.  As a result, to avoid losing good people to their competitors, employers will probably revisit their compensation increase standards, for internally transferred employees.

Addressing Problems, Caused by AMMS

For many organizations, Agile Maturity Metrics (AMM) have become a trusted way to measure improvements of agility at personal (individuals), team and organizational level.

However, it is not always apparent that AMMs are different from Agile Check-Lists (e.g. classic example of Scrum Check list by H. Kniberg) in ways that may actually lead to problems and dysfunctions:

Check-Lists are just a set of attributes that are usually viewed on-par with one another; they are not bucketed into states of maturity (other logical grouping could be applied though)

On contrary, AMMs usually place attributes in buckets that represent different states of maturity that follow one another, sequentionally.

With very rare exceptions (favorably designed organizational ecosystems), there are three potential challenges that companies face, when relying on bucketed AMMs:

1 – System Gaming: If achieving a higher degree of agile maturity is coupled with monetary incentives/perks or other political gains (for many companies that are driven by scorecards and metrics, this is the case), there is will be always attempts by individuals/teams to claim successes/achievements by ‘playing the system’, in pursuit of recognition and a prize.

2 – Attribute-to-Maturity Level relationship is conditional, at most: Placing agile attributes in maturity buckets implies that attributes in higher-maturity buckets are always more weight-carrying than attributes in lower-maturity buckets. However, this is not always a fair assumption: weight/importance that every organization/team places on any given attribute, while defining its own maturity, is unique to that organization/teamFor example, for one team, “…being fully co-located and cross-functional…” could be much more important than “…having Product Owner collocated with a team…” For another team, it could be the other way around.

3 – Correlation between attributes is not linear, at system-level: Regardless of buckets they are placed in, many agile attributes are correlated systemically and impact one another in ways that are not apparent, until system modeling techniques are applied.  For example, placing “Scrum Master is effective in resolving impediments”attribute in a maturity bucket that comes before the maturity bucket with “…Organization provides strong support, recognition and career path to Scrum Master role…” attribute, dismisses the real cause-and-effect relationship between these two variables, misleads and sets false expectations.

To avoid the issues described above, it would more advisable to treat every identified agile attribute as a system variable, on-par with others, while assuming that it has upstream and downstream relationship with other system variables.  In many situations, instead of spending a lot time and resources on trying to improve a downstream variables (e.g.  trying to understand why it is so difficult to prioritize a backlog) it is more practical to fix an upstream variable that has much deeper systemic roots (e.g. finding an empowered and engaged product owner who has as a right to set priorities).

Below, is the list of agile attributes (a.k.a. system variables) that are logically grouped (check-list) but are not pre-assigned to levels of maturity (all flat).   Some examples  of suggested system-level correlation between different attributes are provided (cells are pre-populated).

Please, click on the image to download the matrix to your desktop, amend the list of attributes if you feel that your situation calls for modification, and then use “Dependency on Other Attributes?” column to better visualize system-level correlation between the attributes are of interest to you and other related attributes (some examples are provided).

10/13 – LESS TALKS: MEETUP – Working LeSS Brings Great Results (Case Study)

Tonight -a  great presentation by Malik Graves-Pryor of Natoma Consulting, as he shared how his company leveraged LeSS to achieve  stunning results, while facing challenges and learning lessons.

Malik’s Summary

At the Thursday October 12, 2017 NYC Large Scale Scrum Meetup, Malik Graves-Pryor shared his company’s LeSS case study, “Web and Mobile Applications Agile Transformation”. He covered the extensive issues the company faced at the beginning ranging from only 1-2 releases a year with hundreds of defects, and how they transformed over the course of several months to an organization that released monthly, and then continuously, with low defects and high customer satisfaction and engagement.

The discussion covered the merger of the Sales and Product Management Pipelines, adoption of technical practices leading to a DevOps-focused culture, how to take the necessary steps to build trust and cooperation within the organization, as well as the road-map they used to iteratively migrate the organization to continuous integration and deployment.

The interactive discussion spanned two hours with attendees raising questions and issues about the case study, as well as correlating them with their own challenges and aspirations.

Presentation deck is available at  Natoma Consulting website for download.

 

What Should Agile Leadership Care About?

Agile frameworks (e.g. Scrum, Kanban, XP), individuals’ roles & responsibilities, processes & tools, metrics & reporting, burn-up charts, estimation techniques, backlog prioritization, agile engineering practices, agile maturity models etc. – all of them are important attributes of a typical agile transformation.  However, NONE of them are first-degree-of-importance system variables that are responsible for transformation success.  Most of them, are good superficial lagging indicators of agility but they are all corollary (secondary and tertiary) to another much more important system variable.

What is the most important system variable that defines a company’s agility?  It is Organizational Design –  the most deeply rooted element of organizational ecosystem that defines most of system dynamics.

When organizational leadership decides to take an organization through an agile transformation journey (it could take years, sometimes), it [leadership] needs to acknowledge that real, sustainable agile changes are only possible if deep, systemic organizational improvements are being made.  For that, leadership needs to be prepared to provide to its organization much more than just support in spirit, accompanied organizational messages of encouragement and statements of vision.  Leadership must be prepared to intimately engage with the rest of an organization, by doing a lot of real “gemba” (genchi genbutsu (現地現物)) and change/challenge things that for decades, and sometimes for centuries, have been treated as de-facto.

What does it really mean for leadership to engage at System Level?  First, it is important to identify what a system is: what are a system’s outer boundaries?  For example, one of the most commonly seen mistakes that companies make when they decide on “scope of agile transformation” is limiting its efforts to a stand-alone organizational vertical, e.g. Technology – and just focusing there.  Although this could bring a lot of local (to IT) success, it may also create unforeseen and undesirable friction between the part of an organization that has decided to change (IT) and the part of an organization that decided to remain ‘as is’ (e.g. Operations, Marketing).  For example, if Scrum teams successfully adopt CI/CD, TDD or other effective engineering practices that enable them deliver PSPI at the end of every sprint, but business is not able to keep up with consumption of deliverables (too many approvals, sign offs, red tape) then the whole purpose of delivering early and often gets defeated.  Then, instead of delivering to customers soon, in exchange for timely feedback, teams end up delivering in large batches and too far apart on a time scale.

A successful Agile Leader must treat an organization, that is expected to transform, as a sushi roll.  Just like seaweed alone does not provide a full spectrum of flavors and does not represent a complete, healthy meal, one single department (e.g. IT) is not sufficient enough to participate in agile transformation efforts.  Other organizational layers need to be included as well, when identifying a slice for agile transformation experiment.  A slice does not have be too thick. In fact, if organizational slice is too thick, it might be too big to “swallow and digest”.  But still, even when sliced thinly, an organization must include enough layers, to be considered as a ‘complete meal’.

Note: A great example of treating an organization as a sushi role, while making it more agile, is Large Scale Scrum (LeSS) adoption.

So, what are some key focus areas that every Agile Leader must keep in mind, while setting an organization on agile transformation course?

  • Location strategies. Geographic locations.
  • HR policies (e.g. career growth opportunities, compensation, promotions)
  • Budgeting & Finance
  • Intra-departmental internal boundaries and spheres of influence
  • Organizational Leadership Style
  • And some other areas that historically have been considered as …untouchable

All the above listed areas are defined by Organizational Design and can be better understood through self-assessment, done by organizational leaders at all levels.

Agile Organization, as a Sushi Roll

When we ask an experienced Scrum developer what defines a good User Story, the answer we hear almost immediately is that “…every user story must be INVEST-able…(taken from B. Hartman’s post)”.

When we further elaborate on “INVEST” part, we hear that splitting user stories should be done Vertically (along features), not Horizontally (along components or applications layers).  Why is the latter condition so important? Because when split vertically, and cross-cutting through multiple components, a user story has a much higher chance of representing a potentially shippable product increment (PSPI).  Delivering, UI/UX alone, or business layer alone, or database alone, does not present value to a buying customer.

Frequently, we hear the analogy of a sushi roll, when describing story slicing: “…every User Story must represent thinly sliced sushi roll that provides taste and flavor of multiple layers (caviar, seaweed, rice, tuna, avocado, etc)…


…Now, imagine an organization that is undergoing agile transformation.  Predominantly (statistically), transformation efforts stem from Technology, where agile improvements come in the form of introducing good engineering practices, such CI/CD, TDD, unit testing, test automation, automatic deployments, etc.  But technology alone, is just one layer of an organizational sushi roll.  Sure, just like seaweed alone, it may be tasty enough for starters, but without adding additional flavors, it is not a complete, healthy meal.

Other organizational layers need to be included as well, when identifying a slice for agile transformation experiment.  A slice does not have be too thick. If organizational slice is too thick, it might be too big to “swallow and digest”.  But still, even when sliced thinly, an organization must include enough layers, to be considered as complete meal.

What are some of those layers?  Let’s consider a few:

Business & Operations:  it is imperative to have real customers intimately involved in agile transformation efforts and making them closely aligned with technology partners. This requires identifying and providing a strong support for some key agile roles, such as product owner, stakeholders and SMEs.  Often, this requires organizational realignment and changes to sphere of influence.

HR:  Subjective monetary rewards that are based on individual performance assessments and fueled by invisible internal competition among employees, must be discontinued, in favor of incentives that promote teams’ collective ownership and performance.  An organizational slice that wants to become more agile will have a much higher chance for success if HR policies were genuinely supportive of the initiative of the efforts.

Budgeting & Finance: For agile teams (Scrum, Kanban) that use adaptive planning and iterative development, and continuously have their work re-prioritized by business, it is imperative to have flexible budgets (“flexible spending”).  By unlocking a rigid budget corner of what is known as Project Management Iron Triangle (budget, scope, timeline), technology dramatically increases their chances to do research or conduct new experiments, if an opportunity presents itself (often, unexpectedly).  There is also a higher chance that more Scrum teams would be built out faster, if budgets were flexible and not done as ‘budgets against the wall’ (‘the world ends on December 31st’) – more flexibility to acquire new talent.

Real Estate & Facilities: Having agile teams co-located under the same roof is a huge win: e.g. Scrum team dispersed around the globe is not as good as Scrum team placed on the same floor. (Note: Please, do not confuse a single Scrum team spread thin across multiple locations with multi-site Scrum product development, when many, whole teams are collocated but separated from from peers-teams by geography).

However, putting a team on the same floor is not sufficient.   Interior design must be supportive of team collaboration and dynamics: ‘caves & common’ (read A. Cockburn about XP), information radiation techniques (lots of whiteboard space, flip-charts), breakout areas, extra space to accommodate extended user community during sprint reviews, etc. – is all required.  It is unfortunate but common to see so-called Scrum team members sitting in a long single row, next to each other, spear-headed by a line manager (usually, a window seat), all joining a daily stand-up call by phone (while sitting!) and ‘reporting on status’, while staring at an electronic story board on their respective monitors.  Agile teams don’t want that.


As a summary, please consider the following quote that describes sushi-roll-like organizational design in Large Scale Scrum (LeSS), by C. Larman:

Grassroots of Modern Command & Control Behavior

Examples of Command & Control behavior can be historically traced back into centuries, to the periods of dictatorship, imperialism, monarchy, feudalism and even further back, to more primitive social systems.  However, for the sake of this discussion, let’s refer only as far back as Industrial Revolution of the last century.  Back then, workforce predominantly consisted of low-skilled laborers that performed routine, mundane physical work and managers-supervisors that were responsible for setting goals, assigning responsibilities, monitoring progress and praising-penalizing workers, based on individual performance of the latter (using “carrots & sticks” approach).  This type of management was a classic example of what is known as Taylorian Management (Frederick Taylor), according to which, there had to be clear delineation between individuals that performed work and individuals that controlled/managed work of others.  This type of human relationship in work settings was also later described as Theory X Management (Douglass McGregor), and it suggested that managers needed to use totalitarian and repressive style to ensure tight control over workers, because the latter would otherwise not work hard and efficiently enough.

…Fast forwarding to modern days…

Today, we still have many examples of Command & Control behavior that shape relationships among people in modern organizations.  This happens even in situations, where organizations have workers that are very highly skilled and intellectually advanced.  More frequently, this is seen in organizations that are at Laloux’s Orange state of maturity or lower.

While in part, modern Taylorian Behaviorism can be explained by long-lasting “cultural inheritance” that hopefully will wear off over time, it would be interesting to look closer at some specific root causes of modern-days Taylorian behavior.

Although not exclusively, the examples below, are more frequently observed between individuals that are related to each other by hierarchy (boss-subordinate).

Insecurity about own job. Worries about own career growth.

A manager does not feel secure about his own position.  This could be caused by company reorganization (e.g. merge, acquisition, flattening) and a manager feeling that his role may be reduced or eliminated.   This fear of becoming dispensable could be worsened by realization of personal incompetence and/or lack of professional knowledge.  This is frequently seen in situations, where managers, as they have progressed the hierarchical ladder, have given up their hands-on skills and became peoples’ managers.

Misunderstanding roles of other people

A manager does not keep up with evolution of roles and does not understand purpose/importance of some new roles that have emerged in a workplace.  As a result, a manager tries to “map” new roles to old roles and apply the same yard-stick to measure and manage a subordinate.  His own lack of understanding could be frustrating to a manager and, therefore, make him feel defensive in discussions of roles and responsibilities of his subordinates.

Compromised self-esteem and desire to protect own Status Quo

While being a part of a larger organization, a manager might be getting a significant portion of mistreatment, in the form of command & control behavior, from his own superiors.  This is where the desire to protect his own status quo and not to look defeated in the eyes of his own peers and sub-ordinates kicks in.  There is a growing need for self-redemption and the urge the relieve a built-up psychological stress.

Note: All three examples of the root causes of Command & Control behavior above, usually result in a manager becoming passive aggressive and seeking ways to discharge negativism onto others.  Typically, “others” come in the form of a manager’s own subordinates, with the latter becoming defenseless recipients of mistreatment.

“I am Great” competitive stance “Tribal Stage 3” (D. Logan)

With the attitude of “I am great and you are not”, a manager perceives himself as someone who is smarter and greater than his subordinates.  The person that acquires a managerial position, that is sometimes is just a result of skillful pursuit of a new vacancy (e.g. due to reorg, force reduction) and/or experience to navigate organizational political terrain, feels the need to demonstrate his superiority to others.  To continue being perceived as a super-star and to stay in a spotlight of all events that can further multiply his glory, as well as to be able to claim someone else’s credit (delivery, innovation, invention) as his own, a manager wants to keep his subordinates “at bay”, to prevent their independent advancement and autonomy.

Individual resentment and animosity towards other people

While not very common and rightfully speculative, there are situations when outside-of-work relationships or individual perception outside of working environment, define the relationship between a manager and subordinate.  Broken friendship, unsuccessful romantic relationship, differences in personal values, norms or beliefs – all can impact professional relationship at work.  A manager, who has an upper hand, may leverage his superiority to repress a subordinate, in retaliation to work-unrelated matters.  On top of being unprofessional, this behavior could be also viewed as “non-sportsmanship-like conduct”. 

I am Expert” distrusting stance (distrust in competence of others)

This could be viewed as the least “harm intended” manifestation of command & control behavior.  This is more commonly seen in situations, where a manager still has sufficient hands-on expertise (e.g. technical lead) and can-do work.  Viewing himself as a “super-doer-expert”, a manager usually prefers to “shut the door” and resolve all problems on his own, instead of trusting his subordinates to collaborate and come up with shared decisions.  A manager-doer prefers to make single-handed decisions, while controlling actions and interactions of other people, in a fear that someone’s failure will be perceived as his personal failure.

Below is System Modeling diagram-example that illustrates relationships Command & Control behavior with the reasons described above and some additional system variables that impact system dynamics.

Bad Choice of Verbs Associated with “Agile”, by EFL People

These days, almost everyone knows that organizations cannot “do” agile; they can “be” agile.  And today, this contrast is used not just by agile coaches and scrum masters.   Everyone likes building this fancy figure of speech in their daily lexicon: managers, analysts, developers.  Great!!!  Below is a snippet from Wikipedia, defining the word “agility“, using the most natural reference:  a human body.

From reading the definition, it appears that body agility is equivalent to a body fitness/health.  And if so,  it would be fair to assume that when we talk about organizational agility, we also talk about organizations, being fit and healthy (organizational fitness/health). Just like a body cannot “do fit or do healthy”, organizations cannot “do fit or do healthy”.

But while wrongfulness of “doing agile” is mostly admitted today, there are many examples of using other sophisticated synonyms of “doing” that hint to the fact that people are still NOT clear about what agility is.

As the title of this post suggests, and this is where the biggest irony comes from,  the most advanced EFL people (EFL = English First Language) have been making the most noticeable language omissions, while attaching “sophisticated corporate terms-verbs” (other than “do”) to the word “agile” 🙂 .

Below, is the list of verbs that are not advisable to be used in conjunction with the word “agile”:

  • “Implement Agile”
  • “Adopt Agile”
  • “Use Agile”
  • “Introduce Agile”
  • “Accept Agile”
  • “Follow Agile”
  • “Move TO  Agile”
  • “Transition TO Agile”
  • “Transform TO Agile”
  • “Install Agile”
  • “Administer Agile”
  • “Leverage Agile”
  • “Upgrade to Agile”
  • “Practice Agile”
  • “Establish Agile”
  • “Experiment Agile”
  • “Standardize Agile”
  • “Execute Agile”

What is advisable instead: is just to BE agile 🙂 .

05/26-28: Scrum Coaching Retreat | Kiev, Ukraine

2017 Scrum Coaching Retreat in Kiev  is in the books!!!  The event has brought together a few dozens of agile coaches and trainers from nearby and far away.

The participants came from different backgrounds and focus areas but due to everyone’s extensive experience in self-organization and self-management, got the show on the road very quickly.  After a short round of self-intros, each participant introduced a few topics that they wanted to discuss. By using a combination of dot-voting and affinity clustering techniques, the group came up with a handful of key topics that everyone wanted to deep dive into.  The group broke up into four teams, with each team picking one high-priority topic – to be worked on in consecutive three (3) sprints.

The team I joined (“Happy 7”) picked up the topic “How to influence decisions of senior management directly, from the bottom of organizational pyramid”.  The team consisted of experienced ScrumMasters, Team-level and Enterprise-level coaches.

The problem statement that defined our team’s effort was:

“There are so many instances, of challenges and obstacles that teams face, are not being heard at the top of a food chain.  And even when they are heard, often, original messages get distorted and lose urgency, as they travel up through multiple “translational” layers.  What can be done to fix this problem?  What techniques could be used to effectively segregate impediments that are local and can be resolved by teams and the ones that are systemic/organizational – and must be aggressively escalated upward?” 

The problem above has direct dependency on organizational design, specifically, on its thickness: the number of organizational layers between working teams (on one hand) and senior leadership/paying customers (on the other) – is a well-recognized challenge today.

Our working group has identified the following organizational design scenarios that define dynamics and human interaction in modern Product Development:

  1. Development teams and Product Owner belong to the same organization and end-Customer is positioned internally
  2. Development teams and Product Owner belong to the same organization and end-Customer is positioned externally
  3. Development teams represent Vendor-company and Product Owner represents Client-company and relationships between Vendor and Client are based on:
    • Out-staffing model – when a vendor provides human assets (developers) that are then owned by a customer, from management perspective, whereas legal ownership (e.g. insurance, taxes) is still by a vendor
    • Out-sourcing model – when an entire project gets outsourced to a vendor and a paying customer has no or minimal interaction directly with human assets (developers) that do work (most of communication flows through Engagement Management)

Interestingly, since many of our working group members had a lot of experience with #3 option above, the primary focus of our discussion was about how to bring closer senior leadership of paying customers and agile teams of delivering vendors, closer together, despite multiple “anti-agile” organizational layers that frequently reside in-between the former and the latter.

The ultimate result of our brainstorming was the invention of a non-commercial, collaborative game that was given the name of Influence Poker.

Our game’s purpose was:

  • To identify challenges that delivery teams often face
  • To classify challenges, based on origin, severity and implications
  • To discuss potential ways of resolving and/or escalating challenges
  • To ensure resolution ownership and transparency on its progress

Note: The initial contributors to the game creation were: Serhiy Lvov, Kiryl Baranoshnik, Artem Bykovets, Alexander Karitsky, Mark Summers, Jonas Mann and Gene Gendel .

The most serious organizational design challenge, when a paying customer engages with a vendor-company, is seen with an out-sourcing model.  Here, no matter how agile/robust technology teams are, their ability to deliver effectively is hindered by:

  • Involvement of Delivery Manager (usually, placed on a client site) who owns a relationship with a customer, serves as a single filter-channel of communication between a customer and teams, makes commitments and furnishes progress reporting on behalf of teams. The same person also streamlines feedback from a customer back to teams and frequently assigns work to team members.  This is usually accompanied by micro-management and command and control behavior.  The situation can be further worsened by the presence of Vendor Management function (customer side) that enforces SLAs, SOWs and other formal contracts between a customer and vendor: this just adds additional tension to a relationship and moves further apart end-customers and delivery teams.
  • Weakening of Product Owner role – the importance of this critical Scrum role gets downplayed, because a customer company no longer sees value in direct communication with technology teams.  Instead, Delivery Manager is treated as a single person, responsible for project delivery.  This dramatically narrows all communication media that are used in Scrum (holding events, sharing artifacts).

The above two challenges are inter-related through a positive feedback loop: the less disengaged Product Owner becomes, the more pivotal the role of Delivery Manager becomes.  The opposite is true too: strengthening the role of Delivery Manager, leads to further “excusing” Product Owner from stepping into the game, as Scrum requires.  This is a viscous, de-stabilizing loop that continuously weakens Scrum.

Please, look out for the Influence Poker.first official release that is coming soon! It may greatly help your teams visualize their organizational problems and discover potential workable solutions.

Note: For attendees and participants, here are additional shortcuts:

Sprint Length: Who Decides? How? Why?

What is the best Sprint length?  Who decides on Sprint length? Are there any exceptions?  What are some of the most common mistakes people make, when making decisions about Sprint length?

Let’s start from grassroots and answer the following basic question: “What is Sprint main goal?”  And while looking for an answer, let’s refer to the Scrum Guide, where the goal of each sprint is clearly described as “…increment (a.k.a. PSPI = potentially shippable product increment) that must be in usable condition and meeting DoD (Definition of Done)”.  From the Scrum Guide perspective, it is also clear that while being potentially shippable, an increment does not necessarily have to be shipped.  Why is it so? For PSPI to be shipped, it must also represent MMP (Minimal Marketable Product) and the decision about what is marketable comes only from Product Owner and it is based on several factors, including long-term strategy and economics.

(Note: End-of-Sprint deliverable, sometimes, is also referred to as MVP (Minimum Viable Product) and is described well by Roman Pichler here.)

Sprint Length and Release Economics

Speaking of economics, lets recall the relationship between Transaction Costs (Shipping) and Holding Costs, also described in “The Principles of Product Development Flow” by D. Reinertsen.  By analogy, if applied to Scrum product development, ‘batch size’ would represent a volume of PSPI and ‘cost’ would represent all combined efforts, associated with  production deployment (e.g. integration, end-user training, marketing announcements, etc.).

How does this relate to Sprint length?

While each Sprint is supposed to produce PSPI, it is only Product Owner’s decision ,when to release it (MMP), depends on finding a “sweet spot” between the two types of cost: Holding and Transaction, or if spoken, in software development terms, costs of code deprecation/aging and costs of deployment. On the graph above, it is illustrated by the lowest point of Total Cost curve and it is responsibility of Team and Product Owner to determine what it is.

Corollary to having both strategy and economics changing over time, release frequency may change as well.  It would be natural to assume that sprint duration and release frequency are related too.  Indeed, the need to release more frequently may lead to sprint shortening, and vice versa.

Are there any other external factors that may influence Sprint frequency of a single Scrum team?  The most classic example would be Scrum by multiple teams that sprint together (e.g. LeSS, S@S): develop the same product, for the same Product Owner, and share the same a backlog.  While release economics principles would still apply, the situation with scaling may become more complex if multiple teams are tasked to select a shared cadence.  One assumption comes to mind immediately: if multiple teams sprint together (synchronously), then their shared PSPI (overall output) will be more substantial (“voluminous”) than that of a single team, and from a Product Owner’s point of view, may sooner merge the gap between PSPI/MVP and MMP (more about factors influencing Sprint length below).

In other situations, e.g. in non-scaled settings, individual Scrum teams could be dependent on other teams (Scrum, Kanban, Waterfall groups, etc), separate organizational domains or external vendors that operate on their own cadence.  In such cases, product backlog refinement and sprint planning becomes even more challenging.  As a result, sprint length, as well as frequency of scheduled production releases may be impacted.

Who Ultimately Decides on Sprint Length?

Just like any other decision about Scrum team dynamics, the decision on sprint length belongs to a team.  Nobody should be deciding how to structure or manage work, on behalf of people that actually do it.  Neither Product Owner, nor stakeholders, nor management, nor anyone else.  Teams that are new to Scrum may experiment with sprint length at the beginning, while trying to optimize to conditions that are very specific to a team’s dynamics.  The best time to self-assess and decide if sprint length should be changed is during a retrospective, when decisions about process improvements are made; and it is done by majority voting.  Only in rare cases, when a team has a difficulty to reach consensus, ScrumMaster , who owns Scrum process and plays the role of an arbitrator in retrospectives, can step in and help a team make a choice.  This should happen rarely, as frequent lack of consensus might be a sign of deeper team dysfunctions.  Initially, during team formation, and before ScrumMaster is elected, Scrum/Agile coach may help team with sprint length selection.  Mike Cohn describes his personal experience in a similar situation here.

Factors to be considered while selecting Sprint length?

As a rule of thumb, sprint length should not be shorter than 1 week and should not be longer than 4 weeks. If there is a strong reason to make sprints shorter than 1 week (e.g. could be driven by production release frequency requirements), Kanban, instead of Scrum, could be considered, since it offers, on demand and almost instant, release capabilities.  On the other hand, extending sprint length beyond 4 weeks may lead typical challenges of waterfall (sequential work, silos, hand-overs).

Statistically, anywhere between 1 and 4 weeks, a team should be able to establish a steady and healthy cadence to do product development.

Shorter sprints do have certain advantages:

  • More frequent sprint reviews and retrospectives – shorten feedback loops that allow applying improvements to product and process development, respectively.
  • Shorter sprints require lighter sprint planning and, subsequently, reduce the risk of going too deep into a product backlog and selecting items for a sprint that do not meet DoR (Definition of Done) and are not INVEST-able.

Shorter Sprints may also bring some potential challenges:

  • For example, the ratio of time spent on sprint preparation and process management to time spent on actual product development could be high – too much procedural overhead.
  • Additional important prerequisites must be met, before moving teams to shorter sprints. For example, if a sprint becomes too short (e.g. 1-week) and there is no full test automation and no TDD, then a team may have a difficult time, keeping up with testing: after completing a few sprints, as  the amount of code base increases, manual testing will fall behind. As a result too much work may fail DoD by Sprint-end. 

Relationship between Sprint length and Scrum Maturity

It would be reckless to claim that there is a direct cause & effect relationship between sprint length and maturity.   Some research indicates (some was done by Jeff Sutherland) that for as long as a sprint is under 1 month, there is no strong and immediate correlation between sprint length and performance. But anything beyond 4 weeks lowers performance and introduces elements of waterfall dysfunction to a team’s dynamics.

What is, by far, more important than sprint length is sprint length consistency.  While in early stages of sprinting, it is normal for a team to experiment with sprint length, if length “juggling” continues into later sprints or happens ad-hoc, it could be viewed as a sign of deeper problems.  Some teams falsely believe that by periodically extending a sprint they will be able to get more work to Done state.  Thinking more systemically, this is a false assumption, as cadence- and task-switching, especially done by multiple  teams,  can significantly lower overall output.  Further, inconsistent sprint length will lead to difficulty of sprint planning, unstable velocities and unreliable long-term forecasting.

Are there better ways to teach?

Whether you are a high school teacher, a college professor or professional training instructor you probably always look for ways to increase value you bring to a classroom and some of the questions you might be asking yourself are:  “how to enrich students’ in-class experience?”, “how to ensure information retention by students?” and “how t make in-class learning more applicable to real life?”.  This summary focuses on the following three aspects of teaching: dynamic teaching, teaching focus, feedback loop between teachers and students.

 

Dynamic Teaching

Every instructor must have a set of Learning Objective, based on which, training content is built.  Meeting these objectives deems a training successful.  But there are different schools of thought about educational learning:

Bloom’s Taxonomy classification model for educational learning (created by Dr. B. Bloom in 1956) implies that human thinking goes through six evolutionary (maturity) stages that, if were mapped to Japanese martial art concept of SHU-HA-RI that describes the stages of learning to mastery, would approximately group-by as follows: SHU (Remembering, Understanding, Applying) = “traditional wisdom”, HA (Analyzing, Evaluating) = “breaking with tradition”, RI (Creating) = “transcendence”.  With this thinking approach, to proceed to a next level of maturity, a person must pass through preceding levels.  This type of learning is hierarchical/sequential and uni-dimensional.

An alternative, and more dynamic, taxonomy of leaning has been proposed by L. Dee Fink of University of Oklahoma, in his The Power of Course Design to Increase Student Engagement and Learning.  With this new thinking approach, instead of looking at learning as a hierarchical and sequential journey, we treat it as multi-dimensional process, where each dimension is independent and can interact/overlap with other dimensions, in a Venn-like style.  The following are learning dimensions (categories) proposed by Fink: Foundational knowledge, Application, Integration, Human dimension, Caring, Learning How to Learn.

All categories are independent of one another and within each category, students can advance to different degree of maturity.   Within each of the categories, there could be a critical minimum of learning objectives that must be met by all students – this is something that is decided by an instructor.  Beyond this critical minimum, learning remains dynamic and conditional and is based on an instructor’s assessment of in-class dynamics (may vary from audience to audience).

 

Teaching Focus

Truth be told, in comprehensive multi-session courses (e.g. college or university), where a professor has enough ‘runway’ to build-up her audience for more advanced topics, there is a relatively low risk of short-cutting/by-passing basics, in favor of practical learning.

On the other hand, in short, time-boxed professional training (e.g. a few hours or a few days) there is a higher chance that foundation learning could be shortened by an instructor, in favor of topics that appear (only superficially) to have a more direct real-life relevance.  In short training engagements, due to time constrains and a desire to jam as much information as possible in a session, we see these sacrifices primarily made because:

  • Instructors are pressured to deliver “maximum practical value for a buck” by their sponsors
  • Students attend against their will, with superficial goals to “rent” an instructor’s immediate solutions, instead of learning how to find their own
  • Certain “hot” topics that challenge current organizational values and norms are omitted, to avoid inflaming discussions

A good example of teaching focus loss would be an agile training by an agile consultant, where a class immediately focuses on their day-to-day problems and “best” practices (e.g. metrics, tools, techniques and workflows), instead of learning agile values first (e.g. human interactions, relationships, mindset, collaboration, compensation etc.). [More information about typical challenges with agile training]

By short-cutting to immediate practical implementations and offering ready-to-use “unwrap & install” solutions, trainers significantly reduce students’ chances of retaining learning, developing autonomy and capability of creating and owning their own decisions (as opposed to “renting” from instructor).

Instead of working from outside-in (as per the diagram above), instructors should strive leading students from inside-out, by ensuring that students understand core values first, then build new principles upon values, and only then proceed to developing their own practices.

Teaching Feedback Loop

In 2014, in his “Don’t give me Feedback”, Tobias Mayer described how any type of direct feedback, whether positive or negative, is a judgment made by the giver on the receiver.   Being a judgment call, feedback is always subjective and is anchored to a giver’s personal and self-centered views and ambitions.  Here is an example from a typical agile training:

A positive feedback that is full of compliments, excitement and affirmation could mean that a student learned in class how her role will become more empowered, thanks to overarching organizational changes.  This is a great reason to “celebrate” and give positive feedback to an instructor, even though the class itself was not so great! Another reason for a positive feedback could be that a student is trying to build a good relationship with an instructor, for future “at-work” interaction and “special treatment” or with a hope that an instructor will provide her own positive feedback to students’ superiors.

On the other hand, a negative feedback and criticism (this type of passive aggressiveness is sometimes seen in anonymous feedback forms) could mean that a student learned in class about something that will affect his personal daily work in ways that are not desirable by a student (e.g. required additional learning, loss of control or authority).  So, while learning itself is deep and clear, an individual’s conclusions about personal consequences may lead to negative emotions and mental resistance- thus, a negative feedback.

According to Tobias, a much better way to receive feedback from a classroom, would be by simple Observation.  Instead of soliciting students’ feedback directly, an instructor should pay a lot of attention to in-class participation and interaction: student-to-instructor exchange, student-to-student exchange, questions posed by and answers offered by students, students’ desire to look for workable solutions that are acceptable by everyone, etc.  A good way to increase objectivity of observation would be to re-shuffle students during training, to re-create new working groups, and see if in-class dynamics change, subsequently, as well.

Another big advantage of learning by observing is that it allows for an immediate adjustment of actions by an instructor, and re-applying changes made back to the same group of students, without making it too obvious for students.  For example, if an instructor sees one of students being completely disengaged, she can ask a student to change to another table or request him answer a question posed by another student.


To summarize, in this day and age, with so much information becoming a free commodity available on internet, unidirectional and “scripted” in-class teaching is becoming less and less effective. On the other hand, dynamic and interactive teaching, reinforced by short feedback loops between a teacher and students, will be setting high standards in future learning.