Transforming Chaos To Clarity, Ron Lichty

4,745 views

Published on

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

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
4,745
On SlideShare
0
From Embeds
0
Number of Embeds
2,478
Actions
Shares
0
Downloads
28
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

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/

×