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

  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.

Treating users as players in Agile implementation

Gamification became a main stream approach for marketing as well internal operation of the enterprise. In this post I will talk on one aspect which is understanding the users and categorizing them for Agile implementation.

There have been so many discussions about Agile transformation and how it is eaten by the culture. My argument is that there is only one action we should do toward a company’s culture, which is Respect. Rather than changing the culture, we should focus on more intuitive light weight approach for Agile implementation which is above all should be Fun for the users!

The Agile mind-set changes the roles of traditional project management to become self-organized and team empowerment. For me this is the toughest change and normally takes time. What about if we treated the users (team members, Scrum Master, Business Analysts, UX, Admins and others) as  players?

Bartle Test of Gamer Psychology provides perspective for categorizing players in a gamified system which could be applied to users in Agile adoption.

Gamifiying Agile adoption means creating well designed activities to encourage desired behavior from implementing Agile. The activities should be intriguing to the users so that they are motivated to show the required behavior through implementing those activities.

Example
How a project manager changes so that he can give-up autocratic approach to support empowering a team to sign-off for its own tasks?

The focus should be shifted into designing activities which are rewarding and enabler to the desired behavior. Driven by Bartle’s we could have project managers as:

  • Socializers: Those who primarily want to network with peers in the organization to enhance their Agile understanding and implementation. The human-interaction focus of Agile is particularly appealing to socializers.
  • Explorers: Those who want to explore independently every activity of Agile and to define their role related to each.
  • Achievers: Those who, regardless of rewards, want to prove that they master as many as Agile activity as possible and demonstrate exceptional quality in Agile project management. They want recognition as to be praised by socializers.
  • Killers: Those want objective evidence (e.g. metrics) to prove they beat their peers in implementing Agile.

Gamification activities should be designed bearing the above categories in mind.

At the heart of gamification is the player-centered design which requires careful understanding of Bartle’s categories as it makes sense in the context of Agile adoption.

Let’s respect the culture and center Agile implementation around our players for motivating the desired behavior through having fun!

Culture Change for Agile implementation

A fundamental question here is do we need culture change to:

  1. Be able to implement Agile, or
  2. 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.

Image

  1. As change you should stop asking management to change but instead you be the change yourself.
  2. Sharpen your management skills and avoid getting distracted in technical practices.
  3. Play the role of Agile manager starting with observation without introducing changes.
  4. Maintain Improvement Backlog and watch for improvement opportunity.
  5. Introduce change carefully and succeed.
  6. 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.
  7. The ultimate success happens when executives adopt iterative management framework instead of linear management.
  8. 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.

4 disciplines of execution (4DX)

The 4DX is structured approach for execution to achieve organization’s strategic goals. This post describes synergy of 4DX with Agile product management.

The dilemma is that organizations are not short of ideas and strategy but they lack the capability of execution to achieve them. The 4DX uses the analogy whirlwind to describe the urgency and daily job which distract the organization from achieving its goals.

Continue reading