Category Archives: Training

Common Misconceptions About Agile Multi-team Software Development

Michael James is a software process mentor, team coach, and Scrum trainer with skills in Product Ownership (business), Scrum Mastery (facilitation), and the development team engineering practices (TDD, refactoring, continuous integration, pair programming) that allow Scrum to work. MJ has been involved with LeSS (Large Scale Scrum) longer than anyone else on the US West Coast. He is a recovering “software architect” with programming experience back to the late 1970s, and including control systems for aircraft and spacecraft


We often hear that the Agile approach to multi-team development is to pre-divide products into small independent pieces for different teams to work on, perhaps using implementation approaches such as microservices and coordination approaches such as “Scrum of Scrums.” This advice illustrates widespread blind spots in the Agile coaching and training community. We will challenge those in this online discussion.

To get the most out of this session, we suggest reading the comic book that went viral Why “Scrum” Isn’t Making Your Company Very Agile, How Misconceptions About The Product Owner Role Harm Your Organization, And What To Do About It.

Related artifacts:


03/03 – LESS TALKS: “What is Your Product?”, with Ellen Gottesdiener

To be product-aligned and customer-focused, everyone in your product development ecosystem needs to agree on the answer to the question, “What is Your Product?” Many organizations don’t have clarity on what their product or products are. Ambiguity and disagreement on the answer contribute to slow response to changing customer and market needs and less than satisfying product outcomes. It thwarts your efforts to scale agile product development and causes a plethora of organizational and communication woes.Large Scale Scrum (LeSS) rightly states that this question—and the imperative to answer it—is one of your most important decisions for successful product development. A clear answer to “What is Your Product” powers all aspects of product development, including product management roles, team organization, and product activities. The implications are vast and deep, especially in large enterprises. Product definition is one of the paramount steps in LeSS adoption. Depending on how a product is defined (how widely) an organization may consider simple LeSS or LeSS Huge. Based on the ladder, team structure and alignment is defined, product owner team is created, etc. Product definition has a significant impact on LeSS organisational design.Based on ongoing work with a variety of organizations, Ellen shares techniques for enabling product development leaders and communities to define their product using a cohesive set of product definition principles. In this keynote, Ellen will share why this question is so vital to your product success and ways she’s helped organizations co-discover the answer to the question, “What is Your Product?”

Whether your organization’s product or products are a primary source of revenue or are essential for your business operations, you will learn techniques that help instill product-thinking and shared understanding.

Ellen Gottesdiener’s Bio

Ellen is a Product Coach and CEO of EBG Consulting focused on helping product and development communities produce valuable outcomes through product agility. Ellen is known in the agile community as an instigator and innovator for collaborative practices for agile product discovery and using skilled facilitation to enable healthy teamwork and strong organizations. She is the author of three books on product discovery and requirements, frequent speaker, and works with clients globally. In her spare time, she is Producer of Boston’s Agile Product Open community and Director of Agile Alliance’s Agile Product Management initiative. You can connect digitally via:
http://ebgconsulting.com/blog/
https://twitter.com/ellengott
http://ebgconsulting.com/newsletter.php
http://www.linkedin.com/in/ellengottesdiener


Some Best Coaches May Face Some Biggest Challenges. Why?

Have you ever found yourself in a situation, where you feel that you have so much great value to bring to your potential client, that you are so much better than anyone else they may have considered for the role so far …. yet, a client is hesitant to bring you in. Why?

 First, You Must Self-Assess:
  • Are you a professional trainer, coach and organizational design consultant who had  spent many years honing his/her craft and investing in self-development? Do you consider yourself a life-long learner who openly speaks about it?
  • Over years, have you earned some highest industry-recognized accreditation that represent your professional journey? Do you make it explicit and visible publicly (e.g. LinkedIn, your web site)?
  • Have you, not only read dozens of books and case studies, but also authored or co-authored some on your own? Do you blog, write articles about your experiences and beliefs?
  • Do you speak publicly (webinars, conferences), have your own web site, where you offer free educational information to communities? Do you have tens of thousands followers in the industry, attending to your events, reading your newsletters and benefiting from your expertise?
  • Are you a one-person entity that you have relentlessly built over years?   Are your responsible for your own networking and business development, along with providing community service (this usually, always keeps you busy at nights and on weekends), ON TOP of your paid work?

If you answered ‘yes’ to most of the above, you are actually might be facing against some potential challenges.

