In the early 2000s 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.
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 some example coaching and consulting services we offer:
Informed Consent Workshop
The best Agile adoptions we’ve been involved with were both top down and bottom up.
Agility is a greater opportunity and challenge for the entire organization than training sponsors realize at first.
Let’s get together with a cross section of senior management, HR, developers, and intermediate (e.g. project/program) managers and discuss the likely implications for your organization.
(Team) Sprint Retrospective Facilitation
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 develop these capabilities internally (e.g. with full-time Scrum Masters), in the beginning or at crucial times it can be better to enlist outside help.
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, casual loop diagramming, and large group facilitation techniques to help make these discussions productive.
Other Services – Please inquire about:
Initial Product Backlog Refinement
Team Self Designing Workshop
Current Architecture Workshop
Mob Programming Facilitation
Code Smells Workshop