Introducing my two AI constructs:

• Agile Explainer: Interactive guidance on Agile Software Development and related methods from basics to advanced.
• Systems Explainer: The powerful world of Systems Thinking at your fingertips.

These are specialty GPTs that are remarkably good if I do say so myself. I am not too worried about people in Systems Thinking going unemployed. That was my earlier career and it did not pay my bills back in the 1970’s. Agile expertise is another matter, though. The Agile Explainer has access to a whole lot of information and is ready to answer your questions, and maybe ask a few of its own. Use it if you can’t find a coach when you need one. Fun challenge: ask the GPT your question first then ask your coach, see how well the conversations align. Play Stump the Agile Coach!

I apologize for the pay wall. At this time (11/23), you will need a ChatGPT Plus or Enterprise account to use these. OpenAI did not give a free option. They have LLMs to feed, after all.

Enjoy and please don’t be too mad at me. It was going to happen eventually.

I have been slow to announce my retirement from the Agile space. The reason is that I already announced it three times before it actually stuck. Fun work kept popping up that I could not resist. Plus there was the weirdness of the Covid shutdown when a lot of my colleagues re-tooled for remote training and coaching. I maintained some coaching capability but passed on the training shift as a poor investment at this late point in my career.

As of April of this year, I am no longer taking clients for training or coaching. In thanks to all of my friends, collaborators and clients, I re-purposed my website at agilecrossing.com to be a sort of memoir with pictures from my Agile career. Have a look if you ever had a class with me or helped out in a Coaches Clinic. There may be a picture that sparks a memory, hopefully a pleasant one. As an added bonus, I have made many of my training materials available for free at agilecrossing.com/freebies.

There is a slim chance that I may still post an article or two here. I have a lot of drafts in a folder somewhere. And I have a lot of mini-lectures to share, though they are starting to decay for lack of repetition. If there is any topic you may have heard from me in a class or coaching session that you would like a reminder of, let me know and I will see what I can do.

I am busy with other endeavors that I hope to announce formally (LinkedIn, I guess) in the coming months. Who cares, really? But moving to a new business domain may bring new connections so I will follow the protocols.

While the Agile world is full of great people and more are moving up the ranks as some of us retire, I can’t help but leave the community with a couple of modern tools to fill some of the space I am vacating. Stayed tuned for the next post…

Cheers and hopes for a more peaceful Planet Earth and Human Race,

Roger Brown November, 2023

In this year’s session, we wanted to add some commentary around the current state of affairs, how the COVID-19 lockdown has impacted business for most of us in the US and many beyond. Since my personal response was to just step back from my one active client and let my fellow coaches do the real work, I did not have a lot to offer myself. So I went to one of my strongest sources, the Scrum Alliance Certified Team Coach® and Certified Enterprise Coach® community for lessons learned. This community is close to my heart, having been a founding team member for both programs.

I posted a survey with a short list of questions.

1. How has the pandemic affected your coaching business?
2. What changes have you made to your business and which have been helpful, which not?
3. Has your certification had any effect on business this year, positive or negative? Why?
4. What have you learned to achieve more success at coaching under current conditions (you being remote, clients dispersed and working from home, company downsizing, etc.)?
5. Is there anything else you would like to add?

This is my aggregation of responses from 20 coaches. It was anonymous so please don’t ask me who said what. You may find some answers to be obvious and familiar. You may also find some surprises and ideas on how to make the most of our unusual situation.

Impacts

• All work is remote and leverages video and digital tools, of course.
• Have had to retool training products.
• Less travel means more time for new clients and/or self-improvement work.
• Billable Hours: 3 increased, 9 decreased, 1 up and down depending on client, 2 down then up.
• Leads and prospects decreased in general.
• I now have more global exposure.

Behavior Changes

• Set up tools and space for video-based work.
• Learn more about marketing. (frowny face)
• Remote work takes more hours.
• Doing more training, less coaching.
• Retooled training and facilitation artifacts for online interactions.
• Put effort into more persistent IP (video, blog, books).
• Less time spent on email.
• More time to mentor others.
• Expanded product and service offerings to replace what I can’t offer remotely.

Value of Certification

• Is CTC/CEC helpful at this time? 6 Yes, 7 Neutral, 0 No
• Indirectly, certification leads to more speaking engagements, thereby helping to get business.
• Reputation is worth more than certification.
• With everyone online and remote, there is more competition from self-proclaimed experts.
• Training certificates are helpful now to allow sales of online training as a substitute and/or funnel to coaching business.

Lessons Learned

• Skills and Tools
  • Level up on tools: Zoom, Miro, Mural, Calendly mentioned most.
  • Level up on remote facilitation skills.
  • Keep tool use simple to focus on content instead of technology.
  • Facilitation tools can also provide documentation of decisions made.
  • Make instructions visible when facilitating an exercise.

• Business
  • Sure glad I had a financial buffer in case of really big emergencies.
  • Do more marketing.
  • Less travel == more time for the client
  • Build your network. Tap your connections.
  • Re-calibrate your compensation expectations.

• Self-Improvement
  • Patience, patience, patience
  • Be more flexible and open-minded.
  • “Someday” has arrived for professional growth. Make good use of the time.

• Client Interaction
  • Interactions are more targeted and more pro-active
  • Limit Zoom to 12 people. Use breakouts if you can’t.
  • Actively schedule everything and use a regular cadence when appropriate.
  • Show up for the schedule; don’t wait for client to respond (ie. 1-1s)
  • Kids and dogs are ok.

