From becoming a certified scrum master to learning how scrum training works in the first place, Leadership Tribe is here to work with you every step of the way. Learn how to work with various team members with our insight blogs and videos.
The 17th-century English philosopher Thomas Hobbes had discovered an interesting theory named the ‘Hobbesian Trap’ – when one is gripped by the fear of being attacked, he pre-empts by arming himself, which instils fear on the (would be) ‘attacker’ who in turn upgrades his arsenal. This action escalates the initial fear and forces the ‘defender’ to upscale too, leading to an uncontrolled spiral (the Arms Race). Whilst the analogy may seem off-the-track with Agile and Management, the illusion of the Hobbesian Trap applies to all aspects of human psychology, especially in the realms of coaching and consultancy. When a decision needs to be made between a coach and a consultant, one is put in a dilemma – Who can help the business to improve profitability / produce a higher return on investment / enhance customer satisfaction? The answers to these questions may lead to a spiral of uncertainties. Most business owners face the Hobbesian Trap when it comes to hiring a consultant or a coach, on the sheer premise (or fear) that one is absolutely needed for the business, while having little or no knowledge of what role they play in the company’s growth or what they can help the company to accomplish. The Coach
A Business Coach is a facilitator and enabler. He/she triumphs over your accomplishment and his/her primary job is to enhance and sharpen your skills to ensure you achieve your goals. Coaches work ‘inside out’ – they assist you to develop purposes and reasons, which help to generate desired behaviour in your business. Business coaches also help to address issues with regards to the mind-set or unconsciousness, such as limiting beliefs, fear of unknown and the ‘Imposter Syndrome’. They build a supportive environment with clarified accountability to ensure you follow through your actions to completion. In summary, a coach facilitates you to define your goals for your business and the “plan of action” to achieve them, and he/she stands by you through the process of implementation.
The Consultant
A Business Consultant is a subject matter expert who addresses specific issues to influence your business positively. He/she provides the knowledge, skills and competencies, to analyse your business and propose a solution to the problem, and customises an action plan to implement the solution. A consultant employs his/her extensive experience and knowledge in business planning and strategy to gauge the scalability and direction of your business, course-correct specific domains such as optimising sales and marketing strategies, streamlining systems and processes, reforming organisational structure, and so on. A business consultant brings a fresh opinion, objectively assesses the current state of the business (‘as is’) and helps to shape the target state (‘to be’), creates and implements an action plan to accomplish the business objectives.
Who Do You Need?
The key to unravelling this mystery is to enlist the services of both to support the internal and external mechanisms of your business. That being said, it does not mean that one needs to hire a coach and a consultant – instead, one can be upskilled to step up to either of the two roles with adequate resources. It can be argued that in comparison it is more feasible to be upskilled as a coach than a consultant, as the functionality of the roles suggests. A Coach tends to be more ‘people-centric’ and an Agile Coach operates on the principle of ‘people over processes’, who can be possibly better in understanding this other than the business owner himself?! Of course, the assumption is more appropriate for small enterprises and large organisations would need to engage external coaches to offset bias in work ecology. It is important that the need to be trained as coaches at the Executive level is not dispensed with. It is more to do with people than the task at the senior levels of the organisation, and when it comes to determining a coach/consultant one needs to introspect on three key areas:
The quality of intrinsic knowledge existing in the business
The strength and robustness of the support structure on which the business resides
The quantum and time-sensitivity of the target results
Knowing the difference between a business coach and consultant can help one to avoid the Hobbesian Trap, therefore save costs and avoid disappointing outcomes. Agile enables you to be clear and upfront on the level of knowledge, support and outcome your business desires, and assists you in making the right decision. It obviates you from getting into the trap. It is crucial for one to understand the organisational requirements, and upscale the corporate strategy by deploying an Agile Coach or an Agile Consultant (or get trained as one), or both as per the merit of the situation, to achieve the desired result.
I have been working as an Agile coach for one of the top-tier companies in the world. I want to share my experience working with leaders and teams in regard to Agile metrics. To give a high-level background, one of my clients has adopted the Spotify organisational model — Squads/tribe/chapters and guilds.
FORMING AND TRAINING TEAMS
In the 1st quarter of 2017, I was working an FTSE 100 company, whose objective was Agile adoption and transformation across CIO (more than 2,500 people). We had different domains and subdomains under CIO. A coach was assigned to work with each domain. We started with forming the right teams, doing the right work, and measuring what mattered. The entire 2016 was marked as Wave One — to form the right teams; enable the team members, including the product owner; and train them on Agile principles and values and the basics of Agile (mainly Scrum and Kanban). We also worked on-demand versus delivery management in parallel with forming the teams.
After our teams and workflow system were in place, we worked on capturing the Agile metrics. We agreed to capture the velocity, story points, burn-down/burn-up charts, defect trends, throughput, and cycle time as a few of the key metrics. The Agile Wave One was completed in January 2017, when we (55 coaches across the globe) had finished training 2,500 team members on Agile adoption and implementation.
During the reflection/relearning session from Wave One, we were clear on the metrics we were capturing for the end of each sprint. Leaders were keener on getting the metrics that rolled up into their respective tribes, subdomains, and domains but had no clue on how to interpret the numbers. And leaders were also trying to compare the velocity across squads and tribes; it was just a numbers game at the end of each sprint.
CAPTURING AND COMMUNICATING METRICS
I was interested in discussing with the squads what we should measure. Was measuring velocity and story points helping the squads get better? And did they receive feedback from management on the metrics the squads submitted at the end of each sprint?
The outcome of the metrics discussions was that the squads felt that it was not about measuring the velocity for each sprint that mattered; it was more important to study the trend of the velocity for each squad and analyze the variations/deviations, which would help the team get better and course correct. They concluded that the trend analysis should be done at the individual squad level and not compare the metrics with other squads. A few team members also felt that velocity was more of a predictable number, and the real measure was the value delivered to the customer at the end of the sprint. There should also be a benefits realization of the work done by the team (i.e., Product is responsible for cascading the value and benefit realization to the squad).
KEY METRICS
Metrics are used to measure four key aspects: people, customer, financial, and process. Then balance your metrics among outcome, process, and behaviour.
People: Team morale or team satisfaction; attrition rate or skills gap
Customer: End-user satisfaction or number of defects
Financial: Unit cost per transaction or total cost of whole operations
Process: Throughput or cycle time; the size of the backlog
Takeaway: Don’t focus solely on the numbers. Observe trends. Plot the data over time to determine whether there’s an improvement or fallback.
It is not always about metrics, metrics that matter to the team. Rest all is nonsense!
It is vital that metrics be maintained daily or weekly, and that you are consistent in the way you measure them.
Keep the metric simple: Measure only what matters, not more.
Make big visual charts of the key metrics, and put them up on the walls for viewing.
Leadership Tribe has been helping organisations in their transformation journey and we are here for you. Contact us directly and we can have a quick discussion over a cuppa to support your Agile Transformation.
We all have been studying/doing/practising Scrum ceremonies for years now and we all agree that the Scrum ceremonies are key for the teams and projects success.
I have been working with teams in my organization with regards to Scrum adaption and implementation, as a part of team enablement or training, I thought of applying a different training technique, to understand and learn about Scrum practices/ceremonies. The best I could think of was Simon Sinek’s Golden Circle Theory.
What made me think of using the golden circle theory, were few of my following observations working with Scrum teams, every scrum team in my organization knew ”What” they do as a team, with respect to scrum practices and some of these Scrum teams knew “How” to do it and this very factor made these Scrum teams special from others in the organization, as last very few scrum teams knew “Why” they are doing what they are doing? That’s the outcome or results they are deriving at and it’s the whole purpose of adapting the scrum way of working and scrum transformation.
Here are the ceremonies with respect to ‘Why, How and What’ behind it…
Sprint Planning
Daily stand-up
Sprint review
Retrospective
Let’s look in details for one of the Scrum practice as an example…
Sprint Planning: An event where the team collaborates on the work to be completed in that particular sprint. Entire Scrum team participates in the sprint planning event.
Why we need it:
To understand and establish the sprint goal(Outcome)
Commit to the user stories that help us achieve the sprint goal
Derive at sprint backlog(Output)
To discuss and define the sprint goal
What and How we do it:
The scrum master, Product owner and agile team are part of this meeting.
The Product owner talks about the highest-ranked user stories from the product backlog
The agile team derives at the steps required or tasks necessary to complete the committed user stories
Planning continues while the team can commit to delivery without exhausting or exceeding the capacity.
Sprint Planning is time-boxed to a maximum of eight hours for a one-month Sprint.
Sprint planning answers two things: What can be delivered in the Increment resulting from the upcoming Sprint? And How will the work needed to deliver the Increment be achieved?
Why we need it:
Stand-up unifies team
The team holds each other accountable for their commitments
Teams are transparent about the challenges, success stories and failures
Respect for individual irrespective of their position and performance
Stand-up meetings help the team to focus on a few
The team helps each other
What and How we do it:
Tell about “What you accomplished yesterday”, “What are you planning to accomplish Today” and “Obstacles/impediments which are blocking you to perform”
Try using the following format:
What did I accomplish yesterday?
What will I do today?
What obstacles are impeding my progress?
Any other discussions to be taken offline after the daily stand-up
We walk the wall- talk our cards
Meet at workspace before your scrum/Kanban board, so that you can update the board as you talk.
Time the meeting to <= 15mins
Rotate the facilitator based on the agreed-upon rules. (Every 3 sprints)
Don’t wait for the entire team
The team should be prepared ahead of the meeting
Have agreed on rules about who speaks when
Avoid talking about technical details in the stand-up
Core team, BA and PO/PPO to be part of the daily stand-up
Sprint Review: Sprint review is simply the meeting where the team demonstrate the work done or functionality built during the sprint.
Why we need it:
To inspect and adapt the work done during the sprint.
Assess the work done against the sprint goal, which was agreed upon during the sprint planning.
Make sure the team delivers a potentially shippable product increment of working software
What we do:
Setup the expectation at the start of the meeting, with regards to what will be demonstrated.
The team members will demonstrate the new functionalities built/developed in the current sprint.
Can also talk and discuss the upcoming product backlog.
How we do:
Either the product owner or Scrum master will facilitate the sprint review meeting.
Can last up-to 2hrs for a 2-week sprint.
The entire team participates in the meeting
Close the meeting thanking every participant.
Retrospective: At the end of every sprint, the scrum team reflects on how to work more effectively and adjust their actions and behaviour as needed.
Retrospective Prime Directive:
It’s crucial to have an open culture in an agile retrospective, where team members speak up. In his book Project Retrospectives, Norm Kerth defined the Prime Directive, it’s purpose is to assure that a retrospective is a positive and effective event:
Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.
Scrum suggests 3 roles (The team, ScrumMaster, and product owner), four ceremonies (the sprint planning meeting, Daily Scrum, sprint review meeting, and sprint retrospective meeting), and three artifacts (the product increment, product backlog, and sprint backlog).
A ceremony has three primary elements in it. Firstly, it is a recurring activity that is periodic in its existence. Secondly, it demands a certain form in conduct and protocol, and third, it needs to be time boxed to be effective in its implementation. Finally, the unspoken – practices change behaviour or Do they?
A daily Scrum fulfills all three of the above and hence merits being labelled as a ceremony. A ceremony with certain ritualistic norms that are religiously adhered to. Since rituals are sequenced activities and help in improved conduct, the daily Scrum meeting becomes an important component in the value generation of the overall Agile implementation process. Having said this, are such meets merely regimented and sequenced actions that need to be followed and enacted? Does it only serve the intended purpose for which it was designed or does it have an inherent value addition to team dynamics and human interaction as well? If we dig a little deep and we can uncover the following.
It is not a reason to assemble, but also a reason to celebrate
It is just not a ritual, but also an opportunity to be expressive
It is not a mere ceremony, but an avenue to strengthen relationships
It is not a place to be seen, but also be heard and appreciated
It is not a place to submit, but an opportunity to create possibilities
It is not about quick decisions but also arriving at a considered choice for action
It is not a space to compete but a reason to collaborate
Ceremonies are the bedrock for systemic actions to exist within a structure for effectiveness and are human-centric actions. Daily Scrum ceremonies, therefore, involve human interactions and behaviors. They are not just platforms to improve communication amongst team members, removal of impediments to development, highlight and promote quick decision-making, and improving the team’s participation levels but also serve to uncover human potential and aspirations. They are reasons to celebrate progress, assist and empathize with challenges, build rapport, enhance familiarity and deliver a choice for action. By uncovering the human element in a daily Drum Meetup, one can unleash possibilities of creativity, freedom and self-expression between the team members. This manifests not only in expanded efficiency in the workspace but also instils intrinsic involvement and clear sense of purpose and intent.
At LeadershipTribe we are aware of the hidden potential that exists in a daily Scrum meet. While we accept the need for a ceremony and adhering to the ritual, we also pay attention to uncovering hidden aspirations and wants and releasing human potential to its fullest. In unlocking hidden potential in each member, does the true manifestation of the Scrum process get realized? At LeadershipTribe, we approach the conduct of a Daily Scrum to meet not as a set of self-serving activities but a very potent medium for leadership to generate self-sustaining members. Come and join us or connect with us to know more about why and how we go about achieving this essential value of a Scrum ceremony.
It is my observation that when we implement a change initiative across an organisation, the leaders are generally well aware of why we do what we do, but the message rarely translates down to the team level. Most of the teams ‘just do it’, without understanding why and the benefits those changes may bring. Similarly, in an organization’s Agile transformation, people accept certain new practices and new ceremonies as they have been told so, and they get confused and frustrated when they don’t get the expected results. We need to arouse people’s curiosity, engagement, excitement and drive to thrive the transformation, all of which starts with answering the question of ‘WHY’. I have incorporated Simon Sinek’s Golden Circle Theory as a technique to help the team members to understand the ‘WHY’, and use the Scrum ceremonies to better serve their organization’s goals.
The Golden Circle Theory
The Golden Circle is a thought model developed by Simon Sinek, which suggests that the key to success lies in the way organizations and leaders think, act and communicate. He suggested that influential companies communicate from the inside out instead of outside in, which entails three layers in the order of the ‘WHY’, the ‘HOW’ and the ‘WHAT’.
The WHY conveys what an organisation or brand believes in, it clarifies and communicates the purpose. The HOW represents what the company does and why their products or services stand out from the competition. The WHAT explains what the company sell, its products and services.
The Scrum Ceremonies and Why They Are Important
Let us examine the Scrum ceremonies and identify the WHY behind each ceremony:
Sprint Planning
In the Spring Planning meeting, the entire Scrum team work collaboratively and plan out the work to be performed in the Sprint. The team evaluate and select Product Backlog for the Sprint, decides on the incremental deliverable for the upcoming Sprint and how the work required can be achieved by decomposing the work into an actionable plan.
WHY:
Create the objective to be met through the implementation of the Sprint (Sprint Goal)
Identify Sprint Goal to provide continued guidance to Dev Team on why they are building the increment, and flexibility regarding the functionality implemented within the Sprint.
Daily Scrum
Daily Scrum is also known as Daily Stand-up, it is a time-boxed event (normally 15-minute) held every day during the Sprint for the Dev Team to synchronize activities and create a plan for the next day. The structure of the Daily Scrum is determined by the Dev Team and can be conducted in different ways, as long as it focuses on achieving the Sprint Goal. In general, all members of the team need to answer three questions:
What did I complete yesterday?
What will I be working on today?
What are the blockers that stand in my way?
WHY:
Brings everyone to the same page and inspects on the progress toward the Sprint Goal
Optimizes team collaboration and performance, enable the Dev Team to hold each other responsible and work together as a self-organising team
Improves communication and transparency, promote quick decision-making, remove impediments, adapt and re-plan the rest of the Sprint as necessary
Increases the probability of the Dev team to accomplish the Sprint Goal
Sprint Review
Sprint Review is held at the end of each Sprint to showcase the work that has been done in the Sprint. During the Sprint Review, the Dev Team discuss what went well, the problems encountered and how those problems were resolved. Depends on the Product Backlog and any changes to it during the Sprint, attendees collaborate on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning.
WHY:
Ensures customer requirements are met and elicits constructive feedback
Fosters team collaboration and improves performance
Reviews the change to the marketplace and/or product usage, adjusts the next steps accordingly
Revises Product Backlog items for the next Sprint to meet new opportunities.
Sprint Retrospective
Sprint Retrospective is an opportunity for the Scrum Team to review and adjust itself. It normally occurs after the Sprint Review and before the next Sprint Planning. All team members should attend the meeting to discuss: what went well in the Sprint, what could be improved, and what will the team commit to improving in the next Sprint.
WHY:
Incorporates lessons-learnt to the next Sprint, improves process and practices
Increases product quality and uplifts team spirit
Enable a team culture of trust and transparency at work
Summary
The Scrum ceremonies help the teams to promote collaboration, maintain transparency, maximize productivity, and most importantly, constantly review and adapt as they progress so that they can continuously learn and improve.
It is important to acknowledge that each of the Scrum ceremonies has a very particular reason for its existence and practice. Instead of following the rigid definition of these ceremonies, teams need to understand why we do what we do, be pragmatic and adapt accordingly to make the ceremonies work for them and add value to their daily work.
Many a time we have come across a situation where team members complain that stories were not ready before the sprint.
At times, people complain that they are seeing the story for the very first time. Does this sound familiar?
Another common complaint I have heard is that the Acceptance Criteria is not fully developed.
How can we address these issues?
It is very simple. All the stakeholders of the project should agree upon a cadence where the team meets every single week to go through the product backlog and refine the same.
When is the best time to refine the Product Backlog?
Ideally once in a week and time box it for 1 hour. In a sprint of 2 weeks, at least teams should have met twice.
What is the Purpose of this meeting?
Plan for the next Iteration (sprint)
Refine, Prioritize the stories
Further, develop acceptance criteria
The team should have visibility of at least 3 Iterations
Who are the participants?
It is owned and prioritized by the Product Owner
Scrum Master, Product Owner, Development team (both developers and testers)
Subject Matter Experts, Architects
What is the outcome of this meeting?
Scrum Master facilitates the product backlog refinement meeting
Product Owner picks up each story which would be part of the discussion to clarify any doubts and also to update Acceptance Criteria
This helps the team to identify the dependencies between the teams
Call out from technical architects if it is not technically viable to do right away in the upcoming Iteration
Summarize the action items, decisions made and make sure this is visible to all the relevant stakeholders
The above should help in reducing the frustration during the Iteration Planning meeting and also the teams would get the sense of collaboration to set clear cut acceptance criteria.
