Category Archives: Agile Coaching

Why the idea of a scrum team is so powerful..

1*p7xQMVsJLaXrWqJd9CH_rA

The idea of a team has evolved over the last decade. What started off with a group of people working together to achieve a vague goal under the control of a manager/leader, has in some cases matured where teams are gradually getting more engaged and are aware of the business objectives and are being trusted to get to the finish line.

Screen Shot 2017-08-30 at 6.57.06 PM

The idea of a scrum team presented a new twist to the definition of a team, obviously with its share of discomforts. The thought of a team without a manager, attributes of self organization and self management and emphasis to build trust sounded great but had many heads shaking.

While some organizations have introduced structural changes to embrace 3 scrum roles (Scrum Master, Product Owner, Development team), most organizations are trying to fit the new roles in the context of their current organizational structure or are making a effort to somehow align existing roles to the new ones.

The thought that some existing roles may become redundant can be discomforting and lead to resistance. Some common questions/opinions are highlighted:

  • What about the “other” roles like business analysts, architects, project managers etc..?
  • These people have been with the organization for ever. We can’t let them go.
  • Our product owners are customer facing and have other responsibilities. They cannot be available to the team.
  • A Scrum Master? Who is going to manage the team?
  • Our teams are not mature enough to self organize.

The above questions are clearly indicative of the lack of understanding of the roles and the fact that the organization is focussed on individual roles and not the overarching impact of the roles.

The intent behind the idea of a scrum team was to bring all aspects of product development (business/product, engineering and process) together in order to realize the end goal. While the simplicity of the framework makes it acceptable, the roles continue to operate in isolation and be looked as “speciality driven”. To simplify, Product Managers assume that the responsibility of development team is to implement their ideas only.

As I went around coaching many organizations, I have always made a focussed effort to communicate the attributes of a successful and high performing scrum team, and the attributes that make the idea of a scrum team so powerful. Here are some key attributes that distinguish the great scrum teams from the good ones:

Screen Shot 2017-08-31 at 3.01.06 PMInclusiveness – Scrum teams works best in a inclusive environment. This means that while every individual might have a set of responsibilities that come with his/her role, what creates a big impact is how these roles come together and contribute to the overall success of the product. The idea that only Product Managers are responsible for product strategy, analysis and business decisions and development team implements the decisions made the manager defeats the purpose of a scrum team. In my experience, teams that have been able to achieve the highest level of productivity and created seriously innovative and disruptive products are the ones where these roles collaborate and engage on a day to day basis.

No culture can live if it attempts to be exclusive

Mahatma Gandhi

 For example; the complexity and the time taken to implement a functionality can negate the value of the feature. This information from the development team can impact the priority of the items in the backlog and help the Product Manager make better decisions. So, the idea of a collaborative team that embraces the scrum practices as intended can have a positive impact on the business value produced and accelerate the time take to do so.

For a patient at a hospital going through a surgical procedure involving doctors from a variety of specializations, each doctor constantly provides inputs to others to make sure that every aspect of the patient’s health is known to reduce risks and keep focus on patient’s recovery. Each one is included to achieve the end goal.

Alignment – can go a long way in defining the interest of scrum team members. Often, team members have a very narrow focus on the immediate tasks at hand and lack clarity of the business goals and objectives. Creating alignment is a critical aspect for a scrum team.

Alignment is a practice, not a state.

Unknown

Alignment is critical both at the business and process level and the scrum framework provides practices to help create the alignment through the empirical process control. The scrum team exists so that product, engineering and process can tweak things to stay on course to achieve desired outcome.

Talking about alignment, US and India launched their respective missions to Mars about a year ago. A very big part of the journey to Mars that lasts about a year to complete is to adjust the trajectory of the space vehicle to aligned with the ultimate goal (red planet). This requires various teams handling a multitude of functions to work in complete collaboration and constantly align the vehicle to ensure that the vehicle does not go off course. Any kind of misalignment can have catastrophic results.

Passion  – Alignment creates passion. Once every member of the team is aligned with the end goal of the product with clarity about what defines product success, they contribute in their unique way using their skills to make it big and successful.

Unfortunately, team members work in silos either unaware of the end goal to be achieved or are just not allowed to create impact outside their territory.  There is no focused intent to leverage the team’s creativity, skills or knowledge to drive decisions.

A great leader’s courage to fulfill his vision comes from passion, not position.”

John Maxwell

Time and again companies like Amazon and Google have shared instances where teams were able to come up with innovative solutions just by understanding a problem, doing some experimentation and adapting to feedback and these are the people who feel passionate about what they do. The intent of a scrum team is to create this combined passion for what is expected to be achieved.

Delight – The term delight is often associated with customers but it holds equal importance when it comes to the team we work with. The question one may ask “so how do we delight the team?”. As humans we get a sense of delight from small gestures from people around us. These can include writing a note of gratitude for all they do for the team and the project, engaging in activities to familiarize with the ups and downs of their lives or by just acknowledging what they do as a member of the team.

There is no delight in owning anything unshared

Seneca the younger

When a team comes together to achieve a common purpose and hold each other accountable for the collective success, delight happens. Acts of support, trust, belief, respect, openness result in a overall delightful environment and experience.

Click here to read about an experiment conducted by Thalia Wheatley called impact design to evaluate a delightful experience.

Celebrate – A unique attribute of scrum teams is their ability to celebrate success and failure. The cause of a success or failure is never attributed an individual but the whole team.

“Each day offers a reason to celebrate. Find it and experience true bliss.”

Amy Leigh Mercree

The important aspect of celebration in this case is that the celebration should become part of the team culture. Celebrations should happen frequently, for the whole team and in a way such that it leaves a lasting impact of the team members.

Conclusion: As organizations embrace the scrum team idea, the thought process needs to go beyond the need, skills and title of a role. Instead the focus needs to be towards creating an environment where unique skills are coming together to achieve a common goal in a inclusive environment where there is passion, alignment and celebrations and delight is not just for customer but for every member of the team.

 

My recent podcast on the future of Scrum Master role

SM

In this recent podcast, you can watch me in conversation with Samir Penkar on the topic of “The future of Scrum Master role”. This is part of Samir’s recent research study.

Add your voice to this research study:
https://futureofprojectmanagement.com/2017/01/26/future-of-scrum-master-research-study/

 

My podcast interview about Agile, Scrum and the Scrum Master role

podcast-istock

Image courtesy: cbc.ca

I am excited to share my latest podcast interview with Vasco Duarte where we discuss about agile and Scrum and get into details about the Scrum Master role all through this week. This podcast was recorded for the site http://scrum-master-toolbox.com/ to discuss various topics around challenges related to the Scrum Master role, some anti patterns to Scrum, change leadership, measurements of success for Scrum Masters and agile culture and mindset.

First 2 episodes are live now. Don’t forget to watch the upcoming 3 episodes (Wednesday through Friday) this week.

Please provide your feedback on the podcast, leave comments and like. Also reach out for any questions or if you would like to record a podcast for your site.

1463196442815

3 Pillars of Scrum – Core but easily forgotten

Screen Shot 2016-07-17 at 8.03.49 AM

What are the 3 pillars of Scrum? This is a one question I love to ask leaders, Scrum Masters, Product Owners and members of development teams as I engage with them, trying to help with their agile adoption. The statement “our team is already agile” is commonly heard but what is being referred to is the fact that the teams are conducting Scrum events (sprint, sprint planning, daily scrum, sprint review and sprint retrospective), connecting these events to agility and keeping the ideas of transparency, inspection and adaptation on the side.

Limiting the idea of agile adoption to just events and practices is a clear indication of the missing understanding of the core mindset of agile and Scrum and instead, the use of Scrum as a process control method.

The simplistic design of Scrum framework and the embedded practices are the heart of creating a agile culture for software development. Every event in Scrum is conducted to constantly put the 3 pillars of Scrum in practice to not only ensure adherence to the framework and its practices but also to have agility embedded to the people and process aspects of product development.

Most common examples of situations when transparency, inspection and adaptation are overshadowed by other “not” important decisions are:

– What is the buffer we should account for during the sprint to account for unplanned work? This is a step in the wrong direction from a transparency perspective. Team should rather allow for unplanned work to impact work so that delays become visible and the team can assess the reason behind unplanned work and adapt by working with the Product Owner to make the right decision.

–  Our/Your burn down does not look good. This is commonly bought up as an issue by the Scrum Master or the management and can take the focus of the team from getting the sprint forecast accomplished to making the burn down look good. It is important to understand that the burn down was not created to paint a good picture of the team but to transparently surface delays so that the team can collaborate and plan for the work to be done to possibly meet the forecast.

– Get the stories to “done” by moving the undone tasks to a new story. The “Definition of Done” is sacred to the team and is created with an intent of ensuring that the story accomplished is in a state to be released into production. However; creation of new stories with an intention of claiming browny points for work done or delaying defects for later is a common cause of delays and reduced quality.

There are many such behaviors and conversations that you will observe in your teams and the easiest way to make the right decision is to go back to the 3 pillars and make a decision keeping them in perspective. This is what I do while coaching team and it is what teams should do to create a culture of agility.

Remember, Scrum does not solve problems, it exposes them

Agile transformation – Working with shared services along the way

Screen Shot 2016-07-05 at 1.27.38 PM

The concept of shared services is prevalent in most large organizations. A centralized user experience or architecture group or services group can be commonly spotted. A lot of times, component team setups are given a flavor of shared services.

No matter how much dysfunction it causes, shared services continue to live for many reasons including:

  • Organization’s inability or hesitation to make structural changes
  • Fear of being exposed in getting outside of their comfort zone
  • Fear of change in general
  • Focus on local optimization
  • Others…

The fact remains that shared services are generally not economically viable due to associated communication overheads and increased cycle time to get work done, however; the idea of shared services will not go away anytime soon. So what are some of the ways to work with shared services setup in an agile organization? Saying that organizations need to completely change from a shared services structure to feature teams capable of delivering end to end functionality will sound lame and unrealistic. Below are some techniques that can help organizations work with shared services, trying to transform to the agile way of working:

  • Vision – The environment in a shared services setup is generally chaotic as consumers always have a high priority need. At this time, it pretty much becomes a bidding game. The person or team that shouts the loudest or the person with the highest level of influence is able to get their work prioritized to the top. This is followed by the lengthy process of knowledge sharing where the member of the shared services team spends time in understanding what to build and why. This causes the shared services team member to take a very narrow approach to quickly build what is being asked without understanding the vision and move out to the next ask. This sounds pretty much like a robot in a manufacturing environment that just gets its work done without caring about the end result.

vision

For agile teams, having a common understanding of the vision of the overall product or just a single release is of paramount importance to ensure that every single activity is focussed on achieving the vision. When working on large product backlogs, it is recommended that teams (I mean the whole team and all the teams) get together to create a common understanding of the functionality targeted in the next release. All teams involved should participate and help in sequencing the work to be done to be able to assess when the consumer will need something. This generally calls for investment of time from all teams but the outcome overshadow the cost.

Where there exists a clear vision and a clear understanding of what is needed from the teams, team members remain excited about what is being developed and look forward to their contribution and stay engaged

  • Alignment“Change is the only constant”. A sequenced backlog should not be treated as a project plan. Once a vision has been established and the backlog has been sequenced, all involved teams should come together on a regular basis to inspect the progress and resequenced their backlog as needed. Four-Dimensional-Goal-Alignment

This will specially help the shared services    teams to reprioritize their work to make sure that the next highest priority deliverable goes out quickly.

  • Collaborate – Coming together frequently to align is part of collaboration. Additionally, having someone from the shared services team attend the consumer team’s daily Scrum and other Scrum events and vice versa will help both the shared services team and the consumer team to stay informed about the progress being made and plan their work appropriately.
  • Service Level Agreements (SLAs) – Achieving discipline through working agreements is important when it comes to collaboration between teams. To use a metaphor, car manufacturers rely on multiple suppliers to provide various parts of the car to be able to assemble the end product. Each of the suppliers have to agree to certain processes and protocols to make sure that the assembly line does not come to a halt due to shortage of parts. Each part has a assigned reorder inventory level at which point the order system automatically places order for the next shipment. 3771.PPP_PRD_165_3D_people-Binding_Agreement_1FA08461Not only is the vision of the system clear to each supplier, the suppliers ensure delivery of products on time and are also liable to penalty if the agreements are not adhered to.

The key focus agreements is to build the environment of collective ownership, collaboration and focus to ensure quality and timely deliverable while maintaining a flow.

  • Use a tool – Tools can come in handy when it comes to collaboration and keeping shared services teams informed about their commitments. While I am a huge proponent of physical boards for Scrum teams, I do have to acknowledge that physical boards become a limitation when trying to keep shared services teams informed about the needs or the change in needs of the consumer.

tool-icon

Additionally, tools can be used by teams to generate metrics to assess their performance in being able to meet their SLAs, get notified about key milestones and provide data specifically targeted towards continuous improvement.

 

————————————–

While I truly believe that structural changes are a critical part of a successful agile transformation, it is not always possible  right from the word go. Organizations are generally resistant to radical changes fearing impact on running the business. While baby steps are taken to impact structural transformation, the above mentioned steps will help in the interim to help the organization get started on the journey of agile transformation.

If you have other ideas/techniques that you have used in your engagements, I would love to hear from you.

 

 

 

 

Scrum events are NOT working for you if…

DailyScrumMeeting

Image courtesy: agiletrick.com

Rarely does a agile coach get to transform a completely waterfall team/organization into agile these days. Majority of the organizations are already on the agile band wagon and claim to be doing some sort of agile, however; it is quite obvious that all is not working for them.

The start of an engagement for an agile coach is all about observation. Watching teams participate in Scrum events gives a good sense of the maturity of the individuals, team and organization. Here are things to look out for to know that Scrum events are not working:

  • There is a leader – We need leaders but we also believe that everyone in a Scrum team is a leader. Often, there is an individual or a couple of team members that are the “experts” and end up taking control of Scrum events. So if these “leaders” are calling the shots and driving all decisions, Scrum events are not working for you.
  • There is silence – Scrum teams are all about collaboration and communication. One of the key agile values is “Individuals and interactions over processes and tools”. So if your Scrum events are all about forced communication where team members are not motivated or do not feel safe to share their point of view, Scrum events are not working for you.
  • Something important keeps coming up – The occurrence of Scrum events have been designed to bring the team together frequently to be able to put the idea of inspection and adaptation in practice. However; often team members are absent from the Scrum events with the most common excuse being that there is an important issue to address. When doing Scrum, nothing is more important than the Scrum events. So if your team has something important to address when they should be collaborating, communicating, inspecting and adapting during a Scrum event, Scrum events are not working for you.
  • Design a solution – Every Scrum event had a recommended time box. For example, a daily Scrum should not be more than 15 minutes long or a sprint planning event should be 8 hours or less for a 4 week sprint. These time box recommendations work only when teams a disciplined in keeping a focused agenda for a event. However;  teams spend 30 to 45 minutes on a daily Scrum or a sprint planning session spans multiple days. This usually happens when team members get into a “design the solution” mode leading to significant waste. So if your Scrum events are turning into design and problem solving meetings, Scrum events are not working for you.
  • Team members are checked out – Knowing the significance and reasoning behind each Scrum event is crucial. Each Scrum event is specifically designed to achieve specific objectives in alignment with the agile values and principles. However, it is observed that team members do not focus on the value of the event but rather go through the motions. If you observe that team members are either checked out or focused on their individual goals, Scrum events are not working for you.
  • External decision makers – What the team can get done and how a business problem should be addressed are decisions that a Scrum team owns. A self managing Scrum team is one that makes decisions that are in the best interest of the project knowing their capabilities to deliver. If you Scrum team is under pressure from external forces and are unable to self manage and organize, you Scrum events are not working.
  • There is inconsistency – Having Scrum events occur consistently at the same time and as per a defined cadence is important to reduce complexity and build team discipline. For example; it is recommended the team has a daily Scrum in the morning to be able to create a plan for the day, however; if this is moved to afternoon on a give day and moved again the next day, it effects the consistency and causes unnecessary adjustments. If the occurrence of Scrum events is not consistent, Scrum events are not working for you.
  • Can’t we just – A phrase that is heard quite consistently when working with Scrum teams is “Can’t we just…”. This might be said when the Product Owner is trying to sneak in that extra story into the sprint backlog or when the team members are pushing to fix a bug in the next sprint and call the not done story done. If team members are constantly trying to find ways to step outside the Scrum boundaries, Scrum events are not working for you.

There are many more smells that are seen detrimental to the effectiveness of Scrum. Some of these include Scrum Master assigning work to team members, daily Scrum being a means for management reporting etc… I am sure you have observed many more smells that expose the ineffectiveness of a Scrum event. Please share in the comments below.

Have you read the scrum guide lately

Screen Shot 2016-05-24 at 4.21.31 PM

Every conversation around agile and scrum is a conversation about empirical process control. The term empirical is derived from or related to experimentation and observation rather than theory.

You must be thinking what has this got to do with the scrum guide. Well, there is a connection.

When experimenting, a big part of the experimentation is based upon the rules of idea or a entity that is being experimented with. As a example, when experimenting with chemicals in the lab, there are clear rules on when a chemical compound can increase risk or be harmful. However; scientists and researchers have continued to study chemicals from the time they were discovered to now to explore opportunities to leverage the properties of the chemical for general well being or further analysis. The study never stops.

In a similar way, some of authors who wrote some of the world’s bestsellers have continued their research, aspiring to make the results of their research more proven, well supported with success stories and case studies. More often than not, the key set of rules around the study has remained the same.

Looking at the history of scrum, Jeff Sutherland and Ken Schwaber conceived the Scrum process in the early 90’s. They codified Scrum in 1995 in order to present it at the Oopsla conference in Austin, Texas (US) and published the paper “SCRUM Software Development Process”. With the first publication of the Scrum Guide in 2010, and its incremental updates in 2011 and 2013, Jeff and Ken established the globally recognized body of knowledge of Scrum.

The scrum guide has gone through it own share of revisions. For the most part, the core to the revisions has been the need to keep the guide as simple as the scrum framework itself and to adapt specific terminology to make it more in line with how the industry has adapted the framework itself. The present version of the scrum guide is only 16 pages long with focus on the core framework.

I first got introduced to scrum back in 2007 when I spent 2 days with Jeff Sutherland, participating on a CSM class. Since then, I have been of the assumption that scrum has remained the same till very recently when I happened to attend another class while being in middle of projects. I was surprised to unearth some serious gaps in my understanding of scrum and when the current scrum guide says. I spent the next few days going through the guide multiple time to bring make my understanding of scrum current.

Additionally, talking to may coaches and scrum masters, I feel people have not felt the urge to go back and read the guide recently and have been teaching scrum to teams and individuals based on their past understanding and using the old terminology. This has impacted me so much so that one of the first questions I ask candidates in an interview is “when did you last read the scrum guide?”. This helps me assess how current is their understanding of the framework and the kind information I should be ready to digest.

While some might argue that the changes in the guide have been minimal, I believe the current guide is much simpler, gives a good understanding of scrum in least possible number of words and is definitely the best source to assess your understanding of scrum.

I can confidently say that just going through the guide will help you make the mental decision about the quality of your adoption of scrum without the need to go through the long and formal assessments.

So “have you read the scrum guide lately?” If not, I highly recommend you take a quick refresher and ensure you are doing scrum right. Click here to print the latest version.