Category Archives: Scrum

Applying LeSS Thinking to Basic Scrum

As per Scrum Guide, “…Scrum is a framework for developing and sustaining complex products… It [Scrum] is lightweight, easy to understand and difficult to master”.  The guide talks about basic Scrum, or Scrum by one cross-functional team that works for only one Product Owner, on one single product.  The guide also mentions situations when multiple Scrum teams must work on the same product backlog and share the same Definition of Done (DoD) – an example of scrum scaling.

Large-Scale Scrum (LeSS), is a product development framework that extends Scrum with scaling rules and guidelines, without losing the original purposes of Scrum.…”.  Some of the hallmarks of LeSS are:

  • It is the framework that requires organizational de-scaling (simplification), to scale basic Scrum
  • It is the framework that strongly relies on effectiveness of organizational design and system dynamics of multiple organizational layers, departments and spheres of control
  • It is not merely a group of teams doing their own Scrum, while working for different product owners and supporting different products. Rather, it is a group of teams (2-8) that works together, synchronously, on the same product and serves the same product owner.

It is worth stressing the last bullet point above:
Frequently, novice agile adopters mislabel scrum implementation by independent and unrelated teams, as “LeSS”. Sometimes, they are genuinely mistaken. But there are instances of intentional LeSS terminology overload. In either case, inappropriate use of LeSS terminology creates asymmetry between LeSS guidelines and rules, on one hand, and reality of teams’ working dynamics – on the other.

Another prevalent misconception about LeSS (and more on this later in this post), is that LeSS postulates are ONLY applicable in large scale settings. Some, less experienced agile practitioners feel that if an organization implements Scrum in its basic form only, without attempts to scale, the facing organizational dysfunctions that are vividly exposed by LeSS, could be avoided. This is a mistaken belief: LeSS principles can be used to improve basic Scrum as well. Practically, any organizational dysfunction that is exposed by LeSS, also presents a challenge for basic Scrum, but perhaps, in a form that is not so obvious, and with a manifestation that is not so disturbing. In a way, LeSS serves the purpose of “dysfunctions amplifier/magnifier” that allows seeing more clearly, at scale those things that may not be as obvious at single team level.

Below are the six big topics (LeSS “Hexagon of Values”) that are always brought up in LeSS discussions. Lets take a closer look and see if they still retain their relevance in basic Scrum:

Feature Teams over Component Teams

From LeSS perspective:

From a stand-point of a paying customer, feature-centric product development is the most effective way maximize business value.  Feature teams can perform this work best, since they are able to operate across multiple application components, independently and autonomously.  Component teams cannot do the same. A component team is focused only on one single application domain that is not shippable (marketable) on its own, if viewing from a standpoint of paying customer.  Trying to fake LeSS, by putting under the same wrapper multiple component teams, creates a large amount of handover and other procedural overhead before a release.  For example, if eight component teams (max. # in LeSS) work only on respective single component items, pulling them from the same backlog, there will be a lot of component integration required, before a product becomes truly shippable (PSPI).  This will either, at best, consume a lot of teams’ capacity at the end of each sprint, or will require an additional “hardening” sprint before going to production (at worst).

How is this applicable to Basic Scrum?

It is not uncommon to see single component team that pretends ‘doing scrum’, by introducing scrum roles, artifacts and events to their work model.  At a glance, it may appear that a team does what other scrum teams do – it sprints, but the goal of scrum: to deliver PSPI – is still absent.  The impact of such faking, on the ability to meet a product owner’s goals may not be as strong and obvious, because delivery expectations from a single team just are not as high as expectations from 8 LeSS teams.  (Another word, from a standpoint of time & resources spent and humans involved in performing work, a single component team that pretends ‘doing scrum’ would have an easier time to justify to a product owner and stakeholders ‘why’ their end-of-sprint deliverable is not shippable: justifying ‘undone’ work by 3-9 developers of basic scrum is just easier than justifying ‘undone’ work by 50 developers of LeSS).  However, the core underlying problem still exists in basic Scrum: a sprint deliverable is not PSPI. 

Component Mentorship over Component Ownership

From LeSS perspective

There is a distinction between Component Ownership and Component Mentor-ship:

Component Owner  – is an individual (sometimes, a group) that has unique privilege to work on a particular application component.  If any other team needs to make modifications to a given component, they must delegate this work to a component owner.  Rarely, these ‘private code policies’ are justified by external regulatory requirements or internal audit needs.  More frequently, such ownership is due power retention and sphere of control ambitions of certain individuals/groups, both being secondary to internal organizational politics.

On the other hand, Component Mentor – is an individual that has a lot of work experience with a particular component, but instead of becoming a bottleneck to component-specific work, he teaches others how to do the same.  Effectively, a component expert becomes a teacher of “how to fish”, instead of a giver of an “already caught fish”.  With such approach, any feature team, over time, becomes proficient at working on any application component, without being dependent on a component owner: each component becomes a shared property; no more someone’s private and protected domain.

By giving up the privilege to be the only person who can touch an application component, an application mentor should not lose his organizational value: instead of being a single-contributor/performer he now becomes an educator and advisor – the role that is much more scalable in large organizational settings. This empathizes another concept (below) that is strongly advocated by LeSS trainers and coaches: Job Security should not be confused with Role Security.

How is this applicable to Basic Scrum?

Perhaps, the most important distinction in basic scrum is that for a single-team operation, the benefit of having experienced and willing to share their knowledge with others, component mentors, is not as obvious.  Also, an organization may have a hard time to justify designating a component mentor, per component, serving a stand-alone and unrelated to others, scrum team.  But even for a single team that does basic scrum, the problem still remains: not being able to work directly with certain application components will continuously lead to having external dependencies on other teams/individuals, and therefore, will put at risk the ability to deliver PSPI at the end of each sprint.

System Optimization over Local Optimization

From LeSS perspective:

There is strong contrast made between Local Optimization and System (Global) Optimization.   Any single-specialty department (UI/UX, BA, QA, Dev, DB) is ‘locally optimized’. This means that people within each department might be very busy and work hard to complete a series of tasks that ONLY they can do.  The opposite is true too: a group of single specially workers can perform ONLY a subset of tasks that their skillset allows.  While from their own (local) perspective, they work very devotionally and produce a lot of output, from a stand point of a paying customer, the overall outcome is still low.  False perception of local efficiency by single-specialty workers does not directly translate into system efficiency: individual ‘local progress’ does not add up to system progress.  A classic example of local efficiency could be over-production of comprehensive BRDs by Business Analysts (BA), way ahead of development efforts: while from a stand point of BA, lots of great documentation is produced and signed off, from a stand point of a paying customer, much of this work may become obsolete (projects are delayed, priorities change, budgets get cut, etc) before implemented in code.

How is this applicable to Basic Scrum?

Manifestation of local optimization, also being a direct result of single-specially (component) work, is frequently seen on basic scrum teams that lack T-shaped developers.  For example, non-technical business analysts and manual testers, will be, most likely, focused on ‘writing stories’ and producing manual test cases, respectively, way ahead of sprint development.  For example, is not uncommon to see BAs, attempting to ‘clarify’ user stories by adding to them a lot of conventional, contractual documentation (e.g. BRDs) that leads to reduction of communication with a product owner and stakeholders during sprinting; this introduces elements of mini-waterfall in scrum.

Job Security over Role Security

From LeSS perspective:

Any person should have a job and be capable of making living.  Offering job security to each employee, should be one of the most important goals for any organization. However, job security should not be equated to role security.   Gradual changes of needs in any particular role, could be a natural process that follows bigger industrial changes: modernization, computerization, robotization, etc.  Efficiency an overall system organization should not be sacrificed for preserving specific roles that no longer bring value.

One of the most common role changes discussed in LeSS is the role of Project Manager (usually, first-line PM).  Scrum requires self-organized and self-managed teams that take full responsibility for their own work and interaction with customers.  Everything is done by a team that performs work: work estimation and assignment, ownership and information sharing, communication and reporting.  Historically, all of this has been handled by a project manager.  Shifting all these responsibilities to a team, makes PM feel underutilized, sometimes annihilated.  In environments, where teams no longer require tight managerial control, managers may have to re-focus on removing organizational challenges that teams face and cater to teams everything, what is required, to optimize team work.

It is critical that any organization that reevaluates its existing roles, also takes a close look at existing job families and employee career paths.  If an organization suspects that some employees might be displaced due to changes of roles and responsibilities, it must provide other alternatives for people: education, training, internal mobility to other parts of an organization, etc.

How is this applicable to Basic Scrum?

The need to provide job security for potentially displaced workers in basic scrum settings is no less important than in LeSS.  Business analysts and manual testers should be given an option to move into scrum teams and learn additional skills.  In basic scrum, unlike LeSS, where there is a much stronger need for addressing and resolving organizational impediments, it could be less obvious how a first-line manager of a single scrum team can be fully occupied, with removing impediments, as this is usually Scrum Master’s responsibility (in basic scrum, at single team level, impediments may also be not as systemic).  In such cases, line managers should be given an option to move to another part of an organization, where traditional development is still practiced.

Narrow & Deep over Broad & Shallow

From LeSS perspective:

When it comes to large-scale agile adoptions, it is very easy to develop a false assumption that bigger is always better.  Some organizations are trying to jump on a bandwagon of agile-mania and claim early victories (this is often caused by ill-defined motivation and bonus schemas that praise people for achieving certain fabricated goals, e.g.: by ‘rolling out agile’ to a very large part of an organization.  Such attempts of broad coverage also lead to shallow impact: organizations are able to demonstrate short-term superficial (sometimes, fake) results but there is not enough momentum to ensure continuity and long-term success.

It is always much better to focus on a narrow part of an organization, by extrapolating it from a larger organizational construct, and improving organizational agility, by going deeper into organizational structure.  In LeSS, the recommended size of an organization (at least, on technology side) is about 50 people.

How is this applicable to Basic Scrum?

This concept is probably not as applicable to basic scrum, as other concepts mentioned so far.  ‘Breadth’ of implementation implies wide organizational areas and involvement of many people.  Basic scrum is not as concerned with horizontal span of efforts because, by definition, a scrum team is  only 3-9 people.

Owning over Renting

From LeSS perspective:

When it comes to making decisions, organizations and teams should look for ways to develop their own approaches, instead of ‘copying & pasting’ solutions of others.  Relying on professional trainers, is a great way to learn from expertise of others, in classroom settings.  Leveraging help of professional coaches, is another, longer-term, way to mature, through self-discovery, experimentation, inspection and adaptation.

Organizations and teams should be striving to own their own decisions and take responsibilities for successes and failures.  On occasions, trainers and coaches may lead by example (e.g. mock-up a behavior of a specific agile role), share lessons learned from prior engagements, but this is not done to encourage customers to copy/paste approaches and styles.  Ultimate decisions should be always made by those that will live with those decisions in a long-term.

How is this applicable to Basic Scrum?

In basic scrum, just like in LeSS, teams are expected to leverage what they have learned from trainers and coaches, to gain autonomy and become owners of their decisions and solutions.  Through frequent inspection and adaptation, teams that work in basic scrum should be able to ultimately modify their processes, as needed.  Logically, it would be also expected that a coach who assists team (s) that use basic scrum, coaches ‘himself out of work’ sooner than a LeSS coach, since organizational design challenges have much more severe impact on LeSS team that on basic scrum teams.

Agile Flyer – 03-25-2017

CHALLENGES WITH AGILE TRAINING:
EXAMPLES, REASONS, CONSEQUENCES

Virtual networks of professional agile coaches and trainers is good place to pick up some most thoughtful and provocative agile discussions.
The most reputable networks that I know of, and happen to belong to, are the communities of:
Certified Enterprise Coaches and Certified Scrum Trainers (both, from Scrum Alliance),
and Candidate Large Scale Scrum Trainers and Coaches (both, from LeSS company).
These communities are great because there we continuously share our experiences and learn from one another.
The summary below is the result of one such in-network discussions that spans in duration for more the a year.
It is focused on in-class training experiences and highlights –
some of the most common challenges that we encounter with our students in pre-, in- and post-classroom situations.
Some of our observations are specific to private classes, some – to public and some – to both.
Below, are some of the common challenges with Agile Training that we face:

  • Training “Wrong” Attendees with “Wrong” Intentions
  • Training “Certification Collectors“
  • Influence of Past Quasi-Agile Experience or Misguidance
  • Lack of Pre-Training (Self-Study)
  • Attempts to Change Training Content to “Conform to Reality”
  • Attempts to Steer Training Content towards “Unique Situations”
  • Requests for Exemption from Training by “Special” People
  • Lack of Classroom Participation
  • Too Much Reliance on Training Materials

-Read more…

 


More Selected Periodicals:

Scrum and Kanban at the Enterprise and Team Levels

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….

-Read more…


Motivation 3.0 Is Required to Transition from Tribe Stage 3 to 4

In his book Drive, Daniel Pink says that when it comes to motivation, there’s a gap between what science knows and what business does.
Our current business operating system is built around external, carrot-and-stick motivators — which don’t work and often do more harm than good.
We need a system upgrade. And the science shows the way.

This new approach has three essential elements:

  1. Autonomy: The desire to direct our own lives
  2. Mastery: The urge to make progress and get better at something that matters
  3. Purpose: The yearning to do what we do in the service of something larger than ourselves

-Read more…

Fresh Collection of Ad-hoc Agile References:

I continuously collect articles and publications that come from everywhere: colleagues, coaches and trainers, clients, occasional encounters.
I keep a comprehensive list of resources here, categorized by themes.
Some of my most recent samples from the collection are below:

 

Challenges with Agile Training: Examples, Reasons, Consequences

Virtual networks of professional agile coaches and trainers is good place to pick up some most thoughtful and provocative agile discussions.  The most reputable networks that I know of, and happen to belong to, are the communities of: Certified Enterprise Coaches and Certified Scrum Trainers (both, from Scrum Alliance), and Candidate Large Scale Scrum Trainers and Coaches.  These communities are great because there we continuously  share our experiences and learn from one another.

The summary below is the result of one such in-network discussions that spans in duration for more the a year. It is focused on in-class training experiences and highlights  – some of the most common challenges that we encounter with our students in pre-, in- and post-classroom situations.  Some of our observations are specific to internal classes, some – to public and some – to both.

Below, are some of the common challenges with Agile Training that we face:

Training “Wrong” Attendees with “Wrong” Intentions

At times, we get training attendees that have never held agile roles (e.g. ScrumMaster, Product Owner, Team member), … nor did they ever have an intention to do so.
While agile education is recommended at all organizational levels and for all horizontal structures (perhaps, with different focus, depending on audience), what is sometimes observed is that certain types of individuals show no signs of desire to truly understand to further implement newly-learned agile principles. Instead, their true desire, seems to be, in understanding agility concepts just enough to be able to figure out a way of creating “anti-dote” against them.  Typically, this is seen with individuals that are concerned with their own role security (not to be confused with job security) as it frequently gets challenged in agile and lean organizations (includes processes, tools and roles).

This situation is rather difficult to control in public classes, where any individual who pays a fee, can attend.  However, it can be (and should be) much easier to control with internal training. By requesting class attendees to come in ‘clusters’, as hands-on technical teams that share work already, accompanied by their respective business counterparts, trainers can ensure that right people are gathered together in the same classroom, at the same table, for shared learning, collaboration, and simulation exercises.  This is the most effective way to ensure that in-class learning will retain its momentum, when people go back to their work areas and start implementing newly gained knowledge in practice.
It is important to note that for any trainer who is planning to engage with trainees for a longer period of time and coach them, it would be especially important to have right people in the room during training – together.

Training “Certification Collectors”

It is not uncommon to see individuals that come to training with the main goal to add another trendy certification to their collection.  This is mainly fueled by job market demands, as hiring companies create job requisitions and look for a “soup of certifications”, sometimes, asking for most awkward and, sometimes, conflicting combinations.  For example: “A candidate must have CSM, PMP, PMI-ACP, SAFe, PRINCE2, etc”.  Most of such jobs are usually poorly described and contain erroneous statements about actual role expectations.

This situation has been observed much more frequently in public training courses, where individuals pay their own money to attend.  Less so, this has been observed with internal training, where students do not pay their own money to attend (nor do they get certified). As such, their eagerness to maximize ROI from attending aa class is much lower.

Also, as a side-effect of this unfortunate pattern, blind pursuit of certifications by non-practitioners who don’t have any intentions to put their learning to practical use,  also dilutes meaningfulness of certifications in the market and adds even more confusion to hiring companies.

Influence of Past Quasi-Agile Experience or Misguidance

Some individuals come to training after prior “agile theater” experience.  Please note that in this post, the emphasis is made on specific cases, when prior agile exposure was of low quality and had created confusion or conflict with new learning.

Bad agile experience may come in various forms.  For example, poor agile implementation “on the job”-  often due to a complete lack of training and misguidance by management.  Another example would be previous low-quality/misleading agile training that was delivered by unqualified guides.  The adverse effects of these types of wobbly foundations are observed equally frequently with public and private training.

It is worth mentioning some well-known sources of unqualified guidance:

  • Vendor companies that lack internal agile expertise or track record of teaching.  Historically, such companies have done mostly staffing/recruiting or management consulting of some sort and just recently decided to step into ‘agile arena’ in pursuit of additional revenue (pretty common these days).  Such companies “get lucky” when their is long-standing clients pull their names off a preferred vendor list and ask to fulfill agile staffing needs.  Usually, hiring companies that use this approach get exactly what they paid for :).
  • Internal employees that have been promoted/fast-tracked into trainers or coaches to fulfill a growing internal company demand for agile guidance.  Such individuals, most of whom do not have any prior field experience as coaches or trainers, are too restrained to existing organizational norms and standards: they are not reformists and challengers by mindset; they are conformists and executioners. Thus, in classroom settings, they present “by the book”, at rudimentary level and steer their followers towards “…this is how things are done around here…lets conform our Scrum to constraints of our organizational design and our internal best practices…”.  Such agile guides are not very effective in handling out-of-the-box situations or addressing serious inquiries that require deep understanding of organizational design and system dynamics.

Internal agile trainers that have been more successful in their work than their peers, usually position themselves in a way that they have, first and foremost, ensured their own security and operational safety that is required to drive organizational changes from within. Secondly, such individuals also have a very strong connection with external professional circles of trainers and coaches, though which they explore horizons of their learning beyond boundaries of a single organization and continuously hone their craft as trainers and coaches.

Lack of Pre-Training (Self-Study)

Almost any trainer will appreciate having in her class well-informed students (a.k.a. “educated consumers”) that have done recommended preparatory self-study before attending training.  Self-study helps normalizing basic understanding of concepts and level-setting students’ expectations from in-class learning.  It also, potentially, reduces the amount of basic, rudimentary questions that unprepared students often ask in class: about terminology, conventional abbreviations, jargon, etc.  By spending less time on explaining basic book definitions, an instructor can spend more time on collaborative activities, role-playing, discussing real-life simulations and doing practical exercises.  This case of low preparedness is more frequently seen with internal training, where a company sponsors an event (even, when an external trainer is hired from outside, employees don’t pay from pocket) or training is totally free (done by an internal trainer).  Just like in the situation described above, students’ desire to maximize ROI is lower than in public training, where people invest their own time and money to attend.

Attempts to Change Training Content to “Conform to Reality”
  • “Is it possible to shorten our training from 2 days to a few hours?”
  • “Can we conduct training just for IT people, since it is hard to justify to our business partners why they need to be away from their desks for a few days?”
  • “Can we conduct training just for business people, since our IT people are already well-trained in agile, “doing stand-ups” and using Jira/Rally to track time spent 🙂 on tasks and they see no value in going through another training, alongside with business?”
  • “Can we review training materials upfront, to make sure that we don’t waste any time on topics that are not relevant to us and ensure that we conform to our existing organizational reality (philosophy, norms, rules)?”

These types of requests are almost unique for internal training arrangements.  Frequently, they come from first- and mid-level managers that get their marching orders to “do agile” (a.k.a. “support-in-spirit”) from senior leadership, and while orders are given, the empowerment to make sure that things are done properly– is not there.  Such corner-cutting and artificial scope reduction has its own reasons. Here are some of them:

Sometimes, agile training is perceived by both: attendees and their managers – as an easy way of meeting personal objectives in order to receive good performance appraisals (when students are asked in class why they are there, they frequently respond that “…it is in our personal development plan and our management wants us to do it, because everyone else is doing it…”.  [Author’s irony: “if everyone was jumping off the roof would you do the same?”].  There is no clear understanding, purpose, vision or goal.  There is no clear strategy on how to put new learning to work, after attending classroom training.

There are other times, when attempts to change training content are caused by a desire to circumvent or avoid sensitive topics that could be perceived by some as politically-incorrect implications of organizational dysfunction.  For example, topics about harm of performance appraisals and monetary rewards, weaknesses of conventional budgeting, inappropriateness of old methods to procure for agile roles (e.g. product managers, T-shaped developers or agile/technical coaches), ineffectiveness of waterfall requirements in agile product development, shifting control and responsibilities form first-line management to teams, etc.).  In these situations, agile training might be reduced to a discussion of “best practices” (agile tooling, metrics collection, agile status reporting, etc.) or reviewing some sort of an internal agile guide for best practices that usually comes in a form collection of publicly available, commoditized (internet) information.  On the other hand, there are situations, when internal agile training turns into a battle field between people, whose hidden friction and conflicts of interest become more obvious because of agile topics and associated  with them transparency.

Attempts to Steer Training Content towards “Unique Situations”

Somewhere like the above, this case of uniqueness is more frequently seen with public training, where people come from different companies and pay for training out of their own pocket.  While their intentions to get “more bang for buck” are good and well understood, sometimes, methods are not.  There are instances, when students attempt to steer discussions towards their unique situations at work, by frequently interjecting with inappropriate comments or asking an instructor to reflect, in real-time, on their personal work experiences.  If this happens too frequently, it becomes disruptive for other students and reduces effectiveness of basic learning for everyone.  It becomes a trainer’s responsibility to ensure that special cases and real life scenarios are reviewed at appropriate times, preferably, with participation of other students, in team break-out sessions (could be also facilitated by a trainer).  Such cases of uniqueness are not as frequently observed with internal training because there is much less variance in situations within the same company.

Requests for Exemption from Training by “Special” People

There is a fundamental difference between support- in-spirit (a.k.a lip service) and true, genuine hands-on involvement and support-by-action (a.k.a. gemba).  Unsurprisingly, there is a shared belief among organizational coaches that: “…a coach can take an organization in its agile journey only as far as an organizational leader is willing to go…”.  It is imperative that senior leadership that is behind agile transformation is well informed and educated.  While content of agile education for senior leadership (executive training and coaching) may differ from content taught to feature teams, ScrumMasters and Product Owners, it must be delivered as the earliest phase of transformation, to prepare seniors for inevitable organizational changes: structurally, culturally, processes -, norms – and values-wise.

Unfortunately, there are many cases when senior leaders excuse themselves from agile education.  They delegate this critical activity to more junior people beneath.  Soon, this leads to misalignment and disconnection between teams that are trying to implement agile changes and senior leadership that is trying  to effectively support the effort, but cannot – due to lack of understanding of systemic and organizational implications.

It is a rarity to see senior leadership attending public training – they just find it too difficult to allocate time for this external activity.  With internal training, things are somewhere better, but not by much.  On occasions, senior leaders will attend initial part of agile training, and try to motivate their subordinates by personal example.  While it is somewhere useful to create initial momentum, it is not sufficient.  As a rule of thumb, having a senior leader sit though an entire experience of in-class learning that includes collaboration, system modeling and practical exercises, alongside with a feature team developer or product owner, is extremely rare. As a result of this, leaders leave with superficial knowledge and limited understanding of what their teams will be experiencing on practice.

Lack of Classroom Participation

In public training, it is hard to attribute lack of students’ participation to any specific cause; it is rather situational. Factors may vary from student’s disinterest in a topic (e.g. a person attends only for certification, as described above) to an instructor’s inability to effectively engage with a class, …to anything in-between.

With internal training, however, the situation is slightly different.  Here, in addition to a wide array of factors, suggested above, there is an additional important factor of individual safety.  Existing organizational structures (e.g. reporting lines, chain of command, seniority) may seriously influence in-class environment and dynamics.  Junior folks may feel unsafe and act submissively to others, whose seniority is higher, either by reporting structure or by experience.  It is not uncommon to see first-line managers and team leads attending internal training, alongside with their subordinates and more junior co-workers, and dominating in classroom by trying to set a pace and tone.  What sometimes worsens a situation even further is that, inexperienced internal agile instructors that are also a part of the same organizational structure, are not able (or not willing) to control in-class dynamics to ensure safe and democratic participation by students: they lack their own personal safety and hesitate to put a hard stop to misbehavior of empowered bullies.

Too Much Reliance on Training Materials

This is probably one of the most difficult paradigms that is hard to break: there is often so much reliance on documentation that goes as far as violating the second postulate of Agile Manifesto.  Most commonly, this is seen in internal training, at companies that mostly rely on their internal ambitions and self-confidence to become agile. When it comes to internal communication or information sharing, employees are accustomed to lengthy, “high-density”, corporate-style presentation decks.  They carry this experience into agile training, where now it becomes their expectation of what agile training materials should look like: they look for lengthy pages of instructions and execution plans.

Speaking of training materials, it is relatively easy to distinguish training materials of a professional trainer and materials produced by an internal agile champion, who has little experience in the field.  In the former case, materials are usually light in verbiage, more illustrative, graphical and entertaining; they mainly serve as conversation enabler and a “pacer” for an instructor.    In the latter case, materials are very data-dense, fine-printed and require intensive reading.   Unsurprisingly, when students attempt to follow pages of heavy presentations, they disengage from their classmates and instructor.  This further reduces learning and information retention.  This is also a primary reason why there is so much reliance on slides post-training.  Students mistakenly believe that what has been presented on slides is a prescriptive set of executable instructions.  Upon exiting “deck-driven” training, people end up ‘renting’ decisions that were suggested on slides, instead of deriving and owing their own decisions.  Instead of leaning more towards experimenting, inspecting and adapting, people look for directive guidance and “best practices” from a trainer (whose experience might be also questionable).

A few classic erroneous requests that thrown at internal trainers:

  • “Can we review training materials upfront so we can evaluate relevance of training to how we work today, so we can decide if we should come?”
  • “Can we be excused from training but review training materials instead to get up to speed?”
  • “Can training materials be finalized and standardized across all current and future training for all teams?”
  • “Would it be OK if we joined via audio or video bridge and closely followed training slides, instead of attending in person?”

What some people also don’t realize is that today, the best training/educational information is an absolute commodity and it is freely available on the internet.  Today, a heavy training deck has practically no intrinsic value because it is, most likely, a digest of books and articles created by others with a lot of copy-pasting involved (often, plagiary).  From a standpoint of a professional trainer or coach: if someone is looking for so much reliance on training materials and execution scripts, they may just purchase a really great agile book and read it on their own, instead of coming to class.

Summary:

Challenges with training (both public and internal) may cause further downstream adverse effects, beyond classroom:

  • For public training, this may potentially lead to bad reputation of a trainer or give undesirable publicity to his/her course value
  • For internal training, especially in situations, where it is followed by longer term coaching (could be also done by the same person that delivered training if he possesses coaching skills), this may lead to inability to effectively assist a team in their agile journey.

The “R” part of HR

Frequently, HR topics find their way into Agile Communities and almost always become heated discussions. Recently,  and again, one of such topics was raised in the global community of Coaches and Trainers.

Truth be told, HR norms and policies are a direct reflection of organizational culture (also, corollary to structure) and very much define human relationships within an organization. This is why, very often, the “R” part of HR is referred to as “Relationship”. A few weeks ago, at 2017 Business Agility, held in NYC, there was a strong reminder about this, by Fabiola Eyholzer.

There is a widely shared belief that the historical meaning of “R”, as it was originally defined: “Resource” – is no longer appropriate. Or has it ever been?

To refer to humans as Resources implies that people are inanimate objects, machines, goods or services that are simply acted upon by more intelligent resource managers. But resources do not think, do not take initiatives, do not mature and do not self-advance. And humans – do. So, how can humans be just resources?  “Resource” – was probably an accurate description of a working human in the early part of the last century, during the Industrial Revolution, in the era of Taylorian Management (F. Taylor summed up his management efficiency techniques in his 1911 book “The Principles of Scientific Management”). Back then, when most value of humans’ work was in their mundane, unskilled physical factory labor, there was a strong belief that decision making (done by higher-paid skilled management) and decision implementation (done by low-paid, unskilled laborers) – must be clearly separated.

However, in the 21st Century of nanotechnology, artificial intelligence, nuclear biology and galactic explorations, should humans still be considered as resources, or are they rather humans?

In agile organizations, where self-organization and self-management is one of the fundamental pillars of success, referring to humans as ‘resources’, becomes even more misleading. It would be very inappropriate to consider a highly skilled, cross-functional scrum team member, who is expected to experiment, improvise, inspect and adapt – as a resource. It would be no less misleading, to call a scrum team or a few teams, working together on the same complex product, as “pool of resources”. A manager who says: “I got 15 resources on this project” – is a Taylorian Manager.

And back to the acronym of “HR”: by re-labeling “R” into Relationships makes the meaning of HR, as an abbreviation, so much stronger.
Indeed, how much more pleasant and comforting (psychologically, of course) would it be for an average worker to know that there is an organizational area (department)
that strongly fosters importance of human relationships inside an organisation?

Language and wording is powerful: it shapes behaviors.

For more references and publications about HR-related topics, please visit this page.

Agile Flyer – 02-05-2017

 


Unspoken Agile Topics

/re-printed from its original version/
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.
Read more…


Mentoring Coaches
(New Virtual Mentoring Program)

“How can credible, guide-level agile professionals that have sufficient amount of experience and a proven track record in coaching and leadership make themselves stand out?”
Read more…

Agile Self-Assessment Maturity Matrix
(…or how people self-reflect on their agile journey…)

A few weeks ago, I had a pleasure attending Scrum @ Scale course, taught by Jeff Sutherland.  One of the in-class exercises that spanned across the entire duration of the class was having students make an assessment of their respective organizations, in various dimensions of agile maturity,
as they were discussed in class. The areas covered are displayed in image (below), in the left column.  The dimensions of agile maturity discussed were: Prioritization, Delivery, Refactoring, Continuous Improvement, Strategic Vision, Release Planning, Release Management, Feedback loops, Metrics/Transparency and others.
To “grade” (assess) the state of maturity for any given dimension, people used a grading legend (right image below).
Post-it notes of different color were used to make graphic illustration more visual.  It was pretty revealing to see so much orange color on the wall – indicative of situations with partial blockage/impediments.



(The next Scrum @ Scale course taught by Jeff Sutherland is on March 2-3, in Boston, MA.)

More upcoming Agile Events in NYC:

Product Development Types: What Challenges to Expect in Each Case?

Not all types of product development are the same.  The most three distinct types are:

  • Internal Product development, where
    • Users/Customers are internal
    • Product Owner is internal, playing the role of a conduit between Users and Technology
    • Dev/Technology/IT is internal, mainly dealing with Product Owner (and her team)
  • Outsourced Product (“Project”) development, where
    • Users/Customers are internal
    • Product Owner/Lead User is internal, playing the role of a conduit between internal Users and external Technology vendors
    • Technology is external, represented by vendor-companies
  • External Product Development, where
    • Real (paying) Customers are external
    • Product Owner (classic Product Management/Business Unit) is internal and facing external Customer
    • Technology/R&D/Development is internal and interacts only with Product Owner

While these classifications may seem to be obvious, there are some important “nuances” that are often being overlooked.  Awareness of these nuances could be important for making product development practices less vulnerable.

Here are some potential pitfalls to look out for, with each type of product development:

(Note: This post does not provide any recommendations on how to avoid/reduce pitfalls.  Some suggestions might be covered in future publications.)

 

Internal Product development

  • Fake Product Owners (delegates, proxies, surrogates) that lack either authority, or vision/breath of product knowledge, or both
  • Artificial “internal contracts” between various company units, secondary to organization design. These, are often driven by internal competition, ineffective external motivation, subjective monetary incentives and bonuses
  • Technology is too remote from real customers, does not deal with them directly and has to go through additional organizational layers, units, groups, roles (even to get to  internal Product Owners)
  • Excessive amount of processes, tools, metrics/KPIs and reports that are used as mechanisms for measuring business value delivered and levels of customer satisfaction.  This is because of absence of real, short-loop customer feedback.

 

Outsourced Product (“Project”) development

  • Low mutual trust (both, client and outsourcing company). Product development process is “wrapped” into artificial projects and portfolios, typically, with fixed scope, timeline and budget.  Customer-vendor relationships are very contractual, with legal binders.  While there are much more effective agile contracts that exist today, they are rarely used, because of lack of ability, by either side, to execute them.
  • Documentation is voluminous and is at expense of collaboration and transparency. Approvals and sign offs are mandatory and are usually accompanied by rigid legal processes
  • Unfit vendors: many companies still rely on vendors, with whom they have been dealing historically (via vendor management system), instead of turning to a market place, every time there is a new need,  and searching for best candidates. Preferred vendors feel safe and comfortable, and with such “monopoly” in space, they have low, if any, desire to strive towards improving technical skills, adopting new technologies, etc.   Also, nothing prevents such “preferred” vendors from making unsubstantiated claims about their experience with agile product development: rarely cases studies or references from other clients are requested.  Fixed contracts just make things worse.

 

External Product Development

This product development type is probably the best candidate for agile approach: customers are real, real money exchanges hands, competition is real and often strong, fast market changes require product companies to be nimble, light-footed and fast-responding.  However, there are still some challenges here.

Specifically, the communication channel called “Clarifications” (between Technology and external Customer) that is crucial in agile development (e.g. Scrum) is usually weak or does not exist at all.  Due to geographic distribution, legal contracts and compliance issues, it is challenging to co-locate real customers and developers and have them directly engage with each other.

Since everything flows through Product Management /Marketing/Business internal organizational layer, technologists get their information second-hand.  This also leads to producing additional overhead (processes, documentation, and approvals) by a product development company:  multiple external communication channels and competing priorities (different customers) that must be collected/filtered/prioritized and then single-threaded to technology.  To complete this job, internal Product Owner will require help.  This is how internal Business Units grow thick and as this happens more waste/overhead is introduced to a system.

Agile Flyer – 12-24-2016

 

This week’s Large Scale Scrum in NYC: CLP Training and Meet-up.

December 19-21. This week, there was a mind-blowing 3-day experience of system thinking and organizational design modeling with Craig Larman.
Having been at wide array of Craig’s training and public presentations in the past, I was still overwhelmed with volumen of education that this class offered.   One of the main distinctions ( imo – improvements) of this LeSS training from the previous, was the emphasis on hands-on system modeling by class participants,  with the use of Causal Loop Diagrams (CLDs).  Personally, being a huge fan and frequent user of CLDs,  I was able to graphically reinforce, once again, postulates of LeSS,
while modeling organizational design and inter-connecting system variables, as well as identifying which relationships are
Causation and which ones are Correlation.

Below, are some visuals that illustrate the course dynamics and working artifacts that were produced.

Class Kodak Moments:


Course Artifacts:


Course Highlights (personal):

  • If we go back to history and recall how Agile Manifesto was originally created and naming chosen, “Agile” was never meant to describe ‘speed’, ‘efficiency’ and ‘cost effectiveness’. It was always meant to describe Adaptive-ness.
  • To main goals of LeSS: to maximize Customer Value and ensure continuous learning
  • Organizational Structure is the most important, 1st Order Factor that influences System Dynamics
  • Many junior/unseasoned agile coaches give their clients a distorted coaching advice about agility, by advising to focus only on 2nd Order Factor (system variables) and omitting 1st Order Factor (Organizational Structure)
  • Young, ambitious, career-seeking senior leaders that are in active pursuit of promotion are not the best supporters of agile transformations from within a company. Most likely, they will view agile as a way to fast-track their career and after 3-5 years of supporting the “movement” they will leave their role and move on.  There is a high chance that someone, who takes over will “undo” what was done.
  • While using Causal Loop Diagrams (CLDs) it is important to distinguish between Correlation and Causation relationships that connect Variables
  • Team structure sub-optimization has multiple “dimensions”, e.g. too narrow-defined Products or teams built around Components
  • As per TPS, Kaizen does not mean “small”
  • Budgeting is rarely an issue in product companies. However, it is a BIG issue in internal development companies (e.g. banks)
  • John Kotter (The Heart of Change): <paraphrasing>”… get skeptics and resistors out of the way…. there is a low chance they will support changes…
  • While delivering agile/scrum education, strive to focus on an entire team, not of separate roles (e.g. SM, Team, PO).

LeSS Meetup Kodak Moments:

More upcoming Agile Events in NYC: 

Dec 19-21, 2016. LeSS in New York: CLP Class & Meetup

December 19-21. This week, there was a mind-blowing 3-day experience of system thinking and organizational design modeling with Craig Larman.  Having been at wide array of Craig’s training and public presentations in the past, I was still overwhelmed with volume of education that this class offered.  One of the main distinctions ( imo – improvements) of this LeSS training from the previous, was the emphasis on hands-on system modeling by class participants,  with the use of Causal Loop Diagrams (CLDs). Personally, being a huge fan and frequent user of CLDs,

I was able to graphically reinforce, once again, postulates of LeSS,
while modeling organizational design and inter-connecting system variables, as well as identifying which relationships are
Causation and which ones are Correlation.

Below, are some visuals that illustrate the course dynamics and working artifacts that were produced.

Class Kodak Moments:

Course Artifacts:

Course Highlights (personal):
  • If we go back to history and recall how Agile Manifesto was originally created and naming chosen, “Agile” was never meant to describe ‘speed’, ‘efficiency’ and ‘cost effectiveness’. It was always meant to describe Adaptive-ness.
  • To main goals of LeSS: to maximize Customer Value and ensure continuous learning
  • Organizational Structure is one of the most important, 1st Order Factor that influences System Dynamics.  (Some other 1st Order Factors are # of sites, group structures, organizational roles and hierarchies.)
  • Many junior/unseasoned agile coaches give their clients a distorted coaching advice about agility, by recommending to focus only on 2nd and 3rd Order Factors (e.g. values, norms, culture)  and omitting 1st Order Factors.  By doing so, they (coaches) misguide clients to go after local manifested/superficial problems, while leaving real underlying, systemic issues unchallenged.
  • Young, ambitious, career-seeking senior leaders that are in active pursuit of promotion are not the best supporters of agile transformations from within a company. Most likely, they will view agile as a way to fast-track their career and after 3-5 years of supporting the “movement” they will leave their role and move on.  There is a high chance that someone, who takes over will “undo” what was done.
  • While using Causal Loop Diagrams (CLDs) it is important to distinguish between Correlation and Causation relationships that connect Variables
  • Team structure sub-optimization has multiple “dimensions”, e.g. too narrow-defined Products or teams built around Components
  • As per TPS, Kaizen does not mean “small”
  • Budgeting is rarely an issue in product companies. However, it is a BIG issue in internal development companies (e.g. banks)
  • John Kotter (The Heart of Change): <paraphrasing>”… get skeptics and resistors out of the way…. there is a low chance they will support changes…
  • While delivering agile/scrum education, strive to focus on an entire team, not of separate roles (e.g. SM, Team, PO).
LeSS Meetup Kodak Moments:

 

Agile Flyer – 11-24-2016

 

Key Steps To Success
Agile Flyer

Happy Thanksgiving!!! 

This week’s “Give Thanks For Scrum 2016” in Boston

On Tuesday November 22, Agile Boston celebrated its 8th Anniversary,
by organizing Annual Give Thanks For Scrum event.
The main theme of the event was: Scrum – A Foundational Element of Major Agile Scaling Frameworks.
During the event people learned from regional experts about how Scrum is at the heart of major Agile scaling frameworks like Scrum@Scale (from Scruminc.), Nexus (from Scrum.org),
SAFe and LeSS. Attendees also heard from regional executives who presented how successfully their organizations have scaled Scrum and the lessons they have learned along the way.

Event Speakers

Jeff Sutherland

 

David West

 

Gene Gendel

 

Daniel Mezick

 

Yuval Yeret

 

Tammy Sparrow

 

Rirchard Gratton

 

Patricia Taylor

 

speakers_group

Below are Top-5 take away points from each speaker:

 LeSS presentation, by Gene Gendel

  1. LeSS is NOT!: many teams doing their own Scrum OR “safe Heaven” for existing organizational dysfunctions OR an attempt to “scale” Scrum to match existing organizational complexity
  2. LeSS provides clear distinction between the two types of relationships that involve Scrum Team(s) and Business: Clarification (from users, customers, SMEs) and Prioritization (from Product Owner)
  3. Geographic distribution in Scrum that keeps team members together (even though it may separate individual teams that work on the same product) is still not as harmful as separating members of the same team
  4. Component Teams are caused by existing organizational silos and , subsequently, lead to Local Optimization (that merely offers Role Security), at expense of System Optimization
  5. Frequently made assumption that the role of conventional Project Manager and the role of Scrum Master are the same – is a mistake. These two roles are very different: they engage with teams completely differently and their behaviors are not the same. Project Manager – coordinates and takes full responsibility for deliverable. Scrum Master – facilitates, while the whole team is responsible for deliverable.

Scrum @ Scale, by Jeff Sutherland

  1. In 2016, lean alone is not sufficient enough. Agile competition goes way beyond lean manufacturing. It requires major changes in organization, management philosophy and operations.  Agile Transformations require Senior Leadership transform first.  Managers must become Leaders.
  2. Agile & Scrum can and should go much further than software development. They may touch all organizational domains
  3. Different companies have different needs for improved agility, e.g. Large Defense Contractor, mid-way software company, “Agile Native” company
  4. Strategic Objectives determine Agile Approach. But you have to descale organization first, in order to scale scrum
  5. FrAgile (“Shu” state) = CEO does not have agile mindset. Translation layer that sits between FrAgile layer and Waterfall layer (e.g. PMO), provides insulation and must be ultimately removed to get high performance

Nexus, by David West

  1. Scrum is the most popular way teams are approaching Agile – About 90% of Agile teams are using Scrum. Because of this it forms the basis of all the scaling approaches, even home grown (VersionOne survey 75% using a Scrum of Scrum approach to scale).
  2. Scaling where you add more systems, processes and organizational ‘stuff’ will not make you agile. Agility is the opposite with a strong focus on empowered teams working in a environment that support the three pillars of inspection, adaption via transparency.
  3. Nexus is a light weight exoskeleton for Scrum helping teams have a consistent approach to scaling their product development. Nexus is not an approach to Agile IT, instead focusing on how you can have 3-9 teams working together on a backlog with a large number of dependencies.
  4. Nexus is still Scrum, but adding an additional role of Nexus Integration Team, events of Nexus Sprint planning, Nexus Daily Scrum, Nexus Sprint Review, Nexus Sprint Retrospective, and Refine, and Artifacts of the Nexus Sprint Backlog and Nexus Goal.
  5. If you have bad Scrum, Nexus will just highlight the bad – good Scrum makes scaling work.

SAFe, by Yuval Yeret and Daniel Mezick

  1. We need to scale Scrum DNA, not just Scrum practices
  2. “You can have things your way and push it if want, but this door is pretty stubborn”. – “PUSH” approach does not work well with systems. You have a better chance to succeed if you “PULL”
  3. What do you get when you scale an Agile Theater (a.k.a. Waterfall)? You get SAFe Theater (Starring the Managers-Only PI Planning, The Command & Control RTE, w/ special guest – Waterfall Thinking)
  4. Scrum is a foundational piece of SAFe’s Team Level and is best seen on Essential SAFe 4.0 schema
  5. In order to SAFely scale agile, you must use Real/Genuine Scrum DNA + Lean/Agile Principles + Leadership

 

…Something else you need to know about LeSS….

 

Scrum Alliance (SA), by far, is the largest agile organization, worldwide, and is represented by so many highly exprienced Coaches and Trainers, whose main goal is best described by the following slogan: “we are changing the world of work“.  While educational curriculum, delivered by SA Certified Scrum Trainers (CSTs) is very rich, its main focus has mostly been on Agile Manifesto (with its values & principles), core Scrum (with its roles, responsibilities, artifacts and ceremonies), and with orientation towards and support of basic Scrum certifications, such as CSM, CSPO and CSD.Scrum Alliance has never taken an official position with regards to agile/scrum adoptions at scale.
Its position has always been neutral and agnostic to scaling: “our Coaches and Trainers are versatile enough to pick the best approach for their clients”.
And indeed, when it comes to recommending scaling solutions, Certified Enterprise Coaches (CECs) and Certified Scrum Trainers (CSTs)
have a plenty of ‘scaling tools’ in their toolbox to offer, and they do it situationally, based on specific needs of each client.However, over the last few years, there has been a very strong trend in CST/CEC community with regards to scaling preferences.
If we take into account shared personal experience, case studies and research, coming from Coaches and Trainers, it becomes apparent that a very significant number of them are very supportive of Large Scale Scrum (LeSS), as a preferred scaling approach. Many CSTs have built LeSS teaching in their CSM and CSPO courses. Many CECs have been using LeSS, with its strong principles, guidelines and numerous expericences to de-scale companies, challenge classic system dysfunctions and improve organizational design.Many CECs and CSTs have also become Certified LeSS Parctititioners (CLP) by attending LeSS courses. Also, there is a growing number of
CECs and CSTs that are in pursuit of LeSS Trainer accreditation – to be able to teach LeSS in a more structured way.What does this overwhelming interest in LeSS mean for the agile community at large? For organizations? For Coaches, Trainers, Scrummasters,
Product Owners, teams?

Will LeSS become the “main stream” for scaling in a future?
Will it become as widely recognized in the US as it is in Europe and EMEA (another very interesting trend that is observed!!!)?
It is worth mentioning that there are a few other good agile scaling frameworks available. But LeSS seems to be picking picking up speed and noticeably.
Time will show…Perhaps, soon…

With that said, here is the great opportunity to learn Large Scale Scrum from Craig Larman himself — he is the co-creator of LeSS.

This is the last opportunity this year and probably for a while now (Craig is planning to engage long-term with one of his clients) –
to have LeSS course taught by Craig himself, in its very original form.

Also, receiving LeSS training directly from Craig has another great benefit:
Craig has probably the most exentsive list of experiments with LeSS adoptions and has many real life stories to tell.

 

About the course:

 In this 3-day highly-participative course, people will get a thorough understanding of Large Scale Scrum,
for scaling agile development to many teams working together on one product.

In-depth, you will explore adoption, new organizational design, systems thinking & optimization, the role of management, and approaches of working together in Sprints at scale, by optimizing coordination, architecture and planning.

This course will also include an in-depth Q&A clinic based on Craig’s long experience with LeSS adoptions.

Here are some highlights of the course:

  • LeSS Overview (LeSS principles, frameworks, guides, experiments)
  • Two LeSS frameworks: basic & LeSS Huge
  • Adoption (pre-adoption & the adoption guides, 3 principles, getting started, scope of first adoption, stories of LeSS adoptions
  • Local Optimization & System Optimization
  • Adoption: Organizing by Customer Value
  • Shu-Ha-Ri and frameworks
  • Empirical process control
  • Occupational psychology
  • Lean thinking & value-driven
  • LeSS Sprint
  • Done & Undone in LeSS
  • LeSS Rules
  • LeSS Huge Framework
  • More on LeSS Roles
  • Managers in a LeSS organization
  • ScrumMasters at scale
  • Product Owner in LeSS
  • In-Depth Special Topics: A Deep-Dive Q&A Clinic
  • ….and much more…

If yo would lile to read more about the agenda of this course and register, please follow this link.  You may use the following discount code: hrte416 get a cheaper price.