All posts by Gene

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

Survival List to Vendor Selection on Agile Projects



How to choose Vendor?

Download PDF

  • 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.
  • 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?
Client-Vendor interaction – Make sure that product ownership represents you (client), clearly and unambiguously.  A product owner should be positioned organizationally in a way that he/she faces externally, and communicates with/sets priorities to a doers/team members (vendor) directly (not through engagement managers, BAs or other translation layers), as well as internally – by closely interacting with SMEs, stakeholders and other internal customers, with the latter providing clarifications but not setting priorities.

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.

November 17: Certified LeSS Basics (CLB) Course | NYC


Another Certified Large Scale Scrum Basics is compete!
Such an engaging and participating crowd!!!  Tons of provocative questions and complex organizational scenarios.
Some most intriguing and and actively discussed topics:
  • Seeing and Hearing Local Optimization
  • Feature Teams vs. Component Teams
  • Mentor-ship vs. Ownership
  • Individual motivation
  • Organizational Design implications on LeSS adoption
  • Organizational De-scaling as means of scaling Agility (and Scrum)

Prince 2 and Agile: any Relationship?


The below blogs come from some of the most reputable experts in the industry.  Please, reach out to any/each contributor directly to collect additional insight and recommendations.
Experience Report by Guest- Blogger Rowan Bunning

Rowan Bunning, CST and Agile Coach working for ScrumWithStyle, based in Australia, shares his extensive experience of working in environments, where PRINCE2 was implemented in its pure form, as well as attempted to be used in agile.  

Below, are some of the most salient quotes from his Part 1 writing.

Please, refer to “PART1 – With PRINCE2 Agile, the victim is Agile“, for a comprehensive discussion of:

  • “…Which would you rather your organisation were more like:
    • the British Civil Service; or
    • a product innovator capable of out-maneuvering a superpower’s market leaders?..”
  • “…PRINCE2 is a very widely used project management method in the U.K., a number of European countries as well as Australia and New Zealand. Those in the U.S. might consider it to fill a space similar to the Project Management Institute’s PMBOK in those countries…”
  • “…PRINCE2 Agile values:
    • Processes and Tools over Individuals and Interactions
    • Comprehensive Documentation over Working Software
    • Following a Plan over Responding to Change…
  • “…PRINCE2 constrains ability to be Agile…”
  • “…PRINCE2 Agile makes The Contract Game likely…”
  • “…Like SAFe, PRINCE2 Agile wrappers Scrum which is contained to be exploited as just a “delivery” approach….”
  • “…PRINCE2 Agile is still: Plan driven from Project Board down…”

Please, refer to “PART 2 – With PRINCE2 Agile, the victim is Agile“, for a comprehensive discussion of:

  • Conflicting Roles
  • Conflicting Roles and Accountability
  • Conflicting with Development Team accountability
  • Conflicting approach to project management
  • Product Owner role misinterpreted and limited to tactical (if implemented at all)
  • Product Owner role replaced with an SME or business analyst
    Committee vs involved individual
  • Committee based steering conflicts with Product Owner steering
  • Decision making cycles overly long for meaningful agility
    Progress reporting conflicts
  • Organisation Design conflicts
  • Not designed for Agile performance characteristics
  • Conflicting use of project and product concepts
  • Accommodating Agile adoption rather than improving it
  • Compensating for and holding back Agile maturity
Experience Report by Guest- Blogger Geir Amsjø

Geir Amsjø, CST and Agile Coach working for Lean Venture, based in Oslo, Norway shares his thoughts:

PRINCE2 is very popular in IT in Norway – especially in government projects. I also believe it is widely used in Sweden and Denmark, but not in Finland. Even if development of PRINCE2 was funded by the UK government it would be pretty much abandoned there for public digitization because Government Digital Services wisely prefer and  rely on Design Thinking and Agile these days.

PRINCE2 is probably one of the best Project Management frameworks for IT there is. It contains “stages” which, at a glance, may look similar to iterations. But PRINCE2 all about Management and Governance, while “following the plan” and very little about true adaptiveness. PRINCE2 is very prescriptive and heavy and contains a bunch of roles, documents, process steps and everything one would expect from a classic PM framework.

Many of my CSM/CSPO class participants have PRINCE2 certifications and they often tell me that it would be extremely hard to combine PRINCE2 with Scrum, or another agile framework, for the following reasons:

  • There are a lot of committed up front planning, prediction and estimation
  • Changes are not embraced but are rather regarded as exceptions and they need to go through cumbersome Change Control Board
  • Decisions are hard to make on-the-spot, in a decentralized fashion. They need to be escalated up the chain of command for approvals and sign-offs
  • Project Managers is viewed as the authority and can override teams’ decisions

I became curious about the new PRINCE2 Agile a couple of years ago, and attended a sales meeting from a training provider. As it was expected “Agile” was more slap-onto PRINCE2 itself, not a way to change the ladder.

Ironically, PRINCE2 Agile teaching contained all the right references and buzzwords, and it was very open to iterative approaches. It was clearly focused on learning and exploration. So far so good…

And I have had discussions with people who were quite satisfied with the Agile version of PRINCE2. There was no reason to doubt that PRINCE2 Agile could represented a big step in the right direction compared to the traditional version.  But how on earth can it “be agile” if you put Agile on top of a heavy framework like PRINCE2? Would it not be like putting a lipstick on a pig?…

