Seasoned project managers will tell that delivery of software is result of many trade offs. The main trade off is between Time (when project will finish) and Scope (how much will be done). This post will show that using right tools you could gain improvement for both variables.

While it is possible to create orderly step-by-step process for increasing productivity of software teams, it will never be ideal – too many variations and situations will hinder it usefulness. I believe in set of useful tool that could be combined to craft custom optimal solution.

Strategies

There are several strategies that lead to increase in productivity – how many units of scope software team can produce within fixed time.

1. Increase Capacity (Capacity) – increase capacity by hiring more people or increasing work hours
   • productivity is increased as result of more resources and hours available
2. Improve Value Stream (Value) – increase added business value on each step and reduce waste and overhead
   • productivity is increased as result of optimized delivery of value
3. Adaptat to Reality  (Adaptation)– learn from practice and mistakes, validation of ideas by reality, adapt to changing situation
   • productivity increased as result of early corrections and improving how things are done
4. Empower Individuals (Individuals) – boost people knowledge, skills, morale and focus
   • productivity is increased as result of higher individual performance and motivation
5. Enhance Communication (Communication) – improve communication and mutual understanding inside and outside of the team
   • productivity is increased as result of availability of necessary information, clarity of what should be done and exchange of ideas for implementation
6. Organize Better (Organization) –  structure team and assign roles for better coordination and decision making
   • productivity is increased as result of better decisions and focus on important areas
7. Expand Expertise (Expertise) – increase range of skills and services offered by team
   • productivity is increased as result of better execution of necessary project activities
8. Scale Externally (Externality) – outsourcing and involvement of external communities
   • productivity is increased as result of involvement of more people outside of team
9. Tame Complexity (Design) – manage complexity and provide simple and well designed solutions
   • productivity is increased as result of reducing complexity burden on software development
10. Preserve Quality (Quality) – use defensive tactics to ensure high quality
    • productivity is increased as result of preventing system flaws and reduced effort to fix bugs

• People-oriented – people are the creators of software and have major effect on output
• Process-oriented – the way how people work has significant impact on outcome
• Development-oriented – development practices and approach to the system implementation matters a lot

Read full post >>

A software project is a creative, unique and therefore unpredictable endeavor. We are not building the same thing over and over again, but solve new problems, address increasing demands and use perpetually changing technologies. Under these conditions, people – smart, creative and productive – are the most important factor of success . Software development process can only support and compliment these people, but it cannot guarantee success alone and make the factor of people negligible.

But, business wants predictable, reliable and successful results. I bet they don’t want to be at mercy how cards are shuffled in their talented development team. The answer is in establishing a process that increases chances of success and aligned with present nature of software development (unpredictable, empirical and heavily dependent on people).

The Toyota Way can be a great example that worth to learn. Toyota evolved from a small looming equipment shop to the largest car manufacturing company. The main foundation of successful growth is the system of few core principles that enables best quality, high productivity, lowest cost, shortest time and long-term success.
Read full post >>

What you are as a person is far more important that what you are as a basketball player. – John Wooden

People are amazing, surprising and interesting. They change reality with power of thought and make things happen. What is most exciting – all people are completely different in their attitudes and behavior. But this comes with price – it is difficult to understand people and even more difficult to find the best way to deal with them.
Many people, who see programmers as extensions of their computer systems, will be surprised to discover that programmers are amazing individuals too. Programmers exhibit similar to other people behavior, they have different personalities and need individual approach.

I offer in this post a simple theory about Three Dimensions of a Software Programmer that could help to put relations with these individuals on some rational basis.

Axioms

There are two basic axioms in foundation of the theory

1. Constancy – some programmers consistently outperform others under same conditions.
2. Variability – performance of a programmer varies under different conditions.

Read full post >>

Surprisingly, Jim Highsmith, respected agile guru, argues against one of the core agile principles of self organization, associating it with anarchy. On the contrary, surprisingly again, the Army experts, Don Vandergriff and George Reed, embrace ideas of adaptability and decentralization in traditionally command-oriented military units.

Jim Highsmith says:

“I’ve been thinking recently that the term “self-organizing” has outlived its usefulness in the agile community and needs to be replaced. While self-organizing is a good term, it has, unfortunately, become confused with anarchy in the minds of many. Why has this occurred? Because there is a contingent within the agile community that is fundamentally anarchist at heart and it has latched onto the term self-organizing because it sounds better than anarchy.”

Army experts say:

“A culture of adaptability is one that accepts a lack of absolute control over events on and off the battlefield. Implementation requires revisiting mission orders or trust tactics. It necessitates raising the bar in the education, training and coaching of leaders and soldiers. It seems trite to suggest that an adaptive institution will reward those who, when the need arises, act without waiting for orders, but this also necessitates a climate that is supportive of those who act and fail to achieve stellar results. Instead of seeking perfection or optimum solutions, operators will find a solution that works locally and then exploit those results as a continual evolution facilitated by an organization adept at receiving and communicating such information.”

Read full post >>

Programmer’s Side

Programmers in the software team work well together, trust and support each other. But they don’t talk about their salaries – the most important reason why they work for the company. It is taboo. Tell them that one of their fellow programmers earn 50% more than others. You’ll see smiles disappear, people don’t look at each other and become silent. They will rebound, but these things leave scars on team morale and cohesiveness. Feel of unfairness is not the best companion in the software development.

