Category Archives: Scrum

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.

 

 

 

HR-Related LeSS Experiments – Deciphered

Large Scale Scrum has a history of more than a decade. The first book about LeSS was published by C. Larman and B. Vodde (the co-creators of LeSS) in 2008.  There were two more books on LeSS, subsequently written in 2010 and 2016.  There is no surprise, why the collection of LeSS experiments from the field is so valuable: the authors have documented many (more than 600) experiments, based on their personal experience with LeSS adoptions, as well as feedback and information collected from other organizational design consultants, coaches and early adopters of LeSS, around the globe.
Today, references to LeSS Guides and Experiments can be found in various places on the internet and intranet of many companies that have decided to experiment with LeSS.
This writing is about a small sub-set of LeSS experiments that are specifically related to HR norms, policies and practices. They are all listed in the guide (referenced above), under the section “Organization” and it implies that they are directly related to organizational design – the first-order factor that is responsible for success of LeSS adoptions and agile transformations, at large.
Experiments with Performance Appraisals:
Avoid… Performance appraisals – p. 273 — There is a lot of research and evidence, supporting that individual performance evaluations and individual appraisals that are linked to monetary rewards, are not an effective way to make individuals to become more efficient and productive.  When a manager appraises an employee, usually only one opinion in the room that matters: a manager’s.  Feedback that is delivered once or twice a year is not timely and therefore is hardly actionable by an employee, thus useless, for the most part.  Neither an individual that delivers an appraisal, not an individual that receives it – like the process.  The process, is also pretty expensive, as it uses a lot of company’s resources: it involves lots of documentation, coordination and men-hours spent by many people, from first-line management to HR.
It is worth noting that there is an indirect relationship between conventional Budgeting process and conventional Performance Management process – both of which harmfully feeding off of one another. This is described in the book “Implementing beyond Budgeting: Unlocking the Performance Potential“, by Bjarte Bogsnes.  In his work, Bjarte refers to performance appraisals as “legal trail for a rainy day”.

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

“Try… Team-based targets without rewards – p. 273” — Clearly, team-level behavior, is an extension of individual behavior.  Just like individuals could be inclined to ‘game the system’, so could whole teams, under certain conditions.  Just like individuals, whole teams could be drafted in unethical conspiracies to game numbers, in pursuit of meeting targets, or beating other teams (e.g. producing ‘higher velocity’), whenever monetary rewards are at stake.  It is absolutely necessary to set targets to individual teams that work on par with one another, for the same organization, it would be best to decouple team targets from team rewards.  The latter could be handled through, some sort of profit sharing formula, based on a company’s financial success that is traceable back each team’s work.
Experiments with Job Titles:
“Avoid… Job titles – p. 276 | Try… Create only one job title.  Try… Let people make their own titles – p. 277 | encourage funny titles” – p. 277 —In pursuit of job titles, individuals may also seek gaining authority and “upper hand” over their peers and colleagues.  This may lead to artificial organizational complexity and hierarchy, as well as a casting system.  Individual job titles can also polarize people and drive them in opposite directions, away from shared ownership.  It is for this reason that on agile teams (e.g. Scrum), there is only one title – Developer.  This approach encourages people to think of each other as on-par, as peers, and grow into T-shaped, multi-skilled, cross-functional, willing-to-swarm workers.  In situations, where some distinction between individual jobs is absolutely necessary funny job titles are recommended.  For example, instead of calling someone QA Tester, a person could be called “Bug Finder and Exterminator”
“Try… (if all else fails) Generic title with levels – p. 277” — If it is absolutely necessary to have title distinction (e.g. to signify different levels of seniority/expertize of individuals), try using a leveling system.  For example, Developer level 1(junior), Developer level 2 (mid-level), Developer level 3 (senior)…. However, care should be exercised, not to explicitly associate different title levels with different levels of pay.
Experiments with Jobs:
“Try… Simple general job descriptions – p. 278” – Do not overcomplicate job descriptions.   Precision in a description may lead to contractual perception of what a person should and should not do, in a workplace.  This may also limit a person’s willingness to step out of his comfort zone and learn other areas of work, other skills and becoming multi-faceted.  It may then further lead to “managing by objectives” that are based on detailed job descriptions, and subsequently bring about problems of performance appraisals, described above.  Complex job descriptions also have a tendency attracting underqualified external candidates, whose resumes are excessively long, as they are ‘tailored to closely match complex job descriptions’.  (Relevantly, attracting bad agile coaches, by creating inappropriate job descriptions is a known problem).
“Try… Job rotation – p. 279 | Try… Start people with job rotation – p. 280” — Give individuals opportunities to learn new domains, technologies, lines of business.  This is will reduce the risk of a person becoming uninterested/bored with his current job.  Further, by rotating from one job to another, a person may discover where he fits best and delivers most value.  By having this opportunity, a person will also have a higher chance of merging the gap between “having to do a job” and “wanting to do a job”.  This is especially important with newly hired people that have a limited industry experience (e.g. recent college graduates).
 Experiments with Hiring:
Try… Hire the best – p. 280 | Avoid… Hiring when you cannot find the best – p. 281” — Do not settle for less than “best people your money can buy”.  It is better to rely on fewer great people that you already have on-staff than bring on more under-qualified people, to speed up work, especially at the end of a project that is already late (Brook’s Law).  From a system thinking perspective if you are trying to increase velocity (output) by a scrum team and decide to do so by adding more developers that you procured on low budget (low pay will most likely buy you low-skilled developers), you will most likely reduce velocity, by having low-skilled developers introducing more bugs into a system. Please, see why.
Try… Team does the hiring – p. 281” — If you plan on hiring an individual to join a team, please make sure that a team does most of interviewing and vetting.  Through that, not only a person’s skills and experience will be examined but it will become more apparent if a person can organically jell with a team: if there is compatibility, chemistry and synergy with other team members.   Panel interviews by whole teams are usually much more effective, since they include practical tests, real-life simulations and hands-on exercises.  It also allows some people to observe, while others ask questions, and then rotate.  Try to reduce the level of influence that HR personnel and first-line management have on the process as much as legally possible.  This will reduce the amount of subjective, administrative, frequently bias and error-prone screening (refer to top of page 17).
Conclusion:
As a summary, please consider the following quote that describes sushi-roll-like organizational design in Large Scale Scrum (LeSS), by C. Larman (also, explained in detail in Agile Organization, as a Sushi Roll):
In it, HR policies is listed as one of the vital elements of overall organizational agility.

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

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:






 

 

 

 

 

 

2018 BIG APPLE SCRUM DAY: COACHING CLINIC

2018 Big Apple Scrum Day (BASD)  is in the Copy Box.   This was another amazing  annual event, organized by BASD team of volunteers.

The agile coaches-clinicians serviced more than 30 attendees, by addressing a variety of questions and concerns.  While some of the discussion topics were similar to the prior years’ clinics, there was a noticeable increase in maturity of topics.  My personal (Gene is here) unique experience was with the folks that wanted to discuss:

  • Implementing Scrum in non-IT area, where software engineering aspect is not present (mainly, graphic design, content management)
  • Engaging HR of financial/investment companies in discussions about organizational agility (incentives, bonuses, performance)
  • Using Scrum and “Team of Teams” concept in government projects/contracts in the areas of US Military and Defense (the discussion was conducted with someone who had personal, first-hand combat experience in Iraq).

The following coaches have provided their personal feedback:

From Peter Green: I love coaching clinic. For me, it is a bite-size, speed dating version of agile coaching: It’s has a short timebox and both parties tend to feel good about the outcome of the session. Even though it is micro-coaching, over and over we are able to generate some good insights, ideas, or new approaches that have the client excited and optimistic.  Today at the Big Apple Scrum Day, I coached a handful of people with questions ranging from how to better help individuals and teams to how to get upper management engaged in Agile adoption. If you are familiar with the various competencies involved in professional coaching, you would observe that these quick sessions tend to lean a bit more toward teaching and mentoring than a typical, long-term coaching relationship. But that’s great! People are encountering challenges for the first time that many of us grizzled vets have seen many times, and so we can give them some insight into patterns that we’ve seen work and the context that made those patterns useful. But, it’s not all advice; in two or three sessions today, I had a chance to do more “pure” professional coaching, where it wasn’t me sharing ideas or suggestions, but asking open access questions and making observations about body language and tone.
From Jim York:  I always enjoy the comraderie of my fellow coaches at the Coaches Clinics and getting to meet the people who come to chat for a 15 minute coaching session. This year’s Coaches Clinic at Big Apple Scrum Day in New York City continued the tradition. While every clinic is different based on who shows up, there are two clear constants. One is the coaches’ earnest desire to help people with the next leg of their Scrum journey. The second is the energy of the attendees in seeking a way forward.Everyone’s Scrum journey is unique and that is what makes coaching such an interesting vocation. Certainly there are patterns — well worn paths that many have trodden in the search for improvement — but these paths crisscross, double back, circle around, and blend in innumerable ways.  For me, this year’s coaching topics ranged from estimation (what a can of worms that one can be!), how to get started with agile, how to improve team focus and accountability when the team is distributed, and variations on how to be a better coach or trainer for the team and the organization.   Read more….
From Amitai Schleier:  I had a great time at last year’s Big Apple Scrum Day presenting with Ryan Ripley in my home market, so it was an honor to be invited back to contribute to the 2018 BASD proceedings in a new way: as part of the Coaches Clinic, where attendees could talk through a situation they’re facing and, in so doing, perhaps gain some new understanding or insight.  These conversations, while brief, can have profound impact. Five years ago, my first visit to a Coaches Clinic transmuted my curiosity about a career option into the resolve to try it. And here we are.  Yesterday, I don’t think I came close to doing for anyone what Roger did for me. But I did make myself useful, reasoning about the needs of the people in Matt’s situation until we found an actionable idea. Gene Gendel, who organized the Clinic, is collecting experience reports from the coaches.  Despite the prevalence of Lego in Agile coaching games and simulations, I still hadn’t played with it much since childhood. I guess I decided to start practicing because Taavi will be Lego-ready before we know it. I tried to stay off the grid.  It was energizing to punctuate the pace of the one-day conference by visiting with friends — especially Joanne Perold and Barry Tandy, who I’d met online via Agile for Humans, and now in person, all the way from South Africa. I also got a kick out of rubberducking my code problem with Doc Norton, though we ran out of time to pair on it. (Jo and Doc both keynoted.).  Read more….
From Mariya BreyterStart with Why Agile community is well known for transparency, supportiveness, and generous knowledge sharing – after all, this is what Agile is about. This is one of the reasons I volunteered for the Coaching Clinic. Having previously coached at BASD as well as the Lean Startup Conference, I expected to meet new people, support them in their exciting challenges and opportunities, and share my experience of nine enterprise-level transformations I was part of – and all of this happened, and much more. Gene Gendel who runs BASD coaching clinic since the first conference four years ago, made every coach and coachee (I am told there is no such word so I made it up 😊) feel welcome and comfortable. Anyone could sign up for any slot for anyone or for a specific coach, and there were always coaches available in the clinic area to answer any questions or to have a friendly chat with participants. It was a great opportunity to meet other coaches who are all great professionals well known in the field, and many of them are good friends since the first BASD. Everyone who came over for coaching was super nice, generous and grateful – thank you all for making this Clinic a success! Now about the specifics.  Read more….
From Aleksandr Kizhner: BASD2018 conference to me is where my mindset meets action, and this was another excellent conference. Being part of the awesome team of agile coaches – clinicians I’ve struggled with how to condense all my positive experiences into a few bullets point feedback; this may have to be the first of many. Over just one day, I was able to create new connections, engage people in enlightening coaching sessions, and start a number of thought-provoking conversations with other agile coaches.

Few of my sessions focused on the importance of the team culture and surprisingly less on the health of the product backlog, user stories, and technical agile concepts. Many emphases were placed on relationships and trust between team members instead of the typical command and control and process quality assurance that found in traditional software development processes. One of the main benefits I took from being at a coaching clinic, I was being able to meet and network with other people who were going through their own organizational agile transformation. There were a lot of lessons learned shared and views on how to best proceed. 

 

