The manager slams a door and tells us that we are in a big trouble. Our old customers complain about many bugs and bad performance, new customers complain about delays and lack of dedication. And, top management considers our department financially unsustainable and wants to deeply cut expenses.
The manager tells that we are brilliant programmers, work very hard and create cool software solutions. But there is something wrong and we cannot work this way anymore.

Anxiety started to penetrate our souls. We know what is wrong: our team is short of people, we have too many commitments, our code is becoming a big mess, new technology and our new software version makes something bad with servers. A snowball of different problems makes us stressed, distracted and incapable of productive work.

What could our manager do next?

1. Distrust. Become a dictator, make own decisions including hiring external consultants to recommend what to do or even replace us. However,
   • we are good programmers and know our business well – the problem is not in lack of skill and knowledge
   • external people will take a lot of time to understand the system and they will have different motivation and won’t care about the long-term success
   • people will be demotivated and the manager cannot make effective decisions without active team involvement
2. Faith. Give to team the full power to fix a problems and make own decisions in hope that smart people, motivation and technical expertise will do magic. However,
   • fresh outlook and thinking out of box are hard when a team immersed for a long time into difficult situation
   • a team possibly doesn’t have understanding and control over external forces – management, customers, finances
   • changing of reality is tough (especially in people heads) and requires more than technical experience

There is a third way. Place improvement practices in the core of development process. Make self-improvement inevitable and required for any activity. Do it every day.

Toyota Way is the best example of large-scale reliable self-improvement process. It focuses on eliminating waste, solving problems at root cause and making right decisions. Toyota Way reduces problems, increases internal efficiency and makes a company successful. This is the best receipt for coming out of crisis.

Targets:

• Problems – emergencies, fires that require immediate fix: bugs, server crushes, deadline slips

• Waste – inefficient and non-value adding activities: waiting, misinformation, stress

• Challenges – adaptation to external forces (market, competitors, customers, society): new trends and technologies, changes in users expectations for user interface and functionality

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 >>

Pair Programming is a great way to build software systems. When Pair Programming works, it has significant benefits:

• better ideas – continuous brainstorming, larger knowledge pool, less gaps in understanding and more brain power to solve design problems;
• better quality – fewer bugs, instant validation of ideas, consistent approach and stricter adherence to team conventions;
• better knowledge – experience and knowledge sharing, deeper understanding of why, how and what was done;
• increased productivity – better focus and higher intensity, pushing each other and motivating to achieve best results, less procrastination and wasting of time;
• more enjoyment – most people like to work in groups and solve together interesting problems.

Extreme Programming leaders insist that all significant development should be done in pairs. But can we say that Pair Programming is the best method in all situations?

Read full post >>

“If you do not change direction, you may end up where you are heading.” – Lao Tzu

Software teams have three main strategies to achieve success: retreat, evolution or revolution.

• Retreat – refusal to act or the art of knowing when to say NO. 
• Evolution – continuous improvement and generation of ideas stemmed from existing set of ideas.
• Revolution – rapid advance with radical and disruptive ideas, overhaul of existing core ideas.

How can software teams choose the best strategy? They should consider three components:

1. The Players
2. The Game
3. The Dynamics

Read full post >>

Recently I was reviewing requirements for Microsoft Architect Certification and had found description for architect roles. After reading I had a question: do we need this kind of architects in a software team? Can they really help with building successful software?

The summary of architect responsibilities (as per Microsoft):

• Enterprise architects: set the overall vision and framework for the IT environment from a strategic business perspective.
• Solutions architects: design the solution to take advantage of the existing assets, integrate them into the existing environment, follow the enterprise architecture, and solve the business problems of the business owner or unit.
• Infrastructure architects: responsible for creating an architecture that meets the business and service level agreement requirements of the business owners and supports the applications and solutions that are required to operate their day-to-day businesses.

The bottom line is that company hires expensive and canny software architects before start of the project. They talk with the business, come up with solutions and make bright key decisions about architecture. But they don’t program. During the course of the project they ensure that developers don’t spoil this great architecture.

Now business owners can hire not so bright programmers, who should just follow directives and implement this great architecture. There is even correspondence with theories of some management consultants that programmers are just house painters.

Completely irrelevant questions: Can you trust advise of your friend about Paris, if he saw the city only on TV? Can you trust battle plans if battle didn’t begin and your commander knows little about enemy? How many chess moves ahead can you predict with high certainty before start of the game?

I don’t reject a need in architecture, but I don’t agree who, when and how should make architecture decisions in a software project.

Read full post >>

Marc Andressen quotes Frans Johansson’s book “The Medici Effect”:

In a [1987 study, researchers] concluded that brainstorming groups have never outperformed virtual groups. Of the 25 reported experiments by psychologists all over the world, real groups have never once been shown to be more productive than virtual groups. In fact, real groups that engage in brainstorming consistently generate about half the number of ideas they would have produced if the group’s individuals had [worked] alone.

It is hard to believe (as with any categorical statement) that this is a final verdict. Some bloggers correctly point that done right, brainstorming is a powerful tool (here and here). Mindtools.com and Wikipedia describe effective brainstorming process.

However, group brainstorming indeed has potential risks for generating less and lower quality ideas:

1. Ideas that challenge conventional wisdom are suppressed or considered mistaken
2. People can change or even disregard own ideas while listening to ideas from others, especially authoritative sources
3. Sticking with the crowd causes less willingness for risky and innovative ideas.

Effective brainstorm process avoids these problems when:

1. People investigated the topic before the meeting and come prepared with own ideas and considerations.
2. People are diverse, have different perspective and background. They bring specialized and tacit knowledge to the table.
3. People are encouraged to think independently, creatively and don’t criticize others. Everybody contributes as equal; ideas could be even presented anonymously.

I experienced myself both successful and unproductive brainstorming sessions. I found that good brainstorming session produces ideas, which are better and more than just selection from individual ideas. It is real enjoyment to see when people create ideas, enrich each other thinking and generate new wonderful and unseen ideas. A side effect is important: people consider themselves as a part of the process, feeling ownership and control. They accept final ideas readily, better understand these ideas and are committed to implement them. This is a way to become self-organizing team.

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 >>