Coaching Agile Teams- Certified Agile Coach Training

Let’s start with a question. What are the things that one has to consider for building a successful team?

Most people will think of Right Skillset.

Skillset X

Skillset Y

Skillset Z

Is that enough for a Successful Team?

While Right Skillsets are needed, the reality is if you ask a group of people to share their experience in a Successful Team, and find out a pattern from all the stories it would be

Collective Purpose/Goal

Open Communication within and outside

Collaboration

Continuous Improvement or Learning

Let’s relate this to Coaching and explain some of the benefits of certified agile coach training.

Few excerpts from the International Coaching Federation (ICF). ICF adheres to a form of coaching that

honours the client as the expert in their life or work

believes that every client is creative, resourceful, and whole

Now, let’s relate to Agile Team coaching — One of the modalities for team development.

In the team coaching context, the term “client” represents the team, rather than an individual.

So, going by the context, a team coach should stand on the belief that.

The team has all the skills to do the job at hand — Be it simple problems or complex problems. But it becomes much more necessary for complex problems — More unknowns than knowns.

The Coach shall facilitate an activity for people to form teams on their own.

Now with one tenet for a successful team is accounted for, let’s focus on the coach’s process for a Successful team.

The coach should have the right mindset — Being open, staying curious always and being mindful that it is everything about the team.

The coach should have a proper entry into the team, establishing a partnership with the team members to ensure how team development accountabilities will be shared among the coach and the team.

The coach helps the team to identify a common purpose that motivates people to glue themselves as one team. Coach challenges to ensure the team is in line with the organisation’s priorities.

The coach fosters an environment where individuals can express their views, perceptions, suggestions transparently among themselves—at the same time, acknowledging the collective needs.

The coach encourages effective communication within themselves to build connections to accommodate each other’s strengths and weaknesses. And effective communication outside of the team to build support outside of the team proactively.

The coach acts as a mirror to help teams visualise the critical connections and relationship challenges. Moreover, this will allow teams to identify the need for effective collaboration to overcome the relationship challenges pulling the team backwards.

The coach fosters an environment for experimental learning. This will teach the mindset of seeing the failure as learning thus helping the team be optimistic.

To do the above, the coach may use appropriate modalities based on situations — Team Training, Team Mentoring, Team Facilitation, Team Coaching and Team Consulting. I call this as Agile Coaching Competencies

Resource: https://tryscrum.com/2021/02/18/coaching-agile-teams/

Read More

Scrum Guide 2020: Scrum Masters are the True Leaders

Scrum Masters Are The True Leaders

Just take a second to imagine a professional environment where every individual connects and donates their intellectual capacity to the fullest. It’s a place where each person experiences contentment. It’s a workplace that bestows fulfilment too. Then again, the description here seems somewhat booking and way too ideal. Is it possible to create such a working environment? Indeed, it is! If so, then how? With all my experience, I can say that the present leadership archetype can’t do it, even if everything else falls into place. Proper certified scrum master training at tryScrum is an incredibly popular framework, and it tried to fix the problem by returning it unsolved. Sounds confusing, right? The creators tried to fight fire with fire by giving Scrum Master the role of a leader. Now, for ages, many leaders forced their employees through commands, obligation, and conformity. Such leadership strategies won’t work in today’s complex world. So, what is it that requires changing?

Scrum found the perfect answer to this question by not solving the problem. It lets people solve their own issues. Jeff and Ken redefined and polished the idea of the role of Scrum Master from a “Servant Leader” to a “True Leader” in the 2020 Scrum Guide.

Understanding the concept of a True Leader

What’s the deal with this term, anyway? After all, too many individuals raise their hands whenever someone asks them whether they wish to assume the role of a boss. Who’s the True Leader among them? The only way to answer it is to take a step back and find out: What do True Leaders try to gain? These people only want to help others find a leg to stand on instead of begging others for support. A True Leader won’t try to make others go blind by showcasing his/her brilliance. This person will act as a reflector of light so that we can see ourselves from an entirely new angle.

Everyone must be a leader – The Rebbe

The distinctiveness of True Leaders

Thinking out loud

Discussing what you think is essential in creating all the difference. It’s the only way to become a servant-leader from an information dispenser. We educate people to give voice to their thoughts so that their subordinates at the workplace can’t resort to assumptions. It also brings transparency and makes the leader trustworthy.

Expanding the space of solutions

Among all the intentions of a True Leader, one, in my view, is to let loose collective intelligence. In order to do it, it’s crucial to allow the team to disclose their views, thoughts, beliefs, as well as the things that don’t sit right with them. It’s about creating a safe zone and promoting a continuous buzz of conversation among the members.

Informative authority

Everyone will follow a True Leader without questioning him/her as long as the person manages to present himself/herself as a bona fide executor. By giving people more authority, we create better leaders. These people come up with durable mechanisms to create a paradigm shift.

Undoubtedly, donning the skin of a True Leader is extremely challenging, but achievable nonetheless. As soon as we make our minds to follow the path before us to become a Scrum Master, I think we can make significant contributions to the world by improving our capabilities. In doing so, we yield results that matter and even become whole by discovering and recreating our belief structure.

Resource: https://tryscrum.com/2020/12/30/scrum-guide-2020-scrum-masters-are-the-true-leaders/

Read More

Accelerating Positive Culture and Engagement with Agile Coach Training

Written in 2001 the Agile Manifesto states that in-person interactions are the most effective way to facilitate communication. As technologies and connectivity have evolved, so has the ability for teams to work in different ways. Successful organizations are embracing these new ways of working and reaping tremendous benefits as a result.

Since 2001 it’s become more and more common for team members to be geographically dispersed to the extent that throughout 2020 most teams have been working remote. We have found that not all remote teams perform at the same level; in addition it’s clear there are teams that are working even better remote while others are struggling to cope. With the recent pandemic, it has forced a new way of thinking and working making it critical that agile teams not only survive but thrive during this workplace transition.

Check out this webinar to learn about the practices, tools, and values at agile coach certification online that have allowed many agile teams to thrive while working remotely and the steps that your organization can take if you have teams or individuals who are struggling.

We’ll discuss:

• What great can look like

• Signs that a team or team member may be struggling

• The role tools play in helping organizations navigate and stay productive

• Steps your organization can take to boost engagement and build positive culture

Speakers

Eric Naiburg - VP of Marketing and Operations, Scrum.org

Eric is co-author of UML for Database Design and UML for Mere Mortals. Eric is responsible for all aspects of marketing, support, outbound communications, Professional Scrum Trainer programs, partners and operations for Scrum.org. Eric was program director at IBM and Rational Software where he was originally hired in 1999 by original Scrum Team member John Scumniotales for who he worked for several years and worked closely with another original Scrum Team member Jeff McKenna sitting in the next desk. At IBM and Rational Eric was responsible for application lifecycle management (ALM), DevOps, Data Governance and Agile solutions.

Danny Presten - Chief Methodologist, Digital.ai

Danny has several transformation tours of duty behind him in which he's worked in agile organizations, consulted with senior leaders and led training initiatives. He is an entrepreneurial self starter with over 20 years experience successfully addressing complex delivery challenges in a variety of industries including web development, e-commerce, healthcare, non profit, supply chain, and legal.

Derek Holt - General Manager, Agile & DevOps, Digital.ai

As General Manager of Agile and DevOps at Digital.ai, Derek brings nearly 20 years of experience leading large enterprise and startup technology companies with a consistent focus on the digital transformation. Derek joined Digital.ai after serving as President & COO of K4Connect, a venture backed IoT software company focused on bringing digital solutions to empower older adults and individuals living with disabilities. He received a BS in Computer Engineering from The Pennsylvania State University and an MBA from Duke University’s Fuqua School of Business, where he was named a Fuqua Scholar.

Resource: https://www.scrum.org/resources/accelerating-positive-culture-and-engagement-distributed-teams 

Read More

Scrum Certification Online: Contract Your Team!

In this blog series I would like to address topics that relate to professional team coaching as well as Professional Scrum. In the course of becoming a Professional Team Coach, I noticed a lot of interesting topics for Scrum Masters who want to improve their coaching stance. I'd like to note that models and terms I am using and discuss are not mine. They come from training and coaching sessions belonging to Vroemen from Teamchange. The connection I make to Scrum is my interpretation.

Contracting and containment

The word contract often triggers some raised eyebrows in the Scrum community. It may feel like something strict that prevents people from collaborating, referencing back to the agile manifesto for software development. The fact that this manifesto motivated us to collaborate with our customers instead of negotiating contracts, was a sign that collaboration and contracting were out of balance. However, there is a new need for a contract: a (psychological) contract between the Scrum Master and the Scrum Team (including the Development Team).

By this I don't mean a big contract upfront with the signature of the whole Scrum Team. There are more ways to contract a team.

A couple of examples:

- You have a certain objective in mind for this Retrospective. At the beginning of the session you're transparant about this and check if the Scrum Team is ready and willing to achieve this objective together;

- You're an hour into a refinement session and you read the room. There is tension in the room, discussions are hardened. You suggest a short break and you do a check-in before continuing;

- You start with a new assignment as a Scrum Master. You're assigned to the marketing team. The marketing team never asked for Scrum, let alone a Scrum Master. So this is the first thing you bring up when you meet the team. Together you set up some rules of engagement during professional agile leadership certification, so you can be a servant leader to the team. Or maybe you don't take on the assignment at all?

- You meet with a new team and you create a set of team rules that everybody can agree on.

I'm sure now that I've given some examples, you can think of a couple examples of you're own?

So this contracting doesn't happen just once. It happens over-and-over-again.

Creating a contract like this will create containment and safety for the team to freely express themselves because of the containment of this contract.

Contract the team, not (just) the manager

You will often encounter managers or customers you work with to take on some improvements regarding a specific Scrum Team. Things have not been going that smooth and you're the perfect match to solve this teams' problems. Before you agree to take on the assignment, take a moment to talk to the team first to assess their view on the situation. If this team does not want to be coached, chances are you will be having a very hard time doing so. Find out what the needs of this team are. What do they think/feel? What's the relationship between them and management? All of these things affect the ability of you being able to help this team grow or not. 

I was once the Scrum Master of two teams that started out with Scrum. I was hired by the CEO to help these teams become better Scrum Teams. Or actually, the CEO thought I would help the team perform better on their targets. Management started putting more and more pressure on the teams and they wanted me to do the same. This led to the situation that I had to end my contract with this company. The CEO did not want Scrum, he wanted to get results as fast as possible by pressuring the teams. No sustainable pace what so ever. My contract with the CEO was in conflict with the contract I had (not) made with the Scrum Teams.

Contact and contract

Contact and contract are not that different. Making contact with the people in your team is like making a psychological contract. Sometimes this is done by a subtle check-in, sometimes more clearly by asking for permission to proceed with the agenda for a session. Or having a conversion on the expectations of your role as a Scrum Master in a team. If you treat a contract in this way, you and your Scrum Team will most definitely benefit.

Resource: https://www.scrum.org/resources/blog/scrum-master-contract-your-team 

Read More

How Tools Condition Our Way Of Working In Certified Scrum Master Training?

This week twitter was full of comments about the latest update from JIRA, the dictator of the way we work, the world's most famous Ticket Management tool. I put Ticket Management because it is what it is. JIRA is super vitamin with plugins but what it does really well is ticket management.

Returning to the topic, I put here the update, sorry because I only found it in English and I prefer to show the speech from the original source.

This is the most impressive thing I have seen in time. We put decimals in the story points. We have gone crazy! Various things here. The first is that in good professional scrum master training the story points are a complementary practice.

From what you see and what I have seen in many organizations that I have helped, JIRA makes you a slave to the way you work. Epics, Story Points, Versions, JIRA is assuming that all teams in the world use story points. Big mistake! I'd like to ask the audience a question. How many people who are going to read this newsletter are comfortable with the story points?

It's more. How many people have had to explain to their hierarchical superior who is in the orbit of the development team that a Story Point is? And finally, how many people in the audience are slaves to these JIRA setups? Unfortunately, JIRA imposes our way of working.

I have been endless times trying to answer these questions. And I have always had to make a break, like the day from Messi to Boateng, to have a kind of board for converting hours to story points…. until I discovered Kanban with Scrum.

Kanban with Scrum gave me what I needed. Go back to talking about days instead of story points. In Kanban, we planted 4 metrics; we planted Work in Progress, Throughput, Work Item Age and Cycle Time.

With these 4 metrics you will not need anything else. The most important thing is that you are going to think again in days and not in points.

I made a video explaining how to ditch the story points and move on to more realistic metrics for team day. I am attaching the video below in case you want to see it. I recommend it to end your "nightmare" of story points. Flow control is basic and strategic for any team. There, conversations change and better decisions are made.

Bottlenecks are better observed from the flow analysis and also with the 4 previous metrics we can better manage future predictability. You do not believe me? I recommend you watch the video that I am attaching to you in this newsletter. Make a game of Twig and you will see how these metrics help you.

As professional advice, I also tell you that your life will be better with JIRA faraway since it is to capture the dictatorship imposed for our way of working in the 21st century.

Resource: https://www.scrum.org/resources/blog/como-las-herramientas-nos-condicionan-nuestra-manera-de-trabajar 

Read More

Certified Scrum Master Training - Question Should Ask Their Teams to Get Up To Speed

TL; DR: 20 Questions a New Scrum Master Should Ask

Twenty questions for you — the new Scrum Master — that fit into a 60 minutes time-box. Start learning how your new Scrum Team is currently delivering the product and get up to speed: from Product Backlog forensics to metrics to team challenges and technical debt. Download a printable template for your convenience.

Start Learning the Ropes as a New Scrum Master

I was recently asked to participate in the Product Backlog refinement of a team that was looking for a new Scrum Master. I was skeptical in the beginning. I had only limited knowledge about the project—a commercial website based on a CMS—, the refinement session was time-boxed to 60 minutes, and I hadn’t met the team members before beyond a very brief “hello.”

So, I prepared a questionnaire comprising team-related topics. I wanted to learn more about and listened to the Scrum Team, refining several work items. When appropriate, I asked one of the prepared questions. Surprisingly, the insights turned out to be much more qualified than I expected. Particularly, I could identify the low-hanging “Scrum fruits” to improve product delivery relatively easily. Remember that as a Scrum Master, the stakeholders will always judge you by whether “your Scrum Team” can deliver a valuable, potentially releasable, “done” Product Increment regularly.

The questionnaire I used as is available as a download for your convenience:

Let us get into the questions for a new professional scrum master training at tryScrum:

How large is your Product Backlog?

I do not believe in Product Backlogs that are larger than what the team can handle in three, maybe four Sprints. If the Product Backlog exceeds this threshold, the Product Owner might be in need for some support.

What is the typical age of a Product Backlog item?

A Product Backlog item that has not been touched in five months is obsolete. Cluttering the Product Backlog with ideas, reminders, or other low-value items increases the noise, thus probably impeding the value delivery of the Scrum Team. (Admittedly, I am a fan of Product Backlog forensics.)

What is your average lead time from an idea being added to the Product Backlog to its delivery?

No one could answer that question in the before-mentioned session. But it is actually one of only a few metrics that can provide some insight on whether Scrum has been successfully adopted by your organization. (Read more: Agile Metrics — The Good, the Bad, and the Ugly.)

Does your Product Backlog contain work items none of the current team members is familiar with?

If so, the Product Backlog items in question may no longer be valuable. Consider re-refining or deleting them.

How often are you refining the Product Backlog?

That should be a continuous process. As a new Scrum Master, however, I would love to have a Product Backlog refinement session once a week with the whole team.

On how many Product Backlog items are you working in parallel during Product Backlog refinement?

Ideally, a team should not be working on more work items than it can handle within the next two or three Sprints. Otherwise, the risk of allocating resources on work items that may never make into a Sprint Backlog becomes too high.

How long does the refinement of a typical Product Backlog item take?

The refinement should not be taking more than one to two Sprints. Otherwise, the Product Owner might need some support in preparing ideas properly for the refinement sessions.

How are you creating Product Backlog items? (Is it a joint team effort with the PO, or is the Product Owner writing the work items and the Development Team estimates them?)

There is a tendency to observe that Product Owners become more a kind “technical writer” of Product Backlog items which then get estimated by the team. I suggest, however, to turn Product Backlog item creation into a joint effort of the whole team. Remember Ron Jeffries’ CCC: card, conversation, confirmation?

Where are you discussing Product Backlog items? (Only during refinement sessions or also on Slack or via comments on tickets, for example?)

Every team has its own habits and maybe commenting in Confluence, Jira, Github, or utilizing Slack is an effective means of communication in your organization. As long as this happens before a work item is selected for a Sprint Backlog, this should be fine. Discussing its essentials afterward is a problem, though, as the Sprint Goal might be compromised.

