Coaching and Consulting
In the early 2000s (after a couple decades of waterfall) I was a developer in a small company that had learned a lot about doing Scrum and the related technical practices. We discovered one of our product customers was a local organization with multiple teams struggling to do Scrum. So we visited them, observed how they worked, mob programmed with them, and eventually made some subtle suggestions that seemed to make an impact. Collaboration improved, code quality improved, and soon the product was shippable every two weeks. And so we thought, “Wow! Consulting is easy!”
Months later, the teams had starved their backlog because political issues prevented them from talking to customers and end users. Morale dropped, the strongest developers got bored and left, and they were right back where they started. Eventually the whole project got cancelled.
A couple years later we were contracted to train hundreds of people for an e-commerce company. We knew how to help the teams perform better, but it quickly became clear that team performance was only a tiny factor in that organization’s ability to adapt. The way the teams were organized, the way people outside the teams tried to coordinate their work, the HR policies, the dozens of junior “Product Owners” and “Product Backlogs” didn’t look any better than traditional waterfall development to us. The organization did not become more adaptable and today they continue to lose market share.
A year or so later I coached the development organization of a popular online store and noticed the Scrum Masters seemed oblivious to the organizational improvement opportunities all around them. I wrote the Scrum Master Checklist for them. Evidently it was useful for lots of people, as volunteers have translated it into a dozen languages.
Eventually I had the opportunity to learn systems thinking from Jerry Weinberg, and large scale development from Bas Vodde and Craig Larman. Now my focus is on the whole system. There is very little point in one team “doing Scrum” (or XP, Kanban, etc.) without changing the larger context the team works in.
Below I am listing example coaching and consulting services we offer:
Informed Consent Workshop
The most common complaint we hear in trainings is “Why isn’t my manager in this class?” At least one third of the challenges that participants raise in training are things we’d like management’s help with.
The best adoptions we’ve been involved with were both top down and bottom up.
WARNING: Broad adaptiveness is a greater opportunity – and greater challenge – for the entire organization than training sponsors realize at first.
The informed consent workshop is a get together with a cross section of senior management, HR, developers, and intermediate managers (e.g. program managers, project managers, department heads). We will discuss current pain points, what’s gone wrong with previous improvement initiatives, what pitfalls and setbacks are likely … all the icky stuff. Bring samples of your source code if you like. Please be prepared to discuss what you want to optimize your organization for, what you want to keep, and what you think your organization must give up to move toward that optimization goal.
(Team) Sprint Retrospective Facilitation
Whether your methods are influenced by Scrum, Kanban, XP, waterfall, LeSS, or all/none of the above, we want teams to own their processes and methods, not rent them.
An effective retrospective – one that leads to shared understanding and durable agreements – allows sufficient discussion of objective questions, reflective questions, introspective questions before moving into decisional questions (ORID). An effective facilitator is a skillful listener who creates space for viewpoints from the entire group, not only the most confident.
According to Roger Schwarz, a facilitator should be
- acceptable to all members of the group,
- substantively neutral, and
- not have substantive decision making authority.
Schwarz writes that the facilitator can meet these three criteria only if he or she is not a group member.
While we would like you to eventually develop facilitation capabilities internally (e.g. with
your own Scrum Masters), in the
beginning or at crucial times it can be better to enlist outside help. This is a cost-effective
option for situations that do not need a full-time coach.
Overall Retrospective Facilitation
When more than one team works on a product, they are more likely to develop a whole product view by following their separate (Team) Sprint Retrospectives with a cross-team Overall Retrospective. This is for team members (or representative samples of them), Scrum Masters, the Product Owner, and management to inspect and adapt the entire product development system. A neutral outsider can use systems modeling, causal loop diagramming, and large group facilitation techniques to help make these discussions productive.
Product Backlog Refinement (aka. Backlog Grooming) Facilitation
Organizations struggle to capture user needs in their product backlogs in ways that lend themselves to adaptability, reduced work-in-progress (WIP), and short schedules. Are you struggling with user stories, epics, traditional requirements, estimation, and dependencies? We can help you identify thin vertical slices of customer value work.
Team Self Designing Workshop
It’s very likely that your teams are structured in ways that cause wasteful asynchronous dependencies. We encourage teams to design and reorganize themselves. But doing this without a structured workshop can just lead to people grouping with where they’re currently comfortable rather than where they’ll learn the most and be the most effective.
Current Architecture Workshop
You have legacy code that only a handful of people understand. This is an expensive and risky bottleneck. We use the current architecture workshop to spread knowledge amongst more teams. This can reduce handoff delays and the risk of introducing unintended regression failures.
Mob Programming Facilitation
Your developers spend a surprising amount of time being stuck, or sawing away with tools they don’t know need sharpening. A learning technique that’s especially useful is to have a small group of developers sit together and all focus on the same programming problems at the same time. This spreads knowledge and skills very rapidly. Consider the possibility that software development is actually knowledge creation, not conventional manufacturing or construction.
Code Smells Workshop
Even a child can write code that works. But the real costs of the software aren’t in the initial creation. It takes decades to master the craft of well designed code (and tests) that reduce the long term costs. In the crush of meeting short-term deadlines, developers working alone typically develop bad habits that seem normal to them. In the code smells workshop, participants learn to identify up to a dozen harmful patterns in real code, and of course how to prevent them.
De-scaling Consultation
Lots of people are talking about “scaling Agile” and even selling hideous ways of doing it (e.g. SAFe, Scrum@Scale). Let’s
talk about descaling organizational complexity instead.
Open Space (Large Group) Facilitation
Keep your company conference from being a waste of time. We facilitate Harrison Owen-style Open Space gatherings that increase the communication and camaraderie your organization needs to work toward a shared purpose.
—-
