Common mistakes that Scrum Masters make when giving feedback to Scrum Team Members

How many of us give good and consistent feedback to the people / teams that we work with? There would a handful a people who put their hands up for the question above. Why so few? The reasons are varied: It is hard to do; I am afraid I will say something I will regret; People get emotional when they hear things they do not like; It will mess up with my relationships. All of these concerns are valid; but the all stem from the common mistakes that people make when giving feedback:

The feedback judge’s individuals, not actions.

This is the number one mistake people make in giving feedback is putting it in judgmental terms. If the Scrum Master says to someone “You were to abrasive” or “You need to a better tea, player”. This is judgmental feedback, by the time these words are received by the feedback recipient, He is already thinking “Who do you think you are calling me abrasive”. The energy spent in defending themselves from your attach defeats any chance of having a meaningful conversation

The Feedback is exaggerated with generalities

Another key mistake is using language like “always” or “never”. Hearing these words people naturally get defensive as they can remember plenty of times when they did not do what you claim they did.

The Feedback contains implied threat

Telling someone her job is in jeopardy (“Do you want to be successful in the organization or the team?”) does not reinforce good behavior or illustrate bad behavior. It only creates animosity

The Feedback uses inappropriate humor

If giving feedback is uncomfortable to you, or if you sometimes speak before thinking, you might use sarcasm as a substitute for feedback, But saying “Good Afternoon” to a colleague who is ten minutes late for a morning meeting doesn’t tell that person how that behavior affected you or provide reasons to change that behavior

The Feedback is question, not a statement

Phrasing feedback as a question (“Do you think you can pay closer attention during our next meeting?”) is too indirect to be effective. It may be also be a interpreted as sarcastic, or rhetorical, to which the recipient may respond with indifference

One can avoid common feedback mistakes by learning how to communicate important information about the performance to colleagues, peers or superiors in a way what you are saying and helps them identify ways in which they can improve. During the course, of giving feedback to various people and system, have developed a new technique called as “SBI – Situation Behavior Impact”.

Using this concept of giving the feedback, the recipient can more easily see that action he or she can take to continue and improve performance or to change behavior that is ineffective or even an obstacle to performance.

SBI technique is effective because it is simple and one while giving feedback, they describe the behavior you observed and explain the impact that the behavior had on the system or the team or the project.

Be Simple, Direct and Effective – Learn these 3 step and practice them regularly.

Remember capturing the situation is only the start of the feedback session. Here are some examples to start with:

  • “Yesterday during the Daily Scrum, while the team was discussing the status of XYZ user story ….”
  • During the Retrospective, while the team was speaking on a ABC issue ….”
  • This past Friday during the Release celebration cocktail party ….”

Specificity is important when recalling the situation. The more specifics and details you can use in bringing the situation to mind, the clearer you message would be.

Describing the behavior is next step to providing effective feedback. It’s also the most critical step and is often omitted, It is also the most difficult one to describe. The most common mistake is giving the feedback happens when judgments are communicated using adjectives that describe a person and the person’s action.

Consider the phrases below:

  • You were rude during the meeting
  • She seemed to be bored at the sprint review
  • He seemed pleased with the report as presented to management

These phrases describe an observer’s impression or interpretation of a behavior. Now let’s have a look at some other list of actions as observer might witness that would lead to those impressions and interpretations:

  • He spoke at the same time another person was speaking (Rude)
  • She yawned, rolled her eyes and looked out the window (Bored)
  • He smiled and nodded his head (Pleased)

The list of phrases as given above actual describe a person’s action. The focus is on the actual behavior not on a judgement as to what the behavior might mean. By focusing on the action, not the impression, Scrum Master can communicate clear facts that person can understand and act upon.

So when giving feedback using SBI, it is not only important to capture what is said or done but how it is said and done. You can capture the how by paying attention to three things: Body Language, tone of voice and speaking manner and word choice.

Body language is non-verbal communication can include facial expression, eye movement, body posture and hand gestures.

The final step in giving feedback is to relay the impact that the other person’s behavior had on the team, project or anything else.

By communicating the impact a behavior has had on the you (personally) or on the team or the project, you are sharing a point of view from your perspective. This would help build trust, which in turn can lead to even more effective communication.

