Blog

Reach Us

21 Mar 2018

Agile Coach Toolkit #3: Asking Powerful Questions

As an Agile Coach, you frequently encounter situations which demand quick thinking to get things moving in the right direction. Over time I have found few techniques which come out handy and always keep these in my playbook in case need arise. This is the third part in the series of tools that I have found useful in my role as Agile Coach – Asking Powerful Questions.

Purpose – As a Scrum Master, you will deal with different personas in the Scrum Team with clear goal to build a high performing team. Dealing with human psychology is complex at best (though I feel that it is chaotic at times). At times you are pulled into situations where there are conflicts among the team members and you may need to coach them to ensure it is constructive and doesn’t go down into war zone.

Description – Coaching is a guided discussion meant to sort out conversations, set goals or learn new behaviors. Start your coaching conversation by welcoming the participant and asking the person what he/ she would like to get out of the discussion. This will help set the objectives for the discussion and serve as a guardrail for channeling the conversation. This stage should not take more than 10% of the time.

Let the participant open up and talk about his/ her concerns. To get the person open up more, you may need to ask open ended question like –

“Tell me more about it?” or “What else?”

In order to gauge if the person has tried solving the issue by himself/ herself, you may ask below question –

“What have you tried and how has that worked out?”

Sometimes I find it helpful to ask below question to understand the person’s emotional state by asking –

“How does that make you feel?”

In addition to helping the person express his/ her feelings, it also provides us with good insight into how emotional aspects play into the issue. One of the useful follow up questions I find helpful is –

“If you were to give a suggestion to friend who in this scenario, what would it be?”

This helps the person to take a step back and analyze the problem from third party perspective. Sometimes, even a short question like below also help explore few options

“What is possible?” 

Unless that person has not come up with options and you want to give any suggestion, first ask the person –

“May I offer you a suggestion?”

Then add your thoughts by stating –

“Have you explored … <option>?”

After the conversation has run its course, you would like to wrap up by asking the participant to summarize the take aways and next steps to ensure there will be a fruitful follow up. This should ideally be no more than 10% of the entire conversation.

Have you used this technique in coaching your team? If yes, please share your story.

References –

http://www.coachingagileteams.com/2008/04/15/agile/powerful-questions-for-agile-teams/ – Lyssa Adkins

13 Mar 2018

Agile Coach Toolkit #2: Timeboxing

As an Agile Coach, you frequently encounter situations which demand quick thinking to get things moving in the right direction. Over time I have found few techniques which come out handy and always keep these in my playbook in case need arise. This is second part in the series of tools that I have found useful in my role as Agile Coach – Timeboxing.

Timeboxing is a time management tool that allocates a fixed time period, called a timebox, to an activity. Timeboxing is generally used for ensuring that effort is spent well on activity at hand and reduce waste.

Benefits of Timeboxing –

  • It help everyone aligned and focus on the problem/ issue at hand.
  • Timeboxes encourage the team members who are working hands-on on the problem to create the best possible outcome in the time allotted, within the current context.
  • Timeboxing serves as guardrails and make the team safe by restricting the risk.
  • It avoids procrastination by helping the team to avoid distractions and prioritize their work.
  • It helps prevent unnecessary perfectionism by the team members.

Note of Caution – As a Scrum Master, timeboxing would be a great tool in your kit. But care must be taken in certain scenarios –

  • Do not go aggressive in timeboxing a particular discussion that the team may be engaged in. Sometimes they may be ‘in the zone’ and shorter time duration my end up doing more damage than to help them.

I have found this simple and yet effective idea of timeboxing very beneficial in my role and would encourage Scrum Masters to leverage it in their roles. You may find it helpful to remind the team about time whenever they tend to digress from the problem at hand. Sometimes a periodic reminder helps ensure that discussions/ activities keep progressing.

Have you used this simple technique in your role? If yes, I would love to hear back from you.

References –

Scrum Insights for Practitioners – Hiren Doshi

https://en.wikipedia.org/wiki/Timeboxing – Wikipedia

04 Mar 2018

Agile Coach Toolkit #1: 5 Whys

As an Agile Coach, you frequently encounter situations which demand quick thinking to get things moving in the right direction. Over time I have found few techniques which come out handy and always keep these in my playbook in case need arise. This is first part in the series of tools that I have found useful in my role as Agile Coach – 5 Whys.

Brief History – This technique was originally developed by Sakichi Toyoda and was used within the Toyota Motor Corporation during the evolution of its manufacturing methodologies. It is a critical component of problem-solving training, delivered as part of the induction into the Toyota Production System.

Purpose – 5 whys can be used for:

  1. Root Cause Analysis during Sprint Retrospectives
  2. Identifying impediments

Description – Discuss with team members to look at the issue and ask “Why?” up to five times to get beyond habitual thinking. It is imperative to distinguish causes from symptoms and pay attention to the logic of cause-and-effect relationship to identify the root cause. Be empirical in the investigation by leveraging the facts for decision-making.

Example – An issue identified is “poor Sprint Planning”. Let’s find the root cause for this problem.

  • “Why was Sprint Planning poor”?
    • “Well, we did not have a clear objective and the PBIs were not ‘Ready’
  • “Why were the PBIs not ‘Ready’”?
    • “The team did not meet for Product Backlog Refinement meetings”
  • “Why did the team not meet?
    • “Yes, we were supposed to meet on Thursday from 4 to 6pm, but the CEO called for an impromptu All-hands at the same time”
  • “Why wasn’t the meeting re-scheduled”?
    • “Well, there is no owner for the meeting”

So the real root cause for poor Sprint Planning was no accountability of the Product Backlog Refinement meetings. It is very important to identify the root cause, come out with action items for improvement, identify an accountable person from the Scrum Team and agree on the expected time frame for putting the improvements into practice.

Have you used this technique to identify the root cause of any problems? If yes, please share your story.

References –

Scrum Insights for Practitioners – Hiren Doshi

https://en.wikipedia.org/wiki/5_Whys – Wikipedia

Agile Retrospectives – Esther Derby, Diana Larsen

18 Feb 2018

Scrum Chapter Mumbai – “Leading Agile adoption”

Goal to answer the question:

“As an aspiring Agile Coach, I want to learn how to lead Agile adoption for my 1st prospective client, so that I can deliver maximum value and improve their ROI for the investment they make in me”

We had some excellent discussions.

https://youtu.be/z_ZjImEezus

Some insights we gained from our discussion:

  1. Understanding ‘The why”: Why is the organization is trying to embrace Agile?
  2. Derive the baseline of where the organization stands before the Agile journey
  3. Facilitate retrospectives and interviews with the C-level executives, mid level managers and the foot soldiers to understand the culture of the organization as well as their Agile readiness.
  4. Educate the organization on the new ways of working and get a top-down and bottom-up buy-in. This can include trainings, brown bag sessions, etc.
  5. Define quantitative business metrics to measure the progress with the idea of continuous improvement and the understanding that all we need to do is try to be “better than yesterday”
  6. … and many more

The 2nd edition of Scrum Chapter Mumbai is planned on Saturday, March 24th from 4:30pm to 7:00pm.

Topic:  Moving from “ScrumBut” to “ScrumAnd“

Goodbye, 2017

03 Jan 2018

Goodbye, 2017

Here are the “3 important lessons learned” by me this year:

Overcome your fear of failure:  Be uncomfortable and do something different that you have been avoiding because of the fear of failure. There can only be 2 outcomes – either you will be successful or you have learnt something to be better the next time. And both the outcomes will help you overcome your fear of failure.

Change works better inside-out:  Be humble and accept that the people in this world are not perfect and neither are you. It might be difficult to change someone else, but easier to change yourself.

Health is your biggest wealth:  Working at a sustainable pace is the key to avoid burn out. It is absouletely essential to create a healthy balance in your calendar.

With great humility I also thank the Scrum enthusiasts for accepting my book, “Scrum Insights for Practitioners: The Scrum Guide Companion”. Your positive feedback has been overwhelming and I am glad I was of service to the Scrum community.

Thank you! I wish you all a very happy and prosperous 2018!

What are some lessons you have learnt this year?

Sprint Planning

17 Jul 2017

Sprint Planning

Being the first event for Scrum team at the start of a Sprint, Sprint Planning tends to set the tone for the entire duration of Sprint. Doing the right things at this stage will help reduce the stress on the team and prevent cascading effect of any issues that may hamper the Sprint progress. With that in mind, I wanted to share a ready reckoner for Sprint Planning.

 

Product Owner

Scrum Master

Development Team

Goal

Occurs at the beginning of the Sprint to collaborate and come up with work plan for the Sprint

Inputs

  • Product backlog
  • Latest product increment
  • Projected Development team’s capacity during the Sprint
  • Past performance of the development team
  • Definition of “Done”
  • Retrospective Improvements
  • Impediments

General Responsibilities

Ensure that PBI’s under discussion are “Ready” for selectionFacilitates the event

Ensure attendees understand the purpose

Maintain Time-box

Invite technical and/ or domain experts as needed

Part I: What work can be done?

Discuss the objectives and PBI’s (wish list) for Sprint

Provide PBI’s details

Select and forecast the functionality to be developed

Craft Sprint Goal

Part II: How the work will get done?

Clarify selected PBI’s and make trade-offs

Discuss Acceptance criteria

Be a neutral party to facilitate negotiations between PO and Development teamDecide how selected PBI’s will be converted to “Done” product increment

Renegotiate selected PBI’s with Product Owner, if too much or little effort is needed to convert the PBI into product increment

Create Sprint Backlog: PBI’s and delivery plan

Outputs

Sprint Goal:

  • Objective set for the Sprint based on the selected PBI’s
  • Guidance for Development Team for the Sprint
  • Gives some flexibility to Development Team regarding implementation of the selected functionalities
  • Should be a logical function that makes Development Team work together rather than working in silos
  • Sacrosanct and doesn’t change throughout the Sprint

 

Sprint Backlog:

  • It contains selected PBI’s, tasks breakdown and plan to deliver the product Increment
Do’s
  • Be prepared with PBI’s under discussion
  • Follow Scrum values throughout the meeting
  • Keep stakeholders abreast with the decision post the meeting
  • Listen actively
  • Liaise between Product Owner and Development Team
  • Help keep the discussions on track and time boxed
  • Follow Scrum values throughout the meeting
  • If necessary to keep discussion on track, coach the team on purpose of the meeting
  • Ensure appropriate understanding of PBI’s and acceptance criteria
  • Be cognizant of “Done” and Retrospective commitments
  • Follow Scrum values throughout the meeting
  • Ensure everyone is aware of impediments you foresee that are out of your control
Don’ts
  • Negotiate on “Done” for more PBI’s to be completed
  • Take sides during the discussion
  • Overcommit

Scrum.org training

16 Apr 2017

Some feedback from my students for Scrum.org trainings (PSF / PSM)

Feedback on the Scrum.org training (PSF / PSM):

Highly Enthusiastic , with good interactive teaching style , making sure that everyone is active in the class, great way of answering questions with examples

Highly energetic with several anecdotes and practical learning shared during the session. I loved it!! All questions got answered, and plenty of insights shared. Extremely grateful to you for sharing your insights and making me unlearn & learn Scrum.

Full points for the effective teaching methods employed and your enthusiasm. The answers to the questions demonstrate your Scrum Knowledge and several examples you quote from the industry speak wide experience as a trainer.

Hiren has excellent hold on the subject and explains in such an effective manner that you get answer of further potential question.

Energy is awesome. Scrum knowledge is rated 10/10

Feedback on my book – Scrum Insights for Practitioners:

There are numerous books about Scrum – this begins where most writers stop … Here, not only the Scrum Guide Scrum Insights for Practitionersis reworded, but knowledge and experience are conveyed by one who has Scrum knowledge

Excellent. Lucid and interesting, EASY to READ and UNDERSTAND. Overall 101/100

Good List down of point and Ideas for beginners to start with . It acts as a support system for the baby who is trying and learning to walk.

Very insightful and practical. Helped me understand the spirit of scrum and how it can be practically applied.

Got 77/80 in PSM1 !!! Your book is an absolute Bible on Scrum!

3 Scrum Roles Promote Self-organization

22 Jan 2017 - 1

How do the 3 Scrum Roles Promote Self-organization?

The Scrum Team consists of 3 distinct Scrum roles that promote Self-organization: the Scrum Master, the Product Owner, and the Development Team. The accountability of each role complements the accountability of the other roles. Hence, collaboration between these roles is the key to success:

  • The Scrum Master, through servant-leadership, coaches, facilitates, educates, and guides the team to solve its own problems by using the three pillars of empiricism. The Scrum Master understands that constructive disagreements are necessary to build high performing teams. The Scrum Master allows the team to learn from the cycle of failing, trying, and failing again. The Scrum Master also helps self-organization by proactively and uncompromisingly removing impediments that are beyond the team’s self-organization capability.
  • The Product Owner closely interacts with stakeholders and product management to identify the most valuable work. TheThe 3 Scrum Roles

    The 3 Scrum Roles

     

    Product Owner relies on the Development Team for the actual delivery of a potentially shippable software increment in every Sprint. At every Sprint Review, the stake- holders help the team in shaping the future product.

  • The Development Team members collaboratively select their own work from the Product Backlog ordered by the Product Owner. They collaboratively create actionable activities to realize their forecast as reflected in the Sprint Backlog. They replan their work on a daily basis within the time-boxed Sprint to optimize the team’s output. They deliver a potentially releasable increment (integrated with increments of other teams, if multiple teams are involved) of software at the end of each Sprint. This self-directedness, the ability for people to direct their own work, motivates them and reinforces self-organization.

One of the best examples of self-organization comes straight from Ken Schwaber’s blog post “Self-Organization and Our Belief That We Are in Charge.”

I pose the following question to Scrum Masters: What is the best way to organize 100 developers into Scrum Teams?

According to Ken, he would

let the developers self-organize themselves into Development Teams as per the recommendation in The Scrum Guide that has all the cross-functional skills to build an integrated done Increment every Sprint. The Scrum Master may remind them that all one hundred people must be engaged meaningfully and that mentoring is expected. The Scrum Master may have the lead developers lead a discus- sion about the software and architecture to be worked on, with the underlying dependencies. The Scrum Master may have the Product Owner discuss the intricacies of the Product Backlog. And, if they organize sub-optimally, they can correct and continually adjust team membership as they find out more. Promote a learning organization with Bottom-up intelligence. So the one-hundred-people group self-organizes and divides itself into teams.

This is one of the topics from my book – “Scrum Insights For Practitioners: The Scrum Guide Companion“. Happy reading!

I look forward to hearing your thoughts on how the Scrum roles can further promote Self-organization.

Professional Scrum Foundations workshop

09 Jan 2017

Feedback on Scrum.org Professional Scrum Foundations workshop

Dear Hiren,

Classrooms can survive without iPads, phones or even without any power point based training presentation for that matter, but never without inspirational teacher like you.

vwOne of the way to look at it, this was just 2 days of training event just like other events those keep coming in our journey, but the way it was executed by you, I am sure these memories will last forever.

Instead of leading us by holding our hands, you asked us to walk ahead while you caringly observed from behind.

On behalf of VW team I would like to say big Thank you!

 

Thanks & Regards,

Milind Nanal

Chief Information Security Officer (CISO)