Project manager’s dilemma

I worked with great project managers whom 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, during the project duration, to provide the needed discipline to get things done. Meaning, 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 the PM’s role one of the riskiest jobs in IT industry.

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 the 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/Lean 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.

Agile implementation … incorporate lessons from non-software industries

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.

Scaling Agile what it means? and how to measure it?

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. Continue reading

Growth mindset for enterprise Agile adoption

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.

Continue reading

If we fall from Agile, where would we land?

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
-Bug tracking
-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.

Chef vs. recipe book approach for managing product development

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.

Characterizing product development in light of Complexity Theory

Prof. David Snowden created the Cynefin framework to characterize various domains or systems. Understanding the characteristics of a domain can help us to not only gain understanding on its intricacies but also to establish suitable approach to manage it.

Prof. Snowden- Practice without sound theory will not scale

In my view product development fits into Complex domain (non-ordered system) since it assumes the following characteristics.

There is no repeated relationship between Cause and Effect.

This is because every product is unique and has to bring new features to the end user. In other words, repetition in product development  is against bringing innovative ideas. Specially, instead of controlling variation, we embrace uncertainty because it is our opportunity for discovering new features. Generally, retrospective in Complex domains can help us understand what happened in the past but these insights can not allow us in predicting the future. Continue reading