To develop your effectiveness in carrying out the impact stage of giving feedback, practice putting your feedback in form of “When you did (behavior), I felt (Impact)” or “When you said (behavior), I was (impacted)”.

Putting it all together

Review the situation, behavior and impact steps that build effective feedback and practice those steps at every opportunity. Take time to reflect on your feedback efforts. Ask yourself “Why did I pay attention to this particular behavior?”, What does this say about me?

Reflection also gives you time to understand the true impact the behavior had on you.

You will in turn will benefit from developing a useful skill that not only helps to raise productivity of all people around you, but also bolsters your personal Leadership skills.

Improving people engagement and Retention – In an Agile World

One factor that impacts our ability as organization / project to have a consistent and predictable velocity is in-stability of our team members, we are in the industry, where employee stability is a major issue. This bring to my mind a bigger question, as to why organizations are not able to retain their best employees. It is important to remember that your best employee is the person who desires to leave, under performers do not leave.

Employee retention refers to the ability of an organization to retain its employees. Employee retention can be represented by a simple statistic (for example, a retention rate of 80% usually indicates that an organization kept 80% of its employees in a given period).

In addition to performing exit interviews to learn why employees are leaving, consider asking longer-tenured employees why they stay. Ask questions such as: Why did you come to work here? Why have you stayed? What would make you leave? And what are your non-negotiable issues? What about your team members, your scrum master? What would you change or improve? Then use that information to strengthen your employee-retention strategies.

Communicate your business’s mission and the current project vision. Feeling connected to the organization’s goals is one way to keep employees mentally and emotionally tied to your company.

In a recent research / survey done, it was identified that …

More than half (59%) of respondents believe that chief executive officers (CEOs) are focused on the numbers, rather than their employees, according to research by Coleman Parkes and the Workforce Institute at Kronos. The ‘The £60bn question report’, interviewed 500 people including business/operations managers, HR professionals, and employees amongst a cross section of UK-based organisations

An organisation that engages its employees will be more successful and profitable than one that does not. Organisations of today need employees who are psychologically connected to their work, especially in an economy of service and information industries

Engagement is not the same as motivation. Engagement is when employees are experiencing job satisfaction from a shared understanding of organisational goals that results in enhanced productivity or service levels. Motivation sits on a solid foundation of engagement. It is about firing up employees to achieve specific goals such as sales targets or meeting the defined and agreed service levels.

Employee engagement is not a tick box exercise. It demands a holistic approach to create the conditions that foster engagement. In some cases, that may mean driving a sea change in corporate culture. In an ideal world employee should be presented with a balance between the demands made of them and the resources they can access to meet those demands. Resources may be physical, such as having a laptop for mobile working, but just as often resources may be social or even emotional, in the form of support from colleagues and management. This type of support may look like a ‘nice to have’ but actually organisations derive much of their performance from it.

Just as importantly, engagement cannot be imposed on employees. There needs to be commitment to employee engagement at a senior level, and organisations need to recognise that Scrum Masters and Product Owners that provide support also need to be supported themselves.

Achieving engagement can have a dramatic motivational effect, resulting in low levels of cynicism and excellent performance. Employees demonstrate the best job performance in challenging, yet resourceful work environments. With engagement, a high workload can in fact be a positive motivator rather than a negative issue.

Low engagement can be seen through factors such as high absenteeism and staff turnover, as well as poor staff satisfaction levels as expressed in anonymous qualitative surveys. A Gallup poll found that engagement levels could be predictors of sickness absence, with more highly engaged employees taking an average of 2.7 days per year off sick, compared with disengaged employees taking an average of 6.2 days per year.

Conduct “stay” interviews. In addition to performing exit interviews to learn why employees are leaving, consider asking longer-tenured employees why they stay. Ask questions such as: Why did you come to work here? Why have you stayed? What would make you leave? And what are your non negotiable issues? What about your managers? What would you change or improve? Then use that information to strengthen your employee-retention strategies.

On a very honest side, I would have to say, that in my large expanded career, not a single organization has ever conducted with me or with others (that I know), a STAY interview, is this unheard of? Is that so difficult? Why do we react and try to retain an employee when they put in their papers, all of a sudden we wake up. Can’t we have a type of alarm done to spot these elements and be pro-active … We have also failed to apply the basic principle.

Risk Mitigation is always cheaper than Issue resolution … or put it in simpler approach. Prevention is better than Cure …

