Transforming chaos to clarity - acm 6.15
Download as PPT, PDF0 likes6,631 views
The document discusses strategies for improving software development efficiency by transforming chaos into clarity through better communication, team-building, and agile methodologies. It highlights common disruptions and the importance of focusing on requirements, prioritizing tasks, and optimizing onboarding processes. The document emphasizes that while chaos can hinder productivity, it can also foster innovation when managed effectively.
Transforming chaos to clarity - acm 6.15
- 1. Transforming Chaos to Clarity Making Your Software Development Hum Ron Lichty, Software Engineering Mgmt Ron@RonLichty.com
- 2. Ron Lichty, Managing Software People & Teams SOFTWEST © Ron Lichty 2
- 3. * http://InformIT.com/managing <-----35% off coupon code: MANTLELICHTY http://ManagingTheUnmanageable.net <-----tools, excerpts, more rules of thumb *
- 4. Poll: Software Development in Disarray? • Who has seen chaos in a product group? • Who has seen chaos in your current group? • Who feels like development is running rough? • Who is suffering from organizational knots? • Anyone’s development organization running so smoothly it doesn’t need tuning?
- 5. Define Success • What are you trying to accomplish • How do you know you're not • How will you know when you get there • Assess what’s working • Assess the issues and the symptoms – Every organization is unique
- 6. Issues and Symptoms • Turnover • Productivity • Handoffs • Process glitches, Bottlenecks • Quality • Single points of failure • Communication breakdowns • Unfeasible sales • Heroes vs Teamwork • Sources of disruption and interruption
- 7. No One Can Fix Everything
- 8. No One Can Fix Everything • Life is simpler when you plow around the stump.
- 9. Chaos Isn’t All Bad
- 10. Chaos Isn’t All Bad • Innovation often emerges from “chaos” – Brainstorming – Thinking outside the box • Don’t eliminate useful chaos • Just look for the pings and the misfires – Let’s make our product engines hum • regardless of where creativity and pivots take us
- 12. Categories of Impediments • Process • Culture • Communication • Planning • Rigor
- 13. Requirements: Bridge the Gap • GIGO • Programmers: – who has received an exceptional set of rqmts? – what was the programming experience like? – how did it differ from the usual? • How good are your requirements? – How unambiguous? • Do your requirements change? • Are they ever complete?
- 14. Requirements: Solutions • Communication • Team-building • Agile
- 15. 15 Blank space. The Study of Product Team Performance, 2014
- 16. Requirements: Fix Interdepartmental Communication 16 Blank space. The Good News 10% of product teams function as a seamless team. The Bad News 90% of product teams don’t. How would you rate your product team’s cross-functional collaboration, trust and communication?
- 17. Requirements: Fix Interdepartmental Communication • Build trust relationships • Product Mgmt & Engineering: collaboration • Establish processes for your partners to fit • Communicate, communicate, communicate • Never succumb to “them vs. us” • Avoid the “blame game”
- 18. Requirements: Solutions • Agile – Teamwork: developers, testers, product managers • Co-located, with a focus on team interaction – A single Product Owner – Just enough requirements • The entire project at a high level • Prioritized by business value • Details “just in time” – Requirements very stable during sprints • Change occurs in the sprint boundaries
- 19. Agile: The Challenges • Doing Agile • Being Agile
- 20. Doing Agile: Practices • Common Definition of Done • Timeboxing Standups (and every meeting) • Standups: three questions • Retrospectives • Rapid Relative Sizing • Estimating = ƒ(Size, Velocity, Stable teams) • Sizing, Estimating Committing≠ • Shippable software every iteration
- 21. Being Agile • It’s the values and the principles • Half done is not done • Standups: How are we doing against our plan? • Being empowered and self-organizing • Being a learning organization • Delivering highest customer value every sprint • Building trust and respect with each other
- 22. Focus • Macro level • “When everything is a priority, nothing is a priority.” --Sheila Brady, Apple • Limit task switching • Micro level • Avoid “multitasking” • Limit interruptions
- 23. Task Switching Source: Mike Cohn, citing Steven C.Wheelwright and Kim B.Clark (1993), Revolutionizing Product Development: Quantum Leaps in Speed, Efficiency and Quality, 1993
- 24. Task Switching Source: Rob Maher, “Increasing Team Productivity: A project focus creates waste and leaves value on the table”, Scrum.org Whitepapers taking communications overload into account Rob Maher, surmising that email, texts, IRC, chat, smartphones together represent a second “task” Source: Mike Cohn, citing Steven C.Wheelwright and Kim B.Clark (1993), Revolutionizing Product Development: Quantum Leaps in Speed, Efficiency and Quality, 1993
- 25. --Larry Maccherone, The Impact of Agile Quantified, Rally, 2013
- 26. Focus • Macro level • “When everything is a priority, nothing is a priority.” --Sheila Brady, Apple • Limit task switching • Micro level • Avoid “multitasking” • Limit interruptions It’s not that we don't have enough time. We have too much to do. -- Chet Hendrickson
- 27. Smart Project Planning • Show demonstrable progress frequently • Get the risky stuff done first – the UI should always be high on the risk list • Deliver the highest customer value first • Be first / be ready to integrate / be early • Don’t over-engineer
- 28. Pay Down Technical Debt! • What’s “technical debt”? • Result: interest accrues • Solutions? – Pay down debt – Prioritize – Refactor – Write tests – Embrace Test Driven Development (TDD)
- 29. Optimize Process • Just about any process is better than no process – Mark Ginnebaugh – The exception: process for process’ sake • I’m a fan of – “Just-Enough Process” – Agile – baby steps
- 31. Improve Onboarding • Effective Team Onboarding: – 1 of 5 factors • 67% likelihood high level team performance
- 32. 32 Only 4% of organizations indicate they have a best practice onboarding product team members Improve Onboarding
- 33. The Bottom Line • Chaos is common • It’s really a series of challenges • It’s a series of improvement milestones • Each of them can be transformed – Likely each new hum will reveal the next ping • Like peeling an onion or climbing a mountain
- 34. In the beginning, everyone will talk about scope, and budget, and schedule, but in the end, nobody really cares about any of those things. The only thing they care about is this: People will love your software, or they won’t. So that’s the only criterion to which you should truly manage. —Joseph Kleinschmidt
- 35. Ron Lichty Consulting • Mentoring, coaching, interim VP Engineering, acting CTO: – http://ronlichty.com, Ron@RonLichty.com • The book: Managing the Unmanageable: Rules, Tools & Insights for Managing Software People & Teams – http://ManagingTheUnmanageable.net <-----tools, excerpts, more rules of thumb – http://InformIT.com/managing <---35% off coupon code: MANTLELICHTY • The annual study: The Study of Product Team Performance – http://ronlichty.com/study.html <----- the studies are free downloads • Training: Zero to Agile in Three Days The Agile Manager Managing Software People and Teams © Ron Lichty 35
Editor's Notes
- #4: Managing the Unmanageable: Rules, Tools, and Insights for Managing Software People and Teams http://ManagingTheUnmanageable.net &lt;-----tools, excerpts, more rules of thumb http://InformIT.com/managing &lt;-----35% off coupon code: MANTLELICHTY
- #24: Mike Cohn: citing Steven C.Wheelwright and Kim B.Clark (1993), Revolutionizing Product Development: Quantum Leaps in Speed, Efficiency and Quality, 1993
- #25: Mike Cohn: citing Steven C.Wheelwright and Kim B.Clark (1993), Revolutionizing Product Development: Quantum Leaps in Speed, Efficiency and Quality, 1993