Tag: software development

[MS Techdays 2009] Summary “Lean, Agile Techniques and Team System” Joel Semeniuk

Introduction
The probability of success with a team of medium skilled developers working together is greater than the chance of success of a team of excellent developers not working together.

In his presentation, Joel Semeniuk gives us seven myths about software development and some solutions to overcome these. He has taken ideas from other industries amongst others the manufacturing of consumer goods and applied it to software development.

He started off with a quote of Toyoda’s principle from 1927 “If something goes wrong. Stop everything and fix it once forever.”

Myth 1 Early Specs Reduce Waste
Tell me everything you need into the finest detail and we will not make errors creating it.

The principle is to avoid waste. Waste is everything that is not adding value or preventing value to be created. What is value and what waste remains subjective!

Waste consists of:

Partially done work: avoid inventory of work to be done, one flow: develop – test – document
Extra features: not asked means no added value
Relearning: pass on learned lessons
Handoffs: handoffs are evil because you?l lose the problem context, use face to face communication and not only documents to pass information
Task switching: try to work as long as possible on the same task, it takes humans about 15 minutes to get from one task to another [Book Peopleware: Productive Projects and Teams by Tom DeMarco and Timothy Lister]. Set aside time for triage work.
Delays: what to do when information is unavailable? Stop, switch task or guess? Collocated teams of users, developers, testers Šwork the best.
Defects: try avoiding mistakes but try to find mistakes as soon as possible or even better try to avoid making them. Inspect to prevent defects!

Myth 2 The Job of Testing is to Find Defects!
Build quality in from the start and avoid creating defects in the first place. Inspect often to find defects if you can’t prevent them. Once you have found a defect fix it so it never occurs again.

Example: Visual Studio check-in policies enforces best practices of quality gates.

Myth 3 Predictions Create Predictability!
We don’t plan to accurately predict the future!

Predications will be wrong if they

are complex,
must be detailed,
are about the future and
are dealing with uncertain environments.

The problem is that predictions are considered commitments (see myth 4).

We can deal with this uncertainty by:

Short feedback cycles
Detailing along the way
Releasing quickly with few but completed features
Having an experience team leader

Example: Team System support progress tracking of work items.

Myth 4 Planning is Commitment!
Eisenhower said in preparing for battle I have always found that plans are useless, but planning is indispensable!

Get in the process of frequent re-planning:

Wait until the last moment, you will have more information!
Make decision that reversible but avoid full flexibility.
Plan thoughtfully but commit sparingly

Myth 5 Paste Makes Waste!
Detailed planning ensuring we do it right the first time, mostly results in endless planning without ever starting the project. Companies that compete on time have considerable cost advantages over competitors.

Focus must be on:

Short feed-back loops
Repeatable reliable speed

Example: coding conventions and code analysis enforce automated quality control.

Myth 6 There is One Best Way!
Continuous improvement showed that there is no such a thing as the best way. A process can always get better and people are the cornerstones of the improvements. So you should embrace the people. Software development is a people process!

Myth 7 Optimize by Decomposition!
Optimizing of all the individual parts only leads to a sub-optimal result for the whole. Optimize the Whole!

Value based process improvements are the driving power for this. This means metrics or measurable results.

Examples: use a white board in the team to visualize performance and to gather lessons learned. Team System supports the gathering of performance metrics and putting these in SQL Analyst Cubes for reporting and analysis.

Conclusion
During the last decade some of the best practices and frameworks come closer together to support a more mature approach to software development. We see following approaches mutually enforcing themselves: