About Gordon: Gordon has been a department leader of technology groups in two large banks. And has first-hand experience of three LeSS huge adoptions (he doesn’t like the word “transformation”). All of them with very different contexts. He talked about how he discovered LeSS and enabled it, and what he discovered during his multi year change journey. What didn’t work and gave personal anecdotes about how he dealt with the wider organisation’s persistent and unique ways of trying to force the org back to “normal”.
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:
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
|Morning Session Part 1|
|Morning Session Part 2|
|Afternoon Session Part 1|
|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.
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).
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
Experiments with Performance Appraisals:
“Avoid… ScrumMasters do performance appraisals – p. 275” —Just like performance appraisals done by agile coaches could lead to serious dysfunctions (page. 130), performance appraisals done by ScrumMasters are extremely harmful. Drafting ScrumMaster into this role will create a serious conflict of interest and will hinder ScrumMaster’s ability to influence natural growth and evolution of learning among team members. Impartiality and neutrality of ScrumMaster is highly important; becoming an appraiser – takes away this advantage. Only by remaining neutral and non-authoritative (performance appraisal is exhibition of authority) will ScrumMaster be able to help a team to self-discover, self-improve, and become autonomous in their journey to success.
“Try… De-emphasize incentives – p270.” | “Avoid… Putting incentives on productivity measures – p. 271.” — If achieving a higher productivity (output, velocity) is coupled with monetary incentives/perks or other political gains (typical of many companies that overuse scorecards, metrics, KPIs, RAGs), there is will be always attempts by individuals/teams to claim successes/achievements by ‘playing the system’, in pursuit of recognition and a prize. For example, in pursuit of ‘higher productivity’ teams may start inflating estimates, to claim higher velocity or deliver work that is low in priority but simple to deliver – just to create an illusion of volume. Incentivizing ‘higher velocity’ is an invitation to moving from “low Fibonacci numbers to high Fibonacci numbers” during estimation. (Also, see Addressing Problems, Caused by AMMS)
“Try… Team incentives instead of individual incentives – p. 272” — The process of individual performance reviews loses its original meaning when people work on same teams, where swarming (working together on the same task) and collective ownership is encouraged. Offering individual incentives to people would just polarize them and move in opposite directions, towards becoming selfish, individual performers and super-heroes. In cases such as these, people may be easily drafted into unhealthy competition with each other over claims of success, trying to privatize what should be owned and worked on collectively. Companies that continue incentivizing individual performance with monetary perks just continue widening the gap between “what science knowns and business does” (quote from Daniel Pink).
Experiments with Job Titles:
Experiments with Jobs:
Experiments with Hiring:
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 – Agile Sales Framework 1.0
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)|
How to Choose Vendor:
- Vendor Management System (VMS) – The easiest thing could be to refer to and pick from VMS, as long as a vendor card-rate is in a ballpark of what you wish to pay. But please, don’t do that. Do not let costs become the most important determining factor in your selection. There is a chance that a vendor you are about to choose ended up in VMS based on old selection criterion, other than the ones that you might be looking for, for agile work. Do not automatically assume that old relationships will seamlessly work under new conditions, operating in new ways.
- Case Studies / Use Cases / References – These, could be great ways to understand if a vendor is really capable of doing work they were tasked to do. As a client be always skeptical about heavy, well-formatted power point decks, with lots of fine-print, if they are used by a vendor during initial presentations. Ask for practical demonstrations, working solutions and engage a vendor in extensive Q&A – and please make sure that real hands-on doers present/answer, NOT engagement/sales managers that are specifically trained to make a great first impression. Whenever possible, ask for references from other clients of the same vendor, who to provide feedback about similar work that was performed for them.
- Interviewing Vendor workers – Make sure that you interview every person from the vendor-side, who will be involved in performing work. Be on a lookout for workers that were just hired by a vendor or swapped (for other workers) last minute, just before work commenced, or were being asked to split their time with other projects/clients.
How to structure your ongoing relationship with Vendor?
- SOW – Regardless of SOW type (e.g. Design/Detail, T&M, Performance Based) try avoiding ‘fixed everything’ (time, scope, budget) agreements. When all three corner of the ‘management triangle’ get locked, work becomes very non-adaptive/non-agile/rigid. It will increase risk aversion and decease interest to experiment and innovate. Try building in some contingencies and flexibility into one of the three above variables. Don’t fix-plan work by using waterfall tooling (project plans, Gantt charts, etc.)
- Location of Vendor people – Ideally, bring vendor workers on-site (client) and fully integrate them (physical space, daily interaction) with your internal workers. Once engaging vendor people, don’t treat them as ‘second-class citizens’. Engage them in team-bonding and other social activities to minimize polarization and other adverse behaviors that are not supportive of agile teams. If geographic distribution is inevitable, at least, try to engage with a vendor in the same time zone.
- Strong Partnership at Senior Leadership level – It is imperative to establish close working ties between senior leadership of a client company and senior leadership of a vendor company, not just at the time of SOW creation but beyond it. A relationship must be genuine, multi-dimensional and long-lasting. Client leadership must keep vendor leadership well informed of long-term company strategy, vision and expected future service needs. Vendor leadership must keep client leadership well informed of its internal dynamics, such as staffing limitations, plans for expansion to another geographic area, etc. If client-vendor relationships at senior leadership level are superficial and contractual only, it will likely lead to disjuncture and miss-alignment at team (workers) level down the road. Periodic retrospectives between leaderships of both sides, facilitated by a third, impartial party – are strongly recommended.
- Communication with Vendor people – Communicate directly with doers, not with their line/engagement managers or alike proxies/conduits. Make sure that intra-team (e.g. Scrum, Kanban) relationships between vendor people and client people prevail over reporting relationships on a vendor side.
- Investing in Vendor learning – Invest in education and training of vendor people if you think this will strengthen your relationship and there will be a notable ROI, while they work for you (client). Be also wise about who you invest into and to what extent. Make sure you don’t (over)invest in what a vendor was expected to know in the first place.
- Multiple Vendor Involvement – Be on a look out for any signs of potential rivalry or competition between multiple, concurrently engaged, vendors – this will jeopardize a healthy working environment. Avoid assigning activities to different vendors in ways that increase hand-overs and lead to additional contractual relationships and sequential work (e.g. vendor A – design/development, vendor B – architecture, vendor C – testing).
How to track progress of your relationship with Vendor?
- Progress Tracking & Communication media – Select a single “source of truth” to capture, track and visualize work by agile teams. If a physical board is not sufficient, leverage an electronic tool but make sure that there are no multiple versions information (metrics, reporting, statuses, RAGs etc). Try basing all communications to senior leadership and stakeholders on raw metrics and empirical data that comes directly from teams, without passing through multiple layers of massaging and refinement. Avoid having a vendor using one set of work management tools and a you (client) – another set.
How to position Product Ownership in fully outsourced (Vendor) solutions?
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:
Dynamics of Case Study writing:
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.