But why does compensation is so important and sensitive for us?

• We work to live. We spend more than half of our conscious adult life earning money on work. We need money to live. Money enable for us almost everything material in this world. Any non-material incentives cannot compensate insufficient money income.
• Money are social status. The better compensation means you worth more and more attractive from social and even biological perspective. People strive for relative prosperity. They could accept less themselves than see a rival get more.

Read full post >>

4 Effective Leadership Styles in Software Development

What should be the qualities of the best leader for the software team: strong decisive knowledgeable or quiet supportive cooperative? Best leaders have two main concerns – people and getting things done (Blake and Mouton’s Managerial Grid). Both concerns have cumulative effect – high concern for people makes them motivated and therefore more productive, high concern for production creates sense of achievement and makes people more satisfied at work.

However, there is no one leadership style that suits all situations, projects and individuals. There are 4 main leadership styles (based on The Hersey and Blanchard model and Vroom and Yetton’s Normative Model), which could be effectively used in software development: The Commander, The Coach, The Supporter and Self-Organization.

Read full post >>

“There are very few true artists in computer programming, most are just house painters.” – Tim Bryce’s Law

Management consultant Tim Bryce doesn’t like programmers. Many programmers don’t like him either (here, here, here, here and probably in many other places).
Mr. Bryce’s view of programmers:

• programmers often bamboozle others and heighten their own self-importance
• the average programmer has a lower IQ than any other worker with a college degree
• programmers show signs of sloppiness and mental laziness
• they appear disorganized to make it difficult to judge how they are progressing on their work effort and reveal inadequacies in workmanship.
• the typical programmer often laments he/she is being overworked, underpaid, and unappreciated.
• to the programmer’s credit, they usually possess a curiosity about technological developments. However, this must be carefully nurtured by management – too much information may distract programmers from their job.

Responses on Mr. Bryce’s post (referenced above) provide many excellent points why Mr. Bryce is wrong. However, I want to comment points where he is probably right. Also I want to understand why some management consultants with more than 30 years of experience could have such view? Certainly, I reject Freudian view that an unknown programmer hurt feelings of Mr.Bryce in childhood (the main reason is that at this time the world had only few programmers and all of them are known).

Mr.Bryce’s target audience is not programmers (whose low IQ would probably prevent understanding his Theory P anyway), but IT managers and business decision makers. The underlying premise of Theory P is: “The more effectively we manage the people who program the computer, the better we can utilize the systems to support the information needs of the business”. This theory is not about live people, but about pragmatic business and lets consider the theory from this perspective. There are three points where Mr. Bryce could be partially right.

Read full post >>

If you want to build a ship, don’t herd people together to collect wood and don’t assign them tasks and work, but rather teach them to long for the endless immensity of the sea. – Antoine de Saint-Exupery

I have a dream about a company that always makes users happy. The company that quickly builds high quality, simple and usable software that fully meets user needs. The company that reacts rapidly on customer demands, anticipates new needs and immediately use these opportunities. The company where people are happy, motivated and could realize their potential, dreams and life goals. The company that is successful on market and in the hearts of users, investors and employees. The Ideal Software Company.

The Barriers

What are the main problems with building software? What are contributing factors to these problem? What prevents many existing software companies from being ideal?

1. Unclear, incomplete or misinterpreted user needs. The software programs often don’t solve needs on adequate level, have bad usability and contain many unused features.
2. Difficulty to estimate required effort. Missed deadlines, doomed schedules and budget overruns are the common deceases in software development.
3. Inability to adopt to changes. Often it is even impossible to estimate effort at the beginning as many things are changing during the course of the project: customer needs, performance requirements, business context. But for many software companies these changes still bring chaos to their projects.
4. Poor, rigid or low quality solutions. Implementation defines project success. Talent, experience or knowledge are necessary to build good solutions, and they are often missing in the project teams.

The main reasons for these problems

1. Top-down decisions – only few people make decisions with limited information, lack of feedback and independent information
2. Poor aggregation of information from different sources
3. Lack of diversity: homogeneous groups that are responsible for only specific aspect of the project (requirements, design, programming, etc.)
4. Lack of accountability for the end results, mismatch in company and personal employees goals, politics and suboptimal decisions.
5. Low motivation and morale – minimal control over decisions, poor relation of incentives and payout to contribution into the company success.
6. Centralization – authoritative control causes inflexibility, lack of independence and adaptability; missing local tacit knowledge in decision making.

James Surowiecki in his book The Wisdom of Crowds clearly shows that traditional top-down companies are inefficient in making the best decisions.

The Ideal Software Company

A. Company organization

1. Powerful teams – the company represents a conglomerate of powerful teams. Projects teams are small, diverse and empowered to make most project decisions.
2. Egoless management – management carry mostly support, coordination and representation functions. Leadership is moved to the teams level. Top management is a consulting body, which includes highly skilled professionals in finances, technology, sales, etc.
3. Shared and competing infrastructure – company infrastructure could include services as hosting, customer support, recruitment or distribution. These in-house services are shared and compete with outside providers.

Read full post >>