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, Ron Lichty

5,752 views

Published on

Presentation to PMI - Wine Country Chapter- 4/8/2010: Transforming Chaos to Clarity: Making Your Software Development Hum

  • Be the first to comment

  • Be the first to like this

Transforming Chaos To Clarity, Ron Lichty

  1. 1. Transforming Chaos to Clarity Making Your Software Development Hum Ron Lichty, Software Engineering Mgmt RonLichty@sbcGlobal.net
  2. 2. Ron Lichty, Software Engineering Management SOFTWEST
  3. 3. Poll: Software Development in Disarray? • Who has seen chaos in a product group? • Who has seen chaos in your current group? • Who feels like your devt is running rough? • Who is suffering from organizational knots? • Anyone have a development organization that doesn't feel chaotic right now?!
  4. 4. 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
  5. 5. Issues and Symptoms • Turnover • Productivity • Handoffs • Process glitches • Quality • Single points of failure • Communication breakdowns • Unfeasible sales • Sources of disruption and interruption
  6. 6. Chaos Isn’t All Bad • Don’t eliminate it entirely • Going offroad may seem chaotic – Innovation can spring from chaos • Look for the pings and the misfires – Make your product engine hum • whether you’re cruising the highway or off-road • Tune the engine, not the route
  7. 7. Systems to Diagnose • Requirements • Roadmaps • Motivation and Urgency • People and Teams • Project Planning • Technical Debt • Communication • Development Process
  8. 8. Optimize Your Requirements Process • 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? – ever gotten to delivery only to find out there was another db field desired? • Do your requirements change?
  9. 9. Requirements: Solutions • Agile – Just enough requirements – Details emerge as needed – Requirements prioritized by business value – Co-location and team interaction – Priorities/requirements can change on sprint boundaries • Adopt some Agile practices – Requirements in the form of use cases / stories – Co-location • Automated tools
  10. 10. How’s Your Roadmap? • Why do you need a roadmap? • What’s a roadmap look like? • How do you create one? • What do you do with it? • Why do you need a roadmap?
  11. 11. Develop Motivation and Communicate Urgency • How is developer motivation measured? – Remember it’s a marathon, not a sprint • What motivates programmers? – Are you communicating your reality? – Are you communicating their impact? • Enable them to do their best work – Prioritization – Communication – Cadence – Rally
  12. 12. People and Teams • Most problems are not people – but some are – Occasional problem employees – Employees who need to be mentored into roles • Software development is a team sport
  13. 13. Smart Project Planning • Deliver 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
  14. 14. Get Out of Technical Debt • What’s “technical debt”? – Shabby, rundown areas of code – Untested code / lack of automated tests – Undocumented code – Brittle design – Difficult to maintain, change, extend • Expensive to debug • Result: interest accrues • Solution? – Pay down debt: Prioritize, refactor, write tests, do TDD
  15. 15. Fix Interdepartmental Communication • Build trust relationships • Product Mgmt & Eng. Mgmt: collaboration • Establish processes for your partners to fit • Communicate, communicate, communicate • Never succumb to “them vs. us” • Avoid the “blame game”
  16. 16. 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
  17. 17. Systems to Diagnose • Requirements • Roadmaps • Motivation and Urgency • People and Teams • Project Planning • Technical Debt • Communication • Development Process
  18. 18. Other Systems to Diagnosis • Lots of other systems: – Meetings – Quality • Development’s quality • QA • TDD – UI – Risk – Managers who need mentoring – ...and a long list more
  19. 19. 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
  20. 20. Q&A Ron Lichty RonLichty@sbcGlobal.net http://ronlichty.blogspot.com/

×