Transforming Chaos To Clarity, Ron Lichty

20
Transforming Chaos to Clarity Making Your Software Development Hum Ron Lichty, Software Engineering Mgmt [email protected]

description

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

Transcript of Transforming Chaos To Clarity, Ron Lichty

Page 1: Transforming Chaos To Clarity, Ron Lichty

Transforming Chaos to ClarityMaking Your Software Development Hum

Ron Lichty, Software Engineering [email protected]

Page 2: Transforming Chaos To Clarity, Ron Lichty

Ron Lichty,Software Engineering Management

SOFTWEST

Page 3: Transforming Chaos To Clarity, Ron Lichty

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?!

Page 4: Transforming Chaos To Clarity, Ron Lichty

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

Page 5: Transforming Chaos To Clarity, Ron Lichty

Issues and Symptoms• Turnover• Productivity• Handoffs• Process glitches• Quality• Single points of failure• Communication breakdowns• Unfeasible sales• Sources of disruption and interruption

Page 6: Transforming Chaos To Clarity, Ron Lichty

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

Page 7: Transforming Chaos To Clarity, Ron Lichty

Systems to Diagnose• Requirements• Roadmaps• Motivation and Urgency• People and Teams• Project Planning• Technical Debt• Communication• Development Process

Page 8: Transforming Chaos To Clarity, Ron Lichty

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?

Page 9: Transforming Chaos To Clarity, Ron Lichty

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

Page 10: Transforming Chaos To Clarity, Ron Lichty

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?

Page 11: Transforming Chaos To Clarity, Ron Lichty

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

Page 12: Transforming Chaos To Clarity, Ron Lichty

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

Page 13: Transforming Chaos To Clarity, Ron Lichty

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

Page 14: Transforming Chaos To Clarity, Ron Lichty

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

Page 15: Transforming Chaos To Clarity, Ron Lichty

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”

Page 16: Transforming Chaos To Clarity, Ron Lichty

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

Page 17: Transforming Chaos To Clarity, Ron Lichty

Systems to Diagnose• Requirements• Roadmaps• Motivation and Urgency• People and Teams• Project Planning• Technical Debt• Communication• Development Process

Page 18: Transforming Chaos To Clarity, Ron Lichty

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

Page 19: Transforming Chaos To Clarity, Ron Lichty

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

Page 20: Transforming Chaos To Clarity, Ron Lichty

Q&A

Ron [email protected]

http://ronlichty.blogspot.com/