Category Archives: Coaching

May 19-22: Global Scrum Alliance Gathering | AUS-TX

An amazing 2019 Global Scrum Alliance Gathering (May 19-22), organized by SA staff that brought together a record-high number of professionals from around the globe and had countless amazing events – too many to describe them all in one newsletter. ūüôā
Here, I would like to  recap what committed to my memory the most:
  • Keynote presentation by Daniel Pink
  • My personal experience from servicing the ‘Fans of LeSS’ booth, attended by hundreds of people
  • Highlights of my own presentation that draw more than 100 people: “How to Stop Deterioration of Coaching Quality: Industrially and Organizationally” and feedback from the room
  • Coaches Clinic and Coaches/Trainers Retreat highlights¬†

Keynote Presentation by Daniel H. Pink

During his keynote presentation, Daniel H. Pink (the best-selling author, contributing editor and co-executive producer, known world-wide) shared the highlights of his new book: The Scientific Secrets of Perfect Timing.

Pink’s Synopsis: “We all know that timing is everything. Trouble is, we don‚Äôt know much about timing itself. Our business and professional lives present a never-ending stream of ‘when’ decisions. But we make them based on intuition and guesswork. Timing, we believe, is an art.¬† But timing is a really a science ‚Äď one we can use to make smarter decisions, enhance our productivity, and boost the performance of our organizations.

Some highlights from Pink’s talk:

Scientifically and statistically, both humans and apes, have the lowest well-being at mid-life.

Therefore, D.Pink’s recommendation on how to deal with such unpleasant mid-points, are as follows:

  • Beware [of such mid-points]
  • Use midpoints to wake up rather than roll over
  • Imagine you‚Äôre a little behind

Then, D. Pink also stressed that there are hidden patterns of how time-of-day affects our analytic and creative capabilities ‚Äď and how simple work rearrangements can improve our effectiveness. For example, when a person makes an appointment to a physician, it is best to ask for a morning time slot, instead of afternoon slot, since physicians tend to have more analytical capabilities before lunch.

D. Pink’s next point was that as individuals get older, at the end of each decade, they are more prone to take certain actions that psychologically make them feel younger. As an example, he used statistical data of marathon runners: people are most likely to run their first marathon at the ages that are just at the brink of next decade: e.g. 29 or 49 years old.

‚ÄúBecause the approach of a new decade‚Ķ functions as a marker of progress through the life span‚Ķpeople are more apt to evaluate their lives as a chronological decade ends, than they are at other times.‚ÄĚ- Daniel H. Pink
How about psychological reaction to the fact that something will be GONE and the time when it will happen is coming up shortly?

In one case study (left image), when a person was given one chocolate candy at a time, and was asked to give feedback about its taste, a response was usually consistent, for each subsequent candy. However, as soon as a person was told that it was the last candy to taste, feedback about how a candy tasted became significantly more positive.

In another case study (right image), when a group of people was asked to fill out a survey, in order to receive a certificate, before it expired, responses were different, when conditions were set as “will expire in 3 weeks” vs. “will expire in two months”.¬† Apparently, proximity of expiration date made people much more responsive to the request to fill out a survey.

D.Pink‚Äôs next point was about how half-time checks can shape our behavior and impact final results. According to D. Pink, scientists and researchers really like statistical data from sports because it is ‘clean’.¬† Here, using an example of basketball teams, when teams play a game, the following can be observed, depending on half-time results:

  • Being significantly behind ‚Äď usually results in a loss
  • Being significantly ahead ‚Äď usually results in a victory
  • Being slightly behind ‚Äď motivates people to step up and put an extra effort, which results ultimate victory
  • Being slightly ahead ‚Äď makes people relaxed, less focused and less persuasive, which results in ultimate loss

As such, there is a conclusion:

‚ÄúBeing slightly behind (at half-time) significantly increases a team‚Äôs chance of winning‚ÄĚ ‚ÄďD.Pink

Fans of LeSS Corner
A small group of Certified Scrum Trainers and Certified Enterprise-Team Coaches, supported the Large Scale Scrum (LeSS booth):  Fans of LeSS.

At least a few hundred people has come by the booth, asking for information about LeSS.
The booth servants received the following three biggest take-away points:

  • Unfortunately, still not too many people are aware of LeSS.¬† This is not to be confused with attempts or successes of adoption.¬† Rather, this is about general knowledge of what LeSS is. Ironically, the booth was labeled “Area 51” – the world’s best kept secret :).
  • Once being explained what LeSS is, how simple and common-sense it is, for many people, it has become an ‘AHA’ moment. The most awakening moment was understanding the difference between ‘global and local optimization’, ‘deep and narrow, as opposed to broad and shallow’, ‘owning vs. renting’.
  • Amazingly, how many people shared the same, almost standard complain/pain-point: “… we are currently using a very complicated, monolithic and cumbersome process (usually referring to some widely marketed XYZe framework), with multiple organizational layers involved,… and it creates lots of overhead, waste and friction,… practically nothing has changed in our workplace since the time we adopted it…same people, same duties and responsibilities (practically) BUT different terms, labels and roles … We really don’t like what we have to deal with now and our senior management is also frustrated but it seems that there is really nothing we can do to fix it at the moment…“.

“How to Stop Deterioration of Agile Coaching Quality: Organizationally, Industrially?” (my own presentation)

The goal of my presentation (Gene is here) was to discuss with the audience:

  • What is the problems‚Äô origin [as it is derived from the title]?
  • Examples of the problem‚Äôs manifestation?
  • How can we solve the problem?

Throughout the course of my presentation I:

  • Exposed some classic systemic dysfunctions that sit upstream to the problem in scope.
  • Gave some examples of the problem, by using cartoons and satire
  • Delineated between the problem aspects, coming from outside organizations vs. siting on inside
  • Described types of internal (organizational) coaching structures that are to be avoided vs. tried
  • Gave some suggestions on what to avoid vs. what to look for in a good coach
  • Gave additional recommendations to companies, coaching-opportunity seekers and companies’ internal recruiters

“Download Presentation as PDF”


…and a some additional highlights from the gathering….
The Coaches Clinic – for 3 days
This traditional ‘free service’ by Scrum Alliance Enterprise and Team coaches and trainers what at the highest ever: 300 people were served in total,¬† over¬† course¬† of¬† 3 consecutive days.


Certified Enterprise & Team Coaches and Scrum Trainers Retreat – Day 0:

This year brought together the biggest ever number of CECs-CTCs and CSTs.  One of the most important themes that was elaborated: how important it is for guide-level agile experts (CECs, CTCs, CSTs) to unite together in a joint effort to change the world of work.

Note: Thanks to Daniel Gullo (CST-CEC), who generously created for each attending Certified Enterprise Coach – colleague a memorable gift: Coach’s Coin with The Coach’s Creed:

  • CARITAS: Charity, giving back, helping others
  • COMMUNITAS: Fostering community and interaction
  • CONSILIARIUM: Counseling, consulting, The art of coaching
2020 Global Scrum Alliance Gathering is in NEW YORK(registration is not open yet)

2019 Big Apple Scrum Day Coaching Clinic – Highlights

2019 Big Apple Scrum Day (BASD) was an amazing experience for many Рagain!  The Coaches Clinic, supported by some top notch professionals in the industry, was one of the greatest hallmarks of the event Рthe tradition that has been maintained for the last 5 years.

Collectively, the coaches brought to the table lots of expertise, across multiple disciplines: organizational design, enterprise and team coaching, corporate culture, HR, business, DevOps/agile engineering, human psychology and other specialties.

Each coachee was given 15 minutes or more to share their thoughts, concerns or just ideas that required reflection and validation.  Throughout the daily course, the clinic has served about 35 people.

Below are some testimonies, coming directly from the coaches as well as some best Kodak moments:

Coaches’ Testimonies:

Zuzi Sochova, CST, Agile & Enterprise Coach:

“I had several conversations with people about their careers, about what is next, and it felt that the missing ingredients is a courage. The true agile value we all keep forgetting. The courage to brake the position structure and the prescribed career paths and create a brand new job for yourself. Don‚Äôt wait until someone opens a position. Design it yourself. Create a need for your skills and value you can deliver. Defined positions and career paths are over. They belong to the last century. In modern world the we need more emergent leadership, the flexible solution for an actual problem. And fixed roles only keeps status quo. You are a leader. Step out of your position box and create your own role, focused on value, allowing you to satisfy your dreams.”

Jim York, CEC-CTC, CST at FoxHedge:

“Another great turnout at the Coaches Clinic at this year’s Big Apple Scrum Day in New York City! My thanks to the attendees, sponsors, and organizers that make this one of the premier agile events on the east coast. This year marks the third year I’ve volunteered as a coach at the clinic. I had many good conversations with those who stopped by. If you were one of them, let me know how things turn out!”

Amitai Schleier, Agile and Development Coach at Latent Agility

“It was an honor to once again take part in the BASD Coaches Clinic. When people need advice or guidance for where or how to start improving technical practices, I‚Äôm happy to offer some ‚ÄĒ but only after I‚Äôve asked enough questions to begin to understand where they’re coming from and what they‚Äôre up against. Fortunately, our 15-minute sessions are usually enough to find at least one insight, one recommendation, and one action. Yesterday‚Äôs Coaches Clinic was no exception. My appreciation to Gene and the BASD organizers for including me.”

Mary Thorn, Agile Practice Lead at Vaco:

“Coaching at the Big Apple Agile was an enjoyable experience. The attendees were educated in their questions and ready to be coached. They came curious with open ears. They left with possible solutions to help them in their day to day execution.”

Aleksandr Kizhner, Experienced Agile Coach at TEKSystems:

“Big Apple Scrum Day is a groovy place to meet people who share your passions and interests. It is a place, where you can meet your influencing people and heroes, a place – to share your ideas, learn something new and help others with your knowledge and experience.¬† One interesting thing that I remarked about how it felt: much more about actual practitioners of agile practices, rather than theorists or consultants. This was reflected in the attendees that I was inspired to meet, and I thank them all for sharing their interesting stories with me.
What was coming that might be game-changing in agile adoption 2019?”

David Liebman, Agile Coach at Eliassen

This was the fifth year that I have participated in BASD’s coaching clinic among a group of outstanding and dedicated professionals.  It is always a pleasure and an honor to be part of this group.  

The individuals who came for coaching continue to demonstrate a passion for Agile and the issues and concerns that they brought during this year’s clinic dealt with everything from how to facilitate Scrum events to differences in implementing various Agile frameworks.  

The most notable trend in my coaching sessions was the focus on applying soft skills to foster greater collaboration among the teams, stakeholders and executive management. This was expressed as the need to understand and level set expectations at all levels. It seems that although the basics of Agile practices seem to be better understood over the years the successful implementation of Agile remains an issue where this disconnect in understanding a major cause.  

I believe that as we continue to attempt to be Agile we are at a point where difficult conversations need to be had to ensure that we agree on what success means and what we need to do to be successful.¬† I am confident that we will reach our goals.”

Kodak Moments:

2019 BIG APPLE SCRUM DAY: COACHING CLINIC (COACHES WORKSHEET)


This page is being gradually developed towards May, 2019 Big Apple Scrum Day Coaching Clinic.

For similar past events please visit:

Below are some basic guidelines for participating coaches¬†on how to run a coaching¬†clinic during Big Apple Scrum Day.¬† Experience and working models of previous clinics (Scrum Alliance, Agile Alliance) have being used. If you have other recommendations or additional ideas, please suggest ūüôā¬†¬†.

General Coaching Guidelines:

  • Wear a coaching hat ‚Äď we shall try to get some from Scrum Alliance folks (their ‘station’ should near the clinic)
  • Walk-ins are OK if we have capacity
  • Each session is limited to 15 min, unless there is no line – then you can attend to another person
  • Appointments get priority over walk-ins
  • It is OK to offer a business¬† card for future consultation but¬†Do NOT sell services or proactively solicit business, while coaching
  • Paired coaching is OK if we have capacity (one coach works, another observes; then‚Äď debrief).
  • Always, start off with understanding what brought a person to the clinic (e.g. ‚ÄúWhat brought you here?‚ÄĚ or ‚ÄúHow I can help?‚ÄĚ)
  • We can briefly retrospect at the end of the day or, if not possible, later via email

Participating Coaches (BOARD view):

This is us – the clinicians:

Coach’s Name Home base
 Gene Gendel  New York, USA
Mary Thorn Raleigh, NC
David Liebman New York, USA
Faye Thompson Hilliard, OH
Skylar Watson Des Moines, IA.
Jim York  Leesburg, VA
Alexandr Kizhner   New York, USA
Amitai Schleier  New York, USA
Ben Scott Richmond VA
Ross Hughes  Burlington, Vermont
Dustin Thostenson Des Moines, IA.

 

Coaches’ Availability (BOARD view):

In the morning, we shall put up a board in our working area.  On this board, each coach will put his name (on a sticky), in a time slot when he/she is willing/able to offer service.  Example below:

Time Slot Available Coach
8:00 – 8:30
8:30 – 9:00
9:00 – 9:30
9:30 – 10:00
10:00 – 10:30
10:30 – 11:00
11:00 – 11:30
11:30 – 12:00
12:00 – 12:30
12:30 – 1:00
1:00 – 1:30
1:30 – 2:00
2:00 – 2:30
2:30 – 3:00
3:00 – 3:30
3:30 – 4:00
4:00 – 4:30
4:30 – 5:00

Note: Time slots should correlate to the Event’s Main Schedule

 

Appointment Schedule (BOARD view):

On this board, each attendee will put his/her name/discussion topic (on a sticky), into a time slot when they are planning to attend the clinic.  Attendees may request multiple time slots, within reasonable limits. Each request  = one sticky note.  Example:

15-min Time Slot During

Attendee Name/Discussion Topic

Registration
Morning Session Part 1
Morning Break
Morning Session Part 2
Lunch Break
Afternoon Session Part 1
Afternoon Break
Afternoon Session Part 2

Note: Time slots should correlate to the Event’s Main Schedule 

BOARD: Coachee’s Response:

On this board, every clinic attendee  will be asked to write a brief feedback on a sticky note (example from Orlando). They may or may not provide the name of a coach that offered assistance Рit is up to them.   We, the coaches, don’t have to watch them doing this.  Once we are done with a coaching session, they can self-manage.

BOARD: Appointment Counter

On this board, we shall be collecting all sticky notes that were served. Attendees will be asked to post them there, after they attended the clinic.

 

 

Tips To Run ‘Big’ Retrospectives

For any team that uses scrum framework, a retrospective is a mandatory event that takes place at the end of each sprint.  It is an opportunity for a team to reflect on their most recent learning, while it is still fresh in everyone’s mind.  There are many tips, techniques and tools for running a retrospective.  They start with very basic guidelines of the Scrum Guide and expand into experiences and experiments of many teams and practitioners.
There are also recommendations on how to run a retrospective in more complex/scaled organizational settings, with multiple teams sprinting together (e.g. Overall Retrospective in Large Scale Scrum), as they work on the same product or service and support the same Product Owner and/or customer journey.
Depending on team(s) maturity, a retrospective could be run with or without assistance of an experienced facilitator (Scrum Master, coach) that possesses guide-level expertise in Scrum.
[Notably, a retrospective format is not unique to Scrum.  For example, Kanban teams can also retrospect, on-demand, whenever they feel there is a need.]

What about other organizational settings, outside of team dynamics? What about situations, when multiple individuals, from different organizational areas need to come together and retro-actively inspect (a.k.a. retrospect) on their work within and across various organizational areas, or across multiple organizations (e.g. internal departments, between partners-companies, vendors), involving communication, collaboration, reporting, managing each other’s expectations? 

Below, are some practical tips on how to organize and run a ‚Äėbig retrospective‚Äô (e.g. after multiple sprints and/or completing key deliverable, with people that are not members of development teams).

  1. Most importantly, try having all required parties in the same physical location.¬† For people that are at remote locations, use video conference rooms, and to the extent possible, cluster people together. For example, if a group is distributed between location A and location B, and there is no way to bring everyone together at either location, don‚Äôt settle for letting ‚Äėeveryone joining from their desks‚Äô, via video phones.¬† At least, maximize clustering of individuals, at each respective location, by using conference rooms.
  2. For large groups (more than 20 people), try identifying individuals-delegates that represent views and opinions of others.¬† This is done to reduce noise (too many communication nodes and channels) from people involved in discussions.¬† Identifying delegates will also help with the first guideline above: collocating fewer people in the same place is more cost-effective.¬†¬†Be careful, when selecting delegates:line managers, engagement managers, leads etc. ‚Äď are not the best delegates.¬† Ideally, delegates should be¬†on-par¬†with people they represent.
  3. Consider bringing an external facilitator ‚Äď someone who does not represent views or interests of any specific group of people or department.¬† A facilitator must be neutral and unbiased – a completely impartial person.¬† If a facilitator understands internal organizational dynamics ‚Äď this is great but not mandatory.¬† An experienced facilitator will be able to adjust on-the-fly and leverage to his/her advantage, domain knowledge and subject matter expertise of other participants that are involved in a retrospective. Sometimes, one of the organizational units involved in a retrospective may have their own experienced facilitator available.¬† Falsely, such person could be perceived by other retrospective participants as someone who is subjective or biased.¬† Such preconceived notion may create a problem and must be addressed from start.
  4. With many people involved and/or joining from remote locations, consider doing some preparatory work that will help running a face-to-face retrospective more efficiently.¬† This could be effectively done by a facilitator, by collecting ahead of time, from all future retrospective participants, their preliminary feedback: wishes, concerns, recommendations.¬† All collected information can be then reviewed and analyzed, to make it more presentable and actionable at a retrospective: duplicates ‚Äď removed, relevant items ‚Äď grouped together.
  5. During a retrospective, a facilitator can present all participants with collected and refined information (4 above), in the form of index-cards and leverage one of facilitation techniques (e.g. dot-voting or priority vs. impact plotting) to decide on the order of items to be discussed. Additional, blank index cards should be available on-hand, in case there are last-moment ideas that emerge in a room.
  6. Each discussion point should be time-boxed.  However, since not all discussion points are of equal priority and complexity, time required to spend on each may not be the same.  It is also important to keep a discussion focused/tailored and not let it digress to tangentially relevant (or completely irrelevant) topic.  It is a good practice to spend some extra time at the beginning of a retrospective to not only prioritize discussion points but also estimate, roughly, how much time is each discussion point may take.  This approach of balancing discussion items’ priority vs. complexity, essentially, is identical to what a team does to backlog items during a product backlog refinement session.
  7. Retrospectives that involve people that don‚Äôt work on the same team, let alone, individuals from different organizational structures and of different levels of seniority may create a lot of additional tension in a room.¬† The latter, especially, may force more junior people become very reserved and un-confident in stating their opinions, in front of more senior colleagues (some of whom may also be their line managers). ¬†Allowing privates speak before generals (a.k.a. ‚Äúmilitary democracy‚ÄĚ)‚ÄĚ could be one of the ways to ensure that junior people are not anchored to views of more senior people and feel comfortable and safe to speak out openly.
  8. Similar to a single team retrospective, a big retrospective, should culminate on a positive note (friendly, mutually supportive vibe) with at least, a handful of most critical items, becoming immediate actionable.  Since topics that are bought up at big retrospectives are usually more systemic/organizational in nature (as opposed to tactical, team-level), each actionable should be preferably owned by a more senior person.

 

 

 

BABA Meetup – Does Agile Really Work in Sales?

Business Agility is at the top of conversation in the workplace. The Big Apple Business Agility (BABA) MeetUp launched on Monday, March 11, with an interactive presentation, ‚ÄúDoes Agile Really Work in Sales?‚ÄĚ, by Marina Alex, Business Agility Transformation Coach.
Marina related several of her experiences applying agile to sales, from banks, to an Agile Museum to a chain of dental clinics, Marina shared data that proved improvements in sales were recorded rapidly. In one case 50% in two months, 12 months later 127%. Of course, a shift in culture was at the heart of the process and the biggest challenge, but outstanding results led teams to want to work this way.  A copy of the presentation can be downloaded here.
For the first time, publicly, SWAY Framework guide has been released.  To download a copy please click here.
Some of the steps to success were adopting a backlog that was also qualitative and becoming collaborative through stand-ups, retrospectives and cross-functional teams. One significant hurdle that needed to be overcome was identifying leaders who would take ownership. Marina has adopted an Agile Framework ‚Äď SWAY, that she shared with the group. One of the highlights of the evening was engaging the participants with the content with the Nureva Wall + Span Workspace. The interactive Wall and collaborative software enabled them to make predictions and add their thoughts to the conversation.
SWAY Framework Guide

[Download Meetup Presentation]

Session Feedback

 

SWAY – Agile Sales Framework 1.0

Meetup-recap.  TBA.

 

02/07 ‚Äď LESS TALKS: MEETUP ‚Äď Scrum Master, F/T Role @ JPMorgan

This was an amazing performance by¬†Erin Perry¬†of JP Morgan¬†–¬†¬†last night, at NYC Large Scale Scrum meetup. The highest ever, record-high number of RSVP-ed people: (108) – since the meetup’s inception in, 2015.
Erin spoke about the ‘guerrilla¬†agility’ approach that she has experimented¬†with her colleagues, while coaching the organization, without even¬†calling it ‘agile’.¬† Before Erin dove into the journey of Scrum Master, being made into a full time role at JP Morgan, she demystified some most commonly known misconceptions¬†about the role.

 

This is what Erin shared with the crowd about the most commonly known misconceptions around Scrum Master role:

  • “Mature teams don’t need a Scrum Master”¬†—¬†Erin brought up a great analogy from sports to explain why this¬†is not true:¬†¬†“Athletes and musicians at the top of their game are surrounded by coaches and trainers. Why do we think our development teams will grow past the need of them?”
  • “Scrum Master is an administrative role¬†(that consists of¬†maintaining JIRA,running the daily stand-ups, reporting in the scrum of scrums, and facilitating meetings)”¬†— This is very commonly seen in¬†organizations¬†but it is wrong perception.¬† Trivializing/reducing the role of Scrum Master to JIRA-Master-Admin is the sign of deep misunderstanding of Scrum, as a framework and¬†and Scrum Master, as a role.¬† Administrative tasks are best rotated through the team to allow the Scrum Master to focus on the deep coaching needs of the Product.This is frequently seen in companies¬†that are trying to ‘fit agile’ in their otherwise archaic¬†organisational¬†design, without making much of an effort to change the ladder.
  • “Scrum Masters are non-technical” –¬† Although many great Scrum Masters are not fully capable coders, many very experienced and effective Scrum Masters are hands-on developers.¬† Even if someone starts off as non-technical Scrum Master, it is great if that person has aspiration to learn new things¬†and acquire¬†some basic technical skills (especially, if Scrum is used in¬†software development environments).
  • “Scrum Master is a junior role”¬†– Deriving from Erin’s talk, this is probably one of the biggest evils in the list of common misunderstandings about the role of Scrum Master.¬† This critical misunderstanding alone, to a large extent, is also¬†responsible for depreciation of Agile coaching¬†profession in a market place.¬†¬†This is how:¬† ¬†Scrum Masters are underpaid because companies don’t value the role high enough¬†>>>¬†Instead of honing their craft, as Scrum Masters, people try to ‘upgrade’ themselves (on a resume) to Agile Coaches too soon¬†¬†>>>¬†under-qualified¬†Agile coaches flood the market,¬† get hired and set a low coaching bar for companies¬†>>>¬†coaching profession deteriorates¬†further¬†>>>¬†companies stop seeing value in real, experienced organizational coaches¬†>>>there is nobody, really, to provide good coaching and mentoring¬†to existing Scrum Masters that are at the beginning of their career journey¬†>>>¬†Scrum Masters don’t ‘grow’ in their profession¬†>>>¬†Scrum Masters get frustrated with their role and low pay¬†>>>¬†and the cycle begins again…It’s the same dysfunction we saw in the last two decades with developers and the architect role. Scrum masters should become great scrum masters, not aspire to a “promotion” to agile coach.¬†
    • [Author’s note: This is what has produced so many¬†Chief-Sheriffs-Power-Point Architects: individuals that tend to tell others what enterprise architecture should look like, without actually doing any hands-on development]
  • Career path for Scrum Master inevitably requires climbing up the organizational ladder”¬†– This is another huge misconception about Scrum Master role.¬† Compensation and organizational seniority¬†should not be¬†coupled to¬†to the pursuit of promotion to Coach, or Team Lead, or Manager.¬† A person should be comfortable to build expertise¬†in Scrum Master role, passionate about it, grow within the role, and an organization¬†must provide a healthy habitat for this to be possible (providing fair compensation is one of key things).¬† Erin stressed how this dilemma¬†is swiftly addressed in Large Scale Scrum, where Scrum Master is viewed¬†is a very senior and experienced role, whose focus changes over time. The difference between Scrum Master path¬†Myth vs. Reality –¬†is illustrated below.