What Are Some of Your Potential Challenges?
  • When trying to engage with a client, if you sound very knowledgeable (even if it comes so natural to you), you might be creating an inflated impression about what your aspirations and intentions are. Without any intention, you could be perceived as someone who wants to come in, take over, set your own tone, and run a show.
  • If you attempt to impress others with your knowledge too soon, the effect could be the opposite to what you expect: you  might be putting in an uncomfortable position people that you interact with, some of which could be much less experienced than you, unable to speak at your level, and perhaps even aiming at your future role, because their old roles had been being downsized (Larman’s Law #4). This is not so much a problem with senior management but quite common with first-second level manages and single-function roles (e.g. BAs, manual testers) that are sometimes asked to validate/interview you initially.
  • You might be competing against a very large population of external candidates-consultants that are usually procured through staffing agencies/traditional preferred vendors, and presented as “coaches” (today, coaching is a highly commoditized and heavily overloaded term). In reality, such candidates are coaches in name-only (a.k.a. coaches-centaurs). They are willing to engage at a deeply discounted rate and are easily augment-able into an existing reporting structure (seamlessly fit an existing staffing model) just like any other, traditional “human resource”. Once in, they typically become individual performers (e.g. tool administrators, backlog stewards, or metrics collectors) – a classic coaching anti-pattern.
  • You might be trying to enter into a client company’s domain that is tightly controlled by a large consultancy that already brought in their own, very expensive resources, installed their own, home-baked ‘best practices’ that are presented in the form of heavy power point decks and cook books. Even if you have a lot of experience with such best practices, unless you explicitly express your strong support for them, at the time of initial contact with a client, you might be perceived as a challenger and corporate unfit.
  • Although the most generous rate of a highly experienced independent professional (we assume, you are reading this now) is just a fraction of what a large consultancy would be charging a client for each placed consultant, if you cost more than a coach-centaur (described above), you may put yourself out of range.
What Can You Do to Mitigate These Challenges?

First and foremost, remember: there is only one chance when you can make your first impression!!! You are lucky if you will have a second chance.

  • Try to understand, really well, what a client’s real goals and aspirations are. When you meet a client, even for the first time (first interview or just an informal lunch meeting), listen to THEIR concerns and feel for THEIR pains.  Keep your strong views to yourself and tone down what you  may know: do not overwhelm a client.  At times, a client will not be explicit with you about their real problems, so you may need to read between the lines, ask probing questions. But be careful, how deep you probe.  Don’t become too obvious.
  • Do not up-sell yourself. Do not speak about your own qualifications, credentials or past successes (unless it is absolutely necessary or you are being asked).  Of course, it would be amazing is someone paved a road for you and spoke about you highly, so that you have a fair representation😊.  If you have to refer to your past experiences, present them as circumstantial and based on past conditions (try not sound absolute and categorical).
  • Always remember that when you meet a client, you are on THEIR territory, and eventually, you will leave and they will own everything you have done for them.  You may not even have a chance to claim a credit for your work, because its results will be seen only after you are gone.  Therefore, be very explicit about your intentions upfront, of NOT wanting to ‘take over, become a hero, challenge everyone and change everything’.   This could be a tough one, because at times, against your own will, you could be viewed as a leader-challenger, due of your perceived seasoning and expertise. You must make a client comfortable that you will respect their territory and their decisions and you are there to serve THEM.
  • During your initial interaction with a potential client, even if you discover something that makes you feel that an immediate course correction is required, refrain from stating this too soon (unless you are explicitly asked to provide your own view). It would be wiser to offer assurance to a client that you are seeing a lot of potential of working together and ready to support them in any of their efforts. Then, only after you fully engage and dig in, you should start gently steering a client in a right direction by, reflecting on what you see, and offering alternatives, as needed.

In summary, being a highly qualified and experienced professional does not automatically quality you as, as the best candidate to be selected.  There are many situational conditions that must be considered while interacting with a potential client.  Often times, not all your assets and resources should be revealed at once and to everyone.  You may have to be strategically smart in your pursuit and goals, even if your intentions are most genuine and it feels that you just have to be yourself and hold nothing back.

03/03 – LESS TALKS: Meet Ron Jeffries & Chet Hendrickson @ LeSS NYC (‘Dark Scrum’ and more…)



First and most importantly: Ron Jeffries and Chet Hendrickson are long time friends and colleagues who both had a huge impact on what defines AGILITY.
About Ron:

Ron Jeffries is author of Extreme Programming Adventures in C#, the senior author of Extreme Programming Installed, and was the on-site XP coach for the original Extreme Programming project. Ron has been involved with Scrum, Extreme Programming, and Agile for over ten years, presenting numerous talks and publishing papers on the topic.

Ron is the proprietor of www.XProgramming.com, a highly-ranked source of Agile Software Development information. He was one of the creators, and a featured instructor in Object Mentor’s popular XP Immersion course. Ron is a well-known independent consultant in Scrum, XP and Agile methods, recently specializing in helping Scrum teams get Done-Done.  Ron is one of the original authors of the Agile Manifesto.  Read Ron’s post on ‘Dark Scrum’ at: https://ronjeffries.com/articles/016-09ff/defense/

About Chet:

Chet Hendrickson has been involved with Agile Software Development since 1996, when as a member of Chrysler’s C3 project he helped develop Extreme Programming. In 2000, Ron Jeffries, Ann Anderson, and Chet wrote Extreme Programming Installed. It detailed XP’s core practices, how to do them, and how they work together to help teams be successful.

Chet is the first signatory to the Agile Manifesto.

Since 2002, Chet has been an independent consultant, coach, and trainer. In 2009, he was asked by the Scrum Alliance to help develop the Certified Scrum Developer program. Chet and Ron Jeffries taught the first CSD course and continue to offer them in the United States and Europe. He has been a Certified Scrum Trainer since 2009.

Ron and Chet were the curators of the Scrum Alliance’s Agile Atlas website and in that function created the Alliance’s official Scrum description, Core Scrum.

Chet and Ron Jeffries often work together and are popular conference speakers, bringing an interesting mix of humor and deep knowledge, and the odd cat picture. The are a fixture at the Agile Alliance’s annual conference, Agile 20xx, as presenters in the Stalwarts track.
Last year, Chet attended Craig Larman’s LeSS class in NYC and this is what he had to say:
http://www.keystepstosuccess.com/2018/06/may-30th-june-1st-certified-less-practitioner-course-with-craig-larman-nyc/


02/27 – LESS TALKS: Q & A on “The Spotify “Model”: Don’t Simply Copy-Paste”, with Evan Campbell



Recently, Evan  Campbell wrote an article on SolustionsIQ site: The Spotify “Model”: Don’t Simply Copy-Paste.  It resonated strongly with  many people. This LinkedIn feed alone attracted more than 23,000 viewers and it is growing.

On February 27, Evan was a guest-speaker at Large Scale Scrum (LeSS) meetup of NYC, answering questions about his views and the writing.  The video recording and transcript with live questions are below:

Top 5 Questions submitted before the session:
  1. Evan’s article talks about many large companies blindly adopting the Spotify model, because this is the strong recommendation they get from large consultancies. Are there any examples, at least, when such recommendations were followed and implemented successfully? It seems that ING success is overly inflated.
  2.  In the article, there is mentioning of hard-line reporting within the “chapter” or the “tribe” structures? It means that historical/orthodox challenges of organizational design persist in new “agile” structures. Could you elaborate on that?
  3. In the article, there is mentioning of random consultancies’ PowerPoint solutions, in which a heavy deck is the most important asset delivered. It is often delivered by a consultant who has very little industry experience, yet presents from the deck ‘as if’ it was the best known practice. Any comments on that?
  4. Our organization is big and one-team Scrum is not sufficient. If Spotify is not the right solution to scale, then what is?
  5. Our company was advised to adopt Spotify model. Today, some of old vertical organizational structures (e.g. QA department, Architecture group) have become chapters, and people are mandated to be a part of those chapters. Used to be managers, are now chapter leads. Nothing seems to be changing. What are your thoughts on this?

Discussion of Two Agile Coaches (Erin Perry & Gene Gendel): Uncomfortable Topics Addressed



Erin Perry and Gene Gendel (his site) have known each other for almost a decade through past work and continuous networking.  They both had agreed to have a candid talk about some of their personal work experiences.  The whole recording is about 35 minutes. But there is no fluff. This is slides-free dialogue of two experienced coaches, with many years of industry experience. Erin and Gene are exposing some most pressing  and somewhere uncomfortable topics.

Topics addressed:

  • How do you keep your head up when you’ve seen agility rolled back or stopped over and over again?
  • What mistakes are you seeing over and over again with large scale agility?
  • What are some of the biggest external challenges that organizations face today, with respect to agile guidance (e.g. low quality agile staffing,  big consultancies)?
  • Why organizational agility is in jeopardy, when there is heavy reliance on external vendors (development & testing) that are not familiar with agile, beyond knowing how to spell it?  What could be done to mitigate this problem?

02/18 – LESS TALKS: Tsvi Gal, CIO/CTO @ multiple Fin-Techs: sharing experiences about organizational agility



Tsvi Gal is an accomplished technology business leader, the winner of the Einstein Award for technology excellence.  Tsvi had served as CTO and CIO at a number of large enterprises: Morgan Stanley, Bridgewater Associates, Deutsche Bank Investment Banking, Time Warner Music Group and other companies.  Tsvi has extensive experience in technology and operations, mostly in financial services, media and telecom.
In his recent career, Tsvi led the divisional Agile & DevOps transformation and the changes to the ways of work in technology, workforce strategy and front-to-back initiative.

Some questions presented & answered:
  • When someone wants to transform, it implies that there is a need to transform (change). What were some of the most pressing needs, in your experience, to go through changes? Something did not work? Was not efficient? Other?
  • How many people were involved in the transformation? How long did it take? Who was spear-heading this effort: internal coaches, external coaches, mix of both, PMO, etc?
  • How did you address HR related issues that frequently arise when agile teams are being stood up: individual performance appraisals, bonuses, promotions, career path?
  • Who provided guidance to technical excellence during the transformation? Technical coaches (internal, external)? Were teams using TDD, CI/CD?
  • Did you use any known agile frameworks ro scaling approaches? Or was it all internally defined?
  • DevOps vs. DevSecOps? Any difference? Is it dev practice or org. silo?
  • HR is years behind, when it comes to agility. Why? Do not blindly copy & paste (e.g. Spotify model)

02/11 – LESS TALKS: Nicolas M. Chaillan, US Air Force Chief Software Officer On Technology Agility, Scaling and More

On February 11, 2020, NYC Large Scale Scrum (LeSS) meetup was honored to host the event for a special guest-speaker Nicolas Chaillan – the first Air Force Chief Software Officer.  Nicolas is also the co-lead for the Department of Defense Enterprise DevSecOps Initiative with the Department of Defense Chief Information Officer. His full bio is available here.

Presentation Slides

CSO Memo on Agile – and SAFe, by Nicolas M. Chaillan (US Air Force Chief Software Officer)


Run This Method Through Organizational Compiler



Running this method through an “organizational compiler” may improve health of your organization: (variables are “globally declared” and clickable hyperlinks. You can pass any arguments to this method, as long as they are valid arguments 🙂 )
public class LegacyOrganizationalEcosystem { 
public static void main(String[] args){
if((agile_framework == this_framework{ 
System.out.println ("Simplify your organisation.
Try scaling agility by de-scaling complexity")
} 
else if (agile_maturity_goal == this_goal){
System.out.println ("Stop chasing numbers. Self-assess, systemically")
}
else if (agility_measurement == this_measurement){
System.out.println ("Stop internal competition. Recognize command & control behaviors through system modelling.")
}
else if (coaching_model == this_model-left_side){
System.out.println ("Avoid locally optimized for coaching ivory towers and Agile CoEs.")
} 
else if (agile_coach == this_coach-right_side){
System.out.println ("Beware of 'quasi-coaches'.")
}
else if (agile_coach_career_path == this path){
System.out.println ("Get REAL, experienced coaches with effective coaching approaches")
} 
else if (agile_knowledge_basis == this_certification){
System.out.println ("Avoid certification collectors. Be cyber-vigilant.")
} 
else if (talent_acquisition_model ==  this_model){
System.out.println (" By-pass staffing agencies. Select vendors diligently and responsibly.")
}
else if (architecture_expert == this_architect){
System.out.println ("Avoid 'power-point' architects.")
}
else if (prod_owner_team_communication == this_comm){ 
System.out.println ("Remove translation layers. Learn about benefits of feature teams through gaming.")
}
else if (prod_owner_sm_relationship == this_relation)
{
System.out.println ("Avoid faking Scrum roles. Understand Scrum roles through system modelling.")
} 
else if  (scrum_pattern == this_pattern)
{
System.out.println ("Recognize Scrum anti-patterns.")
} 
else if (sprint_naming == this_convention){
System.out.println ("Avoid Sprints without PSPI. Understand and expand product definition.")
}
else if (customer_request == agile_requirement){
System.out.println ("Avoid 'agile' BAs and BRDs.")
}
System.out.println (“Overall, your organization may need a refresher on what agility truly means :). You may enjoy sharing this” + anecdote + “ with your colleagues and play this”+ game +” at your next town-hall meeting.”)
}
 }

 

About Contracts That Support Agile Ways of Working



One of various under-served (ignored) dimensions of agile transformations that frequently limit an organization’s success, there is one that requires special attention.

It is vendor management that can be traced back to legal contracts between a client company and supplier/vendor.

Vendor management norms and guidelines define relationships and interaction between a company’s own employees and external workers, individually and in team-level settings.  Unfortunately, this issue is not always obvious and therefore, is neither explicitly raised by inexperienced agile coaches, nor adequately addressed by senior leadership that is satisfied with limited results (could be also a sign of complacency).

There is a lot of improvement required in how corporate attorneys and vendor managers define, initiate and maintain external relationships with third parties.

This post provides a short summary of recommended improvements – they are  listed below.  It is based on a more comprehensive excerpt: Agile Contracts Primer, by T. Arbogast, C. Larman, B. Vodde.

(Also, please refer to Top-5 high-level recommendations for what to look for in vendors, selected for agile projects, in “Survival List to Vendor Selection on Agile Projects”)

Recommendations for Attorneys and Vendor Managers:
  • Acknowledge that Legal, just like Finance and HR can diminish project success if not considered as a part of agile ecosystem
  • Get rid of false dichotomies around the 3rd Agile Manifesto value: “just because we value customer collaboration than contract negotiation, it does not mean that a contract has no value” 😉
  • Make sure that attorneys understand that a “successful contract” is not the main goal.  It is a successful project or product (delivery) that is the main goal.
  • Draw analogy between software project complexity and your own (if you are an attorney) legal work complexity, to appreciate how difficult it is to do precise upfront estimation on huge, unpredictable body of work
  • Understand how agile approaches can lower (not completely remove) friction around, such areas of contract negotiation as liability, warranty, payments, pricing, deliverable
  • Understand that external legal contracts have downstream impact on internal non-legal contracts – relationships between people
  • Understand repercussions of subjective incentives and rewards (bonuses), given to attorneys for legal outcomes (event if they are successful), instead of focusing on an overall project success
  • Understand/study agile and iterative development (e.g. Scrum, Kanban), system thinking concepts, lean principles and agile project assumptions differ from traditional project assumptions
  • Gain strong grasp of what Acceptance Criteria, Definition of Done, PSPI and MVP mean
  • Study how continuous deployment and incremental development can reduce risk and exposure, as oppose to sequential/waterfall SDLC that usually  increases it
  • Understand positive implications of agile ways of working Limited Liability and Warranty, Deliverable and Pricing
  • Specifically, with regards to Pricing, understand:
    • Variations of T&M contracts and why they are good for agile projects.  For example:
      • Fixed price per iteration (per unit of time), fixed-price per large project
      • Fixed price per unit of work
      • Pay-per-use models
      • Hybrid shared pain/gain models
      • Capped-Price, Variable-Scope vs. Capped-Price, Partial-Fixed-Scope vs. Fixed-Price, Variable-Scope
      • Target-cost
    • Reasons why FPFS contacts are least desirable/most risky and what are some of the ways of lowering such risks
    • Difference between flexible scope without and with penalty (shared gain/pain)
    • Early termination – does not mean failure
Conclusion

Contracts are not necessarily always bad.  Having an external, legal contract between a client and a vendor/service provider/supplier is perfectly normal and even necessary.  It is the form of a contract that matters, as it has downstream effect on dynamics and behaviors between people within a client company, as well as between the parties.

To produce a meaningful contract for an agile project, an attorney should have good understanding of what is valued most in agile work, by agile teams, and optimize his/her own work for the benefit of an overall project, not just for having an amazing contract (locally optimized for an attorney’s benefit).  To gain such understanding a legal professional needs to invest significantly in studying principles of agile/adaptive product development (e.g. Scrum, Kanban), lean and system thinking.

Some of the above listed contract types are more supportive of agile work than others and each once must be explored in detail for suitability, depending on unique organizational settings.