I am not sure if in my life time of career … I would see this change coming in … we are heavily engaged in target meetings …. Without understanding the basics, that it is the people who would help us meet the target.

Uninspired Team – Reasons why your team is not fully engaged

As a scrum master your main role is to ensure that your team stay motivated, productive and more importantly happy. It is also your job responsibility to identify what is causing them to be de-attached with the system, why are they non-responsive, what is causing them to be dis-engaged and uninspired so you can correct the situation

Inspiring teams is not about just keeping your employees happy. It’s about having well-defined roles that allow your people to advance in their jobs as well as make meaningful and useful contribution to the company goals.

Let’s explore a few reasons as to why teams might be feeling uninspired:


You Demand Perfection

Perfection seems like a recipe for success. But when good is no longer good enough, your team will have a hard time starting things and an even a harder time finishing them. Great leaders don’t complicate things by obsessing over every last detail. They understand that solution is to simplify things. Allow your team to choose something that they think will work and let them give it a try. If they fail, consider it as a learning experience and move on to the next assignment / project

You are not approachable

Too many times managers lock themselves in their office claiming to be busy the entire time. What they do not understand is that being approachable is essential to building inspired teams. When you’re approachable your team can comfortably discuss the latest happening with you and will not try and cover up problems once they arise. This also allows your team to share new ideas with you and they will be confident that you are open to their suggestions.

You Mirco-Manage your team

If you keep insisting on doing things your way, don’t be surprised when you team stops pushing for a change. A micro-manager is someone who holds back on delegating and focuses on minor details and discourages the team members from taking their own decisions. Micro-Management is now an old style of management and is no longer productive in trying to control all aspects of the team’s work. It hurts the team morale and productivity, and is often ranked as one of the top reasons why employees quit

You Cannot tolerate mistakes

If you want to have a creative, innovative and inspired team, you need to give them the permission to fail. If you respond to mistakes and unsuccessful ideas with disappointment or blame, your team will be de-motivated and dis-couraged. However, when you turn challenges into a learning experience, you build up the confidence of your team. Create a culture of creative confidence, which is the ability to come up with new ideas and trying them out. Change your team’s mindset from being risk-averse to being empowered to seek new ideas, thoughts and endeavours

 You Hired a wrong team  

The success of your company depends on the people you hire, if you team seems to be uninspired for good reason, then there’s something fundamentally wrong with your hiring process. It’s either that your employees are not well informed about what is expected of them or you just don’t know what you want in the hire. Successful recruitment is never an easy task. You need to look for successful patterns that have worked in the past to guide you through. Super performers are out there, but just as in good old days, you may need to do some detective work and to actively seek out the people who will turn your company from good to great


Servant leadership is no longer about managing and stepping back, it is all about identifying when to step back and allow the team to take the control of the situation and doing it on their own. It is all about guiding the team to do better, achieve higher altitudes.

Yes, I agree we all are humans and have a legacy approach of command and control, it is difficult to do away on day one, the old thoughts and embrace the new world, but if do not change now, we shall never change, do not expect the team to change, the change has to start from one own-self and that is difficult, but again not impossible …

Parenting and Agile Team – A Case of similarities

There are only three things you need to be a good parent – patience, patience, patience. What about love, affection, attention and other such things, you’d ask. Sure, that’s important as well. But while those things, in most cases, come naturally, patience is something that needs to be cultivated. The lack of patience leads to stress. Stress leads to frustration. Frustration leads to anger. And anger leads to bad parenting.

Now think about this in terms of developing a matured Agile development team and you’ll realise where this column is heading. Parenting and developing a good matured – self-disciplined Agile team are both long-term processes. The immediate effects of any decision that you take are rarely satisfying, but the long-term results can be copacetic if you have the patience. Ironically, you need to be patient to cultivate patience. And that is not easy. The developing teams, much like your children, will behave erratically. They’ll do things that are out of your control. The more you try to be patient with them, teams as well as children, the more they’ll make you lose your patience. It’s a vicious circle.

But there’s no way around it. If you lose your patience, you lose the chance of enjoying the fruits of your efforts. Somewhat similarly, to young one who would behaves like an angel on some days but on other days, they won’t eat her food properly, will throw around their stuff when one has guests over or just be unrelentingly stubborn about something they wants. Such instances are when parents easily lose their patience. But scolding or smacking the kid is hardly the solution. Just the way stopping your teams when the process will fail.

These are decisions that are taken under the influence of impatience. They’re almost guaranteed to fail. I know children aren’t going to become the best-behaved young one in the world if I scold them, but they might listen to me if I calmly keep telling them why they should or shouldn’t do certain things. Whereas Agile teams are expected to have a mind of their own (as they are supposed to be self-disciplined and self-managed), which makes it even more futile to lose your patience with them. Just stick to your approach and plan and you’ll be set to meet your goals and objectives. The agile team’s misbehaviour won’t matter in the long run, but any decision you take after losing your patience will.

But there’s no way around it. If you lose your patience, you lose the chance of enjoying the fruits of your efforts. Somewhat similarly, to young one who would behaves like an angel on some days but  objectives. The agile team’s misbehaviour won’t matter in the long run, but any decision you take after losing your patience will.

My grand daughter, who is 5 year old, operates my Samsung note better than me. Contemplating on why is it so – I spend almost couple of hours on note everyday myself – I realized that what makes her better is her childlike curiosity.

This curiosity to learn something new, day after day, every day.   When was the last time you learnt something new?  When was the last time you took a conscious step towards self-development? Curiosity to learn something must be backed by an innate desire to improve oneself, to become the best version of ourselves. It is the only way to remain relevant in the hyper-competitive markets today.

The same concept should be applied in the Agile projects, we are always running after getting the user stories done and churned out for the product owner. Yes, this is required, but one should step back and take a different view, are we learning anything new, have we added value to our existing knowledge base, are we much better skilled as compared to the start of the sprint, can we proclaim that we now know a trick or two.

When speak of adding value to our customers, shouldn’t we not add value to ourselves, as we are the first customers to ourselves

We always talk and speak about the improvement in velocity and team work, that cannot happen automatically, the organization needs to invest in this area, by providing and allowing a time-box element to each and every member of the team, I recommend a time-box of 5-10% of the sprint time allocated to each team member of the development team (on a different thought, it should include the scrum master and the product owner also). If the sprint cycle is 2 weeks (10 days = 80 hrs.), then the minimum time-box would be 4 hrs. / sprint to a maximum of 8 hrs. / sprint.

Organization should be aware that providing this time to learning and development will reduce the velocity in near term, but there would be major impact in terms of quality, knowledge gain, productivity improvements, team collaboration.

This time allocation should be used by the team members to improve their skills in any area of their interest, which would ultimately help the product to develop and grow better and thereby improve the required velocity. It should be the task allocated to the Scrum Master to ensure that all the team members are using this time-boxed element in the most productive way. One also needs to understand that a Scrum master would also be required to improve and master the skills that are important to the role that he / she is playing to.

Each sprint , the team should have a dedicated time and name it as – ‘Learning with Agility’.
• Define a dedicated time slot. It would be a good idea to have a time slot of 4 hrs planned in the early part of the sprint cycle in week 2
• This week, every sprint, learn a new thing – pick up a functional skill from a colleague, or improve the product knowledge, master an automation tool, learn new elements of coding (do a little unsaid spike)
• learn about a behavioural skill

Learning is not about mastering the hard skills, it includes all those elements that make you a better team member, a team player and more so a better person

Your learning is in your hands and you are the product owner of the product that is you. Take advantage of the fact that you spend 8 hours every day most of the week in an organization that promises you learning opportunities. You have, at your fingertips, access to a whole host of behavioural learning through social media , hundreds of thousands of articles in web, , ride the huge wave of Massive Online Open Courses with the many courses that are available online freely – make use of all these resources to better yourself today.

The above mentioned are but a few of the avenues for learning. Such platforms are present everywhere – the internet, libraries, even in day-to-day interactions with colleagues, it’s you who has to take the first step.

At the risk of re-iterating, I’d say again – that the onus of your learning lies with you. No one can help develop you but you yourself. This week and for the ones to come, promise yourself a week full of rich learning.

The day you stop learning, is the day you stop practising Agile ….. So Learn each day and be agile every moment

Agile Scrum – Nothing more than a COMMON Sense approach

Last few years has really seen the growth of Agile – Scrum adoption in the IT Industry. Organizations are adopting dime by dozen concept in moving towards Agile. Every Software person (whether a developer or tester) is bent on adopting and having the agile experience on their resume / profile. Well nothing wrong with this, But if all (or should I say most) of the organizations are adopting agile and its related frameworks and all the workshops are going full, why the quality of the SW delivered has not improved in the same proportion, Are we not having things which are behind schedule?, are we not working late to complete the commitments that we have given?.

Same happened with Lean applied to manufacturing; people learned the Toyota-ish words but didn’t embrace the philosophy. We all have got certified in various elements, but have not improved. Well, i ain’t talking about the improvements exponentially, but at least by some percentage. So do we say that the agile model is fundamentally faulty or it is our adoption which is creating the unnecessary trouble.

If one thinks that Agile is defined by buzzwords, it is no wonder you not sure can will come or can’t, to me it should come can make it work. Agile is a mindset that leads to:
• Centralized change management to projects
• cutting projects into manageable chunks,
• Insisting on end user ownership, etc.

One of the areas that the industry has defaulted itself is in the area of focusing on Project Management and forgetting about Software Engineering piece of the system. We have conveniently forgotten the idea that every coin has two sides and unfortunately we have focused only on one side of the coin in agile

Just because you’ve travelled in a CAR doesn’t mean you can drive it (like for me, “I can travel in CAR, but cannot drive the same”). Same thing with an agile process, too many people use the buzz words and get the quickie certifications that the industry requires in order to get the job. They did the same thing to RUP, OOAD and OOAP when it came out; everyone was doing it theoretically, yet they really didn’t apply practically and that’s where they failed. If you’re going to say you are using an agile process then really learn it, really do it, and really be it or stop saying you are agile and find something else to blame piss poor requirements, design, and software on.

Personally, for me, Agile Scrum comprises of good common sense elements, doing small things, and doing regular and periodic delivery to the customers / clients or management / end user (whatever the case may be). My concept of Agile is to deliver less, but deliver of good quality, Even if one delivers a great amount of software, but if it does not work at the customer site, how does it really matter. But as they say these days “COMMON SENSE is NOT SO COMMON”.

My belief is that there is a wide range of people using the term “agile” but of these also there are two types of people
1. Some people have a lot of experience doing software development and can use it to create much better software.
2.And other are those people who use the term vaguely in order to sound intelligent and flexible.

There is a fundamental understanding flaw of what agile development is about. There are many people who see agile as anti-process and an excuse to work in an informal and ad hoc manner, While the actual objective of agile development is to follow an agile process and not eliminate process completely. There are unfortunately companies who operate in a chaotic manner and try giving this approach legitimacy by calling it “We Work the Agile Way”. On the other hand, there are companies which, using an agile methodology in the way it was intended, have seen great success.

Agile is abused as a methodology, particularly in India, where there is a culture of pathetic unplanned and managed software development is prevalent. Most of agile principles are not followed and adhered to… It is more of a jargon that is used in the industry to boost up a few resumes and profiles. It is quite surprising when we get assignments to have resources certified for CSM (Certified Scrum Master) or PMI ACP (Agile Certified practitioner), because the client / customers who are giving business to my local clients (In India) want certified resources on the project, I am not sure if the customer understands that getting a certificate and implementing the practices in true spirits are two different ball games… but alas who cares and why should we. On one hand we are getting business (so I am billable) and secondly the resource is getting a new additional element on his / her resume, who would complaint and not sure if the original customer, over a period of years has performed a ROI or cost benefit analysis of having all the resources working for their project certified of any value ….

The bigger question for me is yet to be answered … our management, customers and clients want agile to be practiced, how many of them even understand agile, have they ever got oriented on agile, do they understand the basic principle and thought process behind agile … I afraid not ….

In my long experience in IT industry and more specifically in SW development, certain things are consistent, and they aren’t Waterfall. Project Managers want software rushed out, often on the basis of inadequate specifications. They want something now, and they’ll worry later about having something maintainable. Developers don’t like to comment their code and don’t particularly like to take the trouble of documenting their unit test plans and so on …

One should not forget that we live in the real world, we are also the development team who would have to maintain the previous developers’ uncommented, unplanned spaghetti code, and that isn’t fun. We’re the ones who’ll have to deal with unexpected changes later on, and that will be hard if we wrote novella-sized subroutines that do everything. We should be pushing the idea of communicating with users without swallowing the whole package of bad design practices. Maybe that could have its own element or buzzword.

Could I rename it to Sensible /Common Sense way of SW Development, anyone?

Matured teams – Do not create great Scrum Masters

Disclaimer – Not many may / would agree with the thoughts as expressed in this post.


A successful Scrum Master must lead by example, must have an open mind to listen to others. A good scrum master is the one who is able to visualize the future for the project and lead the team in that direction. A good scrum master has a deep sense of commitment to the project, its stakeholders and more importantly to its team, He should be a person with a lot of passion about the future. Guiding the team from the front in times of crisis. Scrum Master should be constantly encouraging his / her team to get the very best through his infectious energy and unwavering optimism

When you have a matured team, which has worked together for many products and sprints / releases, they start to develop understanding of each other’s behaviours, skills, strengths and areas of improvement. They have worked together for a longer time, they have good coordination across and among the team, They excel technically well and are producing the outputs as needed and required with quality built, In such a kind of scenario, Scrum Master would be relegated to back seat, as the process of Scrum would be typically on a cruise control mode. Having said this, I do not mean, that there would no issues / impediments to resolve, but they would far and few due to internal coordination of the team.

A matured team is excepted to have a climate of trust and openness, that is, a positive atmosphere. A positive atmosphere indicates that members of the team are committed and involved. It means that people are comfortable enough with one another to be creative, take risks, and make mistakes. It also means that you may hear plenty of laughter, and research shows that people who are enjoying themselves are more productive than those who dislike what they are doing. In such a scenario, the role of the scrum master is to provide minimal inputs, as the things are working
Trust is by far the most important ingredient of a positive atmosphere. Matured team members reach a point where they can trust one another. Trust and credibility can be described behaviorally. They can be seen in a more logical way than you might think. Consider this …. What do people need to do to build trust with you?

What came to mind first? Was it honesty? Dependability? Sincerity? Open-mindedness? For a tenured team, all these elements would already be factored in …

A mature team, by definition, also offers little room for bigger improvements and growth. Even if you succeed in making room for yourself in the team, it is difficult to find new processes and introduce significant innovations that push the team forward. This challenge also introduces a key benefit of entering a mature team with a strong, innovative thought process. However, finding new ways to distribute ideas or attract interest from the team is tough.

It is important for us to understand that going from ZERO to SIXTY is much simpler, easier and faster as compared to moving from NINETY to NINETY TWO percent, as the areas for improvement reduce and the smallest of improvement takes a longer period of time to implement.

The costs to enter a mature team successfully are usually high. It takes much more time, effort and energy to enter as a new minted Scrum master, because you have to establish a reputation and promote yourself to get team to understand you and move away towards a new thought process. You also have to invest in research and development to give team something distinct in your ideas and thinking.

The opportunity for the scrum master to demonstrate his or her skills in this kind of an environment, gets limited and this would reduce the elements of learning and improvement for the scrum master. It is important for us to realize and appreciate that rough seas, make skilful and great sailors, smooth seas would not, the same analogy can be applied to the Scrum Master scenario also. Grooming of an individual is also a function of exposing the person to variety of elements, situations, challenges and more importantly sufficiently empowering them.

When we have a new team freshly minted, there is a huge amount of opportunity for the scrum master to demonstrate and utilize the skills, as issues, knowledge, processes, approach would all be required to be explained to all , there would be high amount of coaching, mentoring opportunity available for the scrum master. Scrum Master in such scenario’s would be required to use his skills to the full potential, as the team is new to agile, new to this concept, may be working together for the first time, exposure of small deliverables and increments.

Many a times it has been observed, that post the training of certified scrum master, the person / resource is now supposed to act as a Full time, well prepared Scrum Master, it is as good as learning to drive by reading a manual. This thought process needs to change in the industry.

New Scrum masters may be paired with veterans. Innovations and new thought process should be encouraged. Different personalities, voices, values, and approaches spark interest, keep attention, and prevent boredom to the team also

A good scrum master should and always emphasize that all five fingers are equally important and each of them has a role to play in perfect synchronized coordination of any act by a person. The same hold true for the a good agile team

As we say in Agile, that the team should be allowed a set of time to improve, excel and learn new elements each sprint / iteration, the same logic needs to be applied for the scrum master also, We need to ensure that the scrum master also upgrades his skill sets at end each sprint.