This is how Erin has exposed some most common misconceptions about a career path of Scrum Master:

 Avoid This (Myth) Try This (Reality)

 

It has been a great pleasure (and honor) to host Erin’s¬†presentation to the LeSS community of NYC.¬† Her views on Scrum Master role and career path are very much in line with my own and are strongly supportive of what is recommended in LeSS.¬†¬†The way Erin sees Scrum Master in LeSS (as a very seasoned, experienced and well-versed practitioner) and how sheelevates¬†the role to the level of a team-level coaching, also brings back good memories of our past collaboration, when we together summarized, for the benefits of a global coaching community, what the role of agile coach should be (please, refer to 2015 “Agile Coaching –¬† Lessons from the Trenches“)

 


Special thanks to Khalid Sultan, Raghu Raghunath and John Bradley for sharing their graphics and notes, and to Jim Dermend for his real-time tweets (below):

 

Download presentation

Mentor-Guided LeSS Case Study Writing Experience Report




This writing is about mentor-assisted LeSS adoption case study, written by Certified LeSS Trainer-Candidate ‚Äď Gene G [MENTEE]: Certified Enterprise & Team Coach (CEC/CTC), Certified LeSS-Friendly Scrum Trainer (LFST) / LeSS-Trainer Candidate, Certified in Agile Leadership (CAL) | Certified in Scrum @Scale (CS@S) and assisted throughout by Jurgen D. S. [MENTOR]: Certified LeSS Trainer, Licensed Management 3.0 Trainer, Innovation Games Qualified Instructor, Black Belt Collaboration Architect

Purpose of a case study:

The purpose of writing a case study was to re-live the experience of Large-Scale Scrum (LeSS) adoption, by going back in time and memory to everything that was done by me Рthe agile coach, trainer and organizational design consultant at a large financial institution.  This engagement was done in conjunction/partnership with my former trusted colleague Stuart P. (also, an experienced agile and software engineering coach).   Writing this case study gave me a great opportunity to self-reflect (retrospect) and think about what I could have done differently back then, if I had to go through adoption again.  The name of the organization, as well as names of people, products, projects, applications, components, etc. that were involved in the study are intentionally withheld, for confidentiality and privacy protection reasons.Nevertheless, hopefully the case study, when published on less.works will serve as a guideline to others, in their attempts to experiment with LeSS adoptions in their respective organizations.  It is worth nothing that many existing LeSS case studies on less.works had provided my former colleague and me with some great references when we worked on our artifact piece.


More About my Mentor:

My mentor, also one of not too many Certified LeSS trainers, was very knowledgeable about LeSS (as trainer, coach and practitioner) and very supportive in my case study work.  Him and I have met more than once in real life, at various agile- and LeSS-related public events (conferences, retreats), and this allowed for some of in-personal mentoring sessions.  Visual technology took care of the rest and made our remote sessions also effective (Note: I am based in the US, he is based in Europe)

Dynamics of Case Study writing:

The process had been very iterative all along.¬† My mentor and I used google docs, as a communication media and it allowed us to work incrementally and transparently with one another: typically, I would capture my thoughts directly in the google document, iterate multiple times through them and then, once feeling comfortable enough, would share them with the mentor, asking for his feedback. The mentor would provide feedback, ask questions and suggest clarifications. ¬†My former colleague and the peer-coach, who also had full access to the case study, would attend to it at any point in time, leave his comments, provide clarifications and add his details to mine.¬† Notably, my former colleague-coach has helped me significantly, by recalling facts, decisions, ideas, events that we lived through together (LeSS adoption took place a few years before the case study was incepted).¬† Specifically, my former colleague also helped me significantly in those areas of the case study that talked about technology: architecture, design, and development.¬† In all fairness, this was ‚Äėour‚Äô case study, not just ‚Äėmine‚Äô.
Regularly, at least once a month, when meeting with my mentor, I would receive feedback on those parts of the case study that required further refinement and re-work.¬† Many times, my mentor would ask me questions that initially seemed to be intentionally tricky or even irrelevant.¬† But I always had to give my mentor the benefit of the doubt that he, being a deep system thinking just like me, tried to set me up to think deeper, broader and most systemically into the matter, helping me to discover better ways to formulate my thoughts.¬†¬† Specifically, many of his questions made me go backwards from many of the LeSS experiments that were leveraged during the case study, to underlining LeSS principles ‚Äď and making a connection.

From time to time, my mentor would also share his own experiences and give his own perspective like mine, or related situations.  This made our mentoring more interactive, engaging and fulfilling.


How did I decide on the scope of my case study?

One of the most important mentoring ‚Äėaha moments‚Äô for me was the decision on how many LeSS experiments that were actually used during LeSS adoption did I really want to describe in detail, as a part of my case study.Here, one of LeSS adoption concepts came to rescue: Deep & Narrow is better than Broad & Shallow.¬† I consulted with my former colleague-coach on how many of our LeSS experiments and experiences do we really want to discuss and how deep.¬† We agreed on the shorter list of experiments that represented the crust of our work and could be aligned with logical and chronological sequence of events, as we remembered them.¬† We made our selection described experiments, based on what we felt was most important during the adoption, relevant to the case study and memorable to us, as coaches.¬† I consulted with my mentor on the final list and the overall approach and based on his recommendations, proceeded with deeper dives into the case study.


