Category Archives: Agile

01/15-LeSS Talks: System Modelling in LeSS with Robin Hyman


Miro Board Export

Relevant References:
Additional STRUCTURED LEARNING Learning Assets:

01/24-LeSS Talks: Lead and Serve Others: Focus on the Team, Not Individuals, by Johanna Rothman

 

Materials | Live Chat Transcript

A very relevant resource: Gap Between Science and Business

Additional Learning Assets:

 

01/24-LeSS Talks: Experience Report: Navigating Self-Incorporated Consulting

Recording – TBD

Optional Pre-Read for this event.

 

Additional recommended assets:

12/13-LeSS Talks: Case study about a LeSS adoption in Business Lending, by Cesario Ramos

Materials | Chat Script

Some of you may have seen this publication a few years ago, by Cesario Ramos: “… [Company] improves on the so-called Spotify Model using LeSS” that shined some light, from the inside, on what really took place.
[NB: As many people probably know, “Big Bank Spotify Model” success stories are being used by many large consultancies and companies that followed the advice]. Please, read about it: https://www.scrumwithstyle.com/ing-improves-on-the-so-called-spotify-model-using-less/

Synopsis:

“How do we use LeSS to further optimize the Spotify model; How to tackle scaling challenges with less. We will share our experiments, mistakes, and learning we got from adopting LeSS in a cross-border, dispersed team setting without Continuous Integration.”

Continue reading 12/13-LeSS Talks: Case study about a LeSS adoption in Business Lending, by Cesario Ramos

12/06-LeSS Talks: US Army’s Intelligence Staff Director COL Candice Frost on Crisis & Leadership

Colonel Candice Frost:

Synopsis:

  • An 80% solution on time is far better than a 100% solution late
  • Defining Problem Statement
  • Demonstrating a desire to create change
  • Providing a clear Vision into the Future
  • Leading by Example
  • Clearing Paths to Achieve a Common Goal
  • Changing is Constant
  • Building Strong Relationships
  • Providing Consistent & Continual Feedback
  • Giving Transparency

  • How excessive organizational layers, processes and approvals can lead to missing an opportunity
  • Importance of mentorship/education, as means of spreading knowledge laterally, to many people
  • Significance of striking a healthy balance between being a Specialist (know one discipline really well) and being a Generalist (knowing other disciplines fairly well)
  • Benefits of building long-lived teams
  • Keeping levels of “undone” work to a minimum and thriving to drive it to zero
Additional Learning Assets:

LeSS Trainer’s Class Experience Report: Product Definition, DoD & Team ‘Blueprint’ Exercise


This summary, is an experience report from the recently conducted online LeSS class (provisional CLP).  Specifically, this writing is about a few discussion topics, accompanied by in-class exercises and homework activities: product definition, definition of done (DoD) and teams (blueprint).

In class, we were lucky to have a few people that were already highly experienced with Scrum and knew fundamentals of LeSS. A few people were also from the same XYZ company (name withheld for privacy) that specializes in global ERP solutions for manufacturers. Among XYZ company people, there was a senior vice president of R&D and a few other senior-ranked technology professionals.  With everyone’s consent and for everyone’s benefit, we were able to discuss the above topics in the context of XYZ case.

It was also made clear to everyone that this exercise is merely a simulation of a much more comprehensive discovery process that takes place during the initial phase of LeSS adoption, with many more people involved, not just a few.

We started, by trying to understand the company’s big picture: vision, revenue steams, cost factors, product partnership (internal business, external customers, R&D), value, competition, innovation.  For that, we used the great facilitation tool, created by E. Gottesdiener – The Product Canvas.

After the first round of exploration (v1.0 below), it became apparent that the product definition was too wide (big), and it would be impossible to support its development by a single LeSS product group (2-8 teams).

Of course, this assumption was not conclusive but for the purpose of this in-class exercise, it was decided to reduce the product definition, by focusing only on one particular area – Sales (v2.0 below).  This was consistent with what is recommended in LeSS: to expand product definition as reasonably possible, but not make it too wide to manage.

In the second phase of product definition, the class focused on identifying user types and actions, as well as various product components: interfaces, data, controls, environments, etc. This further helped validating the assumption, made in the first step of product definition.

Following the product canvas use, to identify the most important (and big) product features, the class proceeded with a story mapping exercise. The following five large features have been identified: New Sales Order Interface, Shipping Dashboard, New Quote Interface, Data Layer. They were then further decomposed into smaller features that were prioritized, on a time scale.  The class had a quick conversation about what a minimal viable feature (MVF) could look like if multiple small features, from various buckets were deployed together (the curvy black line below).  Within a few rounds, many more small features were identified and bucketed under large features (but not prioritized). It was a shared understanding by everyone that all identified items, eventually, should end up in a backlog.

