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…
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.
Following my previous post here, I will continue with the 3rd step for Lean implementation in IT/Software setup. Let me explain what the symptoms of poor communication are:
- Disconnect among management, people, project stakeholders and the customer.
- Not asking the right questions. Read more…
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…
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…
This post is my own reflection after reading Harvard Business Review article of Nov. 2011 here. This article focuses on six perspectives or convoluted means which great organizations must have in-order to succeed in today’s globalized economy, which are:
1. Common purpose
2. Long-term focus
3. Emotional engagement
4. Partnering with the public
6. Self-organization Read more…
In this post I describe a perspective of visual board when it’s used with an automated ticketing system. In current project which I facilitate its Kanban implementation I introduced a practice of process review. During which we found gaps between the board and the ticketing system, for a given card we can have:
- Visual board is correct state while ticketing system is wrong: This was the case for the majority of cards having inconsistency issues. This is rather easy to fix by agreeing and communicating instructions with team on the mapping rules between the states of the Kanban board and those of the ticketing system.
- Both states in the visual board and ticketing system are incorrect: This was failure in the process implementation and would require that we may change our mind on the implementation approach.
- Visual board is incorrect and ticketing is correct: This was very rare and in fact we didn’t encounter this situation.
Discontinuing the visual board and use electronic tool on top of the ticketing system can lead to drop in the Kanban process implementation. The visual board allowed:
- Collaboration among all team members to discover issues which otherwise could not have been found if we use electronic solution alone.
- The manual board can act as data validation process,which is often a missed step of a measurement system. Data captured in the ticketing system is validated against manual board which creates improvement opportunities for the whole process.
- Increased degree of transparency between what actually takes place and what is being reported.
- As corollary of previous point, the implementation of the visual board has raised the morale level of team members and improved trust.
- Produced accurate data to top management for deriving the overall process improvement.
The ticketing system is not the process; instead it’s a tracking system to help in implementing the process. The real process is what happens at the visual board, and by implementing the agreed on mechanics of engagement among team members. We can’t rely on the data of the ticketing system if the manual implementation of the process is unclear. The data is reflection to a process and in the absence of the process the data can be misleading.
Having a manual board for 2 months period or so before introducing a tool on top of the ticketing system is my preferred approach. This will allow the process to be substantiated among team members and to produce meaningful data from ticketing system.
He is the perfectionist who wants to continuously improve. He’s theoretical and at the same time is passionate to implement so he can prove or disapprove his theories. Read more…
Ben, an engineer in our development team reported two issues from production and he didn’t like to report them as bugs. A bug is visualized as red card on the visual board and is visual to the whole organization. Read more…