A picture is worth a thousand of words.

During one of the many case study reviews with my mentor, it became obvious that long paragraphs and dry text would make many readers bored.  This is when I have decided to spice up the case study with graphic illustrations and other visual artifacts (e.g. causal loop diagrams, tabular data).  I had to make a dedicated iteration throughout the whole case study and introduce graphics, were they seemed most appropriate.  Ultimately, this made the case study more readable and informative.

Overall experience.

My overall experience of writing the case study was amazing.  It took me through the process of additional deep re-learning and self-discovery.  It made me reassess my past decisions, now seeing them through the prism of additional experience acquired during the last three years of professional work.

Sept 13 -14 | 3rd Global LeSS Conference | NYC


Unforgettable 2 days at the 3rd Global LeSS Conference, at Angel Orensanz Foundation – the historical landmark in NYC.


Conference Space and Our People
Experience Report by Guest-Blogger Ram Srinivasan

Though I have been associated with the Large Scale scrum (LeSS) community for about five years (though the “community” did not exist,¬† I can think of my association with like minded folks) this is my first LeSS conference. While I used to attend a lot of conferences in the past, I have started focusing more on deep learning (by attending focused workshops) than focusing on conferences. But this year, I had to make an exception for the LeSS conference Why (a) it was the first LeSS conference in North America¬† (b) It was not very far and (c) I was thinking that I might meet some of the smartest people in the LeSS community whom I may not meet otherwise and (d) I have heard that it is a “team based” conference (unlike other conferences where you are on your own) and I wanted to find out what the heck it was. I was not disappointed.

The venue itself was very different from the conventional Agile conferences  Рnot a hotel. That definitely caught my attention !! I was pleasantly suprirsed to see both Howard Sublet (the new Chief Product Owner from Scrum Alliance) and Eric Engelmann  (the Chairman of the Board of Director of Scrum Alliance ).  Howard and I had good discussions on LeSS, Scrum Alliance, the marketplace, and scaling
Some sessions that I attended and major takeaways:
  • Day 1 morning keynote –¬† Nokia LTE¬† implementation¬† – Takeaway – Yes, you can do Scrum with more than 5000 engineers
  • Day 2 keynote¬† by Craig Larman. I always find Craig’s thinking fascinating and learnt quite a few interesting facts about cognitive biases (and strategies to overcome them).
  • LeSS Games – component team and feature team simulation lead by Pierluigi Pugliese – very interesting simulation – I used a variation of this in my CSM class past weekend and people liked it. I hope to write about sometime, in the coming days
  • LeSS roles exercise by Michael James –¬† I have always been a fan of MJ. Very interesting exercise which reinforces the concept of LeSS roles
  • TDD in a flip chart – Guess I was there again, with MJ. Well, just learned that you do not need a computer to learn about TDD.
  • An open space session with Howard Sublett on LeSS and Scrum Alliance partnership (yours truly was the scribe) – Lot of interesting discussions on market, strategy, and positioning of the LeSS brand.¬† I personally got some insights from Rafael Sabbagh and Viktor Grgic.
Two days was short !! Time flew away.  It was a great experience !! And  I wish we could have a North American LeSS conference every year !!

Experience Report by Guest-Blogger Mark Uijen de Kleijn

I’ve attended the 2018 LeSS Conference- my first Рin the Angela Orensanz Center in New York. I was really inspired by the many great speakers, experiments and experiences and was glad I could help Jurgen de Smet by his workshop on Management 3.0 practices that can complement LeSS with experiments.

A couple of notes on the Conference; it has been the first Conference I attended in years where I actually learned a lot, either from the many speakers, experiments and experiences, but from my ‚Äėteam‚Äô as well. As the LeSS Conference is a team-based conference, we reflected on the content and our insights during the Conference, which accelerated my learnings.

As I use many games and practices in organizations or courses, I‚Äôve seen several great new games that I can use myself. The ‚Äėbuilding agile structures‚Äô game of Tomasz Wykowski and Justyna Wykowska was the most outstanding game for me, because it makes the differences between component and feature teams very clear when scaling work, and I will use this for sure in the future. The experiences at Nokia by Tero Peltola were very inspiring and especially the focus on the competences (of everybody) and technical excellence I will take with me.Thoughts that will stick with me the most after the conference: the focus on technical excellence (including e.g. automation, code quality, engineering practices etc.) and the importance of the structure of the organization, following Larman‚Äôs fifth law ‚ÄėCulture follows structure‚Äô. The latter I‚Äôm already familiar with, but needs to be reprioritized in my mind again. The former will be my main learning goal the coming period and I will need to dust off my former experiences.

Interesting quote to think about, by Bas Vodde: ‚Äėwe should maximize dependencies between teams‚Äô (to increase collaboration between teams).


Games and Team Activities

LeSS Graphic Art


My partner in crime (Ari Tikka) and me  РPresenting on Coaching

Click here to download presentation: Ari’s deck | Gene’s deck.


