This is the second post for implementing Lean in Knowledge Work based on Harvard Business Review article here, you can read my previous post about visualising waste here. When trying to make knowledge explicit, we should appreciate the following:
- People are non-fungible. People differentiate themselves based on their character and ethics.
- Skills are levelled: We will continue to have people of varied degree of competency in certain skill.
- Having knowledge explicit will never replace people and their interactions. Read more…
Agile methods promote experimentation to discover the unknown and desired product. Please see my post here. Not all software or IT projects require experimentation as noted in the post. Harvard Business Review article here suggested that Lean philosophies are well applied to non experimental IT/Software projects. Such projects will benefit from Lean approach in a way that can not be obtained from applying Agile methods.
Read more…
Software and IT projects are not all the same. The purpose of this post is to explore factors which impact our selection of a project approach.
Read more…
This post based on my reading of Henrik Kniberg’s book Lean from the Trenches. I am not going to write a detailed review on the book but rather I provide my own interpretations.
Maturity in using the tool
Either Scrum, Kanban or XP we should avoid getting obsessed by any one. Instead use them according to the situation. They can be helpful in providing guidelines but they can be tweaked wisely to the environment. Our approach for managing development or project should be composite rather biased to specific method or technique. Read more…
Five years ago I prepared report for a Lean transformation for a certain client department. The PCE was less than 1%! PCE is defined as the ratio between the time we actually spent working on a feature to the Lead Time. PCE is an average metric.
The purpose of this blog is to explore if there were only one metric to choose, should it be the PCE and why. Read more…
PoC is a widely used metric in traditional organizations to monitor their projects. Normally such projects can have 40+ people with multiple vendors involved. The project is structured into teams some implement Agile others are not. Sometimes the program management wants to become Agile but they are not sure how to structure their team for meeting compliance and regulation expectations, as well as inherited organization’s practices. Read more…
User stories creation is a useful mechanism for expressing product features collaboratively. However, having sprint goal as list of user stories, based on team velocity, from my view reduces the business value of the sprint. Read more…
The setup is a project involving sub-contractors from different vendors working in highly regulated industry.
The objective is how to make these diverse skills work as self-organized team?
The challenges are:
- Strong command and control culture.
- Non streamlined views on how work needs to be done.
- People work independently with fear to become inter-dependent.
Read more…
For large organizations, projects are often characterized of being:
- Involve people from various departments with separate reporting structure.
- Involve contractors from multiple vendors.
- Introduce technology which is unfamiliar to the employees.
- General disagreement or even lack of appreciation of the project approach.
- Multiple chiefs and puzzled doers.
- Software development is sub-component of the project. Read more…
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.
This is the second post for implementing Lean in Knowledge Work based on Harvard Business Review article here, you can read my previous post about visualising waste here. When trying to make knowledge explicit, we should appreciate the following:
