Archive
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. Read more…
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.
Vulnerability vs protection
I was inspired by Dr. Brene Brown Ted talk here about vulnerability when writing this post. Instead of control and predict the way to live is vulnerability, that’s how I got it. Read more…
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. Read more…
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. Read more…
Risk based estimation
Although Kanban has been implemented in maintenance I still see there is advantage of implementing it in product development. For me I believe that Scrum provides opportunity to Lean approaches especially in the area is agile requirement development and management.
I prefer having high level business oriented requirements written by product managers who are closed enough to the client. I propose that once requirements are there, we should hold 1-2 day workshop with the whole team to:
1. Introduce team members to the requirements.
2. Complete risk analysis for each requirement and the related tasks.
3. Prioritize requirements based on risks and business value.
Read more…
Ugly face of Software Sizing
For years I have been using Functional Point sizing as prerequisite for developing estimates during project planning.
Risk Management (RskM), can it become interesting?
“Nothing is as invisible as the obvious.” Richard Farson
Background
I always had problem in understanding the difference between theory and practice. I always considered them the same. I can’t imagine that I could trust physician who has no formal education in medicine. For me people who practice based on theory can deliver authenticated results. In implementing best practices, including Agile and Lean, many of the impediments of implementation are known from advance.
“It has been proven scientifically that the Loxodonta africana and Escherichia coli share most of the same characteristic” (Dr. Robert Charette from keynote at LSSC10 in April 2010). Then, we should expect that the creature we create from implementing organizational practices would carry similar characteristics and problems of the old system.
The two creatures, the old and new processes, may appear dramatically different though they are fundamentally the same. Then, how should we expect that our problems will be solved by moving to the new system? In my view, we might divert the attention of the organization to another endeavor till they ultimately hit the same reality (aka we still carry the same traits of the old system).
RskM in context
RskM is a practice that has rich body of knowledge. e.g. PMBOK® and CMMI®, however it has mostly been implemented in non-proactive way. Just to mention its importance, traditionally we chose the software development life cycle (SDLC) of the delivery project based on risk assessment.
The implementation of agile practices requires enabling aspects or structures related to people, process and organization. These structures could be identified from up-front using risk assessment techniques. However, in my view, if we try to mitigate all risks from up-front, we might not start the improvement initiative at all.
Process improvement framework
A Kanban system provides evolutionary framework for incremental process improvement and therefore risk mitigation. It helps in implementing Lean practices to maintain the flow while at the same time the agile and XP practices can be rolled-out. In other words, Kanban system can envelop the implementation of various agile and XP practices to weather the winds that will definitely happen during process improvement.
A good starting point is to state the obvious (“the known unknowns” in RskM language) and use them as constraints in our process improvement journey for discovering the root causes. More risks (” the unknown unknowns”) will be discovered as we progress which can be addressed under the umbrella of the Kanban system.
As we are moving our delivery projects to agile, it is about time to manage our process improvement and transformation programs in agile manner. Kanban system can be a good fit!
Acknowledgment: The above two pictures are from Dr. Charette’s presentation in LSSC10
