transforming chaos to clarity, ron lichty
DESCRIPTION
Presentation to PMI - Wine Country Chapter- 4/8/2010: Transforming Chaos to Clarity: Making Your Software Development HumTRANSCRIPT
Transforming Chaos to ClarityMaking Your Software Development Hum
Ron Lichty, Software Engineering [email protected]
Ron Lichty,Software Engineering Management
SOFTWEST
Poll: Software Developmentin 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?!
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
Issues and Symptoms• Turnover• Productivity• Handoffs• Process glitches• Quality• Single points of failure• Communication breakdowns• Unfeasible sales• Sources of disruption and interruption
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
Systems to Diagnose• Requirements• Roadmaps• Motivation and Urgency• People and Teams• Project Planning• Technical Debt• Communication• Development Process
Optimize YourRequirements 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?
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
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?
Develop Motivation andCommunicate 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
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
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
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
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”
Optimize Process
• Just about any process is better than noprocess. – Mark Ginnebaugh– The exception: process for process’ sake
• I’m a fan of– “Just-Enough Process”– Agile– baby steps
Systems to Diagnose• Requirements• Roadmaps• Motivation and Urgency• People and Teams• Project Planning• Technical Debt• Communication• Development Process
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
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