Some Kodak Moments:

Our worksheets:

From left to right: Peter Green, Gene Gendel, Jeff Patton

Scrum Alliance Education specialist Alexxis Holquin:

Proper Scaling of Scrum and Dynamic Financial Forecasting


The purpose of this post is to summarize two very important and independent topics and then integrate them together, into a joint discussion.  The topics are:

  1. Moving from rigid annual budgets to rolling forecasts (super important! in agile/adaptive product development environments)
  2. Quality of scaling in agile product development, specifically Scrum

…and tying effective scaling of Scrum to dynamic financial forecasting.


Rigid Annual Budgets vs. Dynamic/Rolling-Wave Forecasting

Challenges presented by rigid annual budgets have been known for a long time.  For people that are new to the topic, a great way to stay on top of most recent research and publications, is to follow what is going at BBRT.org (Beyond Budgeting Round Table).  One of BBRT’s core team members – Bjarte Bogsnes, in his book “Implementing Beyond Budgeting: Unlocking the Performance Potential” (please, refer to the book’s highlights here),  clearly summarizes the problems with conventional, end-of-year rigid budgets. They are as follows:

  1. Budgets represent a retrospective look at past situation and conditions that may not be applicable in a future
  2. Assumptions made as a part of a budgeting process, even if somewhere accurate at the beginning, get quickly outdated
  3. Budgeting, in general, is very time-consuming process, and it adds additional, financial overhead to organizations
  4. Rigid budgets, can prevent important, value adding-activities, and often lead to fear of experimenting, researching and innovating (crucial for incremental development)
  5. Budget reports are frequently based on subjective metrics, as they take on the form of RAG statuses, with the latter, introducing additional errors and omissions (for details, please refer to Red, Yellow, Green or RYG/RAG Reports: How They Hide the Truth, by M. Levison and The Fallacy of Red, Amber, Green Reporting, by G. Gendel)
  6. Budgets, when used as a yardstick to assess individual performance, often lead to unethical behaviors (e.g. “churning & burning cash”at year-end to get as much or more next year) or other system-gaming activities

…The list of adverse effects caused by traditional budgeting is long…

On contrary, a rolling-wave forecast, respects the fact that environmental conditions are almost never static, and recognizes that if too much reliance is placed on prior years’ financial situation, it may lead to miscalculations.  Rolling-wave forecasts are based on frequent reassessment of a small handful of strong KPIs, as oppose to large number of weak KPIs, as frequently done in conventional budgeting..  The more frequently forecasts are being made, the higher chance that most relevant/reliable information will be used in assessments.  One good way to decide on cadence of rolling forecasts is to align them with meaningful business-driven events (e.g. merchandise shipments, production code deployments, etc.).  It is natural to assume that for incremental/iterative product development (e.g. Scrum), when production deployments are made frequently and in small batches, rolling-wave forecasting could be a concurrent financial process.  Short cycle time of market feedback could provide good guidance to future funding decisions.

It is worth noting that one of the key challenges that Scrum teams face today, is the “iron triangle” of conventional project management, with all three of its corners (time, scope, budget) being rigidly locked. And while the most common approach in Scrum is to make scope flexible, ‘clipping’ the budget corner brings additional advantage to teams.  Above all other benefits, rolling-wave forecasts address the problem described in #4 above, as they provide safety to those teams that want to innovate and experiment.

But what if there not one but many Scrum teams, each working on their own initiatives, running under different cadences (asynchronized sprints) and servicing different customers?  How many independent rolling-wave forecasts can one organization or department adopt before things become too complicated?  What is too much and where to draw a line?

Before we try to answer this question, let’s review what is frequently seen, when organizations attempt to scale scrum.

 

Proper Scaling vs. “Copy-Paste” Scaling

