“Devoted to Facebook IPO”

Traditionally Project Managers make decisions for the horde of software developers what features should be attacked in the long release. Yes, this approach frees busy developers brains from the mind boggling task of thinking about the business. But developers no longer get business context – why features should be done and what is important for the business. In addition, long releases detach developers from the product market results and inhibit learning and adaptation to the customer needs.

Agile Development

Agile fixes these problems with three important practices – The Whole Team, Small Releases and User Stories. Customers and developers are one team that frequently discuss features face-to-face and create User Stories together. Important User Stories become part of the new release, others go to Backlog. The team releases features frequently and learn from customer feedback and implementation.

User Story is done when it is:

• Code Complete and Working
• Tested
• Accepted by customer

Agile is wonderful process! Developers work closely with business providing speed, accurate interpretation of requirements and intellectual contribution (surprise!) in translating business vision and needs into the concrete software system.

The Customer accepts the User Stories at the end of frequent iterations, provides feedback and change future User Stories based on experience with this real working system. In short, the customer steers the direction of the project instead of being a hostage of the unruly slow development machine.

However, one big problem remains – everything depends on the customer’s ability to get brilliant ideas, correctly read the market and envision what set of features will succeed. Unfortunately, it is almost impossible to get right. Business geniuses (except Steve Jobs), smart analysts or even consumers themselves cannot reliably predict how people would react, what they really need and will like next. And developers can contribute more to the market discovery and quality of business decisions.

Read full post >>

The software system in the period of active growth is a really wild beast. Excited developers with creative minds and feature obsessed marketers consistently add the fuel to this fire of software creation.

Uncontrollable growth, race for features and engineering wonders sometimes give rise to a monster – a software system bloated with useless features, over-engineered internals and erratic behavior.

Read full post >>

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

in·no·va·tion – introduction of new things or methods
im·i·ta·tion – the copying of patterns of activity and thought of other groups or individuals
in·te·gra·tion – an act of combining into an integral whole.

What is the best strategy for an effective developer – innovation, imitation or integration? Should you introduce new creative solutions, adapt other people ideas or just integrate existing components?

Software Development is an exciting intellectual endeavor without physical barriers. It is easy to start innovating – come up with new ideas and quickly submerge into their implementation. And I don’t mean here fundamental breakthroughs. I consider as innovation building of any non-trivial solution that is not directly stemmed from Google search results, development resources or available examples. And certainly, I pose the dilemma – innovate or not innovate – to skillful developers who are quite capable to innovate and who enjoy meaningful creative work.

Read full post >>

Jason Cohen posted an interesting and provocative argument against Release Early, Release Often principle followed by many agile teams.

His main points:

• Ideas. The best ideas are not coming from users and they are bad in providing feedback (iPod). So, there is no point to release early to get their opinion and ideas.
• Features. Minimal early set of features could be unattractive for majority of users and will turn them down for future use (Apple Newton)
• Quality. A buggy and unpolished product could ruin your reputations
• Architecture. An incorrect initial architecture creates waste and serious problems down the road (Netscape, Twitter)

Therefore, Jason against releasing early and often. I don’t agree.

My answer: it depends!

Evolution is the process of small frequent changes to improve and adapt to environment.

Read full post >>

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

Computers are useless. They can only give you answers. – Picasso

Many people (including my mother-in-law) think that computers are becoming so smart that programmers will be no longer needed in the near future. Other people think that programmers are geniuses who constantly solve sophisticated math puzzles in front of their monitors. Even many programmers don’t have clear idea what they do.

In this post I want to provide some explanation to uninformed people what programmers really do:

Programmers are translators of human ideas into the language of computers.

They are a link between two worlds – human and computers. Do you think it is easy to maintain this link?

Read full post >>

Reality is merely an illusion, albeit a very persistent one – Albert Einstein

An expert have much better models of reality and methods to build them than an ordinary specialist. The expert, armed with these models, can quickly put pieces of a problem puzzle together, find explanations and solve the problem.

Models can be related to anything – software systems, business domain or your personal relationships. Read full post >>

A really great talent finds its happiness in execution. – Johann Wolfgang von Goethe

source

Qualities of well composed code:

1. Quick discovery and understanding of programming logic and components
2. Clear organization (for human brains)
3. Ease of reuse, modification and evolution
4. Close connection between customer ideas and system implementation

Read full post >>