Next, the class tried to envision what Dominion of Done (DoD) could look like for a team that was tasked to deliver any of the above mentioned features. The attempt was made to identify those activities that would be still Undone (impossible to finish in a sprint) at the initial stage of sprinting and how important it would be to gradually expand DoD and shrink Undone, over time. The class further discussed differences between Unfinished work (usually, a team’s problem) and Undone work (usually, organizational problem).

Based on all of the information collected, the class tried to envision what technical skill set and functional domain expertise would be required, for each team, to ensure that each team could take any item from a backlog and get it to Done in one sprint.

Finally, the class (this part was mainly driven by people from XYZ company) tried to hypothesize what a team structure could look like (team ‘blueprint’), given that some developers had one and some – more than one, skill set and domain expertise. Everyone understood that this is just a hypo and the intention is not to assign people to teams prematurily, since managers, leads or anyone else should NOT be making decisions on behalf of on teams. The idea of self-organizing team-building workshop was introduced and discussed (a few published LeSS case studies were reviewed to better understand this event).

 

During the break, one of the class members (XYZ company) tried to blueprint what LeSS Product Group may look like if v1.0 model (illustrated above) was followed to describe the whole product.  It appeared that each Requirement Area, would have only between 2 and 3 teams. It was then discussed that this approach would  NOT be recommended, as very small requirement areas (with very few teams in each area area) would lead to organizational silos, compartmentalizing of work, scattered knowledge and local optimization.
The class further discussed R&D organizational design implications of XYZ company. Many HR aspects were highlighted, such as a developer’s career path, promotions, compensation/incentives, etc. Various HR-related LeSS experiments were  explained.

At this point, the class ended the simulation exercise, with understanding that in real life this process could take from a few weeks, to a few months. It was understood by everyone that before an organization makes a ‘flip’ to LeSS, some additional, very important milestones would have to be achieved:

Team Self-Formation Workshop:

Product Backlog Creation (Initial PBR session):
Preferably, a creation of an organizational impediment backlog – something, to be continuously attend to during Overall Retrospectives, where senior management, would take ownership of problems.

HR-Related LeSS experiments

 

XYZ Company people have demonstrated a lot of determination to implement many aspects of LeSS learning and discoveries ASAP, in real work settings, within their organization.

11/18– LESS TALKS: Why Do Transformation Fail? Coordination Chaos, by Ari Tikka and Ran Nyman

Presented by  Ari Tikka and Ran Nyman

(original source)

Download Materials: https://www.keystepstosuccess.com/wp-content/uploads/2020/11/ari_ran_nyc_less_failed_transformations.pdf


Upcoming LeSS Training 

Additional recommended assets:

Shu-Ha-Ri

Click to enlarge

We have to be careful, when applying the ancient Japanese martial art concept ShuHaRi (stages of learning to mastery), to modern corporate structures and organizational dynamics, when talking about agile:

Some examples of a misuse:

  1. Laying ShuHaRi over fixed-in-scope strategic goals, while representing each phase (Shu, Ha, Ri) as a fixed-in-length time-box. This gives an impression of a linear, pre-determined, phase-gated progression.
  2. Mapping ShuHaRi to agile maturity model levels (e.g. Shu=Level 1, Ha=Level 2, Ri=Level 3). There is a risk, that in pursuit of a higher maturity (linked to rewards), teams may be tempted to game the system.  Also, Ha and Ri stages are longer and more complex than Shu. For example, there are multiple instances of Shu, within Ha, while both Shu and Ha could be present within Ri.
  3. Linking ShuHaRi to agile roles that are, subsequently, linked to compensation levels, defined by traditional organizational structures, leads to unwanted ‘agile hierarchies’.

Please, note:

ShuHaRi is a very long, non-linear journey that consists of phases that differ in duration and complexity. Oversimplifying it, to fit the corporate language, is not advisable.

Here is one great reference to better understand ShuHaRi.

 

Word Play, Masquerades and Omissions with Scaling. Any Alternatives?

 

Presentation Materials

Upcoming LeSS Training 

Additional recommended assets:

My CEC and CTC Journey

(Re-posted on LinkedIn | Scrum Alliance)

This writing is way past overdue. I have been putting this off for, at least, a few years. But it is better later than never😊.

Today, I would like to share my (this is Gene) personal journey of becoming a Certified Enterprise (CEC) and Team (CTC) coach.

About the Programs

Both of them: CEC and CTC – have been developed by the Scrum Alliance volunteers.  The evolutionary path of both programs has been pretty long and full of experiments.

CEC came first. Some years ago (more than 10), what is called today as Certified Enterprise Coach (CEC), used to be called Certified Scrum Coach (CSC). At one point, the decision was made to rename CSC into CEC, for a variety of reasons, with one (big factor) being that CEC was more descriptive of a coaching focus, since at this level, a person coached not only Scrum but much deeper and broader (organization, enterprise).

But it was not just changing the acronym, it was also a complete redesign of the program.  What used to be a binary pass/fail outcome for an applicant (you submit, you wait for a while, you get a verdict), has evolved into a high-transparency, enriched with short feedback loops, multi-stage, iterative, full of learning and self-discovery, process.  Some time, after CEC has been redesigned (around 2014), there also came CTC (about a year later, or so). The main reason for creating the CTC, as a separate program/credential (NB: I was one of the co-creators but more about this below), was that (multi-) team-level coaches, had somewhere different focus than enterprise coaches: CTCs are were focused on multiple teams, CECs were focused on the whole enterprise.

Some Most Common Misconceptions about CEC and CTC
  1. “…there is no degree or accepted global accreditation that provides comfort around the skills and experience needed for the job…“. Not true. Howard Sublett, Co-CEO/Chief Product Owner of Scrum Alliance explains why this is not an accurate assumption, explaining how CEC and CTC have evolved, over years.
  2. CEC and CTC are just two certification badges that a person get, by simply attending a course and then passing an exam. Not true. Both programs are supported by a comprehensive application process that requires a wide spectrum of qualitative accomplishments: well documented coaching experience, formal and informal coaching education, mentoring experience (mentoring others and being mentored), long agile community engagement and contribution, deep knowledge of coaching tools, techniques and frameworks; as well as, qualitative “know-how”: deep agile knowledge, coaching competencies and mindset.  In a way, both CEC and CTC, remind a dissertation, written by a person who tries to capitalize of a long agile learning journey.  CEC and CTC can be graphically visualized as these little blue figures, on the left side, of this image.
  3. CEC and CTC – is a guarantee to easily secure a job with a significantly higher pay.  Not true.  Although in some countries/by some companies, a lot of emphasis is made on certifications, there is no statistical data to support that CEC or CTC holders have a ‘golden key’ to companies’ doors, while making significantly more money than non-holders.
  4. Once a person obtains CEC or CTC, their learning journey is over. Not true.  In fact, the opposite is true: the best part of the journey begins after a person earns the credential. Many people, consider getting the CEC-CTC credential as a tremendous boost to a personal ego – an ego to learn and further advance, in order to be ahead of others and continue elevating a coaching bar.
  5. Since CEC and CTC application process does not involve a multiple choice test, it is prone to errors and personal bias, by application reviewers. Not true.  Although, a personal perception factor is always present, whenever one human assesses another human, both programs, are very carefully designed to minimize/avoid subjectivity, bias and anchorage, as much as possible (multiple reviewers, calibrated score cards, recusing from review of colleagues/acquaintances etc.).  Check out the above links for details of the process.
My Personal Journey

My journey has begun in 2010, about a year after I received my CSP credential. I applied for Certified Scrum Coach (CSC) – the old version of CEC. I was so confident that I would pass it with flying colors…  Oh boy, was I wrong?  I did not succeed. Looking at back now, I realize that the reason was two-fold:

  • Back then, the process was not too supportive of me, as an applicant. Although I was sure that my reviewers were qualified people (I got to know them in person only years later), the whole process was not transparent and not conducive of iterative learning.  For me, personally, it was not a learning journey.  I had to work on my application in a complete silo, without having any idea if I was on a right track, without getting any guidance along the way. Then, I summited, and had to wait, for about 3 months, before I got the result back: not ready.
  • But to be fair, years later, after becoming CEC, when I reviewed my own, old CSC application, I thought: what a mess it was!  I would not pass myself either: style of writing, clarity of thoughts, ability to present content – they were not up to par with what I would consider today as an enterprise-level coach.  After not passing the original CS, I took the feedback from my reviewers at its face value (not without a disappointment, of course) and decided to let some time go by, before resubmitting.  I wanted to give myself a good chance to advance in my own learning and experience, at my own pace, without having the urge to re-apply fast.  Luckily, I did not feel that I needed a credential to find an employer or a client.  My other hope was that, eventually, the application process would improve, before I applied again.

Four (4), long years went by…

…Many more coaching gigs, many more read books and white papers, attended conferences, retreats and public events, tons of professional networking.  I mentored others and was mentored by more seasoned people. I coached, as a part of my paid job and if someone just needed personal help – I would coach for free, one-on-one.

As an agile coach, I also came to terms with the fact that I am an organizational and team design agent, someone who needs to strive towards changing the ‘world of work’ (also, happens to be the motto of Scrum Alliance), not just coach for the sake of coaching.

In the early part of 2014 I learned that the old CSC program had been redesigned (the effort, spearheaded by Pete Behrens and Roger Brown, who later became my greatest mentors) into the new CEC program and a beta-group of coaches-aspirants-volunteers was required to become the first “explorers” to go through the experiment. Being a huge fan of experiments and having a gut feeling that the time was right, I volunteered immediately.  As I recall it now, I was probably the only “scarred” applicant – someone who had experience with the old CSC program…

To make a long story short…it took me close to five months to go through the program. The hot summer of 2014 – it was me, spending many hours each week, reading, researching, writing and re-writing. From time to time, I would get a feedback or request for clarification from my reviewers. I would then jump on it, research it, study it and take another stab at the google document (by then, the application process was put online). I loved being a Guinea pig 😊.  The amount of additional learning and self-discovery that I made, while working on my own application was just immense. It also felt, as if I almost relived all of my professional experience as a coach (by then I already had many years of coaching behind my belt). Along the way, I collaborated with other applicants, sharing our experiences and bouncing around ideas (of course, everyone’s application was filled out independently).

In October of 2014, I got notified by Scrum Alliance that I was granted the CEC credential. This was one of the most exciting moments in my professional career! It was truly a huge milestone for me. In fact, I was the very first beta-group applicant that made it through the newly redesigned CEC program. It was a triumph.

Benefits After Achieving the Goal (becoming CEC-CTC)

Although CEC never became an automatic “golden key” door-opener for me, earning the credential certainly gave me additional self-confidence and boosted my ego.  I recall being asked by my clients and interviewers what Scrum Alliance *certified* enterprise coach meant and how it was different from “un”-certified. Those moments, were my best opportunities to talk about my professional journey and valuable assets that I bring to the table, as CEC.  Some of my more open-minded clients admitted that what they considered as a ‘coach’ up until then, was not even near what a coach is/does.

Becoming CEC has put me in small group of elite-guide-level professionals with privileged access.  I gained the privilege of joining closed discussion forums with Agile Manifesto co-signers and Scrum co-creators. Seeing them exchange and engage in hot debates, as well as being able to freely engage in any of those discussions on my own, was such a great asset.  At times, just following a thread about Scrum, Kanban, organizational dynamics, scaling, product management, technical excellence, classroom dynamics, business aspect of public training – would enrich my personal knowledge by a factor.

Helping Scrum Alliance to Further Raise the Coaching Bar

Some time, after earning my CEC, I learned that the group of volunteers-CECs was pulled together to create the new Scrum Alliance certification-credential: Certified Team Coach (CTC).  I volunteered myself and joined the group (Roger Brown was the leader).  The purpose of our effort was to delineate between the two types of a coaching focus: enterprise and (multi-)team.  After multiple years of research and discovery, it has become apparent that some coaches wish to focus on teams’ dynamics (e.g. multi-team PBR, multi-team Sprint Planning, Overall Retrospective), whereas others – on enterprise dynamics (HR policies, budgeting-finance, location strategies, vendor management, etc.).  Please note, the above are not mutually exclusive.

Rightfully, some of the quantitative (and to some degree, qualitative) expectations from CEC were higher than those of CTC.  However, just like the CEC, the CTC program was designed to be a very rigorous and challenging selection process, to identify guide-level, senior coaches.

In January of 2018, I also decided to gain my own CTC credential, since there were many instances in my career, when I had to coach at multi-team level.  It also did not feel right for me NOT to have the credential, while being involved in its creation😊.

Today, I run my own mentoring program for people that wish to pursue the CTC or CEC credential.  My focus is three-fold: advanced system thinking → improved coaching capabilities  → application success.

Other Important Milestones during My CEC Journey

One of the biggest aspirations throughout my entire coaching career was becoming a better system thinker-modeler – a person who could see and assess the whole organizational (eco-)system, not just its individual parts.  In enterprise-wide and multi-team settings this skill is a must, at least in my opinion.

Right around the time when l did not succeed with my initial CSC application, I zoomed my focus onto lean and agile product development, at scale and in multi-site settings – something that most of my clients had interest in and trouble with.  My attention was drawn to a series of books, written by Craig Larman and Bas Vodde (both later becoming my other great mentors), where they have covered many guides and experiments that I found very applicable in my work.  Since then, I have applied much of my learning (today, a.k.a. Large Scale Scrum or LeSS), while coaching individuals, teams and organizations.  I find LeSS education a significant asset to my own coaching journey (during and post- receiving the CEC and CTC credentials).  Today, I am one of a few (worldwide) Certified Large Scale Scrum Trainers (CLT) – another very unique and valuable milestone in my career that is also very complimentary to being CEC-CTC.

The above is originally posted on my blog.

More about me and my work.