SlideShare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our User Agreement and Privacy Policy.
SlideShare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our Privacy Policy and User Agreement for details.
Successfully reported this slideshow.
Activate your 14 day free trial to unlock unlimited reading.
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/
0 likes
Be the first to like this
Views
Total views
7,970
On SlideShare
0
From Embeds
0
Number of Embeds
5,149
You have now unlocked unlimited access to 20M+ documents!
Unlimited Reading
Learn faster and smarter from top experts
Unlimited Downloading
Download to take your learnings offline and on the go
You also get free access to Scribd!
Instant access to millions of ebooks, audiobooks, magazines, podcasts and more.
Read and listen offline with any device.
Free access to premium services like Tuneln, Mubi and more.