Muhammad Waqas Sharif

Muhammad Waqas Sharif

Muhammad Waqas Sharif is an MS-educated PSM ( I – II ) certified Scrum Master with extensive experience in facilitating teams to deliver proven results.
Being an agile explorer, servant leader, and facilitator, Waqas is adept at identifying impediments and problem areas and facilitating his teams in the collaborative implementation of corrective actions.
His mission is to guide, coach, and train companies and teams in their agile journey towards continuous improvement.
He believes that any team can be a high-performing team by:
-Living the Scrum values.
-Continuous improvement by Inspection and Adaptation.


In this article, I would like to share my experience on how I facilitated a kick-start/kick-off session for a team that is assembled for a new project at DPL.

Kick-start is important for any team therefore all the activities under the kick-start must be researched and prepared well enough to have the right impact on the team.

By keeping in mind, the importance and the impact of Kick-start, I started to prepare a week before the event. I spent a lot of time researching and finding out how best I can deliver the session? What should be the key ingredients? What activities should be included? How much do teams need to know about agile/scrum before they “go”? What do they need to know about each other and bout the product to be built?

Kickstart a New Scrum Team

By Muhammad Waqas Sharif

In this article, I would like to share my experience on how I facilitated a kick-start/kick-off session for a team that is assembled for a new project at DPL.


According to Richard Hackman (Leading Teams) and Ruth Wageman (Senior Leadership Teams), a team’s effectiveness is based on the way you launch the Team by 30%.

30% refers to how you start up the Team: define the Vision, Product Backlog, team, how Team handles the conflicts, clarify the process, coordination techniques, roles & responsibilities, etc. It takes 2–3 days to do this activity properly and has a high ROI.

Kick-start is important for any team therefore all the activities under the kick-start must be researched and prepared well enough to have the right impact on the team.

By keeping in mind, the importance and the impact of Kick-start, I started to prepare a week before the event. I spent a lot of time researching and finding out how best I can deliver the session? What should be the key ingredients? What activities should be included? How much do teams need to know about agile/scrum before they “go”? What do they need to know about each other and bout the product to be built?

A scrum master takes on the job of the teacher during the kick-start. There is much for the team to learn. If kick-start is done well, it can be jet fuel to a team, helping them to go further and faster than they ever imagined.

The major challenge for me was to conduct the session online as everyone on my team is working from home. I have to be extra careful about ensuring the participation of everyone and to make sure the interest and motivation of team members never drop during the session. To make sure everything goes smoothly I approached my session as follows.

  • Video chat to ensure everyone’s focus.
  • Screen sharing for the presentation.
  • Use of online real-time collaboration tool (Miro) for engagement.
  • Microsoft teams whiteboard for clarifying concepts.

I divided the session into three parts.

  • Getting to know your team.
  • Scrum training.
  • Creating a team working agreement.

Getting to know your team

You can find dozens of excellent activities to help people break the ice and to get out of their shyness and comfort zone so they can share their dreams, skills, perspectives, and goals with one another. It usually doesn’t matter if people worked with each other for a long time, or they are entirely new to each other. What matters is to spend some time during the first session as a team to get to know each other.

I have borrowed an excellent activity from the Lyssa Adkins book “Coaching Agile Teams”. Activity is called Journey Lines.


“A journey line graphs a person’s professional journey. Starting as far back as they want, each person draws the ups and downs of their journey on a flip chart. As you can see in the figure, the journey line often looks like a roller coaster with notes at each high and low point to remind the person of that particular event. Some include details of their home life as well as their professional life. Some stick to the professional facts. It doesn’t matter. No two are ever the same, and they all work fine. Each team member will present their own journey in front of others.

Through sharing one’s journey and being truly received by the other team members in the form of the notes, each person is affirmed for who they are and what they bring. And the entire team builds a foundation for working cross-functionally because they now know each other’s backgrounds.”

Journey Map from Coaching Agile Teams by Lyssa Adkins

I requested my team a couple of days before the activity to create their journey maps. And that they can draw it in the form of a map or just make a bullet list as per their own convince.

Few things that can be shared in this activity:

  • Introduction
  • Education
  • Total Experience
  • Technology stack/Key skills
  • Previous projects
  • Major accomplishments/Downfalls (overall and at DPL)
  • Goals for this project
  • Long term Goals/New skill to acquire
  • Anything you want to share with the team.

Quoting directly from Lyssa Adkins book to shed some light on the importance of this activity.


“The results of Journey Lines are sometimes astounding. One such case happened for me during a “new” team start-up. The team members had worked together for years over cubicle walls and had come together for their first-ever agile experience. As one person presented her journey line, she got to a hard bit — the year she had cancer. As she talked about the impact of cancer on her life, I noticed another team member getting emotional. After a few minutes, this team member started to cry. Through tears, she said, “I sat in the cubicle next to you that whole year, and we never knew about each other. I had cancer then, too.”

Overall this activity brings a lot to the team. Even if deep connections don’t appear to happen at all, the Journey Lines exercise plants the seeds by making the skills, expertise, and overall background of each team member visible to everyone.

Journey Map of one of my team member

As we are following scrum at DPL so it is important that every team member has some basic understanding of the Scrum framework.

As a Scrum Master, you might need to adjust your teaching style depending on the experience of your team. In case your team members have been working on scrums teams before, then your responsibility as a teacher is to make sure everyone on the team is on the same page as far as scrum knowledge is concerned.

Scrum Framework

There are chances each member has his/her own definition of the scrum but it’s important to help and take them to textbook scrum. You have to show the original version of the scrum. And most importantly you have to do it in a polite way so no one feels offended.

You can start the session by saying something like this, “I know you all have worked in scrum projects before, but let’s take few minutes so I can show you original version of the scrum to make sure we all are synchronized in our understanding of it.“

If your team is new to scrum, you have the opportunity of a fresh start. Your session will be more detailed and longer as well. Try to cover every aspect of the scrum including roles, rules, events, and artifacts.

I covered Vision, Release planning, Estimations along with the roles, rules, events, and artifacts in my session.

Creating a team working agreement

You can call it Working Agreement, Team Norms, Team Contract, Team Ground Rules, or Team charters anything you want to call it.

Working Agreements are a simple yet powerful way of creating rules/guidelines for the team’s culture. It is a list of standard procedures which is a valuable tool for guiding team conduct. It helps the team in creating an environment that is safe for everyone. Where no one is afraid of bringing up any idea to discuss with the team. These agreements usually enable the ethically correct environment and set the team expectation with each other.

I conducted this activity using (Miro) an online real-time collaboration tool to make sure everyone was engaged in the activity.

Screenshot of working agreement environment in Miro

I included the following things in our working agreement:

  • Team name
  • Vision
  • Team roles
  • Events
  • Team norms
  • DOD
  • Definition of awesome
  • Baseline story

Team Name

Name is important as it gives an identity. Every team must have a unique name that should represent rules, values, and principles on how people on the team want to work together. A name provides a bonding and a common purpose to fulfill.

Jacque Rowden, the Senior Director of Continuum’s Help Desk, told a story about a group that worked during the overnight shift. For a while, the group members would blame each other for any shortcomings that occurred during their shift. However, after they came together and rallied under a common team name, they were able to better allocate their resources and as a result, their shift began running much more smoothly and efficiently.

The name should be different than the project name and having a logo/flag will enhance the impact. It can be placed on the walls in team premises.


Everyone on the team must be clear about the vision of the product they are working on.

The Following questions provide the opportunity to better understand the overall vision.

  • What is the core vision statement?
  • What value does it provide to the client?
  • Why it is important for our company?
  • What problem does it solve for the end-user?

Team Roles

Identify all the roles on the scrum team. Make sure the team size is within limits as mentioned in the scrum guide.

Write the name of members like who will be product owner, who will be scrum master, and who’s part of the development team.

You must also list the core competencies/skills of the development team members.


Specify when and where events will take place. Also, mention the event duration as well by keeping in mind the sprint length. The team must know who is required for which event. Don’t forget to specify the time of backlog grooming by the team’s coordination e.g “we will schedule it on the 6th day of the sprint”.

Team norms

In this section, the team can lay down the rules they need to follow during the product life cycle.

A good way to make sure everyone remembers what they have included in team norms by displaying it on the wall in team premises.

Teams don’t have a police force to ensure that it’s followed. It’s the responsibility of the team as a whole to make sure everyone follows it and respectfully reminders to peers when trespassing occurs.

You can include things like following in the team norms:

  • Daily scrum timing.
  • Core hours.
  • Be on time.
  • Check in-outs during w.f.h.
  • Zero tolerance for bullying.
  • Respect other’s opinions.
  • No phones during the meetings.
  • Video chats for meeting while w.f.m.
  • Mute mics.
  • Don’t commit unknown and undone stories.
  • PO availability.
  • Burndown is the responsibility of the team and tfs should be updated daily.

It is worth considering Scrum Values as a source of guidance while creating this list e.g. Value of Respect fulfills when everyone makes sure to be on time in meetings.

Definition of done

There must be a common understanding of what DONE means. A feature is considered as done when it is developed, tested, and meets all the acceptance criteria. Done also means that it is possibly (Product Owner decision) shipped. A great definition of done is the one the Team can actually commit to and not wishful thinking.


Sample DOD:

  • Acceptance criteria to be met.
  • The main functions must functional.
  • Automation test cases must pass.
  • No critical/functional bugs.
  • No major UI bugs
  • Design tested.
  • Must be Integrated.
  • Unit testing must be done.
  • Feature level functional tests must be passed.
  • Non-Functional requirements must be met.

Definition of awesome

After the done comes the awesomeness. I have borrowed this concept from an article by Faye TsampardoukaI urge the team to move one step ahead and have some higher goals to hit. Teams need to answer the question: What will make them super excited and Awesome.

Sample definition:

  • Be able to build, test, and ship a feature within a sprint.
  • QA starts the very first day of the sprint.
  • The work in progress is limited.
  • The satisfaction of all stakeholders.
  • Praise from the client.

Baseline story

The team brainstorms to identify a user story that will be used as a reference during the estimations. A baseline story must be picked with a common understanding and requires the whole team. After picking a story analyze it and estimate it. It’s better to use story points estimations.

Most teams usually pick the smallest story for the baseline e.g. “A simple user login functionality”. But you should facilitate and discuss and let the team decide what to pick.

Baseline story should be available all the time especially at the time of planning and it’s a good habit to just revise the story during the estimations in each sprint planning.

How to maintain the working agreement

Working agreements should act as a living document. The document should be reviewed periodically as the team evolves. It is good to review it in every sprint retrospective meeting and see if teams need to add/remove anything depends upon the circumstances.


An effective kick start meeting serves the team a great deal. It helps creates a shared understanding, norms, and priorities for the team. A good kick start will help the team to achieve fantastic results a lot earlier than any other team does. Kick-start is important for any team therefore it’s your responsibility as a facilitator that all the activities under the kick-start must be researched and prepared well enough to have the right impact on the team. This is based upon my experience and a lot of research I did to find the best activities out there on the internet. I hope this article will help all scrum masters to kickstart their teams and avoid a lot of problems scrum teams face during project development.



  © 2020 by Muhammad Waqas Sharif

All Rights Reserved

This article was originally published at



Scrum Master’s Journey in building high-performance teams.

By Muhammad Waqas Sharif


Scrum master is the guardian and protector of Scrum Team, someone that resolves impediment and has control over the scrum processes. Apart from the conflict resolution and facilitating ceremonies one of the most important responsibilities of the SM is to facilitate/coach/help the team in achieving the highest level of performance.

High-performance teams are not a myth, it is certainly possible as stated by Jeff Sutherland in his famous book “Scrum: The Art of Doing Twice the Work in Half the Time” that “a scrum team can achieve up to 400% of improvement in performance/productivity”.

Have you ever questioned yourself as a scrum master how is it possible? What are the common characteristics of such teams? How can you facilitate a team to achieve such a level of success?

The high-performance team is one that always meets and repeatedly surpasses its goals. High-performance teams not only achieve excellent results, but they often do it uninterruptedly. The main features of high-performance teams need to be first known and then settled and sustain constantly during the team life cycle.

The first approach is to know about your team. You can do this by exploring/determining the maturity of certain characteristics in your team.

The other is to perform some quantitative analysis with your team so you can get a clear idea of where your team is standing right now. And what are the key areas where you need to invest your time more with the team to achieve the desired goal?

You can apply both approaches to the teams consistently producing results but they want to improve more and to those teams which are dysfunctional and you need them to be on track.

I will discuss both approaches in this article.

Characteristics of High-performance Teams

We’ve all experienced, or at least witnessed, high performing teams in action. We’ve also experienced, or witnessed, low performing teams (LPTs). What’s the difference? What are their characteristics?

Dragana Hadzic explained these characteristics very well in her course Building a High-performance Team.

Team Purpose: The team should have a goal or a purpose to fulfill. Teams must know the reason why it was formed in the first place. It is more like a mission and for scrum teams, a product owner is a man who can explain this to the team. Each member of the high-performance team knows what to do? When to do it? And how to do it? There is a clarity of purpose and one that everyone is committed to.

Team Values: If we talk about scrum teams values come from the Scrum guide. Each member of the high-performance team should live the values. In low-performance teams, values are not shared as a whole and value for them are just the words on some poster.

Team Communication Manifesto: High-performance teams often set some rules for communication like no one will be using the mobile phones in the meeting or everyone should reach the meeting in time. For scrum teams, timeboxing rules come from the Scrum guide.

Psychological Safety: This is a part of the team’s communication norms but I have listed it as a separate identity. Teams environment where everyone is able to speak up without fear of embarrassment or rejection. Many great ideas are lost otherwise. High-performance teams established such an environment so everyone can throw his/her idea or comment on anything.

Team Skills: High-performance team members need to learn new skills over time. Scrum emphasis on self-organized and cross-functional teams. Teams should have T shaped skills which means they develop additional and related skills keeping the end product in mind. They don’t limit their individual contribution as per their existing skills.

For example, in a music band, the musicians should have an understanding of how multiple instruments are played to create the desired effect.

Modern Practices: High-performance teams always look for a better and quicker way to solve the problems. These teams are continuously inspecting and adapting their practices. Example of best practices is Test-driven development, Test automation, etc.

Process Adherence: High-performance teams adhere to the process and follow the guidelines by book. Like for example in Scrum, the team adheres to the timeboxing of ceremonies. And invests the right amount of time in the grooming the stories.

Adaptability: High-performance teams are agile and adaptable. They focus on the end result and are open to how that goal can be achieved. Low-performance teams are often rigid with rules.

Characteristics Measurements:

After observing the above metrics you as an SM can list down the potential improvements for the team. You can use group or individual coaching to share the results and make a plan to work on each improvement in a prioritized manner.

Quantitative Analysis

There are many agile assessment frameworks are available in the market which will help you to understand the current level of your team. There is a tool that I have used recently for the assessment of my team called Comparative Agility.

The tool is paid but a free version is available with some trimmed down features. The tool is based upon a survey that allows you to know how your team is working together. It leans towards Scrum so it is best suited for the teams working in Agile and Scrum framework. You can identify improvement areas for your team easily.

After you are done with the survey you can compare your levels with the industry benchmarks. This helps you understand e.g. how your team’s technical practices are compared with those teams who are considered successful in the same domain.

This tool will also help your team in the long term by periodically repeating and comparing the previous and new results.


Scrum is based upon the empirical process control theory. Continues inspection and adaption will help your team grow to the level where the team always meets and repeatedly surpasses its goals. The role of the Scrum master is very important here to bring all the data and findings in front of the team and make a plan to work for the improvements. High-performance teams bring many benefits for everyone from companies to the individuals working in the team but the key to success is knowing yourself, your team and continuous improvement.





© 2020 by Muhammad Waqas Sharif

All Rights Reserved

This article was originally published at



About Best Agile Articles Project

Best Agile Articles is a collaborative project of the Agile community to bring you the best of the best publications each year. Our goal in publishing these yearly editions is to cull through the many articles that are published each year and provide you with a curated set of high-quality articles that capture the latest knowledge and experience of the agile community in one compact volume.
Our purpose is twofold. First, we understand that it’s hard to figure out where to go when looking for ideas and answers. There are thousands of blogs, videos, books and other resources available at the click of a mouse. But that can be a lot to sort through. So, we thought we could be of some help. Second, we wanted to bring some visibility to many people who are doing outstanding work in this field and are providing helpful resources. We hope that this publication will help them connect to you, the ones they are writing for.
Our intention is that this publication is to be by the agile community as a service to the agile community and for the agile community. With that in mind, we pulled together a great group of volunteers to help get this work into your hands.

The articles in this volume were selected by:
• A diverse Volunteer Committee of sixteen people with expertise in a variety of areas related to agile.
• The agile community. A call for article nominations went out in early 2020 and several dozen 2019 articles were nominated by the community.

The articles themselves cover a wide variety of topics including organizational structure, culture, and agile leadership. There is something for almost everyone here. All editions of the Best Agile Articles publication are available on Amazon and free to download on the Best Agile Article site.
We are thankful for the great participation by the agile community at large. If you would like to participate in delivering this publication in future years, we would welcome hearing from you.

Subscribe To Our Newsletter

Get notified about new blog posts, classes, discounts, and more!