Successfully reported this slideshow.

Transforming Chaos To Clarity, Ron Lichty

0

Share

Loading in …3
×
1 of 20
1 of 20

More Related Content

Related Audiobooks

Free with a 14 day trial from Scribd

See all

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/

×