agile journeys

...rants by Asheesh Mehdiratta on Coaching, Transformation and Change

Category: coaching (Page 2 of 2)

How much time do you allow for Improvements?

December 18, 2017 /

This is a common question from many Scrum teams, as they embark on their continuous improvement journey. Multiple teams struggle and then look to the higher powers or just ram through their way. As a Change Agent, to answer this, here is what you can ask them –

Do you allow ‘any’ time currently for Improvements?
  • You would typically hear the team saying as 0% ! and then a good response is to then START Small, with the emphasis on START.
  • You could alternatively talk about doing  10% more than what they are currently doing
  • or simply follow the 1% daily improvement paradigm (aggregation of marginal gains)
  • or you could ask the team about their Pain Index as discussed earlier, and then review from 10-90% of the sprint
So what has been your advice to your teams?

If you like what you read here, then do subscribe to my blog , and feel free to share your feedback in the comments below.

Build technical agility as your Basic ingredient !

August 14, 2017 /

Enterprises today struggle with large scale agile adoption and transformation, without looking at the prevalent technical agility, which is a basic ingredient for building the organizational and business agility blocks.

Wishful Dreams

The dreams of Successful Agile Transformation at SCALE, are sold and bought easily today, with  customer success stories , customer quotes and a conference presentation to back it all up. What else do you need? to dream up wishful thinking.

Reality Beckons

But if you dig deeper you realize that even Basic team level agility is a daily struggle for most enterprises. Most enterprises in the agile fluency model are at the 2 or 3 star teams. Rarely the teams go higher and almost all of them struggle!

So go ahead and ask  if your engineering team is leaning toward heaven or hell? As the statistics show that we are losing the engineering practices and the decline of extreme programming is evident now and ‘scrum’ and ‘scaling’ has overtaken as the Main menu item driven by the transformation office.

THE FIX 

Build up your team's technical agility FIRST.

Technical agility is the ability of your team to undertake technical endeavors, using the core tenets of extreme programming and agile modeling, without impacting the business delivery or compromising on the quality of the solution.

This means that you need to take care of your engineers and their engineering practices. You need to ask if the team is writing the best code, are aware and making use of the modern day engineering practices, which a true software professional would, and are they indeed proud when they sleep at night?

Summary

If the Technical agility is missing in your team, your agile transformation would miss the bus and fall flat on it’s back. You would end up as just another data point which supports this graph, and that would not be what you really need.

So cheer up and let the technical practices bloom first in your transformation, and then the honey bees will surely follow.

Subscribe to my blog for more, and feel free to share your feedback here.

Watch out for Fly-by Coaching

August 12, 2017 /

When your Agile coach simply throws the ‘jargon’ that you do not understand ??? and then pretends that this ‘jargon’ is way above you “mortal” souls, you are entering the world of “Fly-by coaching”

The coach can run this routine once or twice or even thrice if lucky, but the team members can quickly figure out the reality (thanks to google!) and will pick up that the coach is simply faking his stuff and is not really strutting his stuff.

When asked for How do you actually show the stuff (as put up in the jargon)? – you will see the coach either disappearing or simply attending to prepare some management reports.

You should realize that indeed that you have a ‘Fly-by’ Coach in your mix, and you can almost predict the disappearing act!

Newer posts »

© 2025 agile journeys

Theme by Anders Norén — Up ↑