Abstract: The job of the influencer or coach/mentor in a software team, regardless of title (Manager, Director, Agile Coach, Scrum Master, Tech Lead, etc) isn’t to evangelize best practices and beat people over the head with manifestos. Rather, the job of any professional in an Agile environment is delivery enablement, which I define as enhancing/optimizing delivery of value to the customer and our stakeholders. This translates into working code in production. Everything we do should roll up to that, and the 9 Business Outcomes* described below.
When coaching a new team or set of teams, and especially when joining a new company, it is very important to bring with a great amount of intellectual humility. I have seen many folks come in guns-blazing with their ideas, trying to implement what they did at previous work places too quickly. This is far too common, and it usually has multiple consequences:
- Ignores the unique context of the new team(s) or company (context-oblivious vs context-aware)
- Proofs-of-concept executed without first understanding context can fail, even if they might have been a good idea, due to lack of buy-in and ownership (command and control approach vs coaching/mentorship)
- Can be off-putting to partners and team members who know the system better and may already have ideas they were hoping you’d pair with them on instead (know-it-all vs collaborative partner)
- Multiple other detriments, including the burning of bridges and very quickly becoming seen as someone to be worked around instead of worked with (seen as an impediment rather than a delivery enablement advocate)
It is important to show care about the people more than anything else up front. The technology problems will come, believe me, and when they do, you need to be respected and trusted in order to be an effective value delivery enabler. So, what is my mental model and the approach I take when being faced with new teams or a new environment?
Practical Approach to Delivery Enablement
First 30 Days (Initial Absorption)
It is important to learn the various team contexts and people at play; gaining trust and building chemistry, rather than making suggestions out of the gate…
- Heavy Learning of various team frameworks, contexts, scrum events, communication patterns, practices, tooling, dependencies, etc.
- Build Partnerships with key technology and business stakeholders (via 1-on-1s, team outings, troubleshooting, cultural events, etc).
- Identify top 2 or 3 Impediments (‘pain points’) experienced by the development and product team.
- Gain Consensus on prioritization of the 9 Business Outcomes (below) with Tech/Product delivery leadership buy-in.
Day 30-90 (Planning and Experimentation)
At this point, I’ve reached the second stage of learning and I seek to leverage new relationships to start planning how to tackle delivery impediments…
- Prioritize and Generate Impediment resolution plan: The “How” and any possible solutions must come from the team, or indirectly through coaching (e.g. Socratic Method)
- Upstream Coaching: Management and other influential business stakeholders external to the development team may need to be educated on inhibitive anti-patterns observed – Start small and build conversational safety (more offering up questions than definitive changes at this point).
- Fill Agility Practice Gaps: Delivery Transparency via Dashboarding/Metrics, Various trainings, Balance team protection with stakeholder needs, and more.
- Canary-in-a-Coalmine: Execute small proofs-of-concepts (POC), targeting the more experimental/open teams, to gain traction on any new or pivoted agility or engineering practice. (The goal here is to avoid command-and-control practice setting but letting peer-to-peer influence abound post POC).
- Conduct initial Team Health & Agility assessments at both the ART/org and team levels (gain consensus on which categories matter to move the needle)
- Consult development team Retrospectives on any new POC or change and bubble up feedback as appropriate to management and influencer level.
- Widen circle of go-to partners, allies and proactive stakeholders (leverage strengths, interests to get POCs off the ground).
Day 90+ (Coaching and Optimizing)
A success measurement at this stage is having gained the trust and respect of the development team, other peers and leadership such that the continued momentum and desire for continuous improvement stays strong. We can close the loop by both directly and indirectly affecting the business outcomes that the business previously prioritized during the first 30 days…
- Continue to Fill Agility Practice Gaps: Optimize Value-flow through ART (Agile Release Train), PI Planning, Risk & Dependency Tracking, Hardening/Innovation allocation, and more.
- Engineering Practices: Provide coaching on Shift-left DevOps embracement, CI/CD gap identification, automation opportunities, unit testing, build and deployment gates, quality and development risk modeling and test strategy (contextual depending on Monolith or Microservice), SDLC optimization, Vertical Slicing of teams, monitoring and alerting and more.
- Tool Optimization & Information Radiators: Offer guidance on ALM configuration and visibility, provide stakeholder-appropriate value-driven dashboards (Product v Business v Devops, etc).
- Impediment Removal: Continually facilitate team and org level technical and non-technical roadblocks.
- Conflict Resolution: Manage team conflict via iterative stages only escalating when appropriate through 1-on-1, 2-on-1, then manager level if proven necessary or for recurring trends – (e.g. keep ‘team business’ at the team level ideally).
- Ongoing Agility Health Assessments: Continue to asses/re-assess quarterly, or every 6-months depending on environment and contextual maturity.
The Nine Business Outcomes
Everything we do should roll up to one or more of these 9 Business Outcomes. Whether you area developer, tester, product owner, or otherwise, it is important to gain consensus with your stakeholders on which outcomes are and are not a priority in their minds. This then allows delivery teams to move in the direction that our stakeholders across both IT and the rest of the business have in mind…
Let us rise above the average statistic that says 64% of the features we build are rarely or never used. Image how much time and OpEx waste that is ($$). This is what we need to think about as developments teams (Product Owners, Engineers, etc). The goals of Agile isn’t just shortening the feedback loop, but also the learning cycle so we CAN deliver the right thing. More on that in the video link here, David Hawks – User Stories Suck
*Note: The Nine Business Outcomes content is part of the Path To Agility (PTA) program – more information can be found on PTA at the link provided.