Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Transforming chaos to clarity - acm 6.15


Published on

Does your software development feel chaotic?

If you have ever been dissatisfied with your software development flow - if you would like to figure out how to avoid chaos - this is a presentation for you!

Ron Lichty has found himself repeatedly called in as the cavalry to help development groups stuck in confusion. A recognized engineering leader, Ron says, “I've found that I excel at coming in cold, identifying the causes of chaos, untangling organizational knots, creating roadmaps everyone can follow, building communications with other parts of the organization, and getting teams productive and focused on delivery, quality and customers.” He adds, “With a few pointers, any team member can more deeply diagnose their team.”

Ron is author of Managing the Unmanageable: Rules, Tools, and Insights for Managing Software People and Teams, which has been compared by reviewers to Fred Brooks’ The Mythical Man Month. After managing software and product organizations for 25 years, Ron has catered his leadership roles to the needs of his clients, including interim VP Engineering and acting CTO roles. 

Six years ago, Ron began training teams in agile and a year ago training managers in the nuances of managing software people and teams, whether in waterfall environments, or iterative or agile ones.  

If you would like to become an effective agile team member then you'll want to attend this presentation. We’ll look at agile trends, software team pain points, product team solutions, and how every team member contributes to making teams excel.

Drawing from his experience with dozens of product development organizations, Ron will walk through the steps needed to assess your organization’s workings and pull together the elements that will bring order and increased productivity for your business. 

Ron Lichty has been managing and more recently consulting with software development and product organizations for over 25 years, engaged in untangling the knots in software development and transforming chaos to clarity. Originally a programmer, where he earned several patents and wrote two popular programming books, he was hired into his first management role by Apple Computer, which nurtured his managerial growth in both development and product management.

Principal and owner of Ron Lichty Consulting, Inc. (, he has trained teams in scrum, transitioned teams from waterfall and iterative methodologies to agile, and coached teams using agile, iterative and waterfall approaches alike to make their software development "hum". In his continued search for effective best practices, Ron co-authors the annual Study of Product Team Performance.

Ron's most recent book is Managing the Unmanageable: Rules, Tools, and Insights for Managing Software People and Teams - - co-authored with CTO Mickey W. Mantle. Published by Addison Wesley, it has been compared by reviewers to Mythica

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Transforming chaos to clarity - acm 6.15

  1. 1. Transforming Chaos to Clarity Making Your Software Development Hum Ron Lichty, Software Engineering Mgmt
  2. 2. Ron Lichty, Managing Software People & Teams SOFTWEST © Ron Lichty 2
  3. 3. * <-----35% off coupon code: MANTLELICHTY <-----tools, excerpts, more rules of thumb *
  4. 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. 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. 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. 7. No One Can Fix Everything
  8. 8. No One Can Fix Everything • Life is simpler when you plow around the stump.
  9. 9. Chaos Isn’t All Bad
  10. 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
  11. 11. Patterns of Impediments
  12. 12. Categories of Impediments • Process • Culture • Communication • Planning • Rigor
  13. 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. 14. Requirements: Solutions • Communication • Team-building • Agile
  15. 15. 15 Blank space. The Study of Product Team Performance, 2014
  16. 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. 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. 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. 19. Agile: The Challenges • Doing Agile • Being Agile
  20. 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. 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. 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. 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. 24. Task Switching Source: Rob Maher, “Increasing Team Productivity: A project focus creates waste and leaves value on the table”, 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. 25. --Larry Maccherone, The Impact of Agile Quantified, Rally, 2013
  26. 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. 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. 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. 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
  30. 30. Improve Onboarding
  31. 31. Improve Onboarding • Effective Team Onboarding: – 1 of 5 factors • 67% likelihood high level team performance
  32. 32. 32 Only 4% of organizations indicate they have a best practice onboarding product team members Improve Onboarding
  33. 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. 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. 35. Ron Lichty Consulting • Mentoring, coaching, interim VP Engineering, acting CTO: –, • The book: Managing the Unmanageable: Rules, Tools & Insights for Managing Software People & Teams – <-----tools, excerpts, more rules of thumb – <---35% off coupon code: MANTLELICHTY • The annual study: The Study of Product Team Performance – <----- the studies are free downloads • Training: Zero to Agile in Three Days The Agile Manager Managing Software People and Teams © Ron Lichty 35
  36. 36. Q&A Ron Lichty