Agile Engineering Fluency
Every team is different. But there are patterns.
Do you want to ship your product 50 times per day? What about zero-bug development at low cost? Or live without technical debt? Or learn development skills 25 times faster than industry average? Or base product decisions on real customer data and run low-cost experiments?
Each of these capabilities is delivered by a well-known technique. However, people doing these techniques often fail to get the desired result. There's a reason: each practice can be done in many different ways, each of which requires different supporting practices. People sloppily lump these very different practices under the same name. For example, I've identified 9 completely different practices that people all call "TDD," and 14 meanings of refactoring.
In this session, we will explore an engineering practices dependency graph. While each team has a different context, this graph shows their common patterns. Using it, you can identify your team's actual current state, set goals, and chart out a roadmap to get there.
Outline/structure of the Session
Introduction to key concepts:
- Fluency vs Proficiency
- Outcome, Behavior, Skill, and Mindshift
- Not doing vs Aspiring vs Fluent
Explore the graph (whole group)
- Deep dive into 2-3 elements
- Look at dependency trees
Apply the graph (individuals with pair / small group reflection & support)
- Rate your own team
- Pick goals
- Define first next step
- Recognize the importance of Fluency and start to seek it in your practices.
- Increase precision in defining practices so that you can more easily define what you seek.
- Learn a tool for gaining alignment across your team about improvements to make.
Technical Team Member, Scrum Master / Coach, Team Lead, Mid-level Technical Managers
- Perfect layout would be in rounds. I can work with theater.
- Usual projector, etc.
- I might use flip charts if they happen to be in the room; I can easily make do without.
- No prep needed