Author Archives: Kiron Bondale

About Kiron Bondale

Measurable business value can be realized through the successful initiation, prioritization, planning & execution of strategic projects. Striking a pragmatic, value-based balance between people, process & technology is a key to achieving success with Project Portfolio Management initiatives. Effective change management is crucial when trying to improve PPM or PM capabilities. Having been involved with multiple capability improvement initiatives, what I've learned is that "it's easy in theory, difficult in practice"! Continuous improvement of hard & soft skills gained by assisting organizations in the achievement of their business goals through the execution of the right projects in the right way is my ongoing mission.

Will all improvement ideas from a retrospective consume capacity?

The Scrum Guide indicates “The Scrum Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.

During a class which I was teaching this week, one of the learners asked: “Won’t the ideas from a retrospective use up some of the team’s capacity in the next sprint?“.

As usual, it depends.

Here are a few scenarios and I’m sure there are many others.

If an improvement idea requires the team to learn a new skill or to perform a task which they wouldn’t have done otherwise, then yes, it will consume capacity in the next sprint. Teams which aspire to be as transparent as possible will make these types of ideas visible to all stakeholders by explicitly adding them into the sprint backlog. When deciding on whether to implement these ideas, the team should balance the capacity costs against the potential delivery, quality or happiness benefits.

For those ideas which relate to improving behavior or interactions within the team or with the stakeholders supporting the team, there might be no capacity impacts beyond the team figuring out how they will remember to behave in a different manner. If the team was used to working virtually but saw some benefits in face-to-face interactions at least once a week, they could do so without reducing available capacity.

Some suggestions might require work effort from those outside of the team. For example, a dedicated testing environment might be desirable to reduce the impacts of limited access to a shared environment. An external person might provision the environment hence there would be no capacity impacts for the team beyond confirming that the new dedicated environment was setup correctly.

Finally, other suggestions might change the effort required to complete work items. If the team enhances their Definition of Done to include more criteria to improve product quality, this might increase their effort per work item.

Regardless of the nature of the improvements, there is a critical difference between retrospectives and traditional lessons learned practices. With the latter, only a small fraction of what was identified is immediately applicable, whereas with the former, the majority of the vital few ideas identified should get implemented before attention shifts and memories fade.

Thanks, Deepak, for inspiring this week’s article!

Advertisements
Categories: Agile | Tags: , | Leave a comment

Humility is a prerequisite to agility

The Scrum Guide identifies commitment, courage, focus, openness and respect as Scrum Values. Those values apply regardless of the delivery framework or method used and missing any one of those reduces the benefits of an agile journey. But it might be worth adding one more to round out the list: humility.

Merriam-Webster defines humility as “Freedom from pride or arrogance“. I prefer the Cambridge Academic Content Dictionary’s definition that it is “the feeling or attitude that you have no special importance that makes you better than others“.

Similar to the other Scrum Values, humility could be considered in the context of both the individual and the team.

We don’t consider ourselves to have any special authority or rank over other members of our team. We also don’t assume that we are always right which makes us open to hearing differing viewpoints and not shying away from healthy discussions in order to produce the best possible outcomes for our customers.

False humility doesn’t cut it.

We openly acknowledge when are skilled in some areas and best positioned to help the team achieve a goal but will honestly communicate when we know less. While we are happy to accept accolades for our work, we will recognize that our successes were realized through the support of the rest of the team.

We remain open to feedback about our personal work activities and outcomes and are able to resist the natural tendency to become defensive when we receive constructive feedback.

Without humility, the pillars of Inspection and Adaptation crumble.

We know there is no ONE right way (or framework, or method, or practice or tool).

We may meet our sprint goals every sprint and receive rave reviews from our customers but we have the humility to acknowledge that we can always do better. This supports true continuous improvement.

Product Owners will possess a deep understanding of the product domain but effective ones have the humility to acknowledge when a pivot in product direction is needed and don’t allow customer value and team morale to be sacrificed at the altar of preserving the Product Owner’s ego. The scientific method which underlies the good practice of Minimum Viable Products depends on the humility of a scientist acknowledging that their hypothesis might be disproven.

Humility extends to the roles supporting our agile teams. Coaches should know what they don’t know and be capable of recognizing when those being coached have outgrown their services. Such coaches possess the humility to step aside to let others who are better positioned to help those being coached through the next stage of their capability development.

Be like the bamboo, the higher you grow the deeper you bow” – Japanese proverb

Categories: Agile | Tags: , , | Leave a comment

What are the tipping points for your agile transformation?

I’ve frequently said that agile transformations are marathons and not sprints. But when someone runs a marathon there are mile markers to understand how far they’ve come and to help them get their second (or third or fourth) wind.

While there is no single model for how a company will progress through its agile transformation, it is a good idea for transformation teams to proactively identify tipping points where previously unique outcomes or behaviors have become commonplace. While such milestones won’t help them forecast how much longer it might take to reach their ultimate goals, it can provide a leadership team with proof that things are continuing to move in the right direction. Such evidence is critical if there is to be sustained commitment and investment in the transformation.

This list is not exhaustive nor is it in chronological order. Depending on what the starting point is for the organization and where the transformation team chooses to focus their efforts, there may be additional milestones and the sequence of when those are accomplished will vary.

  • Team social pressure encourages appropriate agile behaviors without the need for sustained external coaching
  • Delivery frequency matches stakeholders’ change appetite
  • Zero defects
  • Empowered Product Owners with sufficient capacity, capability, knowledge and influence
  • Team allocation shifts from maximizing utilization to maximizing value delivered
  • You don’t hear team members say “the business” anymore (we are all “the business”!)
  • Pivots in product or solution direction are praised, not punished
  • Teams provide accurate and current updates to information radiators and stakeholders effectively pull information from those radiators
  • There is NO one size fits all for ceremonies, practices or tool
  • Overtime and weekend work is the exception not the rule
  • Hiring practices and performance measurement systems emphasize the “how” as much as the “what”

What would you add to this list?

 

 

 

 

 

 

 

 

 

 

 

Categories: Agile, Facilitating Organization Change | Tags: , , | Leave a comment

Create a free website or blog at WordPress.com.

%d bloggers like this: