Leading Software Development TeamsARNO HUETTER(Based on a presentation held at GRZ IT Center, Austria)

About the Author

Arno Huetter Arno wrote his first lines of code on a Sinclair ZX80 in 1984.

Over the years, he has been programming in C/C++, Java and C#, and also did quite some database development.

Today he is Development Lead at Dynatrace (APM vendor).

Leading Software Development Teams

“The major problems of our work are not so much technological as sociological in nature.“

(DeMarco, Lister in: „Peopleware“)

Cornerstones of Leadership Behavior „Leadership, like software, is built upon a foundation. For software,

the foundation is the architecture. For leadership, it‘s your character.“ (Rainwater, H.)

Understand: The battle for market share is won by leaders who know the nature and methods of software development. People who "see the forest AND the trees".

Communicate: Be an evangelist, convey enthusiasm, share knowledge. Good communicators are also good teachers. Be careful when making unprepared, casual remarks.

Cornerstones of Leadership Behavior Delegate: Select the right people for the right tasks. You can delegate tasks,

but not speed. One effective form of delegation: Senior+Junior pair programming.

Check: No expectation without checking. Daily builds. Automated tests. Obtain feedback from employees. Code reviews. Weekly project status meetings. Four eyes principle. Documentation.

Participate: Participation of leaders in programming and tests (limited in time). The best leaders are not only coaches on the sideline, but are part of the team. Important signal to employees.

Cornerstones of Leadership Behavior Mentor: Enhance problem-solving skills of employees. Attract future leaders.

Your own effort will have multiplier effect. Knowledge sharing.

Reward: Compensation for extraordinary commitment. Fair, reasonable and timely procurement. Several forms possible (financial bonuses, concert tickets, etc).

Revise: Prevent sloppy code and inadequate solutions. Suggest how to fix things, support implementation, aim for team learning effect. No blame game, but identify employees not up to the task. Bring them up to speed, and if that doesn’t work, replace them. Be a role model - leader’s negligence damages quality awareness.

Cornerstones of Leadership Behavior Anticipate: Look beyond the day-to-day business, create an image of the

future and inspire and motivate employees.

Adapt: Adapt behavior to the problem at hand, accept challenges, learn new skills. Problems are also opportunities.

Win Followers Sense of duty: Loyalty to team and product. Have pride on what has been achieved

so far. Be part of a winning team.

Admiration: People will follow leaders whom they admire. Keep consistency in management style, leadership effectiveness and in communication with employees.

Environment: Create a working environment which by itself is already rewarding.

Knowledge: Knowledge is power, especially in software development. Be and remain an expert, share knowledge.

Other forces: Market and competitive situation, payment.

Developer Types: The Good The Architect: Works on large-scale tasks, problem solving by abstraction.

Danger: Disconnected with developers and their needs.

The Designer: Works intuitively, solves problems by code. Danger: Lack of documentation.

The Artist: Creative work, builds intuitive user interface out of requirement spec. Risk: Inefficiency and lack of design.

The Engineer: Handles complexity by reduction. Risk: Lack of flexibility if requirements change.

Developer Types: The Good The Scientist: Problem solving according the principles of theoretical

computer science, purists. Danger: Impractical solutions.

The Speed Demon: Rapid implementation, adherence to the timetable at all costs. Danger: Hidden defects.

Developer Types: The Bad The Sloppy: Faulty code, poor structure, violation of coding conventions, no tests.

The Intimidated: Missing own initiative, doesn’t know how to start, can't deal with incomplete information.

The Amateur: Lack of training and experience, overestimation of one's capabilities.

The Ignorant: Close-minded towards technological innovations, doesn’t want training, doesn’t embrace change.

The Salad Cook: Badly proportioned blend of Engineer, Sloppy and untalented Artist.

Software Craftsmanship Software development is more labor-intensive than ever before.

Developers are often considered the "most expensive resource”.

Countermeasure attempt #1: Quick training programs: FAILED. Software development requires more than the mere knowledge of the syntax of a programming language.

Countermeasure attempt #2: CASE tools: FAILED. Forced developers to apply one way of model-building and of (what was left of) coding.

Code is still the best abstraction model. De-qualification and industrialization are wrong approaches. Automation is useful, but has limits.

Software Craftsmanship Software development as a craft. Mastery of a craft is only possible after

years of learning and practicing.

Once the craft is no longer actively exercised, skills will dwindle.

Apprenticeship: Situational learning. Execute easy tasks unescorted, more complex tasks under the supervision of the master, Learning by example.

Don't see developers as "most expensive resource", see them as your most important asset!

Successful Teams A cult of quality: Quality awareness is a strong team catalyst. Only works in

conjunction with entrepreneurial long-term thinking.

A hint of elitism: People need the feeling to be unique in some way. Corporation-wide consistency might seem desirable at a management level, but is counterproductive.

Allow heterogeneity: It's OK to not be a corporate clone. Add value, e.g. women in otherwise male-dominated development teams.

Successful Teams Successful teams should stick together. Take the momentum for the

next project after completion.

Specify direction at the strategic level, but avoid micro-management: Identify key employees and equip them with corresponding liberties. "Flow of free electrons".

Destructive Forces Defensive management: Decision making without consulting employees,

shows lack of trust.

Bureaucracy: Pointless production of paper, actual work comes in short.

Physical separation: Distribution of a project team. Phone calls rather than direct interaction.

Fragmentation of work time: Allocation to multiple projects.

Destructive Forces Compromise on quality: Reasoning for cost reduction, but actually

increases costs. Low employee identification.

Artificial deadlines: Most probably not taken seriously anyway.

Inspirational slogans: Triumph of the outer form over the inner substance.

Permanent extra hours: Can not be delivered by everyone (consider family situations, etc).

Motivational Factors Two-Factor Theory (according to Frederick Herzberg)

Hygiene factors: Prevents emergence of discontent by means as income, safety, interpersonal relations.

Motivation factors: Motivation to perform, e.g. work content, recognition, responsibility.

Motivation factors are of particular importance for developers who identify with their profession. Usually these are the employees that are key for successful software projects.

Set up for success: Many software projects fail, good developers do not like to fail and therefore look for an auspicious environment.

Have professional project management, be a competent development partner, ensure quality consciousness.

Motivational Factors Excellent people management: Know your staff, include team in decision-

making, show loyalty to employees.

Variety in tasks and constant learning: Software developers likely have chosen their profession exactly for those reasons.

Problem-solving: Programmers love challenges, e.g. voluntary nightly coding sessions until a problem is solved. In contrast, being under-challenged can have fatal effects.

Find hearing: Developers usually sit in the front trenches, and might be the first ones to register looming problems. When they speak out, they should be heard.

Motivational Factors Recognition: Being part of a successful product is motivating by its own

means. In addition, individual recognition should be articulated frequently.

Take part in something that makes a difference: “Conquer the world”. Get rid of manual routine work, improve communication. Don’t produce paper, produce a cool and successful product.

Non-bureaucratic decision making: Let employees take part in decision-making without having a committee convened for every small thing.

Deal with contaminated projects: Maintenance of legacy code or working under a lot of constraints is not satisfying in the long term.

Hire the Right People "The most important practical finding involves striking individual differences in

programmer performance“ (Glass, R.)

"Within a group of programmers, there may be on order of magnitude difference in capability" (Schwartz, J.)

"A few good people are better than many less skilled people" (Davis, A.) "The best performers are clustering in some organizations, while the worst are

clustering in others" (DeMarco, Lister)

But: Large skillset deviation even among graduates of the same university. Formal qualification criteria are insufficient. It’s the individual drive that matters most.

Smart and Gets Things Done

Interview Techniques Several interview rounds, including a test in practical programming. Form a

hiring committee, one NO-vote implies "no hire".

No prejudices (e.g. due to formal education or the opinions of others).

Introduction: Relax situation.

Open question: Let candidate talk about a project he has worked on.

Can he/she explain more complex relationships easily? Is he/she enthusiastic? Has he/she overcome difficulties by own initiative?

Interview Techniques Solve a simple programming problem: Separate the wheat from the chaff.

Quick but elegant solution preferred.

Solve a difficult problem of programming: "Understanding pointers is not a skill, it's an aptitude". The approach is more important than the solution. Spark discussion.

Applicant’s questions.

Chose the Right Employer - The Joel Test Do you use source control? Can you make a build in one step? Do you make daily builds? Do you have a bug database? Do you fix bugs before writing new code? Do you have an up-to-date schedule? Do you have a spec? Do programmers have quiet working conditions? Do you use the best tools money can buy? Do you have testers? Do new candidates write code during their interview? Do you do hallway usability testing?

Working Environment and Productivity

Working Environment and Productivity Separate offices rather than have cubicles: Plan for two to four persons

per office with sufficient space. Focus on people and their needs. Workplace equipment costs are low compared to human resource costs.

Freedom instead of uniformity: People need individuality (up to a certain level).

Have phone-free times, avoid interruptions: "You never get anything done around here between 5 and 9".

"The Flow": Work under high concentration, maximum effectiveness (touch of euphoria), only possible after a certain period of diving into a task.

Sources DeMarco, Lister: “Peopleware”

Glass, Robert L.: “Facts and Fallacies of Software Engineering”

McBreen, Pete: “Software Craftsmanship”

Rainwater, J. Hank: “Herding Cats: A Primer for Programmers Who Lead Programmers”

Spolsky, Joel: “Joel on Software”

Sources Spolsky, Joel: “Smart & Gets Things Done: Joel Spolsky's Concise Guide to

Finding the Best Technical Talent”

Walling, Rob: "Nine Things Developers Want More Than Money“, http://www.softwarebyrob.com/articles/Nine_Things_Developers_Want_More_Than_Money.aspx

Weinberg, Gerald M.: “Becoming a Technical Leader – An Organic Problem-Solving Approach”

Weinberg, Gerald M.: “The Psychology of Computer Programming”

Thank you!Twitter: https://twitter.com/ArnoHuBlog: http://arnosoftwaredev.blogspot.com