Personal Memorable Moments


Next LeSS conference (2019) – Munich, Germany

May 30th-June 1st: Certified LeSS Practitioner Course With Craig Larman | NYC

Another LeSS Training (CLP) with Craig Larman is in the CompuBox.  This highly engaging training brought together 35 attendees from all over the globe.  One of the attendees was Chet Hendrikson.  A bit about Chet:
Chet has been involved with Agile Software Development since 1996 and is the first signatory to the Agile Manifesto. Along with his long-time friend and colleague Ron Jeffries, Chet has made the following important contributions to the global agile community:
  • Wrote Extreme Programming Installed (also with Ann Anderson)
    In 2009, developed for Scrum Alliance the Certified Scrum Developer program
  • Taught the first Certified Scrum Developer (CSD) course
  • Have been curating the Scrum Alliance‚Äôs Agile Atlas website
  • Created the SA’s official Scrum description, Core Scrum
  • Speak at conferences, bringing an interesting mix of humor and deep knowledge, and the odd cat picture.

This is what Chet had to say about the course:

“Chet Went to Craig‚Äôs LeSS Course”

Many years ago, I wrote an article entitled ‚ÄúInside every 100-person project is a 10-person project trying to get out.‚Ä̬† That pretty much sums up my feelings about Agile at scale.

My interests have always been with the programmers and their safety and not with how to ‚ÄúAgilize‚ÄĚ the organization.¬† Some of this was a reaction to the failure of most Agile transformations.
But, as someone deeply rooted in the Agile movement, I feel it is important to pay some attention to the ‚Äúscaling‚ÄĚ end of things.¬† A couple of years ago,¬† Ron Jeffries and I took (most) of the four-day Implementing SAFe course.¬† You can read about that at https://ronjeffries.com/xprog/articles/safe-good-but-not-good-enough/.
I have also been paying attention to Craig Larman and Bas Vodde’s Large Scale Scrum (Less).  So, when I saw that Craig was teaching a LeSS Practitioner course in New York on a week I was not working, I signed up.
There were a couple of reasons for me to take some time away from my wife and cats to do this.  First, after having read the LeSS books, I wanted to learn more.  And, secondly, I have always enjoyed my interactions with Craig and wanted to spend some more time with him.
The course is three full days, 8:30 to 6:00, and involves a great deal of hands on work.  And, I do mean work.
Craigs starts the class by saying that ‚Äúyou won‚Äôt successfully be able to return to your workplace and ‚Äėgive a summary‚Äô of your insights; it is futile & won‚Äôt be understood.‚ÄĚ
He is right about this.  But I will try and give you my impressions of the course.
One of the key takeaways from the course is something I already believed, which is don’t scale.  Do everything possible to build your product with one time.  If that is not enough, find ways of descaling your problem.  Only if that fails take the steps required to turn your organization into one that can build large products with Scrum.  Doing this effectively will require many changes.  Most of which are about removing management and simplifying information flows.

Craig’s organizing principle for the course is that in order to successfully use these ideas,  you must own them.  Having an instructor, no matter how good they are, no matter the depth of their experience, teach you something is no where as good as discovering the answers yourself.  To this end, we spent most the the course learning and practicing organizational modeling to derive the practices and structures that align with our goals.

In the course, our goals where to create a learning organization that has the ability to ‚Äúturn on a dime for a dime.‚Ä̬† You may have other goals, but these tools will help better align with them no matter what they are.
Only on the afternoon of the last day did we turn to a full discussion of LeSS.  This was very insightful and was a fitting way to close out the course.
If you are interested in Scrum at scale, I highly recommend  this course.  If you are interested in bringing your organization into sync with its goals, then this is the place to start.

 

Some more Kodak moments from the event are below:






 

 

 

 

 

 

Centralized vs. Decentralized Coaching

Key Takeaways

Read the original post on InfoQ.

  • ¬†There is a frequently seen confusion with respect to the definition of agile coaching: coaching focus (e.g. enterprise vs. team) is confused with coaching alignment (centralized vs. decentralized) within an organization
  • Centralized coaching departments run the risk of turning into a single-specialty organizational silos that are locally optimized for their own expansion and personal success; they are also removed from real action. The reasoning behind: standardization – has its weaknesses.
  • Centralized coaching is often limited to being ‚Äúresponsible for introducing KPIs, documentation of script-style-one-size-fits-all best practices and cookie-cutting approaches‚ÄĚ. ¬†This leads to system gaming by other departments and organizational silos that must ‚Äúmeet numbers goals‚ÄĚ
  • Centralized Agile coaching makes sense only when it takes place within an organization that is small enough to be effectively managed front-to-back (including its all organizational layers) ¬†and is genuinely supportive of its own coaches, by providing them with ‚Äúorganizational immunity‚ÄĚ and operational safety – to enable them perform their challenging duties
  • The main advantage of decentralized coaching approach is that coaches are close to real action: deeply engaged with products/services, and are intimately engaged with senior leadership. ¬†Decentralized coaching is deep & narrow (as opposed to being broad and shallow) and takes time to cause meaningful and sustainable organizational changes.

Read the original post on InfoQ.