Let’s look at the following two situations: (1) more than one Scrum team, independently, doing their own Scrum and (2) more than one Scrum team, working synchronously, on the same product, for the same customer, sharing the same product backlog and domain knowledge.  The former case, is referred to as “Copy-Paste” Scrum, clearly described by Cesario Ramos. The latter case can be seen in skillful Large Scale Scrum (LeSS) adoptions. Here are some of the most classic characteristics of both scaling approaches:

(1) – “Copy-Paste” Scrum (2) – Large Scale Scrum (LeSS) 
  • Product definition is weak. Applications and components that don’t have strong customer alignment are treated as products
  • “Doing Scrum” efforts are often a result of trying to meet goals of agile transformation (some annual % goals must be met), set at enterprise level
  • Tight subsystem code ownership
  • Top-down, “command & control” governance, with little autonomy and self-management at team level
  • Importance of Scrum dynamics and its roles are viewed as secondary to existing organizational structure blueprints
  • Too many single-specialty experts and very few T-shaped workers
  • No meaningful HR changes to support Scrum team design
  • Simplified organizational design. Reduction of: silos, handovers, translation layers and  bureaucracy
  • Scrum is implemented by coordinated, feature-centric teams, working on  widely defined Product, for the same PO.
  •  Local Optimization by single specialists is eradicated
  • Scrum is a building block of IT organizational structure
  • Teams are collocated Multi-site development is used for multiple locations
  • Strong reliance of technical Mentoring and Communities of Practice
  • No subsystem code ownership
  • Reduction of “undone” work and “undone department”
  • Focus on Customer values
  • Strong support by Senior Leadership & intimate involvement of HR

Note: Please refer to Scaling Organizational Adaptiveness (a.k.a. “Agility”) with Large Scale Scrum (LeSS) for additional graphic illustration.

Based on the above, the following also becomes apparent:

In “copy-paste” Scrum, development efforts, marketing strategies and sales (ROI) are not treated as constituents of the same unified ecosystem.  In this scenario, it is almost impossible to fund teams by means of funding real, customer-centric products.  Why?  There are too many independent ad-hoc activities that take place and artifacts that are created.  There is no uniformed understanding of work size and complexity that is shared by all teams.  Estimation and forecasting made by each individual team is not understood by other teams.  Team stability (and subsequently, cost-per-team member) is low, as individuals are moved around from project to project and shared across many projects.  Further, with multiple teams reporting into different lines of management, there is a much higher chance of internal competition for budget.  By the same token, there is a low chance that a real paying customer would be able to step in and influence funding decisions for any given team: too many independent and competing requests are going on at the same time.

In organizations, where “copy-paste” Scrum is seen (and is often, mistakenly taken for scaled scrum, due to lack of education and expert-leadership), there is still strong preference for fake programs and fake portfolio management.  Under such conditions, unrelated activities and, subsequently, data/metrics (often fudged and RAG-ed) are collected from all over the organization and “stapled” together.   All this information rolls up to senior leadership, customers and sponsors.  Subsequently, what rolls down, is not dynamic funding of well-defined customer-centric, revenue-generating products, but rather rigid budgets for large portfolios and programs that are composed of loosely coupled working initiatives, performed by unrelated Scrum teams (secondary, to conventional departmental budgeting).  As rigid budgets cascade down from top, onto individual teams, they further solidify the “iron triangle” of conventional project management and hinder teams’ ability to do research, experimentation and adaptive planning.

On the other hand, in Large Scale Scrum, things are different:

  • When up-to-eight LeSS teams work synchronously, together (side-by-side), on the same widely-defined product (real), their shared understanding of work type and complexity (having certain scrum events together really helps!) is significantly better. As a result, when it comes to forecasting a completion of certain work (features), eight LeSS teams will do a better job than eight loosely coupled teams that work completely independently, on unrelated initiatives.
  • Since all LeSS teams work for the same customer (Product Owner), there is a much higher chance that they will develop a shared understanding of product vision and strategy, since they are getting it from an authentic source – and therefore will be able to do planning more effectively.
  • Having more direct correlation between development efforts LeSS teams (output, in the form of shared PSPI) and business impact (outcome, in the form of overall ROI), makes strategic decisions about funding much more thoughtful.  When real customers can directly sponsor product-centric development efforts, by getting real-time feedback from a market place and deciding on future strategy, they (customers) become much more interested in dynamic forecasting, as it allows them to invest into what makes most sense.  Dynamic forecasting of LeSS, allows to increase/decrease number of scrum teams involved in product development flexibly, by responding to increased/decreased market demands and/or product expansion/contraction.