• Client Atmosphere
  • Teams adjusted better than expected
  • Team members seem to have more equal voices.
  • Transformation is easier when people are not tied to “place”.
  • Hard to get the bigger picture and undercurrents.

• Personal
  • Have a separate home office.
  • Let family know your schedule.

Other Observations

• When working on a coaching team, all-remote work has too much communication overhead (my personal experience)
• Ironic how much resistance to change there was among Agilists.
• Remote coaching takes a lot of energy.
• Quality of coaching is even more important.
• Don’t try to recreate in-person culture in an on-line world.
• Self-learning opened up new communities to tap. (ex. Online schools.)

Feel free to comment with your own lessons learned that may benefit your fellow coaches.

The slides from my talk are available here.

I don’t think anyone recorded the talk and I don’t know a good way to condense 45 minutes of information (and informed opinion) into text, so I will just summarize the objectives and conclusions here:

Objectives:

• How to describe an Agile Coach
• How to identify Agile Coach competencies
• How to distinguish good Coaches
• How to value an Agile Coach

Summary:

• You will reach Agility sooner
• The path will be smoother
• Your Agility will be more sustainable
• An Agile Coach is a bargain

Take a look at the slides to see how we got from the beginning to the end. Meanwhile I will think about how best to share the details.

There are legacy forces that work against pull systems, trying to push work into both Product and Sprint Backlogs. These include stakeholder requests, maintenance fixes and client feature changes. Scrum is designed to absorb feature requests and changes by buffering them into the Product Backlog. Maintenance work is buffered by defining a set percentage of Sprint time for fixes and paying down technical debt. Ideally, a new product is built using Agile engineering practices that make maintenance virtually unnecessary.

There are times, however, when the legacy forces overpower the Scrum machine. This is especially true in organizations new to Agile principles and practices or lacking in proper training so that Agile Development is not implemented as designed. Another common case is when Agile Development is attempted for a business client under a traditional fixed-cost, fixed-scope, fixed time contract. Such contracts are typically underestimated and then stressed further with scope changes.

When a Scrum Team is pushed, these desired attributes are compromised or lost: quality of product, quality of life for the team, predictability from invalid velocity data, resilience to other surprises. To preserve these attributes and maintain a healthy, productive team – one of the most valuable assets a company can have – there are times when it is necessary to “just say no”. Since saying “no” runs counter to traditional software development protocol, here are some tips on how to say no more judiciously.

Product Backlog Protection

When a Product Owner is asked to add to the Product Backlog, there are other ways to achieve the effect of “just say no” without using those words.

1. Say “Not Yet”, because there are other things that need to be done first according to priority order or dependency build-out. Some of the common secondary artifacts can help here. The Product Vision can help if the request is not in line with the vision. The Product Roadmap can help show where in the desired timeline the request might fit in better. The current Product backlog itself can help, along with a Release Burnup that shows the current release goals and progress towards them.

2. The prioritization method in use for the Product Backlog can help by having a category for “Wont” with a less final name such as “For Consideration”.

3. When the requestor is an external client asking for a fixed-everything contract, try to shift to one of the forms of Agile contract. Sell them ‘adaptability’ instead of busy workers. Ask them to be the Product Owner, or at least provide ongoing input to prioritization in the Product Backlog”. The client usually changes their mind more than once. The Team should not have to pay the price. The ability to change their mind is a valuable feature of Agile, not a bug.

4. Avoid quick agreement to unplanned feature requests. Give them time to “settle”. There is a common corporate dynamic that may sound familiar. A request comes in from a Very Important Person. You agree to it quickly, work hard to deliver quickly and then find out that it really wasn’t that important after all. “Oh, Joe did that for me already, but thanks.” If you take a new request under consideration for the future, it may lose importance before you get to it.

Sprint Backlog Protection

Scrum says that new work is not to be inserted into the Sprint. The Scrum Team creates the Sprint Backlog in their Sprint Planning meeting and from that point on only the Team can change it by pulling in more items from the Product Backlog if they get ahead of the plan or putting items back if the plan is not likely to be achieved.

But it is sadly common for Teams to be asked to do something that is not planned for the Sprint. Here are to ways to say “no”:

1. Ask “Can it really not wait three weeks?” That is the average time for something new to be accomplished if the Sprint length is 2 weeks. The Team is, in a probability sense, in the middle of this Sprint. If the item is important enough to enter the next Sprint then the wait time is 1.5 Sprints. How many requests are so critical that they can’t wait that long? (End user-impacting emergencies like service outages are an exception, of course.)

2. “Which two items shall we remove from the Sprint?” A reasonable rule of thumb is that a new, unplanned item inserted into a Sprint will cost two planned items. Clearly one must be removed to make room for the new item. Another item’s worth of work will be created by context switching, elaborating the new item and backing out any work done that will not be completed. If the requesting Stakeholder is invested in the other work of the Sprint, they may well reconsider the new request, possibly accepting the Sprint and a Half Option described above.

3. The topic of absorbing maintenance work in the Sprint is a big one so we will discuss that in another article.

These tips for constructive reframing of “just say no” may be helpful in protecting the Team while educating your Stakeholders to the underlying “pull” aspect of Agile Development. A smooth, predictable flow benefits everyone and response to change can still be orders of magnitude quicker than anything we had in the pre-Agile past. Everyone wins.