1.
Transforming Chaos to Clarity
Making Your Software Development Hum
Ron Lichty, Software Engineering Mgmt
RonLichty@sbcGlobal.net

2.
Ron Lichty,
Software Engineering Management
SOFTWEST

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.
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.
Issues and Symptoms
• Turnover
• Productivity
• Handoffs
• Process glitches
• Quality
• Single points of failure
• Communication breakdowns
• Unfeasible sales
• Sources of disruption and interruption

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.
Systems to Diagnose
• Requirements
• Roadmaps
• Motivation and Urgency
• People and Teams
• Project Planning
• Technical Debt
• Communication
• Development Process

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.
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.
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.
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.
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.
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.
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.
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.
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.
Systems to Diagnose
• Requirements
• Roadmaps
• Motivation and Urgency
• People and Teams
• Project Planning
• Technical Debt
• Communication
• Development Process

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.
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.
Q&A
Ron Lichty
RonLichty@sbcGlobal.net
http://ronlichty.blogspot.com/