A fundamental question here is do we need culture change to:
- Be able to implement Agile, or
- To produce real value from Agile implementation
Point-2 is where we should aim. We can have point-1 addressed in the form of implementation of a certain Agile framework with its accompanied ceremonies but yet everyone wonders how we improved.
After reading the Cutter’s blog post here by Christopher Avery I had my own reflections in the next concept map.
- As change you should stop asking management to change but instead you be the change yourself.
- Sharpen your management skills and avoid getting distracted in technical practices.
- Play the role of Agile manager starting with observation without introducing changes.
- Maintain Improvement Backlog and watch for improvement opportunity.
- Introduce change carefully and succeed.
- Collaborate with the rest of managers in the organization to enrich and strengthen Agile management movement. Work with them to effect change at the department level.
- The ultimate success happens when executives adopt iterative management framework instead of linear management.
- Establish relationship with executives at highest possible level. They will support your Agile change initiative and therefore help the organization brings the highest possible value from becoming Agile.
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…
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.
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.
Process improvement has been doomed to be a waste function by many organizations. From my background, many who work in process improvement are treated as compliance workers instead of being contributors to the bottom-line. For me process improvement is the business. Every day we take decisions to get certain benefits. 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…
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…
In this post and the following ones I will reflect on the Harvard Business Review paper titled “The New New Product Development Game” published in 1986 here. This paper was the origin of Scrum and Agile movement. Leading companies who produce innovative products assume six characteristics. This post discusses the first characteristic, which this paper suggested that top management creates built-in instability by: Read more…