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.

 

 

2017 Agile Maine Day Recap

The 2017 Agile Maine Day event is in the books.  Great event organization. Great energizing crowd. Amazing presenters and speakers.

Below are the summaries of two selected presentations, whose themes were mostly relevant to System Thinking and System Design:

Don Macintyre’s topic “Agile Leadership” was about Radical Management (Steve Denning’s teaching) and covered:

  • Shifting focus from making money for shareholders to focus on delighting customers through continuous innovation
  • Managers focusing on controlling individuals to Managers empowering and supporting self-organizing teams
  • Shifting from controlling work with bureaucracy to guiding innovation with priorities
  • Shifting from predominantly valuing efficiency to valuing Continuous Innovation
  • Shifting from top-down command structures to horizontal communication and collaboration

Don also talked about Agile Leadership Mindset and stressed the importance of the following behavioral transitions:

  • From Directing to Coaching
  • From Hiding Failure to Learning from Failure
  • From Telling to Collaborating
  • From Avoiding Blame to Seeing Feedback

Bob Sarni’s – “Radical Collaboration” delivered the following main message: “Organizations cannot compete externally until they can collaborate internally

Bob referenced the book “Corporate Culture and Performance” by John Kotter and James Heskett: Non-enhancing Cultures vs. Enhancing Cultures, alluding to the fact that sometimes the best way to overcome resistance, is to remove resistors.

The following four quadrants of self-discovery were covered:

  • Who we are (Self-mastery):
    • Self-Awareness
    • Self-Esteem
    • Emotional Intelligence
    • Values
  • Interpersonal (Social Intelligence):
    • Communication
    • Trustworthiness
    • Cooperation
    • Rules of Engagement
  • What we Do:
    • Project
    • Product
    • Task
    • Service
  • How We Do it:
    • Systems/Processes
    • Decision Making
    • Structure
    • Policies

Bob also stressed the point that when it comes to going through organizational changes, companies tend to focus on Practices, instead of focusing on underlining Principles and Values. This results in unsustainable, short-term successes only.
Another great quote from Bob’s session: “Business Analysis have their focus on the outer side of business”, mainly focusing on questions of ‘what should we be doing?‘ and ‘how can we do it better, faster and more efficiently’.  It turns out that the inner side of the business is where the greatest opportunity for radical improvement resides”.  The inner side of the business contains the heart and soul of the business.

Finally, Bob talked about Red Zone vs. Green Zone Behaviors (refernicing work of James Tamm)


Bob also described Pink Zone behavior that usually manifests itself by the following actions: Leave, Quit, Hide, Passively Resist, Appease, Give in

(At closing, a kodak moment with Dan Mezick and Bob Sarni)

 

2017 Big Apple Scrum Day: Coaching Clinic

The Third Annual BASD (2017) event is in the books.  27 people have been served by the coaches, whose cumulative experience and depth of knowledge were just immense.  Many thanks to Zuzka Sochova, Kim Brainard, Bob Galen, David Liebman and Jim York for making this happen.  This event had the largest every presence of Certified Enterprise Coaches (CEC).

Below is the summary of quotes from the people that attended the Coaching Clinic:

  • “Awesome session. Wealth of knowledge.”
  • “Pleasant convo. Vague question but got some interesting answers.”
  • “Bob helped me with several concerns I had. He broke things down and emphasized the importance of always looking at things with a whole team approach. Will use feedback.”
  • “Dave: – great shaking, -good advice, – will use immediately.”
    “Very helpful and informative, It is always good to learn other perspectives”
  • “Great insight and way to look at personal issues.”
  • “Dave game me some good marketing advice about marketing myself”
  • “Bob listened, provided valuable feedback and helped me walk out with actionable items. Thank you!”
  • “David – useful suggestion.”
  • “Refreshing and very pragmatic session.   Great advice and specific to my exact topic.”
  • “Awesome coaching from Kim. Look forward to taking her feedback to work.”
  • “Practical & useful talk about Scrum roles with development team (PO & SM).”
  • “Great feedback from Dave. Great advice about how to run meetings and to get work done.”
  • “Great pointers to look for next steps. Good and honest advice. Informative discussion.”
  • “Got coaching from Jim on rolling out agile more broadly. Jim was really helpful and got us to the heart of where we should focus. Thank you!”
  • “Dave shared personal experiences that helped me identify possible resolutions to my problem. Very clearly followed the steps from the coaching stance. Got definite actions to try.”
  • “Great advice for retros from Kim.”
  • “Had a session with Jim about career path and my goals. He was extremely helpful. Listened to my concerns and helped with ideas.”
  • “Great therapy session! Was able to get real life examples in the feedback.”
  • “Meeting with Jim was worth every nano-second. He reset my thinking about focus but more importantly, my intention with short-term and long-term goals — but especially humility. Excellent!”