The PM/PO is responsible on the project because he sets the priorities of what to be developed, comes up with deadlines, controls the budget, and in same time he is accountable on customer acceptance.
In this post I shed the light on how a vulnerable PO can be instrumental in delivering what the customer truly wants in Agile set-up.
A non vulnerable PO would avoid facing the development team without having first detailed requirements and probably documented use cases. Her strive to be perfect will preclude the project from the tremendous opportunity which can only happen if the “PO changes her mind”. Read more…
According to Brene Brown, Vulnerability is the birth place of Creativity, Innovation and Change. The rest of this blog is my own view on the implementation of Vulnerability in Agile teams.
Creativity is the ability of the team to create customer valued products.
Innovation is the ability of the team and product manager to come up with features which address the real pains of the customer and provide him gains which he hasn’t thought about. Read more…
The more I watch movies or read stories, the more I get impressed by the author’s perspectives and rich imagination. Such stories make me wonder about how strange life is. When I face my own life events, I can’t apply what I have learned from those stories. They can enrich my experience but I should find my own way out. Read more…
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. Read more…
This post represents my own reflections on Diana Larsen’s book “Liftoff: Launching Agile Teams & Projects“.
Project chartering is well established project management practice. However, the stress in agile chartering is on the collaborative and carefully designed activities to create the charter. Project chartering is part of project liftoff.
A successful project liftoff can set it on the right orbit required to arrive at its destination. It is not a guarantee of success, however, it is a proactive risk mitigation to propel the project on the right orbit. Skipping the liftoff is a recipe for failure .
Liftoff is a session which should be carefully planned for to:
- Estimate required time for Liftoff session, participants, agenda, logistics.
- Distribute materials before the liftoff session.
- The pre work session is a group activity that is led by the product owner/sponsor to vet project idea, arrive at project purpose, estimate the budget, identify the product owner and enforce sponsor commitment.
The liftoff session to be successful must serve to:
- Create strong sense of ownership among participants on its outcomes.
- Sponsor demonstrates his commitment to the project.
- The session should be based on activities but those activities should be well designed to serve real world purpose of the project.
- Create charter for every team involved in the project.
Liftoff session activities can include retrospective to reconcile the team by having shared understanding on what happened in previous phases of the project or in other projects.
Liftoff can be used to improve the situation of existing projects. I see real world examples of canceled projects because of not meeting anticipated benefits. Those projects were set to navigate in wrong orbit. The project community who interacts directly with such failed projects concluded that the project is taking them to no where or to a destination they did not want.
An outcome of project liftoff is the charter which should serve to have all project team and community agree on purpose, have alignment needed to achieve the purpose, and provide shared understanding on the context and boundaries of the project.
Chartering is a collaborative endeavor that focuses on the whole system and the interdependencies among all people involved in the project. Charter undergoes continuous improvement throughout the project, therefore, our aim in chartering session is to have a Good Enough For Now (GEFN) version of the charter.
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…
