Scaling Professional Scrum via Nexus

Implementing basic Scrum at team-level  is prerequisite for Scrum Scaling. Scaling Scrum without addressing the organizational and technical problems to implement Scrum at first place is distraction from resolving real problems.


Moreover, Scaling of flawed Scrum will amplify waste and technical debt while continuing having inadequate products.


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.

Is it time to rethink A3 in knowledge work?

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

  1. A key to success in product development (PD) is to learn  how to embrace uncertainty.
  2. 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).
  3. In PD practices emerge instead of being dictated or planned for. Such practices are context based. 
  4. The team interacts with the system through safe-to-fail parallel experiments with contradicting purposes.
  5. 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.