Some notes from a short presentation I gave on building quality software development teams:
- Effective teams start with good people. A business is not a charity and cannot wait for people to grow into the role required of them. Intelligence and inherent motivation cannot be taught. These and many other aspects must be screened for when hiring.
- But hiring good people is not enough. Getting the most of a development team requires certain environmental factors. I have organized them into three areas: internal/motivational, structural/organizational, and interpersonal/communication. Sometimes they will conflict with practical considerations, but we ought to take them consideration whenever possible.
Motivation
- Instill a sense of professional pride
- Developers should take part in the technical design
- Provide interesting, challenging work
- Developers should own the technical solution
- Technical architects should be part of the development team
- Respect the developers time
- Provide a quiet environment dedicated to development work
- Buy the best tools for the jobs – powerful computers, large monitors, etc.
- Reward learning and exploration
- Take (reasonable) risks with new technologies
- Schedule time for self-education and information sharing
- Create a sense of project ownership
- Delegation “ownership” of functional parts to individual people
- Assign developers responsibility for follow-up maintenance (don’t just hand it off to a maintenance team)
Structure
- Hold people accountable for their work:
- Use a work unit tracking system (JIRA, etc)
- Make task status publicly visible
- Hold daily stand ups (Scrum)
- Consider a public scrum board
- Provide clear project requirements
- Lean development approach
- No time-wasting tasks (useless documentation)
- Isolate developers from unrelated tasks (no business interruptions)
- Hold high expectations
- Monitor quality of work with code reviews
- Regular training & information sharing sessions
- Set consequences for bad work
- Set well defined deadlines
- Don’t set arbitrary deadlines, but all work should have a deadline
- Developers should have input on deadlines for their work units
Team Communication
- Instill a sense of collective ownership of the project
- Hold architectural education sessions
- High-bandwidth communications
- Entire team should work in physical proximity
- Make quality visible
- Use continuous integration and automated testing to provide immediate feedback of quality
- Developers should fix their own bugs
- Track quality over time
- Explicit mentor roles
- Mentor roles should be explicitly defined
- Mentoring time should be scheduled into the project
Interesting not an iota about innovation and innovators.
Nor what EXPLICITLY describes, encourages and drives INNOVATION as opposed to something one points to and talks about after the fact!
None of what I read in your piece would seem to instill actual worker buyin nor integrate laissez faire Capitalism nor address the fact that Quality (Defect Management) Hampers Industry.
For those who really want to actually embrace openness, informality, boundaryless, high involvement, self-confidence, productivity, creating a learning culture might I suggest?
Boundless
https://connect.liberty.me/boundless/
PS As implausible as that tall order sounds, the solutions to the above issues actually had valuable application in making it possible for me to rapidly and easily turn a company from multi million dollar loses into multi million dollar profits with a culture, operations and software that actually supported innovation.