Wednesday, July 28, 2021

5 Scrum Myths–Busted

Myth 1 – Scrum is a Methodology

To bust this first myth, I would prefer to differentiate between the concepts of methodology and framework clearly.

Methodology 

A specific methodology is a well-defined set of principles, concepts, tools, and associated practices that guide processes to meet a focused goal. The methodology is fundamentally more prescriptive.

Framework

On the other hand, a framework is a flexible yet incomplete structure that leaves space for different practices and related tools requisite for the overall process. Thus, a framework is, practically, less prescriptive.

People often refer to Scrum as Methodology.

Scrum is, from a practical point of view, not at all a methodology. Instead, professional scrum master focuses on the scientific implementation of empiricism. As a result, it strikes the chord between well-defined principles and associated practices in a balanced manner.

Self-Managing teams and their dedicated, collective intelligence form the basis of Scrum. The teams solve varieties of complex problems through a series of adaptive solutions.

Myth 2 – Agile is equivalent to Scrum

50% of people I interact with using the terms Agile and Scrum interchangeably. When they say something like ‘We are performing or doing Agile’, they mean they are doing Scrum. On a practical note, these two things are not the same. 

Scrum is invariably a technical, lightweight framework. It strategically helps teams and organisations generate value via adaptive solutions suitable to solve various complex problems.

Agile covers a larger arena with a well-defined set of values, concepts and principles. Scrum does fall under the expansive umbrella of Agile, but there are many other concepts like it.

In addition, implementing Scrum never means you are agile. To become agile, developing an agile mindset is extremely important. Implementing Scrum doesn’t guarantee that you would become Agile but certainly helps build habits that can enhance Agility.

Myth 3 – Cross Functionality means each team member should perform every task

A cross-functional team is an efficient group of people who have a clear goal, representing various disciplines under the concerned organisation.

The combined efforts of the team are meant to add value to the process. Scrum teams are, by nature, cross-functional. This does not mean every team member would display every kind of skill. It means the cross-functional attribute of the Scrum team would benefit the team and organisation from an overall perspective.

It is impractical to expect each team member to be well-versed with all the available technologies and skills in the current competitive world. Instead, a top-class Scrum team knows how to value team members with multiple skills.

Myth 4 – Velocity is an intrinsic element of Scrum

Most of the Scrum teams use the concept of velocity for forecasting the probable completion dates. But it is technically a purely complementary practice within the realm of Scrum.

There is no need for the Scrum teams to leverage velocity as one of the metrics. This is because Scrum Framework does not consider velocity as one of its intrinsic elements. Still, many Scrum teams continue to do so. This is reasonably good when velocity is not regarded as a commitment.

Myth 5- The Product Owner decides the sprint goal.

Scrum tells that Sprint’s single objective is the Sprint Goal. It is specifically a commitment by the developers. I frequently hear that the Product Owner is responsible for determining the Sprint Goal during Sprint Planning. It is not at all true.

The Product Owner has a particular Business Objective. He coherently communicates it to the self-reliant Scrum team.

Fundamentally, the Sprint Goal is rigorously and strategically a collaborative effort involving the whole Scrum team. Scrum guide never says that the Product Owner decides the Sprint goal.

Any Other such Scrum Myths you have heard?

In this write-up, I have busted five myths related to Scrum. In your organisation, have you come across any other myths? You can share whatever thoughts you have in the comment section below.

Resource: https://www.tryscrum.com/blogs/5-scrum-myths-busted/

Tuesday, July 20, 2021

What is Manager’s role in Scrum?

There is one frequent question that I encounter in my workshops. There is a piece of information that is missing in the Scrum Guide. Interestingly, It is regarding the managers. Where is the role of Manager in Scrum? The missed-out information makes many organisations confused if they have a similar place and adopts Scrum or present an Agile transformation.

While there are apparent intermediate paths present for the managers and other senior leadership position holders, the unclearly defined middle managers often question the roles in official Scrum they fill. What are they? Are they product owners? Or a scrum master? Or developers?

It can be a challenging leadership problem and problematic to resolve. However, there is no direct and clear answer to the query. For clearing the dilemma, I have to recall the elementary difference between a project and a product.


Project Vs Product

As you can notice, agile product owner certification in Bangalore focuses directly on products; thus, you have a Product owner. In traditional project management, the success of the project gets measured against scope, time and cost. Thus, the process leads to lesser value management and focuses on task management.

In contrast, the product mindset gets derived from the outcome, and the project mindset is activity. In traditional management, all three variables get managed by the project manager.

In a product environment, all the variables receive collaborative management.

For example, the scope and time get handled by the Scrum team, while the cost is by the product owner. In such cases, the confusion lies in the manager’s role.

Role Mapping

Direct one-to-one mapping is the way out for most of the executives of the organisations. We are following the Agile transformation. Thus, all these people will get a role in Scrum, and the rest of the group will get another position in Scrum. Among all these, I encounter a common idealogy in one-to-one mapping: taking the project management office and turning them into scrum masters and taking the business analysts to enrol them in product ownership roles. But, as per my point of view, it is not a great solution.

Is there a superior approach?

A “try scrum” entity identifies how to determine and focus on the individual strengths of each employee. It is very crucial while undergoing an Agile transformation. If you know who will fit best for each of the roles, acquiring success gets easier. Also, considering the individual’s passion helps in redefining the new responsibilities.

Now, let me get back to the original doubt.

Where is the role of Managers in Scrum? Do we need them?

There is no direct answer to this. My answer to this question will be; it depends on the organisation. Considering my experience, managers can play enablers. Although there is no buzz about Management in Scrum, managemental aspects are present in Scrum.

According to the Scrum Guide, Scrum looks after the existing effectiveness of the management, environment, and functioning ability to improve them. In other words, it challenges the way that the Organisation works to create value.

Scrum is not a methodology. It deliberates gives the choice-making to the management. It allows the business to get structured rightly and organise itself to get better. Considering from my viewpoint, managers are certainly enablers and can perform varied responsibilities.

Leading in a Hybrid World

Every middle manager may not be suitable for the role of product owner or scrum master role. It leaves the scopes of uncertainties. But you need not worry. Despite having no role as a Scrum manager, it does not imply requiring them. Instead, it signifies that their role and responsibilities vary.


We primarily work in an environment that got created on traditional, plan-driven, and top-down principles. We are gradually transforming towards a self-organised and empirical environment. It gets designed for the complex domain. Leading an Agile team refers to making the people more successful with dynamicity. It is one of the major responsibilities of a manager. Among the many responsibilities of a manager, the following are a few significant ones:

·       Developing an environment for the growth of the Agile team

·       Work towards and organisation and scrum teams as a serving leader

·       Reconstruct the obstacles that hamper the growth

·       Proactively work on continuous improvement, self-improvement, feedback, adaptability.

·       Helping the team to succeed.

Conclusion

To conclude, Scrum does not have a role of a “manager”. It certainly does not imply we do not necessitate one. Ultimately, capitalising on individual strengths for transforming them to accomplish the new roles helps the organisation and individuals equally and leads to success.

Resource: https://www.tryscrum.com/blogs/what-is-managers-role-in-scrum/

Thursday, July 15, 2021

The Dynamics of Team Coaching With ICP Agile Certified Coach

Coaching an individual varies largely from the process of coaching a team. What is a team? It comprises more than one person, and they collaborate to work. Thus, the coaching also needs to have a distinct approach. Nevertheless, the essence is the same; the approach and the skills play the distinguishing part.


What is team coaching?

One-on-one coaching focus on a single person, while working with a team needs looking after more than one factor. When you are coaching the team, you cannot focus on one aspect. You need to analyse first the dynamics of the team and the comprising elements. The way you coach them will bring on further opportunities to excel beyond their existing capacities.

Coaching concerns

Unlike individual coaching, when you deal with a team, you always look for an overall result. A good ICP agile certified coach uses the team to build a better bonding and understand the overall factors in concern. Focusing on individual needs leads to resource wastage in these cases. Instead, use your experience and practical outlook to manage the team essentialities while coaching.

Focusing factors

It gets tricky when you sit to jot down the factors to focus on while team coaching. It takes up combined effort to facilitate team learning as each one plays a part. Gain better insights and alter the ways depending on the goals. There is no single rule to stick to as the dynamics are changing practically. However, the critical factor to focus on always lies in the overall growth and improvement. There are a few things I would like you to consider when coaching teams.

·       Unpredictability concerns

Team dynamics are not predictable. Every individual act distinctly, and that is the essence of team building. Everyone has something different to offer and a varied capacity. Identify that and implementing ways to put that into yielding a productive outcome. Be comfortable in dealing with ambiguities and direct yourself in the right direction.

·       Boundary making

Setting a boundary at a one-to-one level is more effortless. With a team, you require a distinct approach. You get to explore more than one aspect while dealing with a group and agree to terms with that. Focus on gaining ground at three levels –

1.     Individually

2.     As a whole

3.     Organizationally

·       Consider long term

Expecting an immediate result with team coaching is unwise. It is easier when considered from an individual level. But with multiple factors playing a part, it is harder to reach a concrete goal at once with a team. Do not put too much pressure, instead be determined and patient. Introduce newer ideas and let them flourish with time so you can gain an impacting outcome.

Ways to provide coaching at your organisation

Functioning as a coaching leader at your organisation takes a mindful approach. When you coach a group, the coaching conversation needs to be careful. It should not exhibit a judgmental or pressuring atmosphere as it will act reverse.

·       Clarify first: Be clear about the performance and your aim. When a team gains insight, it is easier to act rightly in accordance. For this, clarifying what you wish to achieve gets an effective outcome.

·       Developing rightly: Developing through discussion is a productive way to look at the coaching. It successfully avoids difficulties while operating. Share and influence to coach them right. Do not hesitate in cases of ambiguity, instead asses the situations to drive them right.

·       Understand better: The critical step is to understand the team and then set the boundaries. Proper analysis on your part saves a lot of effort in the actual process. Organisational demands are constant but pressurising is not the solution. Instead, encourage productive collaboration to extract the best from the team members. 

Wrapping up

Achieving fast does not always mean gaining rights. Instead, work slowly but steadily towards accomplishing the overall goal. Remember the three key steps:

Introduce: Give room for a fresh perspective to find newer solutions.

Break: Alter the ways to refresh the usual way of thinking and acting.

Share: Providing a glimpse of your struggles makes the team identify with your more.

I have shared my views based on my experience. What has worked for you? What did not work for you? I would love to hear your perspectives.

Resource: https://www.tryscrum.com/blogs/the-dynamics-of-team-coaching/