Who is writing acceptance criteria and in what format?

It should be the Product Owner in collaboration with the Development Team following the Definition of “Done,” thus creating a shared understanding of what the team needs to build.

How are you estimating the likely effort of a Product Backlog item?

There are plenty of practices on estimating a work item if your Scrum Team estimates at all. (Think of #noestimates or creating similarly sized work items instead.) The emphasis should be on creating a shared understanding among all team members what shall be created. An estimate is a side-effect, not the primary purpose.

Are you estimating in man-hours or story points?

Estimating in man-hours is better than not estimating at all. However, I prefer story points, particularly if the application in question is burdened with legacy code and/or technical debt. Predictability and stakeholder communications become easier this way as story points have a built-in buffer.

How are you practicing the estimation process, if the team shares different opinions?

Preferably, you should observe the team’s estimation process in real life. But in case you have to ask: is it a typical vote-discuss-revote cycle? Or: when and how do you pick an estimate? (Examples: 50:50 split, e.g. 3*3 and 3*5 – which one do you take? Or a majority split: 2*3 and 4*5. Or the estimations cover a range, e.g. from 2 to 8?) It is a good way to learn more about the team building state, too.

What is a typical distribution of work item sizes in your Sprint Backlog?

This question tries to figure out, where the productivity sweet spot of the team is, based on the Sprint Backlog composition. In my observation, Scrum Teams often work more successfully when a Sprint Backlog comprises one or two larger Product Backlog items, some medium-sized stories, and a few small ones.

Are you re-estimating work items at the end of a Sprint? If so, under which circumstances are you doing so?

That should always be done if a Product Backlog item turns out to be way off its original estimation. Re-estimates make good data-points for Sprint Retrospectives, too.

What was your velocity for the last three Sprints?

A Scrum Team should know its velocity or productivity, how could it otherwise possibly improve?

How many user stories are typically not finished within a Sprint and for what reasons?

If the team is bullish and picked more Product Backlog items than it could probably handle at the beginning of the Sprint, so be it—nothing to worry about if the Development Team meets the Sprint Goal nevertheless. If the Development Team, however, is regularly leaving work items on the board and not meeting Sprint Goals, this should be a major concern for the new Scrum Master. See also: Scrum: The Obsession with Commitment Matching Velocity.

Are you changing Product Backlog items once they become part of a Sprint Backlog? And if so, under what circumstances?

Making work items smaller if the Development Team runs into a problem is certainly not great, but acceptable—if the work item in its reduced form still delivers value and the Sprint Goal is met. Extending it after the Sprint Planning, however, would only be tolerable if the Development Team agrees on the extension, and the Sprint Goal will not be compromised.

How would you consider the level of technical debt?

As a new Scrum Master, you want to know everything about the current level of technical debt and dependencies on other Scrum Teams or external suppliers. These issues are directly responsible for your Scrum Team’s ability to deliver product Increments. (Read more: Technical Debt & Scrum: Who Is Responsible?)

What are the three main challenges the Scrum Team is facing today?

This closing question is by design an open-ended question to get some ideas for the next Sprint Retrospective.

Conclusion

The New Scrum Master and the Scrum Team

What is your preferred technique to get familiar with a new Scrum Team as soon as possible? Where do you start? Please share your experience in the comments. 

Resource: https://www.scrum.org/resources/blog/20-questions-new-scrum-masters-should-ask-their-teams-get-speed

Read More

Valuable Coaching Tips for Certified Scrum Master Training

In this Scrum Tapas video, Professional Scrum Trainer Stephanie Ockerman provides tips for Scrum Masters while in the coaching stance. Stephanie discusses 6 different tips that you can take start applying immediately. The Scrum Master course is for anyone involved in Improving the software development using the Scrum framework. It is particularly beneficial for those people within an organization accountable for getting the most out of Scrum, including Scrum Masters, Managers and Scrum Team members. In this course, you’ll explore what it takes to MASTER the art of being a Scrum Master. The most exciting part is the practical guidance & Mentoring from Venkatesh Rajamani offers to support you on your own path to greatness.

Know more: https://tryscrum.com/scrum-masters/ 

Read More