A Concordia waterfall project

For large projects, the size can be 50+ people working for 1.5 to 3 years, which is more than 100,000  man-hours/year. If the project is about to sink, new skills will be required which are not available in the project team.

It can be surprising how such entity which can have wealth of skills and resources are not capable to save the project. In fact the ship captain and crews will step aside (either voluntarily or forced)  and leave the helm for rescue consultants till the ship becomes ready for normal operation. Continue reading

Risk management for ScrumBut

Once I read that a project plan without risk assessment is a kid’s plan. Scrum is great framework design around “continuous risk mitigation” or probably avoidance.

Organizations who run projects in “command-and-control” mentality and making transition to Scrum are challenged and normally resort to ScrumBut implementation. ScrumBut is a low-fidelity flavor of Scrum which for me can be worst than command-and-control as it deprives the organization from doing full-fledged risk management.

Risk management is a proactive critical component in either Agile or traditional world. Agile project management de-emphasizes formal risk management. Because if Agile is adequately implemented then all benefits of doing risk management are attained. From my view, good Agile implementation can provide results which far exceed the implementation of formal risk management.

ScrumBut is where the organization wants to move to Agile but held back by its legacy of bureaucracy and inefficiencies. ScrumBut is where leadership is in the test and instead we have mediocre people who try to survive by implanting waste. That waste creates environment where morale is low and is characterized by excessive motion but with little accomplishment.

For ScrumBut I highly recommend going back to the basis of pro-active project management which can be implemented through effective risk management at various levels including:

  • strategic
  • technical
  • teams
  • sub-contractors, and
  • others

Ignoring formal risk management in ScrumBut creates domino effect of spiral project failures, because of losing the pro-activity which is the back-bone of Scrum.

Blind spot of visual board

The visual board has an orthogonal dimension which we can not visualize, this is the quality of engineering work. As Agile/ Lean facilitator we should be proactive in improving such engineering competencies, even if we are non technical. I suggest implementing the following two concepts.

Maintain waste basket

For me this represents noneffective requirement management. This contains the cards which decided not to complete after we had started working on them. For me this is the materialization of risks ignored during the estimation phase. However, they can be due to:
– Requirement was a wish which we discovered later that there is no need for
– Requirement is beyond economy to be implemented
– Requirement is non feasible based on the current product architecture.

Defect escape

For me this represents noneffective engineering development practices. Defect escape is defined as “For given set of cards, it is the percentage of defects found after being DONE compared to overall defects of these cards”. This percentage should be zero. The engineering failure is more severe if this measure is non-zero for non New Product Development cards, which represent the repeatable type of work. Examples for causes of non-zero value of this measure are:
– Inadequate architecture
– Poor product owner review
– Overlooked unit testing
– In effective code review

Embedding Scrum in Kanban board

In a typical maintenance project managed using Visual board, we can have cards representing bugs, enhancements, new features or new product development. All card types can be managed using the value stream of the visual board except for new product development (NPD). The NPD represents fundamental architectural change into the product leading to break through added features to the existing product. Such NPD card can be managed as Scrum project because of the following.

Long duration
A typical NPD project can take in average 10 weeks which is much longer than cards from other kinds.

Team effort
While a typical card can have one developer, for NPD it requires team.

Requirement management
NPD by definition means requirement will evolve and new discoveries about the product would occur from one iteration to the next. This kind of convoluted development activity would require highly iterative and risk oriented delivery of slices of the requirements.

Different value stream
The value stream for non NPD card is agreeable and visualized. The NPD can have a very different value stream and can employ different skills from the maintenance value stream.

Technical risks
NPD involves myriad of technical risks and can require substantial architectural and design work.

Management oversight
For NPD management and business users would require periodic review of the increment for feedback. In normal value stream though these review  can occur but not to the extent of interactivity required for NPD.

Marketing analysis and ROI
NPD is driven by marketing and financial analysis of ROI. In additional to the technical product risk, there is also financial risks due to competition from other vendors. The revenue model is important for NPD and derives the prioritization of backlog of a NPD card.

Based on the above factors, I would recommend managing NPD card as sub-project using Scrum.

How to classify the card as NPD? Use the above factors as check list. Another rule: the card should be classified as NPD if the current value stream of the visual board fail to work.

What about code integration?
I suggest managing NPD card as separate trunk in the version control system. It can take multiple iterations before we can have shippable product, at that point we should start merging this trunk with the baseline product.

What is wrong with Gantt chart?

Answer, nothing wrong. It is a great tool. The reason it is not popular in software development is that it does not usually work. Gantt chart is a project management tool for scheduling activities (start and end date), assign resources, track progress. It’s arguably the main tool which I have seen used in project management, but not in software development. Continue reading

Estimation value add

Lead Time is the average time from when client submits a request till related software is produced. Cycle Time is average time between two successive releases from the system. The lower the Lead Time the higher the Throughput, which is number of client-valued features, released every time interval. Ultimately this impacts the bottom line by having lower cost per feature. Continue reading