All heavy process descriptions lead to forming a certain mindset: “Please obey the procedures. Don´t think for yourself, because you don´t really own the problem.” This would be clearly incompatible with the agile mindset.

Experience Report by Guest-Blogger Kurt Nielsen

Kurt Nielsen, CST, of AgileLeanHouse in Denmark, shares some of his personal insight:

Remember that Prince2’s logo or mantra at the beginning was Plan-Delegate-Monitor-Control (sort the dark side of the force Plan-Do-Study-Act), it is not promoted these days, but that is what it is at the core, designed for compliance.

In that is a complete parallel to Leffingwell’s SAFe, the best orchestrated marketing gambit for years, selling people (well classic Management) what they want but don’t need. In our little pond (the Danish Market) we have lost significant territory to SAFe, the whole financial sector have jumped on that bandwagon. One of our largest customers (we lost them) did that with devastating effects on the Teams, I have met several staff members, who have just “headed for the Mountains”.

As Schwaber said about SAFe: “The empire strikes back!”, the hierarchy has a hard time changing, perhaps some of you would appreciate an article, we did here.

September 17-19th: Certified LeSS Practitioner Course With Bas Vodde | NYC

Experience Report by Guest-Blogger Heitor Roriz Filho
I am not going to entertain your hypothetical situation” answers Bas during the LeSS training in the last three days in NYC. His modesty during answering the questions posed by participants, advanced or more basic, really struck. The strong influence from Systems Thinking brings to mind the importance of experiments and hypothesis validation, one thing that most companies using Scrum today have completely misunderstood. Overall the three days of training were entertaining and served for me to consolidate the knowledge acquired during the first LeSS training I attended in Minneapolis with Craig Larman earlier this year.
Less (Large Scale Scrum) is a very strong and solid option scale Scrum in organizations. This is due to the fact that LeSS, as pointed out by Bas Vodde, was actually the result of Systems Modeling exercises and discussions. As a consequence of that, LeSS explores the organizational ability and desire to be more adaptive and to create and maintain customers by producing products or services they actually love. Systems Thinking applied in practice to actual problems organizations face, Product Owner responsibilities, team accountability and several real life examples and case studies were the things that stood out in the training.
If you are willing to learn more about LeSS, or become a LeSS trainer, you need to attend both classes: with Bas and the one with Craig. One complements the other in such a way that someone who is passionate with Agile can feel reinvigorated to go back the their clients and promote real Agility. Both instructors teach theory and practice but Craig’s class stands out laying more theoretical and philosophical foundations (crucial for true Agility) while Bas brings that to the trenches (crucial to get your hands dirty).

Experience Report by Guest-Blogger Michelle Lee
This was the first training class I have attended in several years. I’ve been reading Bas’s books and visiting the LeSS.works website to learn about this scaling framework. I ended up in New York on accident. I was suppose to attend this same training a week prior in Atlanta, but that class was cancelled due to scheduling issues. I am so glad it was. 

I have been interested in LeSS for about 5 years. What attracted me to this framework over others was the simplicity of the principles. For anyone who has done Scrum with a team, the principles just make sense, period. Had I attended the previously scheduled class in Atlanta, I would not have had Bas as the facilitator and I don’t think I would have learned as much. No offense to the trainer who I would have learned from, but the opportunity to learn from one of the co-creators made the class all the better. Bas does a great job telling stories and giving examples, he doesn’t pretend to know the answer to everything and he is honest about it. Just as all good Scrum Masters know, you can set up the guardrails, but until you experiment with what works for your company, team, style, it’s just an opinion. 

The content of the class was what I expected, and more. To be honest, I was frustrated after the first day. Why was I frustrated? I was frustrated because my table group and I were storming during our first exercise. Most of the people in the class are used to being the coach, not the player! When you are used to being the coach, jumping “in the game” requires you to look at the problem from a different angle and I wasn’t used to looking from that angle!! The exercises Bas put together forced each of us into having to play the game, listen to our teammates and self-manage our time to accomplish the outcomes. Sometimes we did well, sometimes we didn’t – sometimes we failed. I was reminded that failing is hard. Yet, we coach teams through failure all the time? We coach teams to learn from their failures, in fact, as Bas shared, most of the time we know an idea will fail, and we let it play out because we know the learning will be worth it!

The 3-days have made me look at how I coach differently and I thank the “banking table” team and Bas for allowing me the opportunity to fail, to learn, and to improve! New York was also a great city and the location was amazing, nothing against Atlanta. 🙂

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

August 25: Certified LeSS Basics (CLB) Course | NYC

 

This class brought together people of different skill set and domain expertise: hands-on software engineers, managers and analysts, agile coaches, trainers and Scrum Masters. It was a high-pace introductory review of LeSS framework, with the focus on organizational design, system dynamics, LeSS principles/rules/guides, local optimization vs. global optimization, feature vs. component teams, LeSS roles and responsibilities, as well as highlighting most commonly seen anti-patterns in LeSS adoptions.
The students got engaged in structured (instructor-led) and interactive learning, mixed up collaborative break-out sessions and exercises.
Extensive Q&A was handled throughout the session, with many learning moments being related to organizational reality of modern companies.