Noteworthy that in LeSS Huge cases, when product breadth has outgrown capacity of a single Product Owner and requires work by more than eight teams, dynamic forecasting can still be a great approach for Product (overall) Owner and Area Product owners (APO): they can strategize funding of different product areas and make necessary timely adjustments to each area size/grown, as market conditions change.


Conclusion:

All of the above, as described in LeSS scenario, will decrease organizational dependency on fixed budgets, as there will be less interest in outdated financial information, in favor of flexibility, provided by rolling-wave forecasting that brings much closer together “the concept” (where value is built – teams) and “cash” (where, value is consumed – customers).

December 6th-8th: Certified LeSS Practitioner Course With Craig Larman | NYC


Another Large-Scale Scrum Training (CLP), taught by Craig Larman in NYC, is in the CompuBox.

More than thirty people from all-around the globe (North America, South America, Europe) came together for this brain-jelling learning experience! The group consisted of product owners/managers, software engineers, managers and organizational design consultants (scrum masters, coaches and trainers) – people coming from different backgrounds and with a focus on different aspects of organizational agility. What has united them all, however, was their eagerness to learn in-depth about principles of organizational design and implications of Scrum adoption at scale in complex organizational settings.

Course Highlights

With exception of a few rare questions/clarifications, the class spent NO time discussing basic Scrum.  It was implicit (assumed) that everyone in class had strong knowledge and hands-on experience with the basic framework.  On occasions, the topics discussed would bump into “…oh this is not even LeSS-specific; this is just basic Scrum…” but those cases were rare.

Not until day three,is when the class took a deeper dive into LeSS Framework and LeSS-specific events, artifacts, roles…. Why was not it done sooner?   Well…

  • LeSS is Scrum. It is the same very Scrum described by Ken Schwaber and Jeff Sutherland in the Scrum Guide, but done by multiple teams, as they are working together, on the same product, for the same product owner.  LeSS is not “…something that IT does, that is buried in a company’s basement, under many layers of organizational complexity…”. LeSS is an organizational design that uses Scrum (team) as a building block.  Understanding basic Scrum made understanding of LeSS very easy for everyone.
  • The class was made of people that have completed all assigned homework (self-study), before attending. People knew what LeSS picture looks like 😉, when coming in.  Everyone in class was an educated customer.  Importantly: there were no attempts to change LeSS (or change training content 😊  of LeSS), to make it better fit conditions of organizations, where people came from.
  • Spending the first two days on understanding system modelling techniques, differences between causation and correlation (as well as other dynamics) among many system variables, made full understanding of LeSS on day three, come more naturally.

The class learned how to see ‘the whole’/full picture of organizational ecosystem and learned to appreciate why Organizational Design is the first-order Variable that defines System Dynamics (followed by everything else: culture, policies, norms, processes, etc.)

One of my (Gene) biggest take-away points (on the top of an excellent LeSS refresher, from Craig himself), that I plan on using immediately, was the fact from history that was discussed at the beginning of the course (and, sadly, forgotten or known known by many).  And it goes as follows:

…Back in 2001, at Snowbird, UT, where the group of seventeen entrepreneurs-product-developers have met and came up with what is known today as ‘Agile Manifesto’, the two contending terms to-be-used were adaptive (suggested by Jim Highsmith, the author of Adaptive Software Development) and agile (suggested by Mike Beedle).  ‘Agile’ won because of the reasons that are described here.  Truth be told, because the English meaning of ‘agile’ is not as intuitive is the meaning of ‘adaptive’, today, there is a huge number of fads and terminology overloading/misuse that make the original meaning of agile so diluted and abused…. As it was meant to be: Agile == Adaptive ==Flexible.  We all have to be careful with the meaning of words we use, to avoid this painful irony😉.


Here are some Kodak moments from the event: