I worked with great project managers, all work was centered on them. They treated team members with dignity, they worked long hours, track risks, follow-up actions to conclusion, address organizational impediments, be the single point of contact for the project, take responsibility for project failures instead of pointing to team members,……
The reality is that project manager (PM) constructs a temporary organization within the parent organization, during the project duration, to provide the needed discipline to get things done. A fact is that without this temporary organization, business accomplishments cannot be realized. The whole gamut of project management is founded to address this time tested fact.
Organization’s success becomes dependent on this temporary ‘virtual’ organization, which its CEO is the PM. But this quasi CEO has no authority, while he needs to constantly deal with impediments in the parent organization that stands in the project way. In other words, there is invisible contract between the organization and the project manager, whereas the latter secures his job in return of fill-in for the leaders. This makes PM role one of the riskiest and vulnerable undertakings in any project.
Why we need to have a PM to tell the organization that it needs to change its practices? For every PM I dealt with, they believed that organizational impediments are the main project’s threats. They are less worry about technology issues, solution complexity, process aspects, training, deadlines and other familiar risks. In many cases such organizational impediments cannot be communicated but rather the PM keeps and cannot even document in the project status or impediments log. The worst quickly happens, when the PM’s reason of existence becomes dependent on existence of such impediments. Do you think a PM in this environment would have any interest to make such impediments visible?
Agile organizations have leadership at their foundation, which can further reduce the value-add of traditional PM. However, many of traditional PMs transcended to process consultants, enablers for team empowerment, professional facilitators, and other Lean/Agile roles.
Finally, strong PM and Agile are for me contradictory premises. The more an organization needs a PM, the higher the chance it is not ready or willing to change its long-time organizational impediments.
Listening to various renowned leaders from non software, the following message resonated to me.
“If you want to turn-around a company, you need to make sure that the solution comes from inside the company“.
Companies are formed from people coming from diverse cultures, which can bring insight and richness, provided they are engaged. To introduce changes, the employees should be engaged in designing them in the first place. Meaning, apart from how sound the advise from external consultants can be , it would not serve the purpose of change which is to achieve improvement. Strategy, though important, only weights a very low fraction in the whole percentage of success. The dominant weight to succeed in change initiative is “Execution”.
Execution is the ability to implement the idea for change and therefore realize organizational growth. Bringing the idea is important, but many organizations do have great ideas whilst they donot grow, because of their inability in “execution”.
If we compare this thinking to Agile implementation, we find that Agile is the strategy for the majority of companies, at least from my experience. But the ability to effectively manage the execution of implementing Agile is what differentiates a company which grows from the one which use Agile as a fad.
Shedding the light more, a company’s implementation of Agile is unique and may not be cloned from another one. This is regardless of how strong the similarity is with the company which we are imitating. Another view, an externally imposed Agile strategy can come as cookie-cuter solution from external consultant, which apart from how sound it is, it won’t work.
Taking this idea further, companies should discover their own Agile character. This discovery can happen only from within the company by engaging its employee. Hence, the employees create the plan for change, own it, implement the plan and be responsible in proving a measured success. This is a rationalization to the saying at the beginning of this post, “to turn-around a company changes need to come from within”.
Given Agile is the growth strategy, our role as Agile coaches is to assist the company in discovering its unique Agile vision. Introducing proven Agile strategy would not help because it didnot come from its employees.
Instead of being a goal, Agile for me is enabler for the organization to stay in business and therefore to grow. I believe Scaling Agile is about the effective use of this enabler to solve organizational problems which stand in the way of its own growth. The idea is that it is not definitive on how the organization can grow so that it can remain in business. The organization needs Agile as enabler or tool to uncover such problems and address them. Read more…
Enterprise Agile adoption goes beyond the project level adoption of Agile to address organizational wide problems. A strategy for enterprise adoption of Agile can expose those problems, which are to be resolved by its employees (practitioners and managers). Organizations which implement Agile at the project level without solving organizational wide problem are just doing Agile. This has very limited gains to the organization. In this post I will demonstrate why the growth mindset is needed for the organization to become Agile instead of just doing Agile.
The idea of this post is to invalidate the assumption that teams which give up Agile will follow Waterfall. This is because, despite being unsuitable for product development/ IT projects, Waterfall is a highly disciplined engineering framework. In other words, Teams implementing Waterfall need to implement rigor procedures, for example:
Base lining of requirements
-Base lining of designs
-Change control process
-Detailed schedule upfront, which is based on baselined requirements, having detailed tasks
-Code base lining
Teams who fall from Agile, are probably not geared for the disciplined execution of Waterfall. Those teams are most probably landing to uncharted waters. Those teams might still comply to the organizational governance. However, they actually abandoned Agile values and principles, not to the rigor of Waterfall, but rather to the land of no law.
Symptoms of the team’s new destination include:
Managers take charge: In the absence of transparent values and principles, daily conflicts will be resolved by managers rather than their reports who are part of the project team.
Fragmented team:Tension among team members who report to different managers is high unless conflicts are avoided. According to Patrick Lencioni, “Fear of conflict” is a symptom of dysfunctional team.
Compliance becomes the goal: Business value mindset will be ridiculed because the prevailing value is to de-motivate teams so that they are recipients of commands.
Emergence of heroes: Those individuals can save the day by solving the wrong problems.
To summarize, teams which are not able to hold to Agile are improbable to follow Waterfall. They will fall to a state of team fragmentation, dominant chiefs, and supreme of compliance. In lack of transparency, metrics will be mis-leading.
This post represents my own personal ideas and has no attribution to any of my previous/ current clients or employers.
A3 is a collaborative method for driving improvement by the team. A3 is based on the ability to envisage the future state “by the team” and create plan to bridge the gap with the current state.
According to Complexity Theory and the CYNEFIN model, I believe product development fits in the Complex domain. Please see this video https://vimeo.com/53734972 by Prof. David Snowden talking on Complexity Theory. In Complex Adaptive System it is required to understand carefully the current state, however we should not try to envision the future state which is against A3 thinking.
The reason of the above is that A3 was originated from manufacturing which values predictability and uncertainty control. The carving for having repetitive process is behind locking the future state from upfront.
Product development has characteristics which are non congruent with A3 thinking.
- A key to success in product development (PD) is to learn how to embrace uncertainty.
- PD is a Complex system where the team and the system co-evolve based on given constraints (for example technology employed) and within attractors (rewarding system).
- In PD practices emerge instead of being dictated or planned for. Such practices are context based.
- The team interacts with the system through safe-to-fail parallel experiments with contradicting purposes.
- Every experiment creates knowledge and pave the way for a new one. Nevertheless, at some moment the team shifts from experimentation to “exploitation” to scale its practices.
Prof. Snowden created this ACTION_forms_2013_01_edition to help in experimentation to probe a Complex system.
A3 Thinking was not meant to handle experimentation but instead to create a concrete plan to reach the future state. This thinking is contrary to PD because of the above characteristics.
The chef and recipe book metaphors were originated from the work of Prof. David Snowden on Complexity Theory.
Recipe book approach suggests the implementation of specific frameworks to achieve the value from certain practice (Agile). This will require the organization to re-engineer (or transform) itself, at its own cost, so that those frameworks can be implemented.
On the contrary, Chef based approach does not dictate pre-configured set-up as pre-requisite to achieve the value from implementing the practice. Instead, the chef uses whatever is there to create valuable implementation of the desired practice. The value the chef delivers allows organizations to evolve and thus gradually restructure as they become motivated by implementation gains. Specifically, the chef understands how to deal with unusual scenarios which can happen when conditions change. This is because the chef has developed knowledge over years of implementation and following instructions.
Advocating Inspect and Adapt without understanding these two approaches cannot help. In absence of a chef, Inspect can lead to superficial improvement suggestion which can produce mediocre outcome from Adaptation.
The chef approach leads to evolution of the system to new states which cannot be defined up-front. The chef has the ability to guide teams (Inspect) so that they can come up with options implementable by them (Adapt).
A good agile coach implements a Chef based approach. He can help the team and system to interact together so that they can evolve to a target state which is being shaped as we go. The agile coach can help to introduce the mind-set of conducting fail-to-safe experiments by the team, so that it can probe a direction for improvement. Probing the direction can lead to sensing what approach to follow.
In contrary relying only on recipe book (for example, strict implementation of Scrum events and roles) will require pre-configuring the organization roles and teams to fit into cookie-cutter structure to achieve the up-front defined future state. In this mode we can only expect reaching this target state with no real value. For that reason, recipe book approach deprives the organization from improvement opportunities which can happen if it embraces uncertainty and experimentation.