Lean Startup (LS) method for product management

Startups should not implement the practices common in existing companies because they are not not smaller version of large companies. The LS movement is aimed to establish appropriate practices for startups which are different from what MBA graduates learn in business schools. Thanks to Steve Blank who has articulated the philosophies and principles in his web, videos, books and others. Continue reading

Pair programming

This blog is based on my reflections after reading of Alistair Cockburn work. I am addressing the case of Pair-Programming to improve quality and therefore reduce cost.

In software quality can be improved through increased collaboration among talented developers. In traditional models of development this collaboration was optional with high degree of formality sometimes and with irregularities in other times. By now, we are more having understanding of software as creative and highly demanding endeavour with little influence of formal processes.

The XP practices provide a collaboration forum that help guiding developers to produce higher quality software. Continue reading

Growing Process Improvement with Scrum

Here are the points I discussed with attendees during the Open-Space session of Orlando Scrum Gathering. The topic was the current state of Process Improvement and how implementing Scrum, as Project Management framework, can help.

  1. Why Process Improvement (PI) is perceived as second priority?
  2. There is always disconnect between the PI professionals and practitioners. Practitioners believe that they know what matters, while PI does not understand the real issues.
  3. PI professionals should be part of the product team with accountability similar to the practitioners.
  4. PI is continuous commitment.
  5. PI is best done by the people who do the job. These people own the process and they can improve it better than anyone else.
  6. PI should begin with a point where we unhappy with the existing situation and like to move to a new destination that is not known. For example, 10% of the defects are escaped to the customer and we want to improve our processes to reduce this to 2%.
  7. The discovery phase of PI is vital to uncover the root causes.
  8. We should restrain ourselves from suggesting solution till the discovery phase is completed.
  9. Discovery phase should be completed as fast as possible and the output is the quantifiable result of the causes of the problem.

10. The solution should NOT address the problem; instead it should address the cause.

11. We will always be surprised that the cause we find is far from our initial expectation.

12. Rushing to implement a practice to solve a problem without discovering the cause, will lead to noise and distraction to other problems which are not the real ones.

13. Scrum team is formed of specialists and generalists. Trained generalists can provide PI support to the team. The Scrum Master is a generalist who can lead the PI activities for the Scrum Team.

14. Improvement should be classified as either improvement story or much more important discovery story and they should be part of the product backlog of the project. The PI stories should be given equal priority to other non PI features.

15. The success of PI is measured quantitatively in terms of improving the metrics related to the problem and reducing the Cost of Poor Quality.

16. Scrum can give momentum and visibility to PI by ensuring meaningful delivery at the end of each sprint. This allows PI activities to survive and help the organization to realize business value.

17. Scrum PI can be applied to non software industries.

18. The role of Scrum Master is influencer and should promote PI to find causes of the problem which are beyond boundaries of the team.

19. Scrum PI is managed by facilitators who are more capable to deal with the constant change in PI. Traditional PI is managed by highly technical people who tend to control the scope and are less open toward the turbulence accompanying PI projects. This contributes to higher success rate of Scrum PI over traditional PI.