Scrum Interview Questions Agile Management

This typically happens when the Sprint Goal becomes obsolete. A Sprint can be cancelled before the Sprint time-box is over. A Sprint would be cancelled if the Sprint Goal becomes obsolete. This might occur if the company changes direction or if market or technology conditions change. The abnormal termination might also occur if the team gets into the Sprint partway and finds that the work is going to consume too much time than expected in sprint planning.

No. One product has one Product Backlog, regardless of how many teams are working in that project. It is easy for the Developments teams to coordinate with other teams if one product backlog is followed throughout the project.  

Never. All Sprint Backlog Items are "owned" by the entire Development Team, even though each one may be done by an individual development team member. Sprint Backlog and all of its items are collectively owned by the Development Team. No individual team member can claim ownership over an item as this would block communication and collaboration among the team members.

Only one. One product has one Product Backlog and one Product Backlog should be taken up by one Product Owner. If several development teams are working on the same product, then one product backlog is common to all of them. So, to deliver a single product, only one product owner is enough though there are several development teams present

No. Products have one Product Backlog, regardless of how many teams are used. Any other setup makes it difficult for the Development Team to determine what they should work on. A good product backlog is a result of the combined effort of the product owner, scrum master, scrum team and stakeholders and one product backlog is used to explain the work on the product.

Without a new vocabulary as a reminder for the change, very little change may actually happen. Also, the organization may not understand what has changed with Scrum and the benefits of Scrum may be lost.

Scrum adoption is good, but this massive shift needs complete dedication. The organizations that are implementing the Scrum practices every day can be successful in Scrum adoption. If Scrum is implemented with all the team members on a daily basis can increase the collaboration and a quick product delivery. So, it is recommended to implement only Scrum methodology without clubbing any other methodology as it can be applied to any complex project and will meet the project deadlines within a timeline, making the customer happy!

It can change. The Sprint Backlog makes visible all of the work that the Development Team identifies as necessary to meet the Sprint Goal. The Development Team modifies the Sprint Backlog throughout the Sprint, and the Sprint Backlog emerges during the Sprint. If the work appears to be different than expected, the dev team collaborate with the PO to negotiate the scope of the Sprint Backlog within the Sprint and adds more PBIs related to the current Sprint if necessary.

All Development Teams must have a definition of "done" that makes their combined work potentially releasable. Each Scrum team consists of its own ‘Definition of Done’. Definition of Done defines the acceptance criteria across all User Stories. Scrum requires an Increment to be releasable. This is an Increment of product. Many teams working on a single product are expected to deliver the quality of work.  

No. The product increment should be usable and releasable at the end of every Sprint, but it does not have to be released. In Scrum, it is not mandatory to release each increment without accepting the acceptance criteria. The developed increments should have a value according to the customer’s needs. In short, you can say that it should be usable and releasable at the end of every Sprint without releasing to the production. 

Inform the Product Owner so he/she can work with the CEO. The items selected for a Sprint have been selected as most valuable with the Product Owner. The items serve the Sprint's goal. No changes should be made that endanger the Sprint Goal. No one external to the Scrum Team can force changes on the Development Team (Sprint Backlog) and the Product Owner (Product Backlog).

The Product Owner and the Development Team. During the Sprint, the scope may be clarified and renegotiated between the Product Owner and Development Team as more is learned. As issues emerge, changes can be made to the sprint backlog to accomplish the Sprint Goal. The Development Team will then re-negotiate with the Product Owner regarding the Sprint Backlog. Although the Sprint Goal is fixed during the Sprint, the Sprint Backlog is not.

No. The entire organization must always respect a Product Owner's decisions. For the Product Owner to succeed, the entire organization must respect his or her decisions. No one is allowed to tell the Development Team to work from a different set of requirements, and the Development Team isn't allowed to act on what anyone else says. The PO can remove the product backlog items if he/she feels that is not a high priority one. Anyone can add an item to the product backlog. But, it is the PO who decides what happens to the PBI.

Firstly, it assures the Increment reviewed at the Sprint review is usable so the Product Owner may choose to release it. Secondly, it creates transparency regarding progress within the Scrum Team. All Scrum Team members must have a shared understanding of what it means for work to be complete, to ensure transparency. This is the definition of "Done" for the Scrum Team and is used to assess when work is complete on the product Increment. The Increment reviewed at the Sprint Review must be usable, so a Product Owner may choose to immediately release it.

Re-work the selected Product Backlog items with the Development Team to meet the Sprint Goal. During the Sprint scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned. The development team looks to the product owner for product backlog, for alignment and direction on the delivery of value through the sprint goal achievement through the backlog implementation. The backlog can be changed to achieve the Sprint goal, but PO is responsible for value delivered through the implementation of backlog to achieve a sprint goal. 

Release an Increment to the market to learn about the business assumptions built into the product. The Product Owner manages Product Backlog against the assumption that value will be generated. This assumption remains invalidated when not checked against users and market. The Product Owner drives iterative development from an exploratory attitude, aiming at incremental progress through continuing discovery and validated learning.

No. In Scrum, Product Owner takes care of the Product Value in order to generate, deliver, and maintain a successful product. Value is likely to vary across the products and organizations. The value of the product depends on the context of the product which you are developing.  

There are no such pre-conditions. Sprint Planning serves to plan the work to be performed in the Sprint. This plan is created by the collaborative work of the entire Scrum Team. Sprint Planning is time-boxed to a maximum of eight hours for a one-month Sprint. What can be achieved in this time-box may be influenced by additional practices that are however not prescribed by Scrum.

No. A Product Owner engages actively and regularly with the Stakeholders. However, to limit the disturbance to the development progress and keep a focus of the Development team high, the key Stakeholders are allowed to take part only in the Sprint Review meeting. However, any Scrum team member can interact with them at any time.  

By releasing often, and updating key performance indicators (KPIs) on value after every release and feeding this information back into work on the Product Backlog. Scrum Teams deliver products iteratively and incrementally, maximizing opportunities for feedback. If a product isn't released, the opportunity to capture user and market feedback is lost. By releasing every increment and updating the Key Performance Indicators (KPIs) on value after every release can help to know the product built through Scrum is successful.  

Whatever is the most appropriate for the Product Owner to achieve the product's goals and to optimize the value received. The Product Owner is responsible for ordering the items in the Product Backlog to best achieve goals and missions, thereby optimizing the value of the work the Development Team performs. How this is done, and what value means, may vary widely across the organizations.

The owner of a product is not only accountable for the development and release of a product, but also the cost of maintaining and operating the product. If a person 'owns' the product, he/she can be expected to be responsible for the complete lifecycle of a product.

It is a good practice, keeping in mind that market reception is the best measure of value. Indications of value on Product Backlog are useful but are only a prediction until validated against users and market.  

Yes. The Scrum Master is one of the roles from the Scrum team which is responsible for ensuring the team is adhering to the Agile values and principles. The Scrum Master is the team facilitator. Along with that, the SM is responsible for clearing the obstacles, protecting the team from external interruptions and distractions that hinder the project goal.  

No. Single members might handle most or all of the work of a particular Sprint Backlog item, but responsibility remains for the whole team. When each member of the Development team owns the Sprint Backlog items, the team will derail from the core-value of Agile which is nothing but the ‘Collaboration’.  

The Scrum Master. It’s the responsibility of the Scrum Master to create a supporting understanding of Scrum in the whole organization. The Scrum Master is responsible for ensuring the team is adhering to the Agile values and principles. The Scrum Master is the team facilitator. Along with that, the SM is responsible for clearing the obstacles, protecting the team from external interruptions and distractions that hinder the project goal.  

Refer the representative to the Product Owner to discuss it. If the customer is asking for adding an item to an ongoing Sprint, adding it in a collaboration with the Product Owner is the best-suited way to add any new item to the Sprint. Because adding a new item to the product backlog without asking the product owner may result in removing a transparency and undermining trust with the Product Owner.

Timeboxing is the process of allotting a fixed and maximum unit of time for an activity. That allotted unit of time is a timebox. The goal of timeboxing is to define and limit the amount of time dedicated to an activity. The time-box set for the Sprints should not be longer than one month and should be selected considering different factors such as the risk and delivery time.

Yes. The Scrum Master position is the management level position, but it is not a manager position. Scrum Master does not manage the Scrum Team or even the Development Team but manages the Scrum process. If the Scrum Master is not at the management position, he or she may not have the influence to remove the impediments.  

15 minutes. The purpose of the Daily Scrum meeting is to carry out a communication between the team members. The Scrum meeting is timeboxed to 15 minutes irrespective of the team-size and is held at the same time and place each day to reduce complexity. Also, it is usually held at the morning time when maximum team members gather to plan work for the day.

Product Owner.The Sprint can be called off before ending up the Sprint time-box. Only the Product Owner has the authority to cancel a Sprint. This happens when the Product Owner realizes that it makes no sense to finish the Sprint, as defined in Sprint Backlog. The PO may cancel the sprint under the influence of any Stakeholder, the development team, or the Scrum Master.

By facilitating their decisions and removing impediments. Scrum Master does not manage the Development Team. It is the responsibility of the Development Team to manage its own efforts. However, the Scrum Master helps them by facilitating their decisions and removing impediments and protecting them from the external distractions.

There should be one Product Backlog and one Product Owner. Many Scrum teams, each with a Scrum Master can pull work items from a single product backlog and the presence of the product owners depend on the number of product backlogs. A certain project should have only one Product Backlog and one Product Backlog should only have one Product Owner otherwise, it would be difficult to deliver the product.

One. Multiple Scrum teams, each with a Scrum Master can drag their work items from a single product backlog and the presence of the product owners depend on the number of product backlogs. A certain project should have only one Product Backlog and one Product Backlog should only have one Product Owner otherwise, it would be difficult to deliver the product.

It is not an appropriate goal since Sprint Goal should be about expected business value.

In some projects, a development team member acts as a scrum master as there is no rule set up officially that a scrum master cannot be a developer. Definitely it is hard to perform 2 roles at one time, however, it is definitely possible. A development team member playing the scrum master role depends on the team, team members skills and internal choice of manager or team. Ultimately, everything is possible in agile-scrum projects.

The development team should ask the executive to work with the Product Owner. The product owner is the voice of the executives in the process of communicative discovery. How the feature is developed is up to the PO and the Scrum Team, and depends on the nature of the product under deployment and the availability of the stakeholders. The product owner represents the needs and desires of the executive to the development team and prioritizes their work that helps the team to do it in the right way.

The Scrum Master should let the team decide the format of Product Backlog items.The product owner brings forward the main objective that should be achieved in the sprint and the PBIs that would help to attain these objectives. The development team selects the PBIs that will help to achieve the sprint goal based on the product owner input and creates the plan for delivering the PBIs. The scrum master ensures that the scrum rules are followed appropriately. There is no need for a scrum master to conduct events, but instead to facilitate as required.  

You should gladly volunteer because being a Scrum Master in an organization also involves responsibilities to coach the organization.

No. The benefit of forming self-organizing teams is not that the team identifies some additional role within the scrum for its work that a manager has missed. Instead, it is that by enabling the team to self-organize, it is motivated to completely own the problem of performing the work at its best. In short, a self-organizing team is a group of motivated individuals who have the authority and ability to take decisions and adjusting to changing demands quickly and easily working together towards a goal.

The development team should ask him to work with the Product Owner.

The product owner only. A customer shouldn’t spend time detailing the product issues to the development team, this is a job of a product owner. The product owner is responsible for the project success and is finally responsible to the customers, team and to the company. He/she is the voice of the customer to the development team and ensures that all channels of communication are open and that project has ample amount of support needed to succeed.

No. The entire team collaborates with stakeholders during the product review. Scrum Master can also work with stakeholders to help them understand Scrum. Stakeholders communicate with Product owner with respect to Product Planning, its progress, and Product backlog changes. Good communication helps project stakeholders engaged and informed and keeps the scrum team focused on finishing the accepted work for the sprint.

The development team needs to facilitate. The development team is responsible for performing development work and meeting the Sprint Goal. If they have any issues within their influence to resolve, they are responsible to solve it. Scrum Master is responsible for impediments that are outside the Development Team’s influence.

Yes, the length of the sprint can be changed but it should be fixed before starting the sprint. The product owner needs to ensure that the sprint is short enough to limit business risk and also short enough so that the team can synchronize their development work with other business events. Finalized Sprint length cannot be longer than 4 weeks (1 month).

The Development Team should it transparent that they cannot make a forecast with insufficient information, and negotiate with Product Owner on refining the stories to a Ready state. In scrum, each and every iteration starts with a sprint planning meeting. During this meeting, the PO and the team discuss which stories a team will handle that sprint. The Product Owner needs to help clarify the selected Product Backlog Items. Scrum Master can also coach the Product Owner on how to accomplish this viz. by having regular Backlog Refinement sessions. Later, the team can also discuss in Retrospective.

Not necessarily. It is preferable to conduct it at the same time and the same place to reduce the complexity of meeting overheads. Unless the Product Owner and Scrum Master are also part of the Development team it is not required for Daily Scrum. Daily Scrum is for the Development Team. The Daily Scrum is not planned as a status report or management reporting mechanism. Performing Daily Scrum highlights liability and commitment in the development team.

No. After developing a product increment at the end of each sprint, a Sprint Review meeting is held. The Sprint Review meeting provides a platform to the team members to show what they accomplished during the sprint. Scrum events are time-boxed to eliminate waste and reduce risks. The team needs to address the root causes and adhere to the time-box.

This indicates that the development team added new work. The line indicating effort remaining in the burndown graph varies from team to team and day to day. If more work items (user stories and issues) are added after the sprint started then this shows an upward spike. The spike indicates added work and the Product Owner cannot add new work to Sprint Backlog without the consent of the Team.

No. The Sprint Goal gives some flexibility to the Development Team. If the work turns out to be different than expected, the Development Team collaborates with the Product Owner to negotiate the scope of the Sprint Backlog within the Sprint. In that case, the development team discusses with the PO and reaches the conclusion.

Since the introduction of the CSM qualification there has been feedback from Scrum Masters that the need for ‘soft-skills’ and how to use Scrum in a programme of product development are not taught on the CSM course; ie how to deal with people:

• who resists change
• have a lack of engagement
• have low motivation
• will not make themselves available when needed

and how do Scrum teams work with other Scrum and Agile teams.

The SA could have added 2 days to the CSM course to cover these ‘soft-skills’ and aspects but that is a lot to teach and examine for those who wish to be Scrum Masters but have not had any ‘formal’ experience of ‘soft-skills’; we all have them, to some degree or other, just by growing-up and learning how to interact with our subordinates, peers and superiors.

It was decided that Scrum Masters should learn the ‘Scrum mechanics for the CSM qualification and be ‘introduced’ to the ‘soft-skills’ needs during their first Scrum Master engagements.

It was considered that after a minimum of 1-year experience, Scrum Masters would have been exposed to issues requiring the appropriate use of ‘soft-skills’ to resolve them.

However, the only recognition that ‘experienced’ Scrum Masters had of this new knowledge was just the time they had spent being a Scrum Master.

The SA decided to introduce the A-CSM qualification and the A-CSM course to ensure that all such qualified Scrum Masters have a ‘baseline’ of advanced Scrum knowledge and appropriate ‘soft-skill’ needs.

You can attend an A-CSM course and sit the examination at any time after you have gained your CSM qualification but even if you pass the exam, the SA have decided that you cannot be awarded the A-CSM qualification until you have at least 12 months of Scrum Master experience logged into your Scrum Alliance profile.

 During the Certified Scrum Master course you will have learnt about ‘The Rules of the Game’:

• Scrum Values
• Roles, events, artefacts, and the rules that bind them together
• What Scrum can be used for; it is not all about software development

However, hopefully, you were also told that being Scrum Master is about ‘servant leadership’; depending on your instructor, you may have gained a little insight into servant leadership but there is not enough time during a 2-day course to cover everything in depth.

During your Scrum Master engagements, you have probably discovered that there was more to the job than you learnt on the CSM course; things such as:

• Encouraging Product Owners, Team members, customers, stakeholders and executives to communicate with each other effectively.
• Dealing with people who resist change, have a lack of engagement, have low motivation and will not make themselves available when needed.
• Encouraging everybody to have increased engagement to achieve greater accountability, commitment and buy-in.
• Working with other Scrum and Agile teams.

As you can see, most of these aspects of your job fall into the category of ‘soft-skills’; dealing with people, understanding their fears, needs, wants and attitudes; in a word – facilitation.  Also, there are additional ‘Scrum Mechanics’ needed when working with other Scrum and Agile teams; so-called ‘Scaling Scrum’.

The A-CSM course builds on your ‘mastery’ of the ‘Scrum mechanics’, that you have learnt and practiced during and after the CSM course, by consolidating the lessons in this area that you may have already learnt during your time as a Scrum Master and introducing you to other facilitation techniques.

Having a CSM qualification indicates to employers and peers that you have the knowledge of the basic ‘Scrum mechanics’ and that you could implement the Scrum framework for a Scrum Team.

In an ‘ideal world’ all those people involved with a product development will have been appropriately trained and have fully bought into the 5 Scrum Values:

• Commitment
• Courage
• Focus
• Openness
• Respect

It is when these values are embodied and lived by all those involved in a product development, the Scrum pillars of transparency, inspection, and adaptation come to life and build trust for everyone.

We do not live in an ‘ideal world’!  Ensuring that everybody involved in a product development is fully and appropriately trained is an expensive business and addressing the scepticism and fears of some people can take a significant amount of time.  We all have our own personal and professional agendas; the introduction of any Agile framework be a threat to these agendas.

So how, as a Scrum Master, can you help the product development people achieve this state of ‘nirvana’?

During your early days of a Scrum Master in an organisation you will have, no doubt, come across people who are ‘less than Scrum friendly’ and have had to devise ways to encourage them to ‘play the game’.

There are many publications about individual psychology and team dynamics that you may have used as a reference and/or you may have had an Agile coach to consult for help and advice.

By having an A-CSM qualification you will demonstrate to employers that not only do you have the knowledge of the basic ‘Scrum mechanics’ and that you could implement the Scrum framework for a Scrum Team but also you have the knowledge and skills to facilitate a ‘smoother’ Scrum transformation in a ‘Scrum immature’ organisation.

The A-CSM course and qualification was introduced by the Scrum Alliance in February 2017.  Since then, at the time of writing in August 2018, 953 people have passed the A-CSM examination; the list of alumni is at the Scrum Alliance Certificant Directory.

The percentage distribution of A-CSM across the world, by ‘continent’, is:

North America 67%

Europe 18%

Indian Sub-Continent 8%

Asia/Pac 6%

South America <1% 

Middle East <1%

The companies that these A-CSM work in are too many to list here but the overwhelming majority are in the commercial sector, many Fortune 500 companies are represented, with just a few representing public sector organisations.  However, there is a significant number of A-CSM that have not declared an organisational connection, so it is not possible to quote definitive statistics for A-CSM organisation and sector representation.

 The Scrum framework is defined in The Scrum Guide; maintained and published by Scrum.org.

To get an answer to this question you must first ask the question ’What is Agile?’.

The definition of Agile is owned by the Agile Alliance that was formed in February 2001, at Snowbird, Utah.  The first Agile Alliance publication was the Manifesto for Agile Software Development closely followed by the 12 Principles Behind the Agile Manifesto.

So, to answer the question, the Agile Manifesto and Principles are listed below with the explanation of how the Scrum Framework implements them. 

• The Agile Manifesto

 “We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more”

© 2001, the Agile Manifesto authors

These are the 4 Agile Values and any product development framework that purports to be ‘Agile’ must embody these Values in the specifics of the framework.

It is worth noting here that although the Agile Manifesto specifically talks about ‘software development’, the Agile Values and Principles can be used to develop non-software products.

Agile Manifesto explanation and how Scrum embodies the Agile Values

• Individuals and Interactions:  There must be advice about how the people involved interact and communicate:

Scrum defines the roles for product development and specifies the necessary individual and group interactions.  Although Scrum does define a product development ‘process’, it is tool agnostic.

• Working software:  The product development team’s focus must be on producing working increments of the proposed product and not in documenting what has or needs to be done:

The Scrum framework proposes a minimalist list of required ‘documentation’.

• Customer Collaboration:  The best results for product development come when all those involved work together as one ‘team’ to solve problems whether they be business or technical people and whether they are internal or external to the product development organisation:

Scrum defines a Scrum Team that includes business and technical people.

• Responding to change:  The major drawback to ‘waterfall’ processes is that they recommend obtaining all detailed requirements before development starts and create the development plan; ‘contracts’ are set in place and organisations think that they have a high degree of functional, time and cost predictability.  However, as we all know, the development team discover hitherto unforeseen problems and the business change their minds. To cope with this situation, ‘waterfall’ processes introduced ‘Change Procedures’ which became bureaucratic and time wasting.

Scrum uses a high-level ‘requirements list, the Product Backlog, ordered by business value the content and ordering of which is the responsibility of the Product Owner.  Furthermore, the Scrum framework has frequent, short events that include consideration of recommended and requested changes to the Product Backlog.

• The Agile Principles

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

The Scrum framework recommends that product development takes place with short, 2 to 3-week development periods, Sprints, that result in a working increment of the required product.

If appropriate, the increment may be released to the live environment at the end of a Sprint or the increments from several Sprints may be released together at 2 to 3-month intervals.

  2 Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

The Scrum framework recommends that the product development requirements defined before development begins are of the lowest level of detail of the names of the business processes necessary for the product; they are ordered by business value.

At regular intervals, at least once in every Sprint, consideration is given to requested changes to the requirements and ordering.  The result is that the highest business value is achieved in any given timeframe.

  3  Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

See Principle 1 above.

  4 Business people and developers must work together daily throughout the project.

Scrum defines a short, 15-minute, daily event called the Scrum, when all Development Team members, both business and technical and whether full or part-time, come together to state what was done during the previous day and what is planned to do for the next day.  Also stated are any problems that individual members are facing.

Any discussion of ‘matters arising’ from the daily Scrum event are conducted after the Scrum has ended.

  5 Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done.

The Scrum framework does not recognise the term ‘project’ preferring to focus on product development which may be more open-ended than the concept of a project.

However, Scrum does implement the spirit of this Principle in that it recommends appropriate empowerment to the Scrum Team and encourages cross-functional, self-organising Development Teams; the day-to day work of the Development Team is the sole responsibility of the Team and not a ‘project manager.

   6 The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

The Scrum framework defines all the events when the Scrum Team and stakeholders must come together to plan, refine and review the work and to reflect on the detail of the day-to-day activities being followed; it suggests that these are done in face-to-face environments.

However, much of today’s product development involves people in geographically dispersed locations and it is financially and culturally prohibitive to gather all required people at 1 location.

Although not part of the Scrum Guide, most Scrum practitioners take advantage of the abundant video-conferencing and desktop sharing facilities available from secure internet environments.

   7 Working software is the primary measure of progress.

The Scrum framework requires that the product increment requirements that are developed in a Sprint must pass the quality criteria defined in a ‘Definition of Done’ to be considered complete and fit for demonstration to stakeholders.

Organisational product development progress is measured by the number of requirements that have been completed; task and activity progress, if used, is the sole responsibility of the Development Team and is not published to persons outside of the Development Team.

   8  Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

The Scrum Guide does not mention sustainable development specifically.

However, it is part of the Scrum Master’s responsibilities to remove impediments to the Development Team’s progress; one such impediment may be that the Development Team as a whole, individual team members and/or stakeholders may be working too hard.

It is a proven fact that productivity reduces when people are stressed and tired.  The Scrum Master must look-out for signs of ‘overwork’ in those involved in the product development and help overcome the problem.

In this way, the Scrum Master can promote sustainable development.

  9 Continuous attention to technical excellence and good design enhances agility.

The Scrum Guide does not mention technical excellence or good design specifically.

However, the Guide does require that only “Done” requirements can be demonstrated to stakeholders.  The ‘Definition of Done’, the checklist of criteria that defines when a requirement is “Done”, will vary from product to product and organisation to organisation but will most probably include technical excellence and good design criteria.

  10 Simplicity--the art of maximizing the amount of work not done--is essential.

This is a widely misunderstood Principle but essentially means ‘only do today what is essential to do today’.  For example, is it essential to gather all the detailed requirements before development work begins? The answer is no; we gather the most important requirements at a high-level of detail; these may change over time and the time taken getting the details ‘up-front’ will be wasted.

All the aspects of the Scrum Guide embody a minimalist approach to the amount of work to be done.

  11 The best architectures, requirements, and designs emerge from self-organizing teams.

Scrum requires the use of cross-functional, empowered and self-organising teams.

  12  At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.

The Scrum Guide defines the Sprint Retrospective event where the Scrum Team inspects itself and creates a plan for improvements to be enacted during the next Sprint.

the development of the Scrum framework is not linear; different people did independent studies and experiments and gradually the ideas and concepts coalesced into what we know today as Scrum.

Probably the first publication that compared product development to the game of rugby, moving the scrum down the field, was the white paper “The New New Product Development Game” by Hirotaka Takeuchi and Ikujiro Nonaka, published in the Harvard Business Review in January 1986.

In this whitepaper, the authors researched the product development methods of prominent and successful companies and concluded that, in the main, success relied upon:

• Built-in instability
• Self-organizing project teams
• Overlapping development phases
• “Multilearning” 
• Subtle control
• Organizational transfer of learning

They called such processes ‘Holistic Methods’ as opposed to the waterfall ‘sequential’ processes.

Some sources attribute the ‘invention’ of Scrum to Jeff Sutherland, John Scumniotales and Jeff McKenna in 1993 when they implemented Scrum at the Easel Corporation.

Independently, Ken Schwaber, as a software product development manager in the 1980s and early 1990s, recognised patterns of failure in many product development initiatives that used ‘waterfall’ approaches.

Ken tells the story that he approached a process engineering company, described the software development environment and ‘waterfall’ process; he was told that a ‘defined process’ such as ‘waterfall’ was very unlikely to succeed consistently in a software development environment; what is needed is an ‘empirical process’ that allows process change from feedback from short experiments.

You would need to ask Jeff or Ken how these 2 first came together to ‘compare notes’ but they collaborated to produce the first public presentation of Scrum at OOPSLA 1995.

There have been many other people involved with the development of the Scrum framework; people such as Jim Coplien and Mike Beedle.

Ken Schwaber and Mike Beedle published the first Scrum book, ‘Agile Software Development with Scrum’, in 2001.

There are many product development frameworks that embody the Agile Manifesto values and Principles from the more well known to specific, bespoke frameworks in a single organisation.  The more well-known frameworks and what they contribute to the Agile movement overall are:

• The Agile Project Framework (APF) – The APF is a development of the world’s first published ‘Managed RAD’ framework, DSDM, from the Agile Business Consortium, formerly the DSDM Consortium.

The APF is the only Agile framework to include advice and processes specifically about product development governance; aspects such as Product Vision, Objectives, expected Benefits, Business Case, management structure and communication plans.

Other Agile frameworks do not go into these details because they believe that organisations already have governance processes in place; for those organisations that do, the processes are not usually suitable for use in an Agile environment.

Similarly, the APF includes the most information about the processes required to release increments of the product into the live environment.

One of the APF phases, ‘Evolutionary Development’,  can be replaced with other Agile frameworks such as Scrum, Kanban or Lean Software Development.

• Kanban – the Kanban framework evolved from the visual board that represents product development flow from the Toyota Production System; in Japanese the word is ‘kanban’ with a small ‘k’; the Kanban framework is usually spelt with a capital ’K’.

David Anderson developed the Kanban framework from the concept of a kanban adding required process management aspects.

The values that Kanban brings to the Agile community are:

• It can be introduced simply into an existing process; the existing process changes from a continual series of ‘Inspect and Adapt’ sessions; there is no need for a large cultural change up-front.
• It introduces the concept of the ‘kanban board’ that shows product development flow through the development stages; sometimes known as a ‘Story Board’, ‘Sprint Board’ or ‘Team Board’.

• Introduces the concept of limiting the work in progress (WIP) for any column to keep the focus on a small subset of the required work and helping to identify development issues.
• eXtreme Programming (XP) – The XP framework development was led by Kent Beck during the Chrysler Comprehensive Compensation (C3) project.

XP focusses on software development techniques and as such contributes the following to the Agile community:

• User Stories – To avoid ‘Requirements Specifications’, early XP practitioners developed User Stories to define ‘requirements’ on 5x8 cards:

“As a {role name}

I need to {name of business process}

So that {business reason for the business process need}”

• Pair Programming – ‘No line of code is written without 2 people looking at it’.  

This does not double the cost of software development because the reduction in rework needed when using pair programming more than compensates for the apparent extra cost.

• Test-Driven Development (TDD) – ‘No line of code is written without a coded test being written for it first’.

TDD is concerned with Unit Tests; other testing, such as system, integration and user testing is carried out much as the same as in any other framework.

Just as with Pair Programming, above, the quality increase of first-pass coding dramatically reduces any necessary rework.

• Continuous Integration (CI) – With CI a complete build of the parts of the product so far built is done often, sometimes as often as when the source code for each new piece of functionality is checked-in to the source code repository.

CI allows for any integration errors being found as soon as practicable and they are fixed before further development continues.

• Refactoring – is a technique where the working source code for an object-oriented method/function is split into smaller, very focused and re-useable methods/functions.

Although there are significant costs to refactoring during the product development, the cost of the product maintenance is significantly reduced because the source code is easier to read.

There are not many implementations of XP in the world but, as you are probably aware, the above techniques developed by XP practitioners are used by practitioners in many other Agile frameworks.

• Lean Software Development (LSD) – LSD takes the principles of Lean Manufacturing and applies them to software development.

The concepts embodied in the LSD Principles can be used to enhance Agile Values and Principles:

• Eliminate waste
• Amplify learning
• Decide as late as possible
• Deliver as fast as possible
• Empower the team
• Build integrity in
• See the whole

The following are the major misinterpretation or breaking of each of the Agile Principles and suggested ways to fix the problem(s); there are many other ways that some organisations try to ‘break the rules’ but the fixes apply in most cases; it is how the fixes are applied that may vary:

• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Some people focus on the ‘happy customer’ aspect of this Principle and will do whatever the customer asks.  This may make the customer happy in the short-term but the real value to the customer is delivering valuable increments of the product as early and continuously as possible.

The fix – ensure the development team and customer agree on a regular Sprint and Release Schedule and ensure that they keep to it.

• Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

Some Agile teams understand the word "welcome" here as permission to forget about any requirements management at all. What is the easiest way to welcome change? Obviously, just get rid of any requirement documents!  However, this Principle does not mean abandoning any requirements management process.

The fix – Ensure that the Product Owner maintains an ordered Product Backlog and that all change requests are handled by the Product Owner; the PO will decide if the change is justified and, if it is, whether the request is important enough to interrupt the current Sprint or whether it is placed on the Product Backlog in the appropriate business value position.

1. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale
2. There may be some Development Team members that think this Principle applies at the Development Team level but does not apply to themselves individually.  It is difficult to imagine how these people think that the team will deliver without their individual contribution!
3. The fix – Ensure that all Development Team members attend Release and Sprint Planning workshops and contribute appropriately.  Additionally, ensure that all Development Team members attend the daily Scrum; it will soon become obvious if an individual’s progress on their chosen activities is less than ‘optimal’.
4. The Scrum Master should engage any ‘miscreant’ Development Team member in individual mentoring to discover what the underlying problem is that is causing the problem and help the person to improve.
5. Business people and developers must work together daily throughout the project

Working together doesn't mean working without clearly defined rules and processes. Some  teams interpret this Principle as a legalization of chaos; they think that, since we work together, we do not need to define roles, we should not document requirements and we should not care about responsibilities.

This is clearly nonsense; Agile requires that all the responsibilities necessary for successful product development must be identified and an individual or group of individuals take on one or more of those responsibilities.

The fix – As a Scrum Master, for new Scrum Teams, ensure that a workshop is held with the Scrum Team and key stakeholders to define all the necessary responsibilities and ensure that all the responsibilities have been accepted by one or more people appropriately.

Do not allow individuals to ‘quote’ their named role job specification to avoid responsibilities; if they have the knowledge and capacity to fulfil a responsibility outside of their job specification, then they could accept that responsibility.

1. Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done
2. It may be difficult for some ‘managers’ and ‘supervisors’ in the early stages of an Agile transition to ‘let go of the reins’; they are used to assigning low-level tasks to individuals and monitoring their work closely; this implies a lack of trust on their part in the ability of individuals and teams.  Agile teams should be self-organising and self-managing.
3. The fix – As a Scrum Master, you must closely monitor the activities of ‘managers’ and ‘supervisors’ and if these activities are disruptive to the Development Team, then you must mentor the individual ‘miscreants’ to explain the Agile philosophy and Principles to them how their ‘interruptions’ are causing delays in development progress.
4. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation
5. Face to face does not necessarily mean that all people contributing to the conversation being in the same room; some people believe it does and use this to avoid Agile when all people cannot be in the same room.
6. However, technology has moved on since the Agile Principles were written; today, communicating by video-conference and desktop sharing facilities is commonplace.
7. Video-conferencing is preferred over tele-conferencing because with the latter, you lose the ability to observe ‘body-language’, an important part of any communication.
8. The fix – As a Scrum Master, if communication with remote people is needed, whether within the Development Team or with stakeholders, encourage the use of video-conferencing at a time that is suitable to all the people in different time-zones.
9. Working software is the primary measure of progress
10. This Principle states that the working software is the primary measure of progress; it is not the only metric we can use to analyse product development.
11. The Development Team measure and use their Velocity to help them plan; the business (product Owner) measures the benefit achieved from released increments.
12. The fix – As a Scrum Master, you need to ensure that the Development Team and Product Owner agree the metrics that are to be used.  You must help to ensure that the metrics are measurable, relevant and are of value.
13. You need to make sure that collecting any metric may have the effect of changing peoples’ behaviour; for example, if the number of lines of code per day was to be measured, developers may use verbose coding practices thus reducing progress and technical quality.
14. The focus of any metric chosen must be its contribution toward the overall business value accruable from the product increments being delivered.
15. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

This Principle focuses on the wellbeing of all involved with product development but it must not be forgotten that the prime focus of product development is to deliver value to the ‘customer’; the Development Team cannot just keep working at a comfortable pace if they are not meeting the ‘value deadlines’ set by the ‘customer.

The fix – As the Scrum Master, you need to ensure that the Development team estimate the Product Backlog Items and agree with the Product Owner what is possible in a fixed time and what is included in the Product Backlog MVP; ensure that the Product Owner is aware of his/her responsibility to measure the rate of delivery of business benefit.

• Continuous attention to technical excellence and good design enhances agility

This Principle means that there must be technical ‘rules’ in place that must be checked for in each developed requirement source code before it can be considered “Done” and allowed to be reviewed by stakeholders.  If these rules are not in place or they are not checked for, then the quality level will decrease resulting in an unhappy ‘customer’ and reduced progress as required rework is done.

The fix – As the Scrum Master, encourage the Development Team, Product Owner and technical advisors to agree what the technical and design quality criteria are and how they will be checked for; the agreement forms the “Definition of Done” (DoD) that each requirement and increment will be checked against before it is reviewed by stakeholders.

• Simplicity--the art of maximizing the amount of work not done--is essential

To some developers, it is tempting to ‘future proof’ their work, adding functionality that may be or known to be needed later.

This results in slowed progress and potential work when the perceived later need does not transpire.

The fix – Ensure that there is some DoD item that check for future-proofing in requirement source code.  This will encourage developers to:

‘Only do today what is essential to do today’

• The best architectures, requirements, and designs emerge from self-organizing teams

We say that the Development Team should be self-organising for the work that they do during Sprints but they are subject to constraints such as:

• The overall technical architecture to work within; set by corporate tech architects.  The Development Team can ask for amendments to the technical architecture but they have no control over it.
• The requirements – Requirements are the Product Owner’s responsibility; the Development Team can suggest changes to the Product Backlog but they only have control of how the agreed requirements are implanted.
• The design – There may be corporate design standards in place; again, the Development Team can suggest design changes but only have control over how the agreed designs are implemented.

This Principle not just about the Development Team; the self-organising concept applies to the wider group of business and technical stakeholders that must work closely together so that the product can provide the best business value.

The fix – As the Scrum Master, you must analyse any constraints that the Development Team must work with and ensure that adequate processes are in place whereby requested changes are speedily analysed and accepted or not.

• At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly

This Principle is embodied in the Scrum ‘Inspect and Adapt’ Pillar and is enacted through the Sprint Retrospective event.

The Sprint Retrospective is not just about discussing what is wrong but also what is good and maybe the team should do more of.

At the start of an Agile Transformation the team may ‘find’ many things that are ‘wrong’; the long list may be seen by some to be time wasting and others as demotivating; ‘how are we going to address all these problems?’.

Because of this, many teams give up on the Retrospective!

The fix – The discovery of good and bad things during a Retrospective should be time-boxed to maybe 15 minutes when the major points will be discovered.  There are many Retrospective Games that can be played by the team members to make the discovery more enjoyable.

An important part of the Retrospective is that the team prioritise the issues and plan how to resolve the top 1 or 2 issues in the coming Sprint.

Progress on issue resolution can be done during the daily Sprint and the overall success of the improvement plans checked at the start of the next Sprint retrospective.

 The following is a quite comprehensive list of attitudes and skills that contribute to be a great Scrum Master; of course, you don’t have to meet this entire list to be a great Scrum Master; consider it as some inspiration on areas you might want to research. 

• Involves the team with setting up the process. A great Scrum Master ensures the entire team supports the implemented Scrum process.
• Understands team development. A great Scrum Master is aware of the different phases a team will go through when working as a team. He/she understands Tuckman’s different stages of team development: forming, storming, norming, performing and adjourning.
• Understands principles are more important than practices. Without a solid, supported understanding of the agile principles, every implemented practice is basically useless.
• Recognizes and acts on team conflict. A great Scrum Master has read the book ‘The 5 Dysfunctions of a Team’ by Patrick Lencioni. He/she therefore recognises team conflict in an early stage, can apply different activities to resolve it, and even better, he/she knows how to prevent conflict.
• Dares to be disruptive. A great Scrum Master understands some changes will only occur by being disruptive. He/she knows when it’s necessary and is capable to be disruptive enough to enforce a change, but without causing irreparable damage.
• Is both dispensable and wanted. A great Scrum Master has supported the growth of teams in such a manner they don’t need him/her anymore on daily basis. But due to his/her proven contribution he/she will get asked for advice frequently.
• Let the team fail (occasionally). A great Scrum Master knows when to prevent the team from failing but also understands when he/she should not prevent it. The lessons learned after a mistake might be more valuable than some good advice beforehand.
• Encourages ownership. A great Scrum Master encourages and coaches the team to take ownership of their process, task wall and environment.
• Has read… A great Scrum Master has read all the stuff produced by e.g. Geoff Watts, Lyssa Adkins, Tobias Mayer, Henrik Kniberg and Gunther Verheyen. 
• Has studied… A great Scrum Master has studied the Trello board that Growing Agile has published. The Shu-Ha-Ri levels offer a very useful structure to a knowledge base for every Scrum Master.
• Is RE-TRAINED. A great Scrum Master recognizes himself in the acronym made up by Geoff Watts, RE-TRAINED: 
• 
  
  • Resourceful: is creative in removing impediments
  • Enabling: is passionate about helping others
  • Tactful: is diplomacy personified
  • Respected: has a reputation for integrity
  • Alternative: is prepared to promote a counter-culture
  • Inspiring: generates enthusiasm and energy in others
  • Nurturing: enjoys helping teams and individuals develop and grow
  • Empathic: is sensitive to those around them
  • Disruptive: breaks the status quo, help create a new way of working
• Has faith in self-organization. A great Scrum Master understands the power of a self-organizing team.  Attributes of self-organizing teams are that employees reduce their dependency on management and increase ownership of the work. 
• Values rhythm. A great Scrum Master understands the value of a steady Sprint rhythm and does everything to create and maintain it. The Sprint rhythm should become the team’s heartbeat, which doesn’t cost any energy. Everyone knows the date, time and purpose of every Scrum event. 
• Knows the power of silence. A great Scrum Master knows how to truly listen and is comfortable with silence. He/she is aware of the three levels of listening and knows how to use them.
• Observes. A great Scrum Master observes his team with their daily activities. He/she does not have an active role within every session; for example, the daily Scrum is done by the team itself.
• Share experiences. Great Scrum Masters share experiences with peers. This might be within the organisation, but also seminars and conferences are a great way to share experiences and gather knowledge. 
• Has a backpack full of different retrospective formats. A great Scrum Master can apply lots of different retrospective formats. This ensures the retrospective will be a fun and useful event for the team. He knows what format is most suitable given the team’s situation.
• Can coach professionally. A great Scrum Master understands the power of professional coaching and has mastered this area of study. Books like Coaching Agile Teams and Co-Active Coaching don’t have any secrets for him/her. He/she knows how to guide without prescribing. 
• Has influence at organizational level. A great Scrum Master knows how to motivate and influence at tactical and strategic levels.  Some of the most difficult impediments a team will face occur at these levels, therefore it’s important a Scrum Master knows how to act at the different levels within an organisation.
• Prevent impediments. A great Scrum Master not only resolves impediments, he prevents them. 
• Isn’t noticed. A great Scrum Master isn’t always actively present. He/she doesn’t disturb the team unnecessary and supports the team in getting into the desired ‘flow’. But when the team needs him/her, he/she is always directly available.
• Forms a great duo with the Product Owner. A great Scrum Master has an outstanding partnership with the Product Owner. Although their interests are different, the Product Owner ‘pushes’ the team, the Scrum Master protects the team. 
• Allows leadership to thrive. A great Scrum Master allows leadership within the team to thrive and sees this as a success of their coaching style. They believe in the motto “leadership isn’t just a title, it’s an attitude”; it’s an attitude everyone in the team can apply.
• Is familiar with gamification. A great Scrum Master is able to use the concepts of game thinking and game mechanics to engage users in solving problems and increase users’ contribution.
• Understands there is more than just Scrum. A great Scrum Master is also competent with XP, Kanban and Lean. He/she knows the strengths, weaknesses, opportunities and risks of every method/framework/principle and how & when to use them. 
• Leads by example. A great Scrum Master is someone that team members want to follow. He/she does this by inspiring them to unleash their inner potential and showing them the desired behaviour
• Is a born facilitator. A great Scrum Master has facilitation as his/her second nature. 

The empirical process control theory asserts that knowledge comes from experience and making decisions based on what is known ie at defined points within an overall control process, teams must inspect what has happened and, from that experience, adapt the process to what will happen.

The Scrum framework is founded on empirical process control theory so the included ‘Transparency, Inspect and Adapt’ processes are indispensable.

• Transparency

Scrum relies on transparency. Decisions to optimize value and control risk are made based on the perceived state of the artefacts. If the transparency of artefacts is incomplete, these decisions can be flawed, value may diminish and risk may increase

• Inspection 

Scrum users must frequently inspect Scrum artefacts and progress toward a Sprint Goal to detect undesirable variances. Their inspection should not be so frequent that inspection gets in the way of the work. 

• Adaptation 

If an inspector determines that one or more aspects of a process deviate outside acceptable limits, and that the resulting product will be unacceptable, the process or the material being processed must be adjusted. An adjustment must be made as soon as possible to minimize further deviation. 

Transparency and Inspection are important in the Daily Scrums and Sprint Reviews.  Although Adaptation is mainly considered during the Sprint Retrospective, it should be considered at any time during the Sprint if the current process is significantly detrimental to the best value being achieved.

 The Inspect and Adapt process is important throughout the Sprint but especially during the ceremonies:

• Sprint Planning – During Sprint Planning it is important to Inspect:
  • The comments from the previous Sprint Review to ascertain if any remedial work is needed and Adapt the expected velocity if needed
  • The Risk Log to determine if any significant mitigation actions are required for high risks in the Sprint and Adapt the expected velocity if needed
• Daily Scrum – During the Daily Scrum it is important to Inspect the progress toward the Sprint Goal and if there are any concerns about the progress, consideration must be given to Adapting the current priorities, task assignments and/or work practices
• Scrum Review – During the Scrum Review it is important to Inspect:
  • The increment produced to discover if any Adaptations (changes) are required and the priority of those Adaptations
  • The Product Backlog to determine if it needs to be Adapted in the light of any new PBI required, any PBI that can be removed and any reprioritisation required
  • The Release Plan to determine whether it needs to be Adapted considering the experience gained so far during the Release development period
• Scrum Retrospective – During the Scrum Retrospective it is important that the team Inspect:
  • What had gone well during the Sprint
  • What had not gone well during the Sprint

The results of these Inspections should lead the team to considering the Adaption of the process that they followed

 Scrum prescribes four formal events for inspection and adaptation, as described in the Scrum Events section of the Scrum Guide; as a Scrum Master you should attend the events and ensure the team are following the ‘Transparency, Inspect and Adapt’ processes: 

• Sprint Planning
  • Inspect the average Team Velocity over the previous 3 or 4 Sprints, ensure that the velocities have been Transparent to the team and ensure that the team Adapt the Velocity to be used for planning the Sprint
  • Inspect the Product Backlog (PB) and ensure that it is up to date, that it is Transparent to all stakeholders and that the team Adapts the PBI estimates if necessary
    
    
• Daily Scrum
  • Inspect the Team Board and Adapt the plan for the next day ensuring changes are Transparent to all the team
  • Inspect the Impediments Board and Adapt plans to resolve impediments if necessary
    
    
• Sprint Review 
  • Inspect the increment and Adapt the Product Backlog if necessary making sure that any changes are Transparent to all stakeholders
  • Inspect the Release Plan and Adapt it if necessary making sure that any changes are Transparent to all stakeholders
    
    
• Sprint Retrospective
  • Inspect the process that has been followed and make plans to Adapt the process if necessary making sure that any changes are Transparent to all team members

When problem solving and idea creation is needed, for example when constructing the Product Backlog from a product Vision, Objectives and expected Benefits, there are 2 strategies that are usually used, divergent and convergent thinking.

Divergent Thinking

The “divergent thinking” strategy used to solve problems is the proposal of multiple possible solutions then examining each to determine the solution that will work.

In a ‘problem solving’ workshop, the participants are asked for any ideas individually; writing on ‘sticky notes’ is a good idea.  The results are analysed to see if there is any overlap and the participants agree a single list of potential solutions.

Brainstorming and free writing are two processes that involve divergent thinking.

During the analysis of the potential solutions unexpected combinations may be made, information may be changed into unanticipated forms, connections among remote associates may be identified. In divergent thinking, a single question returns multiple answers and though the answers vary considerably depending on the workshop participants, all answers are of equal value; each proposed solution may not have existed before and therefore may be novel, surprising or unusual.

Eight elements of divergent thinking:

• Complexity – The capacity to think of difficult, multi-layered or intricate products or ideas
• Curiosity – The personality characteristic of asking questions, learning to get more knowledge/information about something and of being able to go deeper into ideas
• Elaboration – The skill of adding to, building from or enhancing a product or an idea
• Flexibility – The capability of creating different perceptions or categories from which a range of different ideas may be produced
• Fluency – The skill of producing many ideas to have an increase in the number of potential solutions
• Imagination – The capability of dreaming up or inventing novel products or ideas; to be original
• Originality – The skill of coming up with fresh, unusual, unique, extremely different or completely new products or ideas
• Risk–taking – The readiness to be courageous and adventuresome

Divergent thinking has been detected in people with personality characteristics such as curiosity, nonconformity, persistence and readiness to take risks.

An extreme example of divergent thinking was when Twitter developed an online service that did not have any obvious practical application.  The company deployed a basic application to find out how people used it and, based on the findings, refined the application. Though launching something and finding out what the market for it is only after the launch doesn’t have to be a bullet-proof strategy (in most cases it is not), this worked for Twitter.

Convergent Thinking

Once the divergent thing ‘phase’ of the problem-solving session has been ‘completed’, the workshop participants use convergent thinking to bring together the different ideas to determine a single best solution.

The term “convergent thinking” was ‘created by Joy Paul Guilford. He came up with the term as an opposite term to “divergent thinking”.  

Convergent thinking needs speed, logic and accuracy and relies on identifying the known, reapplying techniques and amassing stored information. 

A vital part of convergent thinking is that it produces one best answer; you either have a right answer or a wrong one.

An example of where convergent thinking would be used is when the problem is:

“If there are 3 potential outsourcing companies, which one do we choose?”

This would require listing all the criteria that the ‘buying’ company need from an outsourcing company and examining each to see which has the best ‘off-the-shelf’ fit or maybe which is open to negotiate to meet all the required criteria.

Summary

Divergent thinking is used to go from one stated problem to many potential solutions.

Convergent thinking is used to from multiple potential solutions to the correct one.

 Frames of reference are everywhere.  For example, if you are in the northern hemisphere and you investigate the night sky, you will see the visible universe as a collection of stars grouped into constellations.  Now imagine a person in the southern hemisphere looking at the night sky; the person will still see the visible universe as a collection of stars grouped into constellations but they will be a different set; the 2 people have different frames of reference.  

If the person in the southern hemisphere says to the person in the northern hemisphere “I think that there is something happening to the fourth star in the Southern Cross constellation”, the northern hemisphere person may not know what the other is talking about and certainly could not tell if something was happening or not

We all have our own unique frames of reference for every subject in our heads; they are based on our experiences of childhood, parenting, education, religion, previous interactions with other people etc and even where we are physically located.

If you live in a country where there are words written in the road to warn you of something, like “SLOW”, if you are in a car, you will see the word SLOW ‘normally’ but if you were in a helicopter above the word you will see it vertically elongated.

It is the same sign but it is seen differently because of the different frame of reference of the viewers.

So why is this important to you?  When people are communicating the words and ideas that they express come from their own frame of reference and the potential for mis-communication is high if the frames of reference of the listener is not like that of the listener.  Imagine trying to describe a hippopotamus to someone who has never seen one; would you try an analogy with something your listener had seen? Would you try to draw one? Not simple!

As a Scrum Master/Facilitator you need to be aware of different peoples’ frames of reference when they are communicating so that you can spot possible misunderstandings in listeners.

The participants in product development workshops will all have their own frames of reference from business and technical and even between people within the same skillset depending on their individual experience.

Listen for jargon and abbreviations in conversation and ensure that all listeners know what the speaker is talking about.

The ‘Groan Zone’

After a period of divergent thinking (see Q – What are ‘divergent’ and ‘convergent’ thinking? ), most groups enter a Groan Zone.

Having just ‘brainstormed’ a list, the next task, in theory, is simple; sift through the ideas and pick a few to discuss in depth. 

In practice that task can be difficult because everyone has their own frame of reference; when people misunderstand one another, they become more confused, more impatient and possibly more self-centred; people repeat themselves, they interrupt, they dismiss other people's ideas and rudely put each other down.

Without a facilitator, at some point, the participants will agree to almost anything, any half-baked, unrealistic, mediocre compromise, just if it will get them out of the room.

One way to help workshop participants gain an understanding of each other's ideas is to encourage them to ask direct questions of one another and listen carefully to the answers. 

However, there are some challenges to this ‘simple’ approach:

• Some participants fear that asking questions might seem confrontational or rude
• Many people cannot cope with the ambiguity of unstructured inquiry and dialogue for very long
• It is hard for everyone to tolerate the poor behaviours and emotional turmoil that occur when people feel misunderstood

 Making decisions in a group has its advantages and disadvantages; the main advantage is that there will be more information and data available by which to make the decision; the main disadvantage is that it can take a significant amount of time.

Let us consider first a jury for a trial.  The decision that they must make is ‘black and white’ or binary; is the defendant guilty of not guilty?

A jury session usually starts with a vote amongst the jurors, guilty or not guilty.  There follows a discussion between people on either side why they have the opinion that they have.  By this means, each juror hears opinions about pieces of evidence that they may have forgotten or dismissed and the relative importance of different pieces of evidence.

After a set time, another vote is taken to see in which direction the overall opinion is ‘going’.

It depends on whether a majority or unanimous verdict is required; if majority, once the requisite number of people all vote the same way, the decision is made; if unanimous, there is a danger that that the longer the discussions go on, those in the minority will vote with the rest just to ‘get it over with’.

There is another decision that a jury can make, they cannot agree to the set majority or unanimous parameters and inform the judge.

But not all decisions are ‘black and white’, most represent a range of options that must be chosen from.  The following are the major recognised ways in which groups of people can come to a decision:

• Consensus decision-making 
• At the start of the decision making ‘workshop’, some participants will have their own opinion of which way the decision should go usually based on their own or their ‘departments’ best interest.  However, the aim of the consensus process is to reach a decision in the best interest of the whole.
• The first thing a facilitator must do is to establish the agreed boundaries of the possible decision spectrum; for an extreme example, if the decision is to be made about new products in a consumer product manufacturing organisation, you wouldn’t expect the boundaries of the spectrum to include ‘Make a spacecraft’.  However, the facilitator must not allow the group to dismiss reasonable innovative ideas.
• Much as in a jury, proponents or ‘champions’ of each possible solution put forward their reasons; others listen and ask direct questions to further understand the reasons from their own frame of reference.
• In this way, the group opinion gravitates in one direction.  Eventually, those in the minority, unless vehemently opposed to the majority, agree to ‘let’s see how it goes and review later’.
• Trying to reach consensus avoids "winners" and "losers".
  
  
• Voting-based methods

Voting of some form will always form part of any decision-making process.  In all discussion-based decision-making, votes are solicited at regular intervals to get a ‘snapshot’ of the group’s opinions and to decide in which direction further discussion would be beneficial.

The following are some of the voting processes that may be used:

• Range voting – Each participant gives each option a score based on an agreed scale and the option with the highest average is chosen. 
• This method has been shown to produce the highest participant satisfaction with the result compared to other common voting methods.
  
  
• Majority – A majority requires support from more than 50% of the members of the group.  Thus, the bar for action is lower than with unanimity and a group of "losers" is implicit to this rule.
• Majority voting is not considered suitable for business group decision making unless a great deal of discussion has taken place beforehand.
  
  
• ‘First past the post’ –  With ‘first past the post’, each participant votes for one option; the option that receives the greatest number of votes is taken as the decision.
• The problem with this voting method is that the winning option may only be supported by a minority of the participants; it is unlikely that those in the majority will actively support the decision.
  
  
• Delphi method 

This method is a structured communication technique for groups, originally developed for collaborative forecasting.  It involves ‘experts’ answering a series of questionnaires and after each questionnaire is completed, a facilitator presents anonymised results and the reasons for those results.  The idea is that each expert modifies their opinion based on the reasons and it is expected that the range of opinions becomes smaller and converges on the ‘best’ decision.

You can possibly see that Consensus decision making is a less structured version of Delphi; all workshop participants are experts in their own field, but their opinions are not anonymised.

• Dotmocracy 

Using this method, participants are asked to place ‘sticky dots’ or use maker pens to indicate for which option they vote for.  The may be given one vote or a range, identified by colours, such as ‘I want this one’ (green), ‘I would be OK with this one’ (orange) and ‘I do not want this one’ (red).

There are different ways of using the results:

• ‘First past the post’ – Like the description of this above, the decision to be adopted would not be the option that the majority voted for but also the option that the least number of participants that voted against it.
• Removing ‘outliers’ – Options at either end of the ‘decision spectrum’ can be removed from consideration and further discussion can take place on a reduced set of options with further dotmocracy votes at intervals to remove other outliers.
• The disadvantage of this way is that innovative options may be dismissed too early.

used especially when listening.  Therefore, they need a space where they will be comfortable and without distractions.

As a facilitator, ensure that the workshop space:

• Has no external diAs with many facilitation tools, facilitative listening is perhaps most useful when there is a chance that conflict may arise.  Facilitative listening is sometimes known as ‘active listening’ and is ultimately about making sure that all group participants are properly listening to each other.

The following are techniques to help with facilitative listening:

• Paraphrasing

It may be that the listener does not totally understand the statements being made by someone:

• The listener could ask the speaker to restate their argument using different words
• The listener could state their understanding of the speaker’s words but in the listeners vocabulary

Both are examples of paraphrasing.

Part of your responsibility as a facilitator is to be aware of the listeners ‘body language’ and if you believe that one or more are not fully understanding what is being said, you could ask:

• The speaker to paraphrase their statements
• A listener to paraphrase their understanding and confirm with the speaker.
  
  Mirroring

Workshops are set up for participants to express themselves but more than just space for expression is needed. If a participant speaks without a sense of being heard, they are likely to either ramp up their expression or else shut down neither of which is desirable for collaborative decision making. Mirroring requires that the speaker can feel that they have been listened to.

Mirroring may take a variety of forms:

• After several people have spoken, a facilitator gives a summary of what has been said so far
• The facilitator can offer a direct paraphrasing back to someone who's just spoken, offering a restatement of the feelings and main points of what was said
• The facilitator or a workshop scribe can write key points onto a shared display that everyone present can view.
• After a general discussion, a synthesised statement may be drafted by one or a few people based on what was said

Mirroring may happen in the moment of a session or in after/between sessions as part of a longer, iterative process.

The effectiveness of Mirroring may be enhanced by checking with those reflected to see if the Mirroring was accurate.

Not all the Mirroring needs to be done by one central facilitator.  A facilitator can also invite others to participate in Mirroring, whether in the whole group or in pairs or small groups.

Mirroring summarizes the state of current knowledge.  Once what is now known is acknowledged, that naturally opens space for new ideas and creativity to emerge, whether for one participant in a meeting or for a group.

• Making space
  • Participants in a decision-making workshop need to be focstractions; noise from roadworks, air-conditioning rattling, next to a noisy office etc
  • Is at a comfortable temperature
  • Has sufficient refreshment facilities available
  • Has enough space to accommodate the number of participants and ‘break-out’ sessions
• Stacking

This technique to aid facilitative listening is called ‘Taking Stack’ and its purpose is to facilitate discussion and decision making in which all participants have equal say in a conversation.  Otherwise, in a structure-less setting, an individual or a small group of people could easily dominate and shut out other participants.

For this method, one group participant needs to fill the role of the Stack Keeper whose responsibility is to structure and order the dialogue of the decision-making process.

“The Stack” is the order of participants who are speaking.  If a participant raises their hand to say something, the Stack Keeper puts them on “Stack”; their name is put at the bottom of stack list.  When the person at the top of Stack has finished speaking, the Stack Keeper crosses their names off and announces who the next two participants on stack are.

Thus, the Stack Keeper is the person responsible for identifying who speaks and when. The Stack Keeper must constantly be paying attention and looking around the room to see who wants to speak.

There are other hand gestures to indicate a request for more immediate contribution when someone else is speaking:

• Direct Response

If a participant has a “direct response” to something that another group member said, they should make the hand motion shown in the picture (index fingers out, thumbs up, moving hands up and down in opposite directions). A “direct response” is only a correction to something that was incorrectly stated by another participant, an answer to a question that another participant had, or that is so important that it must be said at this moment.

The Stack Keeper allows this participant to state their response before the conversation goes on.

Correct Usage: “You asked who volunteered to take over your shift? That was me.” OR “, the store spent $100 dollars yesterday, not $1,000.”
Incorrect Usage: “I disagree with what you just said, because…”

• Clarifying Question

Any participant may make the hand gesture in the picture to indicate that they want to ask a “clarifying question.”  

The Stack Keeper allows them to ask their question before stack goes on.

Correct Usage: “Wait, what were our expenses last week?”
Incorrect Usage: “How can you say that when you disagreed with Jeremy’s point?”

• Point of Process

If a participant feels that the group discussion is not following the correct procedure or a discussion has gotten off topic, they may make this hand gesture and say out loud “Point of Process.”

The Stack Keeper allows them to speak before the next person at the top of stack. They must then say how they think the discussion has gotten off topic or is not following procedure.

Example 1: “I’m not sure why we’re talking about shifts when the agenda says we’re supposed to be talking about salaries.”
Example 2: “There’s a proposal on the table, and I think we should resolve that before we move on to anything else.”

Although a Scrum Master is said to facilitate the team to produce the best results, workshop facilitation is sometimes a different matter.

A workshop facilitator must be independent of the topics being discussed and should not contribute facts or opinions to the conversation.

In most general product development workshops, if he/she has the skills, the Scrum Master may facilitate the workshop.

However, if the workshop is to discuss something like modifying the Scrum process, the Scrum Master does have important things to contribute and should not facilitate that workshop.

The following facilitator activities are required when preparing for a workshop:

• Identify the Workshop Owner – Each workshop must have an owner; the person who needs the group decisions.  For example, for a ‘requirements gathering’ workshop, the owner would most likely be the Product Owner.
• Establish the Workshop Objectives – You can treat a workshop like a mini product development; the Vision is the overall reason for the workshop; the Objectives are the first decomposition of the Vision.  For example:
  • The Vision: To decide which products to promote
  • The Objectives:
    • Decide the products in scope
    • Evaluate the relative value of the products
    • Establish a prioritised list of products to promote
• Establish the Participants – The Workshop Owner should give a list of required workshop participants and/or direct the facilitator to a person who can provide that information
• Establish by when the workshop must be run – All decisions are time sensitive.  It may be that some proposed participants may not be available at specific times.  The date and time of the workshop must be chosen to be within the cut-off date and to maximise the number of proposed participants
• Establish the type of workshop to be run – Workshops can be run as participants sitting around a horseshoe shaped tables to an ‘Open Space’ where participants are free to roam a room with separate areas for discussion on specific topics.
• Arrange the workshop venue – A workshop venue must be chosen and booked to suit the number of proposed participants and the workshop type
• Establish any pre-workshop participant reading materials – It may be useful for proposed participants to have some information pertinent to the workshop before the workshop begins.  Although you, as facilitator, will give them access to these materials, do not expect every participant to have read them!
• Invite the participants to the workshop – Send invitations to the proposed participants with the following details:
• The reason for the workshop
• The Workshop Owner
• The workshop Objectives
• The date, time and venue for the workshop
• The proposed participants; this may be the distribution list on the email; it gives proposed participants to suggest other participants and/or to suggest replacements for themselves
• Arrange for refreshments to be available
• Prepare the workshop space

The coaching stance is what the Agile Coaching Institute (ACI) refers to as “the heart” of their Agile Coach Competency Framework.  The coaching stance is supposed to be the place you start from and return to. 

The coaching stance elements highlighted are:

• maintaining neutrality – do not judge peoples’ attitudes or actions; question them about the whys and how they think that they may improve things
• serving the client’s agenda – do not approach a coaching situation with a set of pre-defined directions that you want the client to follow
• reducing client dependence – introduce thinking and decision techniques that, once used by the client, they no longer need your services
• not colluding – do not collude with the client to introduce attitudes and practices that would be detrimental to the organisation even if they believe that that is what they want
• signature presence – bringing your best self to the coaching situation  

There are many lists of coaching techniques; the following is a comprehensive list but not exhaustive:

• The 5-minute pre-session Check-In – Let your clients complete a short questionnaire before each coaching session. This helps both you and your clients to recognize their progress and success since the last session.  You’ll find out if there were roadblocks and what they’ve been struggling with; it shows you what bothers them most now and what they want to focus on during their next session.
• Use the SMART goal setting technique in your coaching – SMART goal setting stands for Specific, Measurable, Attainable, Relevant and Time-Based.

This technique brings a clear structure into goals.  Each goal or milestone comes with clear and verifiable elements instead of vague resolutions.  The broad goal of “I want to grow my business” will be described in much more detailed and action-oriented steps by the client. The SMART goal could be: “I will win five new clients for my business within this month by asking for referrals, creating two useful blog articles and social media networking”. 

• Let clients write down and share the gold nuggets after each session – Encourage your clients to share their gold nuggets from each session with you; it leaves them with a clear picture of how much value they received from your coaching. 

It’s easy to help them get going with just a few simple questions like: “What was the most valuable takeaway from this session?”. This coaching technique helps you to find out the client’s “A-ha” moments and to avoid misunderstandings. 

If all these notes are organized in a shared stream that is accessible to both you and the client you can reread and recap these nuggets any time at later stages during the process.

• Ask open-ended questions – Open-ended questions allow your clients to include more information, including feelings, attitudes, and understanding of the subject. This allows the coach to better access the clients’ true thoughts and feelings on the topic. 
• Use the power of writing – Writing down plans and goals is the first step towards making them a reality. It commits your clients to act, especially when they are shared and recorded with someone else (like with you – their coach). 

Writing enhances your client’s power of observation and focus during a change or development process. 

A study with two groups has shown that people who write down goals and make a weekly progress report achieved their goals at a rate of 76%, whereas the participants of the group who didn’t write anything down achieved their goals at a rate of only 36%. 

• Be fully present and focused – Take two minutes for yourself and breathe calmly before each session.  Once your meeting has started, try to avoid distractions and give your clients undivided attention. Show your genuine interest and that you really care. This may sound self-evident but is an important step toward building trust and a meaningful coaching relationship.
• Follow-Up with the client – Use regular questionnaires where clients share their progress, experiences, success or challenges they might be facing. 

This ongoing feedback as a follow-up between sessions is a perfect way to monitor and evaluate the effectiveness of the coaching. It shows your clients that you really care about their progress and gives them the feeling they’re not alone with their challenges.

• The coaching journal of progress – A regular progress and reflection journal helps your clients to develop and gain self-awareness. 

A coaching journal is like the ongoing feedback described before. Your clients can write down their emotions, experiences, observations, challenges, success, thoughts, and feelings. They don’t have to wait until the next sessions which might be in a week or two but can share what’s on their mind right in the moment where it happens.

A shared journal gives your clients the feeling that you’re always there for them and “listening” without the need of your presence. They can write whenever they feel like it; at night, in the morning, during the day, at the train station on the way to their workplace or while waiting at the doctor.

A coaching journal gives them the ability to focus on themselves only without any time pressure or distractions. Once written down they can always reread and recap prior entries at a later stage of their process. Once these thoughts are shared with you you’ll gain invaluable information that will take your coaching and mentoring to the next level. 

• Homework assignment to strengthen accountability – No matter if you call it homework, worksheet, questionnaire or action item. They all support the work you’ve been doing within a coaching session. They help clients to reflect, act and achieve necessary milestones towards their bigger goal. 

Homework helps to see if and how the plans from each session are being applied; it helps clients to keep the focus on their plans, ideas, and goals.

The GROW model – The GROW model is a simple method for goal setting and problem-solving in coaching. It includes 4 stages:

1. G for Goal: The goal is what the client wants to accomplish. It should be defined as clear as possible. You could combine it with the SMART method described earlier
2. R for Reality: That is the status quo, where our client is right now.  The client describes his/her current situation and how far she is away from her goal
3. O for Obstacles and Options: What are the obstacles (roadblocks) that keep your client from achieving the goal? Once these obstacles are identified you can find ways to overcome them – the options.
4. W for Way forward: Once identified the options need to be converted into action steps that will take your client to accomplish his/her goal.
5. A Shared To-Do list – The client commits to various action steps and plans during the coaching sessions.  Once they write down and share these ‘to-dos’ with you they put them into existence; they become like a contract between you and the client and strengthens their accountability. 

Another benefit is that both of you know what is getting done and what isn’t at any moment during the process. You immediately see where they procrastinate or struggle and when your support is needed.  The shared to-do list helps to set priorities, achieve milestones faster and keep track of the small wins during a coaching process.

• “My goal is achieved” – It is a great thought experiment if you ask your client to exactly describe a perfect day once the desired goal is achieved. 

It shouldn’t be just a vague description but a whole day from start to finish:

• How would he/she feel after waking up? 
• What would he/she do? 
• How would he/she feel? 

This technique will encourage the client to use his/her positive imagination and visualize what he/she truly desires. 

Afterwards, you can work together to get the actual steps to that “miracle” where the goal is achieved.

• Use every session to become a better coach – Every single session offers you the chance to become a better coach.  Take five minutes immediately after your client left and write down some thoughts; you can:
  • track reactions to questions of a client
  • think about methods and techniques you used in the session and how they worked
  • reflect upon the overall success of the session
  • think about something you would do differently if you could “replay” the session?

Add comments, plans, notes, and ideas for the next session.

Self-organising teams is one of the keys to Agile success but experienced developers who are used to working in a ‘command and control’ environment may find it difficult to adopt this Agile practice; they are used to being told what to do and sometimes how to do it.

Instead of asking the Project Manager (PM) what to next, a developer needs to look at the Team Board and choose what to do next; instead of asking the PM how to do something, he/she should consult their peers on the development team; if no one knows, that is an impediment and the Team should discuss how to resolve the issue.  The Scrum Master, as the Risks and Issues Manager, can help the team decide how to resolve the problem but should not be expected to solve it for them.

The main coaching techniques that a Scrum Master can use to help the team become more self-organising are

• Powerful Questions – are used by a coach to extract more details about a problem or situation; making the inquirers articulate their answer often organises their thoughts so that they start to answer their own questions.

Powerful Questions are open questions ie they cannot have a yes or no answer; they usually start with ‘who’, ‘why’, ‘what’, ‘when’, ‘how’ or ‘where’; they may also start with statements such as ‘Tell me about …’.

Reflecting a statement back to an individual can help prompt further exploration; for example, “You said you were worried about the quality of the product so far … tell me more”. 

For more information about Powerful Questions, see Coaching with NLP.

• Autonomy, Mastery and Purpose – One way for a Scrum Master to help with self-organisation is to look at the Team members’ motivation.  People who rely on outside influences for their motivation, so-called extrinsic motivation, are far less effective than those that are self-motivating, so-called intrinsic motivation.

To foster the intrinsic motivation, we need to examine the following aspects of individuals and the Team:

• Autonomy – We all have an inner-drive to satisfy our psychological needs; if what we are told what to do is not satisfying our inner drive, then we become de-motivated.

Giving individuals and teams more control of what to do, when and how to do it, motivates them more.

Also, if individual Team members identify with their team (their tribe) the team becomes more autonomous and self-directing.

• Mastery – Do not expect individuals or Teams to master Scrum straight out of the training course.  Mastery comes from small steps from what they know now to the goal of Mastery; you possibly know of the problems associated with ‘big-bang’ implementations; the same is true with ‘big-bang’ Mastery.

As a Scrum Master you should discover what the Team members know now and ask them to have a go at something small but significant in Scrum and give them the space and time to experiment on their own to work out how to do it.

Most people want to do better; by helping individuals and Teams toward Mastery leads to greater Team self-organisation.

• Purpose – People and Teams who understand and buy-in to why they are doing their work are much more motivated than those who come to work just to pay the bills and do not care about the work.

Whenever possible, involve the Team in the early stages of product development; let them hear the discussions about forming the Product Vision and Objectives; let them have an input to the Product Backlog ordering.

For more about Autonomy, Mastery and Purpose see Drive by David Pink and Intrinsic Motivation by Richard Ryan and Edward Deci

• Active Listening – To help you gain trust with individuals and Teams, as a Scrum Master you need to use Active Listening techniques to show that you care, understand and are prepared to help them.  The following are the techniques that some coaches use; there are others:

1. Pay Attention

Give the speaker your undivided attention and show that you are hearing the message; your non-verbal communication, body language, can help the speaker feel comfortable.

• Look directly at the speaker
• Do not be distracted by other thoughts
• Do not mentally prepare a response to one thing the speaker has said; you will not be listening to what he/she is saying now
• Observe your own and the speaker's body language

2.  Show That You're Listening

Use your own body language and gestures to show that you are engaged.

• Nod occasionally
• Smile
• Make your posture open and interested
• Encourage the speaker to continue with small verbal comments like yes and OK

3.  Provide Feedback

Your own assumptions, judgments, and beliefs can ‘distort’ what you hear.  As a listener, your role is to understand what is being said; this may that you have to ask questions to clarify what is being said.

• Paraphrase what has been said; for example, "What I'm hearing is... " or "Sounds like you are saying... "
• Ask questions to clarify certain points; for example, "What do you mean when you say... " or "Is this what you mean?"
• Summarize the speaker's comments periodically.

4.  Defer Judgment

Interrupting a speaker is a waste of time; it is frustrating for the speaker and reduces understanding of the message.

• Ask the speaker if he/she has finished a point and if it is OK to ask a question at this time

5.  Respond Appropriately

Do not ‘attack’ the speaker; show respect and understanding of the speaker’s position. You are gaining information and perspective. 

• Be candid, open and honest in your response.
• Assert your opinions respectfully.

See Four Active Listening Techniques and Characteristics of Effective Listening for further reading

There are many challenges facing self-organising teams which can be grouped into the following categories:

• Organisational inertia.  In organisations that have been around for some time, the way that things are done have become habits; many supervisor and management personnel are reluctant to change from fear of their job changing significantly or disappearing altogether

• Individual Team members’ inertia.  Individual Team members may have fears about:

  • having to learn new techniques

  • accepting greater responsibility

  • learning to cooperate with other team members more

  • taking on activities outside of their specialist skills

A Scrum Master must be aware of these potential challenges to self-organisation, look for signs of them and help both the organisation and Teams to overcome them.

Below are 3 typical challenges faced by teams and the possible help that a Scrum Master can give:

1. Bad Forecast:  In the early stages of an Agile transformation, the Teams may be asked to estimate using Story Points, relative estimating, instead of the conventional task estimates that they have been used to.  This technique requires practice to become proficient and early attempts may result in the forecast at Sprint Planning for Product Backlog Items (PBI) to be attempted being significantly in error, generally, Teams tend to under-estimate.  This may demotivate some Team members and make them question the use of the new technique.

Solution: During the early Sprints, at the daily Scrums, the Team will realise that their progress toward the agreed Sprint Goal is slower than they would like.  As a Scrum Master, you should ask the Team if there is anything they can do to improve progress; some changes could improve progress.  

However, the time to address the underlying problem to do with estimating is during the Sprint Retrospective when the estimates for each Sprint Plan PBI should be compared to ‘actuals’ to see if there was any common reason for the estimates being inaccurate or if there were one or two ‘one-off’ estimating mistakes.

If there was a common or systemic reason for inadequate estimates, the Team must re-estimate the Product Backlog in the light of the new evidence; if the errors were due to ‘one-off’ inaccuracies, the Team should re-estimate similar User Stories in the Product Backlog.

Emphasise with the Team that nobody is expecting ‘perfection’ straight away; the importance is that they take time to learn from their experience and apply that learning going forward.

2. Technical Debt:  We build products incrementally; ‘only do today what you need to do today’.  It is probable in later increments that some code that worked for a previous increment no longer works for the current increment so the code is changed.  Over time a single method in the code may have had several ‘patches’ applied to it so that becomes difficult to read and restructure when further ‘patches are needed; this may cause de-motivation in some Team Members and even cause arguments between them about the state of the code.

The programmers aim is for ‘clean’ and simple code but the temptation is to produce something that works now without considering future maintenance needs.  The fact that the resulting code may not be ‘clean’ and simple is known as Technical Debt.

Solution:  Resolving Technical Debt costs time and money; the longer you leave the resolution, the more time and money it costs to resolve.

There are 3 suggested solutions that a Scrum Master can encourage the Team to adopt to address potential Technical Debt problems:

1. Definition of Done (DoD):  Ask the Team to add an item to the DoD to ensure all new or changed code is peer reviewed to ensure that the structure is ‘clean’ and any potentially reusable code fragments are refactored to their own method.

Do not let the Team wait until the end of the Sprint to do the code reviews, have them do it once the programmer believes that he/she has finished.  In this way, there is the shortest time between ‘finished’ and any refactoring that may be needed.

2. Pair-Programming:  The idea of two programmers working side-by-side to develop one function may seem counter-intuitive; it would cost twice as much to produce the code.  However, in the medium to long-term, Technical Debt may be reduced or even eliminated when one programmer is looking on and offering advice to the programmer at the keyboard.

3. Test-Driven Development (TDD): 

With TDD, no line of production code is written before a test has been written to test it, the test is run and is expected to fail.  Only enough production code is written to pass the test.  See Test-Driven Development.

Practicing TDD does require an Integrated Development Environment that supports it and to be successful, all programmers must have the discipline to use it.

Initially, some programmers may be reluctant to use it because of the perceived extra work; however, when they see that the maintenance effort is reduced by more than the extra initial work, they come to accept the practice.

1. Team Member Leaves:  Each Team member has a list of responsibilities and capabilities including their own specialisation, DoD checking and contributing to work outside of their specialisation.

The Scrum Master should keep a list of all these responsibilities and capabilities so that when a Team member leaves the Team for some reason, the remaining members can distribute the leavers responsibilities and capabilities amongst themselves.

If it not possible for any of the remaining Team members to take on any required responsibility or a required capability is not available, the Scrum Master must raise this as an issue with the Product Owner and management; a Team member training may be the resolution to the issue or an additional Team member may be introduced to the Team.  In the latter case, the Scrum Master should monitor how the ‘new’ Team are managing their self-organisation.

See also Self-organizing teams – Challenges and Strategies.

Even good self-organising teams can face challenges with Retrospectives in how they are run and addressing issues that they discover.

The following are some of the most commonly experienced challenges with their suggested solutions:

• Apathy:  After a while, some Team members may consider that the Retrospective is a waste of time:
  • They have already discussed problems that are out of their control to resolve
  • They have improved their process as best they can

Solutions:

• The Team must devise a plan to attempt to resolve ‘external’ problems probably involving the Scrum Master as the Risks and Issues Manager
• Although there may be parts of their process that are working ‘OK’, the Team should devise experiments to innovatively change some parts and review the changes at the next Retrospective
  • Boring:  If all Retrospectives follow the same ‘sit around a table and discuss’ format, they will quickly become boring.  

Solution:  The Retrospective facilitator should change the format of the Retrospectives by using ‘games’ to elicit required information from the group; see Fun Retrospectives and Agile Retrospectives Ideas: Games For Your Next Retrospective for more ideas than a Retrospective facilitator could possibly use

• All Talk, No Action:  During early transformation Retrospectives, the Team are likely to come up with many impediments; the list may seem daunting and the thought of discussing them all is de-motivating.  Also, although the impediments may be discussed and understood by all, there is no plan to resolve any of them

Solution: 

• Timebox the discovery of impediments.  The Team members will, hopefully, only come up with their most important impediments
• Treat the Impediments or Blocks List like a Product Backlog
  • Before discussing any impediment, get the Team to order them in terms of Team importance
  • Discuss only the top 2 or 3 impediments and produce plans to try to resolve them
• Every 2 or 3 days during the next Sprint, get the Team to state how the plans are going
• The first item for the next Retrospective should be to discuss the result of the plans; removing the impediment if it has been resolved or putting it back onto the Impediments List for consideration with the rest of the un-resolved and un-discussed impediments.

 Generally:

• Working groups consist of individuals with specialist skills who take their direction of from a supervisor or manager to produce an output but who do not necessarily interact with each other; ‘traditional’ software development ‘teams’ follow this model; each team member is a specialist whose work is controlled by the Project Manager.
• Teams are comprised of people with specialist skills but interact with each other to produce an output; individuals may work outside of their specialist skills in to produce a ‘team output’

The following table compares how attributes differ between working groups and teams:

                                                         Table 1 - Differences between Work Groups and Teams

There are many lists of the key attributes of effective Agile Teams produced; the following list distils and collates the common themes of most of them:

• Having Ground Rules

Effective Agile Teams set their own Working Agreement, Ground Rules, whereby the members know and buy-into the Team working practices into which are usually elements to do with all the following attributes.

• Working Together/Collaboration

In a successful agile team, the team members work together on features; UI designers, developers and testers work together to ensure that they, as a team, have finished a story.

All Team members are aware of their own and colleagues’ strengths and weaknesses so he/she knows who to go to for improvement advice for themselves and who else he/she can help to improve.  

As the successful agile team collaborates to finish features, they avoid the problem of having many features started but none getting finished at the end of the Sprint.

• Having Short Feedback Loops

Obtaining feedback at regular, short intervals is a major contributor to the success of an Agile team; they use 1 to 3-week Sprints so they can produce potentially shippable increments of a product to obtain feedback form the wider stakeholder community.  During the Sprints, if it is not possible to work with end-users directly, successful teams will seek feedback at every stage of the development of each Product Backlog Item (PBI).

• Being Adaptable

As in all product development, conditions are not always favourable in an Agile environment:

• The Agile team may not have acceptance criteria for every PBI
• A team room may not be present
• The Team may not be able to remove all obstacles. 

However, the Team must get the work done; Agile team members must be adaptable to any kind of situation (be it the ideal or the worst situation).

Agile team members must be willing to work outside their specialisations.  This does not mean that they are expected to work in areas that they know nothing about; they can help other Team members under their supervision; the simplest form of this is for anybody to run test scripts if they are becoming a bottleneck.

• Intra-Team Communication

Good intra-Team communications is one of the major characteristics of a successful Agile team; Team members:

• challenge each other in a non-aggressive manner
• should not filter their communications ie ‘tell it like it is’
• must be willing to exhibit a sense of vulnerability; a willingness to say “I don’t know.” 
• must have the ability to ask for help promptly when they need it
• Being Committed

Successful Agile teams members are fully ‘bought-in’ to the Product Vision and Objectives and are fully committed to achieving the best value for the business within the time and cost constraints. 

They try to find ways to share their knowledge, learn various new things and enhance their own skills. 

Also, all Team members must be able to see where Team members’ workloads stand at all times; if someone is overloaded, members must be willing to help the over-burdened person so as to smooth workflow across the team; this would normally happen during the daily Scrum.

There are several ways to help a Team improve its performance but they can be categorised as follows: 

• Ensuring the Team has common goals and purpose:  The performance of a Team that is ‘pulling in different directions’ will never be optimal; all Team members must know the product development and objectives and fully buy-in to them; no ‘ifs’ or ‘buts’
• Ensuring the Team understands and embraces Shared Accountability:  We all understand self-accountability; you do something wrong and you pay the price.

Team Accountability or Shared Accountability is taking responsibility for others ie Team members must be aware of the work that others are doing and be prepared to challenge their work for the good of the Team

• Having a Working Agreement:  A Team Working Agreement states the ‘rules’ that the Team will follow to produce a valuable product; is something that the Team members discuss and agree; nobody ‘issues’ a Team Working Agreement to the Team.

The Agreement can contain anything that the Team would feel useful to enhance collaboration ie:

• Dates, times and places for the Sprint ceremonies
• How the Sprint ceremonies will be run
• Pair-programming arrangements
• How the ‘Definition of Done’ will be implemented
• Ensuring Psychological Safety:  Psychological safety is the belief that the individuals within the Team are safe for interpersonal risk taking ie a Team member must be able to be themselves and speak their mind without fear of negative consequences to their self-image, status or career.

Adhering to the Scrum value of Respect produces Psychological Safety.

An homogenous team is one where the members are all similar in background, gender, age and culture; we are not talking about similar skillsets but general life experience.

Homogenous teams have been shown to suffer from the following drawbacks:
Stifling of creativity – homogeneous team members have a similar world view and so find it difficult to ‘think out of the box’
Communication – Although homogeneous team members may think they understand what is meant by a colleague’s jargon, they may have misinterpreted which may lead to mistakes; in Teams with members from diverse backgrounds it is more likely that such jargon will be challenged and a greater understanding is obtained by all Team members
Minorities – People not of the same background as the homogeneous Team members may have feelings of exclusion and/or discrimination

 All multi-staged models for team formation recognise different stages that a group of people go through from the start, getting together, to becoming a high-performing team.

There are several published models from those that involve rigorous mathematical steps to analyse team needs and individual attributes, such as that proposed in Two Multi-Objective Stochastic

Models for Project Team Formation Under Uncertainty in Time Requirements, to the more simple and well-known Tuckman Model.

Tuckman’s model, first published in 1965, initially only had the first 4 stages in the table; he added the 5th and 6th stages in 1975.

At first the group of people are reliant on a ‘leader’ and as the group emerges as a team, they become less reliant on a ‘leader’ and become self-organising.

The ‘Definition of Done’ (DoD) is a checklist of all the activities that must be completed for a Product Backlog Item (PBI) before it can be considered ‘Done’ and is fit for review by the wider stakeholder community and potentially released to the live environment; the DoD is a key artefact for Product Development quality control.

The DoD is assembled and agreed by the Product Owner (PO) and the Development Team members.

Potential Problems with initial DoD

There is a possibility that the Team develop a minimalist DoD and submit it to the PO for approval; some PO will give it a cursory glance and approve it.

In such situations, as a Scrum Master, you should remind the PO that he/she is solely responsible for the value to be accrued from the Product Development and that he/she needs to understand each DoD element in case any have been forgotten or any are unnecessary; the best way to achieve this is for you to facilitate a DoD workshop with the PO and Development Team members.

Another problem with minimalist DoD is that they assume that small but significant steps in the development process will be done because ‘they are obvious’; they may be obvious in the ‘cold light of day’ but not so obvious in the ‘heat of development’; as a Scrum Master, you should encourage the rest of the Scrum Team to include more detail in the DoD than seems necessary; items can always be taken out if they are felt to be redundant.

DoD Examples

The DoD for software development may include items such as:

• Detailed requirements analysis done with appropriate business people
• UI and User Experience approved by the appropriate business person
• The system architecture conforms to organisational system constraints
• All code adheres to the coding standards 
• All PBI functionality has been Unit Tested and passed
• Full Regression Testing has been completed and passed
• User Acceptance Testing has been completed and passed
• All necessary documentation has been completed

An actual DoD would probably add more detail to some of the elements.

The DoD for a PBI is usually peer-reviewed by another Team member that has not had significant input to the PBI development.

Given that Scrum is not just for software development, a DoD for a non-software product development, such as running an event, may look something like this for the PBI of ‘As the Invitations Coordinator, I need to send invitations to the event, so that we maximise attendance’:

• The list of invitees has been collated from the {xyz} customer list
• The list of invitees has been approved by the event Project Manager
• The form of the invitation has been designed by the Marketing Dept
• The form of the invitation has been approved by the Marketing Director
• Invitee addresses have been updated

Once all the DoD items have passed their checks, the Invitations Coordinator is authorised to send out the invitations.

The ‘Agile Technical Practices’ or ‘Agile Programming Practices’ all come from work carried out or developed from other ideas by eXtreme Programming practitioners;  They are not part of Scrum or any other Agile framework but have been adopted by many, if not most, Agile programmers as a ‘toolkit’ of ‘best practice’ for producing minimal, ‘clean’ and maintainable code.  The list of practices, with explanations, is as follows:

• A common "war-room" style work area – Where Team members are co-located, they should occupy an area that they can call their own.  

There will be many artefacts that are best displayed on a wall and it is best to keep them in one place.  

Also, the Team members can obtain ‘osmotic communication’ just by being in the same area as others having conversations.

• Sharing the codebase between all or most programmers – Individual programmers do not ‘own’ their own code; it is a shared resource between all programmers.  

Because nothing is considered ‘finished’ the first time through (it may meet the Definition of Done for the current Sprint but may have to be modified for other functionality in a later Sprint), other programmers need access to all the code in order to update it when necessary; if they do not have access, they may write redundant code. 

• A single coding standard to which all programmers adhere – Just as sharing the codebase is an important practice, having a common coding standard reduces the time that a programmer needs to understand code that another has originally written.
• Pair-programming – The simplest practice to implement, it requires that no line of code, production or test, is written without 2 people being involved; one typing at the keyboard, the other reviewing what is being done and suggesting alternatives.  

Contrary to some beliefs, this practice does not double the cost of development because the resulting code will be virtually bug-free thus reducing rework time considerably

• Simple Design – most things are simple when they start out but become more complex as time goes on.  The codebase must be inspected regularly for signs of complexity and the code refactored to produce small, simple functions and methods.  
• Test-Driven Development (TDD) – This practice requires that no line of production code is written unless an ‘automated’ test has been written for the functionality, the test has been run and fails and only enough production code is written so that the test passes.

The practice does require the use of an Integrated Development Environment (IDE) that supports TDD or access to a TDD framework that supports the programming language being used.

• Rigorous, regular refactoring – As stated in most of the practices above no line of code can be considered ‘finished’ until the end of the Product Development.  Even during a Product maintenance phase, the code may need to be modified. If ‘patches’ are added just to make the code work, the codebase will become complex and difficult to modify and maintain; see Simple Design above
• Continuous integration – Even code that works in the IDE and passes all tests, it may fail in the system build; the longer you leave it between system builds (integration), the harder it is to track down what caused the build to fail.

Integration system builds should be done as often as practicable to catch errors early and make them easier to find and fix.

Some organisations do a full build of source code that has been checked-in to the source code repository every 2 hours; some organisations do a full build each time code is checked-in to the source code repository.

This practice does require the use of automated system build systems.

Scaling Scrum involves using multiple Scrum Teams to produce increments of a ‘large’ product; this will involve more people with the potential communication problems.

Of the Agile Technical practices listed in the answer to the previous question, the following are essential technical practices when scaling Scrum:

• Simple Design – the simpler the code design used by one team, the easier it will be for other Teams to understand the code if they need to modify it for their own purposes.
• Test-Driven Development (TDD) – With Teams sharing the Product codebase, it is essential that any Team modifying the code produced by another Team must be able to test that their changes do not ‘break’ the original functionality or ‘interfere’ with code from any other part of the system.

The practice of TDD is the only way to ensure that a full suite of tests can be run to test the whole of the codebase.

• Continuous Integration – with multiple Teams adding to the codebase it is essential that automated integration testing be carried out more frequently than a single Team may use.  The origin of any integration errors can come from any of the Teams and build problems must be fixed as soon as possible to prevent costly bug-fixing toward the end of a Release period.

Definition

Firstly, we must define what the Product Vision is.  Just as any Vision, the Product Vision should be a short statement of what the product is for.  Here are some characteristics of a good Product Vision:

• One sentence
• Emotive and inspirational – a ‘call to the flag’
• Colourful with a logo – for Product Visions that are up on the wall
• Written in the present tense – imagine that the product already exists
• What does the product do – not how it was created or how it works

Roman Pichler, the acknowledged father of Visions, says that Product Visions should be:

• Clear & stable: Every participant should find it easy to understand, so avoid empty phrases that don’t say anything (aka bullshit).
• Broad & engaging: It should depict a higher picture that everyone can relate to and that inspires people to give their best to make it happen.
• Short & sweet: It needs get straight to the point.

Additionally, make it:

• Achievable: Although a vision should be a futuristic idea of what the product might become, set a goal that can be met.
• Insightful: Craft the idea based on users’ needs and motives and define the main reason behind the product’s existence.

Examples

Before investigating how to help the Product Owner create the Product Vision with the Development Team, let us look at a couple of examples:

Tesla:

“Build sports car

Use that money to build an affordable car

Use that money to build an even more affordable car

While doing above, also provide zero emission electric power generation options

Don't tell anyone”

Whilst this Vision ‘breaks’ the one sentence guideline, it does fit Roman Pilcher’s advice.

Ikea:

“At IKEA our vision is to create a better everyday life for the many people”

This is a short and broad Vision for the company that will drive the products that the company produces ie will a proposed product help ‘create a better everyday life for the many people’.

Product Vision Creation

So how does the Product Owner, who is responsible for the Product Vision, go about creating the Product Vision?

Firstly, the creation of a Product Vision is best done collaboratively; as a Scrum Master, arrange a facilitated workshop with the Product Owner, relevant stakeholders and the Development Team to ‘brainstorm’ ideas; you may facilitate the workshop yourself (see Creating A Shared Vision That Works).

There are 2 widely used ‘models’ to use to help create a Product Vision:

1. ‘The Elevator Pitch’
2. Bill Shackelford’s ‘Design the box’

The Elevator Pitch

The idea behind the Elevator Pitch is to put together a statement about something to ‘pitch’ to the CEO when riding in an elevator; we are not going to do this; it is the elements of an Elevator Pitch that we need to explore for the product so that we can come to a suitable form of words for the Product Vision.  There are different lists of Elevator Pitch elements; for now, we will look at the following list from Roman Pichler:

• The Target Group – who the product is likely to benefit
• The Needs – the main problem the product addresses or the primary benefit it offers
• The Product – summarises the three to five features of the product that make it stand out and that are critical for its success
• The Business Goals – explains why it’s worthwhile for your company to invest in the product. It states the desired business benefits, for instance, increase revenue, enter a new market, reduce cost, develop the brand, or acquire valuable knowledge. 

By ‘brainstorming’ the above elements, the workshop participants get a better understanding of the product and can converge onto a suitable Product Vision.

Roman Pichler has a downloadable Product Vision Board that you can use to organise the ‘brainstorming’ ‘sticky notes’ and capture the decisions:

Design the Box

In a facilitated workshop, the participants imagine the product to be a ‘shrink-wrapped’ physical box containing the product; or it may be that the product is to be ‘shrink-wrapped’.

The elements of the box are:

• The Front – The product name, main features and a graphic
• The Back – Product information
• The Sides – Limitations, Health & Safety, Legal

There is a good description of how to run a Design the Box workshop at Design the Box.

Again, as with the Elevator Pitch, the workshop participants get a better understanding of the product and can converge onto a suitable Product Vision 

It is not advisable to go straight from the Product Vision to collecting requirements for the Product Backlog.

The Product Owner (PO) is solely responsible for the value produced by a Product Development and to have some understanding of this value the Product Objectives, Benefits and an initial Business Case should be investigated to check that, in all probability, the product will produce value for the company; it is no good having a great product if no one will buy it and/or it will take 5 years to recoup the development costs.

Figure 3 – From Product Vision to Product Backlog

To help the Product Owner and Development Team move from the Product Vision to the Product Backlog, as a Scrum Master, you can arrange a series of facilitated workshops to determine the Product Objectives, Business Case and Backlog.

Product Objectives

The Product Objectives are a list of things that enable the meeting of the Product Vision.

It should not be a long list; between 5 and 10 is usual; Objectives are not requirements.

Some examples:

• “MVP to be released for the Christmas Market”
• “Reduce report creation time by a minimum of 50%”
• “Increase re-registrations by 50% in 1 year”

Although a Product Vision may state some development attribute that can be measured, most do not; it is the Objectives that should be measurable.  Some people use S.M.A.R.T Objectives.

The Objectives list may also be ordered by business value and may define what is to be included in a Minimum Viable Product (MVP).

Benefits

From the Objectives list, we can now make an estimate of the expected benefits that we expect the product to give to the ‘customer’ (internal and/or external) and the company; each Objective may contribute to more than one category of Benefit; for example, an Objective of “Reduce report creation time by a minimum of 50%” may have the following Benefits:

• Allow Marketing Dept to make faster pivot decisions:
• 
  
  • Less rework: expected savings = 20% of marketing costs
• More timely information
  • Reduced customer frustration: increased customer re-registrations revenue = 50% 
  • Reduced staff frustration: reduced staff turnover and recruiting/training costs = 20%

Although we have used percentage values in the examples above, it is recommended that actual monetary values are used.

Business Case

Now that we have the expected Benefits from developing the product, we must now estimate how much it might cost to develop.

At this point, the Development Team may not have been chosen:

• We may outsource the development
• We may not have chosen the technology to be used
• The potential Team may be busy finishing another product development

To help the PO create an initial Business Case, as the Scrum Master, arrange a facilitated workshop to include the PO, relevant stakeholders and senior ‘technical’ personnel to investigate the probable costs of:

• Configuring something that already exists
• Developing the product in-house
  • Different implementation technologies
  • Hiring contracting staff to cover skill shortfalls
• Outsourcing part or all the development
• Doing nothing: Although the immediate cost of doing nothing is zero, doing nothing now may have significant costs in other areas of the business

From these investigations, the workshop participants must decide as to which option will give, potentially, the best value.

The costs of the potential solution option must be compared with the expected benefits to make a cost-benefit decision as to whether the proposed product development is worthwhile.

See the APM website and other websites for more detailed information and ideas.

Product Backlog

Once the Business Case has been approved, the PO can turn his/her attention to creating the Product Backlog.

As the Scrum Master, organise a facilitated workshop to include the PO, relevant stakeholders and the Delivery Team to discover the Product Backlog Items (PBI), usually User Stories, that will fulfil the Product Objectives.

These PBI will be estimated by the Development Team and the results fed back into the Business Case to ensure that the cost-benefit analysis still indicates a viable development.

The Sprint Retrospective is a key ceremony for ‘Inspect and Adapt’ to aid Continuous Improvement.

Many organisations have only the Development Team, facilitated by the Scrum Master, to reflect on their past process performance and make plans to improve it.

However, The Product Owner (PO) is also a member of the Scrum Team and there are advantages to having the PO included in the participants of the Retrospective:

• Strengthen the relationship with the Development Team and improve collaboration with them:
  • Enough time with the development team?
  • Available to answer questions or provide feedback quickly enough? 
  • Right level of feedback and guidance in the right way?
  • Is communication between the Development team and the PO open, honest, and trustful?
• Understand why the Development Team requires some time in the next Sprint to carry out improvements such as refactoring or investigating a new test tool
• Improve the PO’s own work:
  • Understanding why some PBI were not completed
    • Too big
    • Insufficient Acceptance Criteria
• Does the team know how the users employ the product?
• Are the team members happy with:
  • Their involvement in analysing user feedback and data
  • Changing the product backlog
  • Getting stories ready for the sprint? 
• Do you get enough support from the team to “refine” the backlog?
• Are the team members aware of the big picture:
  • The overall vision
  • The product strategy
  • The product roadmap? 
• Does the PO get enough of the Development Team members’ time to help with product planning and product road mapping?

If the Development Team have ‘a problem’ with the PO, it is tempting for them not to invite the PO to Retrospectives but this ‘problem’ is an issue and as a Scrum Master it is part of your responsibility to help resolve issues; the Retrospective is the best mechanism to discuss and resolve problems between the Development Team and the PO.

 The Product Owner (PO) is responsible for all of the Product Backlog Items (PBI):

• The wording of the PBI
• Each ordering of PBI’s business value
• Each PBI’s Acceptance Criteria

The Development Team are responsible for estimating the size and complexity of each PBI; this will be done initially just before development work begins.

During the development Sprint Planning, the Team must select the next highest value PBI to be attempted during the Sprint.

However, as time goes on, the PO and Development Team need to apply any lessons learned from development so far to ensure that the candidate PBI are sufficiently well described and sized (but see Scrum.org Myth 14); this ‘confirmation’ is done during Backlog Refinement during which the following questions are answered:

• Is the wording of the PBI sufficient for the Development Team to understand what is required?
• Has anything occurred to warrant any changes to the PBI wording?
• Are the Acceptance Criteria for each PBI complete and understandable to the Development Team?
• Is the initial size and complexity estimate for each PBI still valid?
• Are all the candidate PBI sized adequately? – A PBI that cannot be completed in 1 Sprint is too big and must be decomposed
• Is the Product Backlog ordering still correct?

All of these criteria and others to suit a specific situation can be documented as a ‘Definition of Ready’ checklist.

There are a series of blogs that make interesting background reading: Product Backlog Refinement explained.  See also Grooming the Product Backlog

Techniques

• Run the Backlog Refining session as a facilitated workshop, timeboxed to 2 to 3 hours or 10% of the Development Team capacity for a 2-week upcoming Sprint (see Product Backlog Refinement: Make the Most of It) 
• Anybody presents feedback from released increments
• Ask the PO what the next Sprint Goal will be
• ‘Modified’ Planning Poker: 
  • Each Development Team Member has ‘YES’ and ‘NO’ cards
  • Show an element of a PBI and ask participants to select a card
  • All participants show their cards at the same time
  • Ask each ‘NO’ what information they need or have
• PBI wording – use ‘modified’ Planning Poker technique with 
• Acceptance Criteria – use ‘modified’ Planning Poker technique with Development Team members and PO
• Sizing – use ‘modified’ Planning Poker technique with Development Team members (see also Resizing a Backlog, Story Splitting Cheat Sheet and Elephant Carpaccio Exercise)
• Ordering:
  • Ask PO if there are any business value changes that require the Product Backlog to be reordered
  • Ask the Development Team members if any PBI changes introduce new dependencies
• Spikes – if the Development Team do not fully understand a PBI or unsure how it might be developed, they can choose to introduce a ‘Spike’ item to the next Sprint Backlog to do some research into the problem
• Behaviour Driven Development (BDD):
  • Also known as Specification by Example (SbE)
  • An extension of Test Driven Development that requires the use of specialised development tools
  • Uses structured language to automate production of some development artefacts

Although using BDD requires a toolset that might not be available, you can use the structured language to create PBI Acceptance Criteria:

Given {some context}

When {some action is carried out}

Then {a particular set of observable consequences should happen}

                                      An example:

Given my bank account is in credit, and I made no withdrawals recently,

When I attempt to withdraw an amount less than my card's limit,

Then the withdrawal should complete without errors or warnings

For many years, business stakeholders have seen or been involved with building products using the so-called ‘waterfall’ model; business stakeholders are intensely involved at the beginning of the development to specify the detailed requirements and do not get involved again until just before deployment to do User Acceptance Testing (UAT).

People get used to a way of working even if they experience problems with it; it is human nature to ‘get on with it’ and/or develop personal ways of mitigating the problems that they experience.

Many business stakeholders are sceptical about ‘wholesale’ changes to the way that they are being asked to work especially as, superficially, their involvement with the product development is significantly increased.

Also, many senior business managers are risk averse and require predictability from the product development process.

The reasons why the waterfall development model evolved are beyond the scope of this question; to explain Agile to a business stakeholder, you need to know the major elements of the waterfall model that can cause ‘problems’ for the business:

• Gathering detailed requirements takes a significant amount of time where money is being spent for no additional income
• Detailed requirements change over time:
  • If there is little or no business involvement during development, capturing required changes is difficult
  • If the changes are not implemented, the business get the ‘wrong’ product
  • If the changes are implemented, it leads to extra cost and delays in deployment
• The project plan, created just after requirements gathering, is based on estimates but is taken as a quote by many which leads to ‘recriminations’ if the development costs more and/or takes longer

Each business stakeholder will have had frustrations based on one or more of potential waterfall problems; before trying to explain the whole of Agile, it is recommended to start by discovering which areas of the waterfall development process is causing the frustrations and explaining the aspects of Agile that will help overcome them.

One model of product development to base your explanations around is ‘The Iron Triangle’ 

                                                                             The 'Iron Triangle' - Waterfall

Waterfall sets out to define all the detailed requirements and plan how they will be implemented; the resulting ‘contract’ assumes that features, time and cost are all fixed.

However, as already said, it can take a long time to capture the detailed requirements and plan their implementation; however, things never go according to plan (requirement changes, staff changes) and so, when trying to implement a ‘fixed’ requirements list, the result will probably be time and cost overruns.

An Agile product development approach turns the ‘iron triangle’ upside-down:

                                                                                                   The 'Iron Triangle' - Agile

You can see from Figure 4 that with an Agile product development process:

• The business fixes the time for the product development; this time is based on business imperatives such as market or legislation imperatives
• The development costs, which are mainly made up of developer costs, are fixed by having a fixed, cross-functional team
• What is delivered in terms of the requirements is variable

The requirements variability is based on ‘high-level’ requirements and needs some rules to give the business some confidence; the main rule is the Minimum Viable Product (MVP).

One of the major advantages of an Agile product development process over a waterfall one is that the product is delivered incrementally allowing some return on investment before the product is ‘completed’.  Incremental delivery can also help with experimentation when the product details are unclear; parts of the potential final product can be deployed early to get ‘customer’ feedback that will help produce a better product.

One of the important factors when explaining Agile to a business stakeholder is to make sure that they understand the major differences in output that they can expect compared with waterfall and the differences expected of them:

• Documentation will be minimal focusing on what is needed not what might be needed
• Probable participation throughout the development for discovering detailed requirements, planning and reviewing

Another approach to answering this question can be found at How to Explain Agile to Your Stakeholders.

 There are many opinions as to what the ‘typical’ impediments that Scrum Teams face are; the following list is not exhaustive but covers the impediments that Scrum Teams may probably face:

• Old Habits – During the early stages of an Agile Transformation, when many parts of the organisation are not conversant with the implications of Agile, some business and technical managers expect the Scrum Team to deliver documentation and reports that they are used to.  This can be either impossible or time-wasting.

Also, when Development Team Members, new to Scrum, are under ‘pressure’, it is natural for them to revert to old work practices because they know them and having to think about and use the new work practices takes more time and increases the pressure.

Solution:

During the early stages of an Agile Transformation, the role of a Scrum Master as the Risks and Issues Manager, is key.

During the daily Scrum, he/she must listen to what the Development Team members have been working on and what they plan to be working on; note any item that does not seem to be adding to achievement of the Sprint Goal and discuss with the relevant developer after the Scrum has finished.  If the item is a ‘hang-over’ from the old ways of working, the Scrum Master must identify the person who asked for the item and engage them in a ‘Scrum Mentoring’ session to explain why their request is inappropriate.

Similarly, the Scrum Master should question any developer that does not seem to be following the Agile and Scrum practices; for example, the developer may be building the user interface for a User Story from his/her own knowledge, because it is quicker, without collaborating with a relevant business person to get the correct information.

• Distractions – In organisations that are used to using Matrix Management for resource allocation, it is usual for one person to be working on multiple product developments or other work.  This causes the individual to become distracted from the necessary work for any one of their assignments which results in reduced quality of their work and more time overall to complete the work.

Solution:

Scrum requires that the Development Team is made up of all the skills necessary for the development and that the relevant resources are dedicated to the product development.

The Scrum Master must work with the matrix managers to assign resources to one product development at a time for the long-term and not assign people based on short-term expediency.

There may be occasions when a particular Development Team member is considered to be the only person who can solve a problem outside of their immediate product development responsibilities; as long as this is to be a short-term (1 to 3 days) commitment, it is allowable but their reduced development capacity must be reflected in the Team’s expected velocity.  If this situation is a common occurrence, it is a significant impediment to the Team’s progress and the Scrum Master must escalate the impediment to the Product Owner.

• Lack of cross functional teams – In the waterfall model of product development, the ‘team’ is not constant throughout the development:

The team member skills are different for each ‘phase’ of the waterfall development process, whereas with Scrum we require all necessary skills to be available at all times throughout the development:

Solution:

As in Distractions above, the Scrum Master must work with the organisation resource allocators to ensure that Scrum Development Teams are composed of members with all the necessary skills for the development all of the time.

• Old HR Systems – The traditional HR system for compensating employees is based on the individual; their skills, their seniority, their responsibilities.  This is particularly true of ‘Performance Related Pay’; it is a competitive system.

We expect Scrum Development Teams to be self-organising, cross-functional and work in a collaborative manner; traditional HR systems are an impediment to this goal.

Solution:

The Scrum Master must work with the HR department to make them more Agile.  There is a good article from the Agile Alliance, Practicing Agility in Human Resources, to help with this HR coaching.

• ScrumBut – The ‘mechanics’ of Scrum are relatively easy to implement but it is implementing the Agile values from the Agile Manifesto, the Agile Principles and the Scrum values from the Scrum Guide that make Scrum work; these values are principles are the hardest part of Scrum to implement because they require an organisational culture change.  Many organisations implement the Scrum ‘mechanics’ and ignore the values and principles and then wonder why this ‘Agile thing’ is not working.

Solution:

It is not possible to change an organisations whole culture overnight!

It is recommended that the Scrum Master, during the early stages of an organisational transformation, focus their ‘culture changing’ efforts on the stakeholders directly involved with a single product development.

Some may be sceptical so the Scrum Master may have to spend a significant amount of mentoring time with them.

Even though the Scrum Master may explain the implications of Scrum to sceptical stakeholders (and developers in some cases), some people do not believe until they see the results.  Be prepared to answer all the sceptical people’s questions but do not let them introduce non-Agile practices.

• Late Attendance in Meetings – In ‘traditional’ organisations where there are many meetings, many required meeting attendees get bored and turn up late because they know that the early Agenda items probably have nothing to do with them.

Solution:

Do not hold meetings!

Do not have Agendas!

When more than two people are required to discuss a topic or make decisions, hold a facilitated workshop.  Although some say that a facilitated workshop should have an Agenda, the word ‘Agenda’ still indicates to some that a facilitated workshop is just another name for a meeting.  Instead, have clear workshop objectives which are tightly focused around a single topic so that all workshop invitees are motivated to attend on time.

For those people who still consistently turn up late, the Scrum Master must individually mentor the person as to why it is important for them to be on time:

• They may miss something of importance to themselves
• They may miss something that their input to the discussion would be vital
• Asking to recap what has been discussed in their absence wastes other peoples’ time
• Blocked Work – The development Team will rely on people who are non-team members for information or reviewing of work before they can move on.  Sometimes these people consider their primary responsibilities to be more important than their product development contribution or their supervisors do not allow them the necessary time.

This results in ‘blocked work’ and will probably be ‘reported’ during the daily Scrum.

Solution:

The Scrum Master, as the Risks and Issues manager, must work with the affected developer to resolve the problem and if the resolution is not successful, he/she must escalate the problem to the Product Owner (PO) who may have to use their seniority and company politics to resolve the problem themselves.

Remember that the PO is solely responsible for ensuring the best business value emanates from the product development; blocked work reduces business value.

• Supplier Issues – Similar to Blocked Work above, the Development Team may have to rely on parts of the product development solution that they have to integrate with being supplied by other teams; these teams may be internal or external to the organisation.

The suppliers may or may not be using Agile or specifically Scrum for their development work.

The other teams may deliver their parts late with respect to the plans or the delivered part may not be of suitable quality.

Solution:

The process for dealing with Supplier Issues will probably be different between ‘internal’ and ‘external’ suppliers.

• For ‘internal’ suppliers, the first action would be for the Scrum Master to discuss the problem the Project Manager or Scrum Master of the ‘internal’ team
• For ‘external’ suppliers, the first action would be for the Scrum Master to approach that part of the organisation that let the contract to discover the dispute process and to follow that 

In both cases, if resolution is not possible and given that there is Programme Management in place, the Scrum Master should escalate the problem to the PO and facilitate the problem resolution with the Programme Management.

A longer-term solution to minimise Supplier Issues is for the organisation to have all ‘internal’ suppliers using Agile techniques and only use Agile Contracts for engaging ‘external’ suppliers; you can find more information about Agile Contracts at Agile Contracts or Agile Statement of Work - Must-Haves and Agile Contracts - The Foundation of Successful Partnering.

It is often tempting to see the immediate symptoms of a problem and fix things so that these symptoms disappear only to see different symptoms appear later for a related problem.

To successfully solve problems, we must get to the root cause of the problem; so-called Root Cause Analysis (RCA).

The following are popular techniques used to carry out RCA:

• Brainstorming

Brainstorming the RCA relies on several people producing their thoughts and feeding off other people’s thoughts in order to converge on the probable root cause of the problem.

It is a relatively unstructured technique for RCA and it can be difficult to see the root cause amongst a great deal of data.

The 5 Whys

The 5-Whys technique is possibly the simplest RCA technique; it is a little like an annoying 5-year old asking question after question to the answers you give them.  Essentially, the RCA workshop facilitator keeps asking “why” until an apparent problem root cause is discovered.

Generally, a minimum of 5 ‘Why?’ questions are asked, although sometimes more or less may be needed.  For example:

This example could be extended to discover why the vehicle had not been maintained properly; the root cause could be that the need for regular servicing was unknown; the questions go on until the group agree that a fixable cause has been found.

Flowcharting

Flowcharting can help discover problems about a process in a graphical manner; a group of people affected by the problem will chart the supposed ‘As-Is’ process to see where the problem has arisen:

• Someone does not know that they have responsibilities in the process
• A vital step in the process has been left out or is not being ‘run’
• A step in the process is producing incorrect output

Fishbone Diagrams

A Fishbone or Ishikawa Diagram is most useful when the “5 Whys” technique is considered to be too basic. 

In a Fishbone Diagram, the various causes are grouped into categories, with arrows in the image indicating how the causes flow toward the problem; categories used in the diagram are not pre-defined but common categories include equipment, processes or methods, measurements, materials, environment and people.

This type of RCA seeks to understand the possible causes by asking questions such as “what actually happened,” “when,” “where,” “why,” “how,” and “so what” until a possible cause is identified and the consequences and significance is investigated further for each category; for example:

Figure 8 - Example Fishbone Diagram

• Affinity diagrams

An Affinity Diagram is a tool that gathers large amounts of language data (ideas, opinions, issues) and organizes them into groupings based on their natural relationships.  The Affinity process is often used to group ideas generated by Brainstorming.

See Affinity Diagram for more information

 The Scrum framework, as described in the Scrum Guide, is focused on one product development Scrum Team.  However, in many large organisations, products can be large with various diverse aspects that make up the product that could not be developed by one Scrum Team; they require a programme of product development teams.

There are a few ‘Scaling Scrum’ frameworks that address using multiple Scrum Teams to develop one product, the more well-known of such frameworks are as follows:

• Large-Scale Scrum (LeSS)

LeSS provides 2 Scrum Scaling Frameworks

• LeSS: Up to up to eight Scrum Teams of eight people in each Team
• LeSS Huge: Up to a few thousand people developing one product

Both frameworks follow the same ‘rules’:

• A single Product Backlog that each Team draws from
  • One Definition of Done for all teams 
  • One Potentially Shippable Product Increment at the end of each Sprint 
  • One Product Owner 
  • Many complete, cross-functional teams with no single-specialist teams
  • All Team Sprints are concurrent.

In LeSS, all Teams are in a common Sprint to deliver a common shippable product, every Sprint.

The following is how the LeSS frameworks run Sprints:

• Sprint Planning Part 1 – In addition to the one Product Owner, it includes people from all teams. 

Team members self-manage to decide their division of Product Backlog Items. Team 

members also discuss opportunities to find shared work and cooperate, especially for related items.

• Sprint Planning Part 2 – This is held independently and usually in parallel by each Team 
• Daily Scrum – This is held independently by each Team although a member of Team A may observe Team B’s Daily Scrum to increase information sharing
• Coordination – Teams or rotating representatives from each may hold an Open Space, Town Hall Meeting or Scrum of Scrums regularly to increase information sharing and coordination
• Overall Product Backlog Refinement – There may be an optional and short overall Product Backlog Refinement (PBR) workshop that includes the one Product Owner and people from all teams. 

The key purpose is to decide which teams are likely to implement which items and therefore select those items for later in-depth single-team PBR. 

It is also a chance to increase alignment with the Product Owner and all teams.

• Product Backlog Refinement – A Single-Team PBR, the same as in one-team Scrum.
• Overall Sprint Review – In addition to the one Product Owner, it includes people from all Teams and relevant customers/users and other stakeholders. 

For the purpose of inspecting the product increment and new items, consider a “bazaar” or “science fair” style: a large room with multiple areas, each staffed by team members, where the items developed by teams are shown and discussed.

• Overall Retrospective – To explore improving the overall system, rather than focusing on one Team. 

The maximum duration is 45 minutes per week of Sprint. 

It includes the Product Owner, Scrum Masters and rotating representatives from each Team.

See LeSS Framework for more information about LeSS.

• Disciplined Agile Delivery (DAD)

The DAD process decision framework provides a cohesive approach to agile solution delivery; it is defined as: 

“The Disciplined Agile Delivery (DAD) decision process framework is a people-first, learning-oriented hybrid Agile approach to IT solution delivery.

It has a risk-value delivery lifecycle, is goal-driven, is enterprise aware and is scalable.”

DAD extends Scrum with proven strategies from Agile Modelling (AM), Extreme Programming (XP), Unified Process (UP), Kanban, Lean Software Development, Outside-In Development (OID) and several other methods.

DAD doesn’t prescribe a single lifecycle because it recognizes that one strategy does not fit all. 

DAD includes advice about the technical practices such as those from Extreme Programming (XP) as well as the modelling, documentation, and governance strategies 

missing from both Scrum and XP.

See Going Beyond Scrum for more information about DAD.

• Scrum at Scale (S@S)

“S@S is a framework within which networks of Scrum teams operating consistently with the Scrum Guide can address complex adaptive problems, while creatively delivering products of the highest possible value”

The S@S framework is based on the ‘Scrum of Scrums” (SoS) concept but the SoS becomes a Team within its own right and coordinates the work of several Scrum Teams; equivalent to a Programme Management Team.

For large multi-programme developments, The SoS is scaled via a “Scrum of Scrums of Scrums” (SoSoS) Team.

For coordinating the whole Agile Enterprise there is an “Executive Action Team” (EAT):

• Each grey pentangle represents a 5-person Scrum Team
• Each small red pentangle represents an SoS Team coordinating 5 Scrum Teams

For more information about S@S, see The Scrum at Scale Guide

• Enterprise Scrum

The Enterprise Scrum initiative was formed to give a definition of what “Business Agility” is:

“Business Agility is the ability to adapt quickly and effectively to all forms of change to deliver maximum value and customer experience”

Enterprise Scrum provides a way to implement Business Agility; it is a generic framework to implement Agile Management for just about anything.

The framework consists of the following:

• Create 3 roles:
• Business Owner — provides both vision and support
• Coach — provides coaching to do the best Enterprise Scrum possible
• Team — does the work
  • Follow this process:
• Vision — what you want your company to be
• Initial Value List — what you want to do “one customer segment” at a time
• Cycles — get organizations to have Business Agility
  • Each Cycle has:
    • Planning — what we want to accomplish
    • Collaboration — get things DONE passing a DOD (definition of done)
    • Review — review what we got DONE, and where we are in all important things
    • Improve — find ways to improve in all important things

All Enterprise Agile personnel must act according to Agile Values and Agile Mindset to create an Agile Team with an Agile Culture.

See Enterprise Scrum Business Agility for more information about Enterprise Scrum.

The senior management of some (if not many) large organisations, having accepted the ideas behind Agile and knowing that the one-team Scrum framework is inadequate for their organisation, try to go straight from a traditional organisation to a ‘Scaled Scrum’ organisation.

Those that have tried this have hit severe cultural problems and perceive that ‘Agile does not do what it says on the tin’.

Implementing the cultural changes required for single-Team Scrum is difficult enough; the problems with trying to implement the cultural changes required for ‘Scaled Scrum” are exponentially more difficult.

The following is advice about when not to scale Scrum:

• Don’t try to scale when you are first starting out –  When beginning the agile journey, it’s critical that you start small and master the basics. Introducing a large enterprise framework with multiple dependencies presents a steep change curve and typically requires extensive investment. 

In the early stages, you will reap greater benefits if you focus on developing the core agile principles and Scrum Values

Work on developing a good backlog, meeting commitments, reaching a standard velocity, and achieving high-quality output. 

Additionally, starting small creates excitement, focuses on quick wins and learning more nimbly. 

• Don’t start before you have nailed the basics –  You may have reached the stage where you have multiple Scrum teams, that are working well in a Scrum environment and have started introducing larger epics that could benefit from being split across multiple teams.

This may seem like a natural point in the journey where you may start to ask whether you are ready to scale. 

Before taking that leap, it is strongly recommended to optimise your current Scrum teams and Agile processes; really concentrate on strengthening your base in order to maximize throughput and ROI—instead of trying to build the product-development processes that you will need for Scrum at scale. 

If you are at this point in your Agile journey, take a look at implementing test-driven development, continuous integration and deployment (not included in the Scrum Guide) and meeting commitments on a regular cadence. 

• Don’t do it just to do it – Scaling Scrum has become incredibly popular in many industries; SAFe is a buzzword in the agile community; companies that are truly ready for enterprise frameworks are getting major rewards from them but that by itself is not a sufficiently good reason to move to an enterprise framework. 

The transition from team-level Scrum processes to an enterprise framework requires a significant investment in change management. The move should be well thought-out and cautiously approached. If you have specific problems that scaling can solve, lay them out with an advisor and see if the journey is worth the investment. 

When you’re ready, know that enterprise frameworks are tried and true tools that have delivered tremendous benefits for many organizations but you have to be at the right point in your journey to take advantage of these tools.

 When a product is being developed by multiple Scrum Teams it is recommended that there be 1 Product Backlog (PB) for that all the Teams draw from to produce their own Sprint Backlogs.

It is probable that 1 Team may be dependent on an output from another Team before they can develop a particular Product Backlog Item (PBI); for example:

• Suppose that part of the product being developed requires a customer to pay for goods/services; we may have a User Story as a PBI something like this:

“As a customer

I need to pay for my goods/services

So that the company will send them to me”

• At some point in the development it is realised that there are so many ways to pay (credit card, debit card, PayPal, WorldPay etc) that the User Story could not be completed by 1 Team in 1 Sprint; ie it is an Epic
• It is decided to split the User Story above into 1 User Story for each payment method
• It is decided that the MVP for the next release includes paying by credit card and paying by PayPal
• It is further decided that Team A will develop all the common elements of payment as part of developing the ‘Pay by Credit Card’ functionality and Team B will develop the ‘Pay by PayPal’ functionality, which will use some or all of the common payment elements

Clearly, Team B has a dependency on Team A such that Team B cannot start their part of the payment functionality until Team A has completed their part.

When Scaling Scrum, the aim of Release Planning is to minimise the inter-team dependencies; it is improbable that all inter-team dependencies can be eliminated.

The following are some of the ways that inter-team dependencies could be handled:

• User Story Mapping and Minimal Marketable Features (MMF)

MMF is the group of features that make up the MVP.

The Release Plan may be developed using the following steps:

• Ensure that all candidate features and User Stories/Epics are decomposed to manageable sized User Stories
• Assign User Stories to the MVP
• Assign User Stories to potential Team Sprint Backlogs keeping in mind any dependencies 
• Highlight dependencies

For the payment example above, you may end up with a Release Plan Board and proposed Team Sprint plans that looks something like:

                                                                                         Possible Release and Sprints Plans

You can see that all Release MMF are planned to be finished by the end of Sprint 2 leaving Sprint 3 to cater for any overruns.

• Team Structuring

With the advent of Component-Based Development (CBD), some organised their development teams into Component Teams and Product Teams who ‘glued’ together the necessary components.

If this continued into an Agile environment, then each ‘product’ development team would be dependent on separate component teams and the required coordination would be an onerous task.

In an Agile environment it is recommended to have ‘Feature Teams’; 1 Team should be responsible for the end-to-end development of all of a Feature’s User Stories.  

This does not preclude the reuse of components; part of the organisation’s Design Strategy would require that a separate (possibly non-Agile) Component Management Team (CMT) reviews the output of the Development Teams to see if there is any functionality that could be componentised; the CMT are responsible for componentising the functionality and maintaining a Component Library.

Before writing any code, the Development Team search the Component Library for any components that would be useful.

                                                                                                 Component Teams

                                                                                                      Feature Teams

• Scrum of Scrum Workshops
  Scrum of Scrum meetings are conducted at regular intervals, probably at least once per week, to track dependencies among scrum teams.
• Use Kanban/Scrum Boards to Visualize Dependencies
  Dependency threads or tags may be used for visualization of dependencies among features and/or teams.

• Use a Central Dependency Team for Large Enterprise Programs
  As part of Agile programme management, “independent” dependency teams may be used to track inter-team dependencies, blockers, external dependencies and ensure they are taken to closure.

When scaling Scrum, many of the Scrum Events/Ceremonies need to be run with all programme Teams and, sometimes, all product stakeholders present.

This obviously requires a larger than normal space but the format used is important as well to maximise the value of the ‘workshops’; for example, for a Sprint Review where several Teams are ‘show-casing’ what they have produced, it would be boring for the stakeholders just to sit through multiple presentations and demonstrations especially if there are features being reviewed that they have no immediate interest in.

Scaled Scrum Events/Ceremonies are best run if everyone is co-located or can travel to the Event.  This is not always possible or economical for organisations that have programme Development Teams and stakeholders scattered around the world.

• Overall Programme Scrum Event Process

The overall Programme Scrum Event process is similar for both non-co-located and co-located Events:

• All participants attend an opening session where the objectives and specific process for the workshop are explained
• Depending on the needs of the workshop, all participants may stay ‘together’ for the whole workshop (unusual) or ‘break-out’ sessions may be held that focus on specific workshop topics; anybody may attend a ‘break-out’ session if the topic is of interest to them
• If ‘break-out sessions are used, then it is usual for all participants to come ‘together’
  • At least once during the Event for ‘catch-up’ and information sharing.  There may be discussion about altering the Event process
  • Toward the end of the Event for ‘catch-up’, information sharing and conclusion purposes
• Non-Co-Located Programme

For non-co-located Teams and stakeholders, use should be made of tele-conferencing and video-conferencing technology.

Scheduling of combined and ‘break-out’ sessions can be difficult if the Teams and stakeholders are in widely different time zones; what would normally be a half-day Event may have to become a full day or even a day and a half.

• Co-Located Programme

For a co-located programme and stakeholders, it is essential that the ‘main room’ is big enough to hold all participants and is equipped with white boards and flip charts.  If the room is really large, then a big screen and PA system may be required

The ‘break-out’ sessions may be held in the same room; some or all may be held in readily accessible smaller rooms.

• ‘Big-Room’ Formats

The detail of how the ‘big-room’ Events may be run and facilitated vary but the 2 most common are Open Space and World Cafe.

The following are how the ‘standard’ Overall Programme Scrum Event Process may be configured for specific Events:

• Release Planning

For one-Team Scrum we would only plan a Sprint at the beginning of a Sprint wherever we are in the Release cycle but for a programme, the stakeholders will need to have some idea what will be in the Release and the Teams need to produce outline Sprint Plans so that dependencies between Teams may be discovered, minimized and planned for.

Before the joint planning session, the Programme Manager will have worked with the relevant stakeholders to set a Release Goal and select potential features for the Release ordered by business value.

At the start the start of the Event the Programme Manager may allocate potential Release features to Teams or the Teams can volunteer for them.

The Teams, aided by relevant stakeholders, will go into concurrent ‘break-out’ sessions to decompose the features into User Stories and estimate the total effort required for each feature; this activity should be timeboxed to reduce the risk of the Teams going into too much detail.

The Teams will come together to see each other’s list of User Stories, to identify dependencies and distribute User Stories so that the effort is spread evenly between Teams.

The Teams then go back into ‘break-outs’ and produce an outline Sprint plan for each Sprint in the Release.

Finally, everybody comes together to produce/update the Release Plan Board with the outline Team Sprint Plans to ensure that the highest value User Stories will be developed first and that inter-Team dependencies have been catered for.

• Sprint Planning

Some Programme Teams hold their individual Sprint Planning in the same space but separately and then ‘compare notes’ toward the end of the session to ensure that dependencies have been identified and catered for.

• Daily Scrums

Some co-located Programme Scrum Teams hold the daily Scrums at the same time and in the same space but separately, then each team summarises any highlights to the other Teams.

Other organisations hold their Team daily Scrums as ‘normal’ and the Scrum Masters have their own ‘daily Scrum of Scrums’ at a convenient time.

• Sprint Reviews

A programme Sprint Review involves all Teams and all relevant stakeholders so the large space is needed for a co-located programme.

The workshop starts with the Programme Manager summarising what has gone on in the Sprint then the stakeholders attend as many Team demonstrations and hands-on trying of functionality as ‘break-outs’, held either in the same space or readily accessible ‘break-out’ rooms.

There are usually white boards and/or flip-charts available for stakeholders to make notes about things that they would like to be discussed toward the end of the Review when everybody comes together again.

The final ‘all-together’ session also includes the Programme Manager asking the stakeholders if there are any features/User Stories that need to be added to the Product Backlog; if there is anything that needs to be deleted from the Product Backlog and if the current ordering is still viable.

For non-co-located Teams and Stakeholders, the individual ‘break-outs’ can be run as concurrent timeboxed ‘webinars’ at scheduled times throughout the Review session; each Team running several ‘webinars’ to allow as many stakeholders the chance to ‘login’.

• Sprint Retrospectives

Although each Programme Scrum Team may hold their own Sprint Retrospective, it is important that a Programme Sprint Retrospective is held.

A Programme Sprint Retrospective follows the Overall Programme Scrum Event Process described above; the opening session is used to identify the good and bad things about how the programme is running and choosing the most important issues that need to be addressed.

Each ‘break-out’ session focuses on one area of issues and any members for any Team attempt to find the root cause of the issue and devise resolution plans.

There may be an interim coming together to discuss progress so far and maybe add to or subtract from the list of issues to be discussed in a second ‘break-out’ session.

During the final coming together, the results of the ‘break-out’ sessions are discussed and plans are devised to resolve the most important issues.

 Scrum Team productivity is difficult, if not impossible, to measure for a single Team and definitely impossible when comparing productivity of different Teams.

The metric that Scrum Teams usually use to help them plan Sprints is the Development Team velocity; some ‘managers’ believe that Team productivity is directly linked to Team velocity; the higher the velocity, the higher the productivity.

Nothing can be further from the truth!

Velocity is Team, product and time specific and should only be used to aid Sprint planning.

The value that a Development Team is delivering per Sprint cannot be used as a measure of productivity either; by its very nature, a Team will deliver higher value at the start of the product development because they will be working on higher value User Stories.

Increasing Scrum Team productivity can only come from ensuring that the fundamental ‘rules’ and ‘values’ of Agile and Scrum are being followed.

The following are the main areas of organisational change that will help improve Scrum Team productivity:

• Senior Management Awareness and Involvement – In the 2015 State of Scrum Report it was stated that: 

“Respondents report that senior management sponsorship and support is far and away the most important factor in adopting Scrum.”

AND

“… though senior management support is considered critical in Scrum adoption, only 7% of respondents reported that as visible in their organizations.”

The need for senior management Agile awareness and involvement in product development is that Scrum Teams are not isolated ‘islands’ in the organisation, they have to interact with other parts of the organisation that may resist changes to their work practices for the Scrum Teams to be productive.

The motivation for these other organisation parts to adapt must come from senior management.  

As an example, an Agile Team was formed to implement a new process to get connecting passengers from one aircraft to another, especially if the inbound flight was delayed.  The new process involved the development of a new IT system and the team planned to release increments of the new software monthly.

However, when it came to the first release, the team discovered that there was an organisational process that required 2 months before ‘desktop ready’ software could be made ‘live’.

The problem was resolved eventually by allowing the team to have a ‘fast-track’ release process but the resolution took a month of discussions with the management of 3 other divisions within the organisation.

When an Agile/Scrum transition starts, it is important to discover all the stakeholders, at whatever level in the organisation, that can influence the early team’s productivity and ensure that they understand the possible implications to them and their subordinates of the Agile transition.

Mark Levison suggests one way of coping with the necessary senior management ‘education’ in his blog, Taking Organizational Improvement with Scrum Seriously;  he proposes a ‘Change Management’ Scrum Team to develop the organisational change product.

• Keep Teams Together – The ‘traditional’ approach to product development is to create a project, assign the right people when they are needed throughout the project; there is never one coherent team; ie ‘bring people to projects’.

The Team members in Agile have all the skills needed to complete a product development; the Team size is generally constant for the whole product development.

If we take Tuckman’s group dynamic model, all groups of people go through ‘forming’, ‘storming’ and ‘norming’ ‘phases’ before the group becomes ‘performing’; it can take a significant amount of time before the ‘performing’ stage is reached.

It therefore follows, that once a Team has reached the ‘performing’ stage, we should keep the Team together after the product development is finished; the ability to work well together as a team is more important than any individual skills.

Keeping teams together can be characterised as ‘bring projects to teams’.

• Allow the team to determine their Sprint capacity – Some Product Owners (PO) ‘cajole’ some Development Teams to take on more work in a Sprint than the Team members think is possible.

This has 2 possible effects on individual team members:

• They know it ‘won’t’ happen and that they will be blamed.  They become demotivated and do not work productively
• They try to work faster to complete the work and cut-corners, producing low quality outputs.  Overall team productivity falls because of all the necessary rework later

The team must be allowed to do their own estimation and set their own ‘comfortable’ Sprint capacity; the Team members must collectively believe that a Sprint plan will work at the end of Sprint Planning.

• Do not add work during the Sprint – The aim of Sprint Planning is to set the Sprint Goal and add the relevant Product Backlog Items to the Sprint Backlog that will contribute to the Sprint Goal.

There are still many established ‘Agile’ organisations where it is normal for Development Teams to receive extra work during the Sprint from different people, most of which does not contribute to meeting the Sprint Goal.

To be productive, a Development Team need to keep focused on the Sprint Goal, distractions reduce product development productivity.

Most of this extra work can be categorised as ‘fire-fighting’; there are 2 approaches to resolving this ‘problem’:

• Form a ‘fire-fighting’ team to deal with ad-hoc work
• Find the root cause of why this extra work is needed and fix the root cause problem.
• Allow the Team to add improvement work to the Sprint – A common management misconception about Sprint Planning is that all the chosen Sprint Backlog Items (SBI) must be completed; the total chosen SBI estimates must ‘fill’ the Team’s Sprint capacity.

Not only is this unreasonable, because the effort for each SBI is only an estimate, but it also leaves no room to implement any of the improvements that were identified during the previous Sprint Retrospective.

A reasonable agreement must be made between the PO and the Development Team for an agreed number of ‘Improvement’ Items to be added to the Sprint Backlog with a high priority.

Finally, there is a good article by Łukasz Krzyżek about the Scrum Master as a Change Agent for the organisation.

 As a reminder, the 5 Scrum Values are:

• Commitment
• Courage
• Focus
• Openness
• Respect

As a Scrum Master, you will remind the Development Team occasionally of the Values and probably use the Values when trying to find the cause of team impediments.

However, you are also a member of the Scrum Team so you should also embody the Values in your own work.

It is advised that Scrum Masters carry out their own 5 Values ‘retrospective’ at regular intervals to see if any improvements could be made.

Some Scrum Masters include get the Development Team members to evaluate them to gain an insight as to how others see them.

A good technique to use for the evaluation is to use a Radar Chart:

By plotting the results for different dates, a ‘history of improvement’ can be seen.

This technique may be used for each Development Team member as part of a Sprint Retrospective. 

 To be a successful Scrum Master, you need to be motivated to become one.

There are many theories and learned papers about motivation and all agree that it is a complex subject; two people who are ‘successful’ in one field of expertise may have different driving factors.

Also, what does successful mean? Is it being seen as successful to other people or is it believing we are successful to ourselves.  You can see that it gets really complicated if our own definition of success is to be seen as successful by other people.

There have been cases where someone who is seen by ‘the world’ as highly successful, does not believe in themselves that they are successful.

In our professional lives, it is our own fundamental driving factors that inform our decisions about how we do our job.

If you have not already examined your fundamental driving factors, a good visual tool to help you choose is Maslow’s Hierarchy of needs:

The Basic Needs in Figure 15 are why we get out of bed in the morning and go to work; if you are a Scrum Master, those needs have been met.

The third level of needs has to do with the instinct of human beings to be tribal; are we accepted by a group of people that we would want to belong to; family, team, organisation, country etc.  You can have different motivations to different groups; for example, you could be motivated to be part of the worldwide Scrum Master community and be indifferent to your nationality.

The fourth level of needs is tied closely to the third in that if you have achieved ‘membership’ of your chosen tribe, it is probable that you feel accomplished.  However, you may want to be seen as having prestige in that tribe; so, you have your Scrum Master certification and your search for prestige, in the eyes of others, is why you wish to become an A-CSM.

It is at the top level in Maslow’s Hierarchy, Self-Actualisation, that an individual can feel that they ‘have made it’.

Our fundamental driving factors will change depending at which level we are in the Hierarchy; if we are at the bottom, then the driving factor is to get some money, or otherwise, to feel safe; if we are at the top, then the driving factor is how to stay at the top.

The following is a non-exhaustive list of possible fundamental driving factors:

• Money – Some people do have the acquisition of wealth as their fundamental driving factor and some are very successful at it.  However, many of those people are indifferent to the tribal needs; they become ‘successful’ in that goal and then try to ‘retrofit’ the tribal needs, possibly too late.  They are not Self-Actualising.
• Control – The need to be in control of your destiny can be a strong motivational factor.  If you are content to come to work, do the best at what others tell you to do, then you probably wouldn’t have become a Scrum Master.

Not that being a Scrum Master means you control the team but it does mean you have control of how you go about helping the team become a high-performance team.

• Competency – Your own level of a fear of failure will have a significant influence on your willingness to improve/increase your competency.  If you are seen to be a successful Scrum Master with established teams and feel a sense of accomplishment at this, you may avoid being a Scrum Master with a new to Agile team because you fear the possible drop in prestige if you were to ‘fail’ with the new team.
• Value – The value that you place on a task or goal will determine your motivation to attempt the task or strive to reach that goal; for example, you are a CSM, how much value is it to you to become an A-CSM? The value could be to earn more money and/or be given a greater degree of control and/or achieve greater tribal prestige and/or to increase your competency as a Scrum Master
• Goal Orientation – There are 2 goal orientation factors that determine a path to pursue the goal:
  • External Appearance – Looking good in the eyes of others
  • Internal Satisfaction – Accumulating knowledge for its own sake; the benefits that come from that knowledge are secondary

If you wish to be a successful Scrum Master and you wish others to see you as a successful Scrum Master, you need to analyse your own fundamental driving factors in order to decide how you will go about becoming one; be proactive and not reactive.

See “The 5 most powerful self-beliefs that ignite human behavior”.

Conflict arises when a group of people (2 or more) have different goals when choosing a desired outcome or how to achieve a desired outcome.  If you do a search for ‘the different ways to respond to conflict’, you will probably get in the order of 200 million hits.

The following are some of the more common ways of responding to conflict:

• Denial – If all parties to the conflict or possible conflict believe that discussion would be damaging to them, their group and/or their organisation, they may just ‘ignore the elephant in the room’ ie go into denial.
• Consensus – Discussions including statements like “We must do it this way” and “I disagree, we must do it this way” are the basis of conflict and without significant explanations of why either way is a ‘must’, there will be no conflict resolution.

Achieving consensus requires that all the parties in a dispute state the reasons for their position while the others listen; in this manner everybody’s goals will be amended based on new information; for example, one person’s goal may be based on a short-term reason while another’s is based on long-term concerns.

There may be risk involved in either goal; the idea is to come to an agreed decision based on the lowest perceived risk.

• Giving in – If someone believes that the relationship to the person(s) with whom they are in conflict is more important than their own goals, they give in as a means of handling conflict; they want peace at all costs; to be accepted and liked by other people.
• Overpowering – People who do not place much value on relationships with others overpower their opponents; however, they are rarely as powerful as they like to believe; ‘winning’ and being seen to win is part of their goal. 
• Withdrawal – If people feel their goals are not important and that it is not important to maintain good relationships by siding with one of the goals, they may respond to conflict by withdrawing; staying away and stopping to take part in the discussion; they may withdraw because they feel the conflict is none of their business. 

On the other hand, they may feel powerless and helpless and their involvement will make no difference at all and find it easier to avoid the conflict.

It is generally agreed that the best response to conflict is consensus whilst the worst is denial.

 There are some behaviours that escalate a conflict into a self-sustaining way of life; these behaviours are dysfunctional and destructive. 

Destructive conflict in any one situation may its roots in the outcome of previous destructive conflict where one party may feel slighted or not listened to; the actual cause becomes irrelevant; the slighted party is set on ‘revenge’ and their approach to subsequent conflict becomes irrational.

Destructive conflicts are more likely to occur when behaviours come from rigid, competitive systems.

As a Scrum Master, when facilitating any workshop, you will come across conflict; what you must look out for are the signs that the conflict may become destructive and attempt to ensure that the conflict becomes positive.  The following are some of the signs of destructive conflict:

• Aggression – When one party starts to be aggressive toward someone who disagrees with them, they are trying to intimidate the person by making them feel ‘small’ or inadequate in the hope that the other person will back down.

Such behaviour must be curtailed as soon as possible; one way would be to move the focus of the conversation from the people in conflict to other workshop participants to gauge their opinion of each side of the argument.

• One-way communication – if one person dominates the conversation with little or no response from the other workshop participants, then this could lead to a passive destructive conflict; decisions will be made that not everybody will agree with people will not be motivated to implement decisions.

If, as a workshop facilitator, you come across this situation, be sure to take time to ask the ‘non-verbal’ participants their opinion of what the dominant person is saying; they may all say that they agree but you must gauge that agreement; are they ‘agreeing’ because they feel intimidated by the dominant person.

• Frustration and Emotionality– A conversation may be ‘going well’ even though parties are disagreeing when one of them abruptly ‘shrugs their shoulders’ and withdraws from the conversation.

There are different reasons for this behaviour, both of which are destructive

• The withdrawing person is frustrated with not being understood and feels that further discussion is futile; they will go along with any decision made but will not be motivated to implement it.
• The withdrawing person may suddenly realise that their opinions are wrong but do not want to admit it in front of others; even if they now agree with the decision taken, their motivation to implement it is reduced because of they do not want others to think that they were wrong.
• Tone of voice – It is said that 40% of communication is non-verbal; body language and the way something is said can indicate a person’s negative or positive response to what is being said by others.

The question ‘so you want to do it this way’, if said in a calm measured tone, is probably a request for clarification, that is a positive response; however, if the question is said with a raised and highly critical tone of voice, it indicates aggression and an attempt to belittle the original speaker; this is destructive.

The reason for the belittling tone could be a request for more information and it is just the person’s personality that makes them use that tone; it could be an attempt to belittle.  In either case, as the facilitator, ask the original to give further information or detail about why they hold the opinion that they do.

• Low interest in solution – The participants of a workshop have all been invited because someone believes that they have something to offer to the conversation; as a facilitator, you must assume this to be true.

If someone is quiet and not contributing to the conversation, as a facilitator, you must ask them directly what their opinions are.  If you get a negative response ie ‘Don’t know’ or ‘Don’t care’, then the other workshop participants will possibly not get the full information to make the ‘right’ decision and/or become uncomfortable with the quiet person’s presence; the quiet person will be equally demotivated to implement whatever decision is made.

This situation is a tricky one to overcome; one way would be to talk to the person privately, during a workshop break to discover their true reason for their seeming lack of interest.  They may genuinely not have anything to contribute, in which case you should suggest that they leave the workshop, or you must try to motivate the person to contribute. 

Little consensus exists on how to define servant leadership. Instead, studies on servant leadership provide loose descriptions on what servant leaders are, the behaviours they show to their followers and the impact on the organisation. 

To encapsulate the various aspects of servant leadership, a recent literature review provided the following definition; 

"Servant leadership is an other-oriented approach to leadership manifested through one-on-one prioritizing of follower individual needs and interests, and outward reorienting of their concern for self towards concern for others within the organization and the larger community."

Eva, Nathan; Robin, Mulyadi; Sendjaya, Sen; van Dierendonck, Dirk; Liden, Robert C. (2018-07). "Servant Leadership: A systematic review and call for future research"

So what does this mean? Let us look at the definitions of the 2 words:

• Servant – The common thread of many definitions of a servant is a person who takes on duties within their skillset to aid other people to do their job and/or run their life; they are set a goal and it is up to them to organise how to achieve that goal.
• Leader – Someone at the ‘top’ of an organisation or part of an organisation who ‘owns’ the vision/goal that they wish their ‘followers’ to achieve; they may share the Vision/Goal with their followers and usually issues ‘orders’ and ‘directions’ to their followers to achieve the Vision/Goal.

It follows then, that a servant-leader is someone who ‘own’s the vision/goal, shares that with their followers who work out how to achieve the goal and helps their followers when needed.

Robert K. Greenleaf coined the phrase servant leader and noted that a person whose first inclination is towards serving others, and then leading, was quite different from someone who wanted to lead; a servant leader thinks about others first instead of self.  He/she is more concerned about the benefit and growth of others rather than putting their own desires or goals first.

Servant Leader Goals

• Commit to something outside of their own self-interest and see themselves as a resource to help those they have been given the privilege to lead ie is committed to the growth and improvement of those they lead
• Create a community of people that are proud to say ‘we did this’

Servant Leader Attributes

putting people first, communicating skilfully, being a systems thinker

• Be a good listener – Leaders need to be good communicators and have decision-making skills but a servant leader also places a high priority on listening to others to discover what their will or desire is
• Practice empathy – The servant leader can empathize with the group and with individuals and uses empathy to not make snap judgments about people
• Be aware – A servant leader makes a point of being aware of the obvious and the subtle, both in their own life and in other’s lives
• Be persuasive – Servant leadership is about service, not domination; a servant leader uses powers of persuasion to help people choose the right path as needed instead of demanding the path.
• Be able to conceptualize – Servant leaders are big-picture thinkers:
  • They inspire their followers to think beyond the day-to-day grind and beyond the immediate issues in front of them
  • They look beyond numbers and goal posts, thinking of what their team needs to do to accomplish everything, not just the one thing in front of them
  •  They help their followers get the training and tools they’ll need not just for today, but for next year and on.
• Commit to building up people – Servant leaders understand their most important resource and concern is people; they are committed to the growth and well-being of their followers, thinking first of them instead of themselves
• Love the community. Servant leaders love the community more than their own individual success. They don’t sell out the community for any immediate or flashy goal. Servant leaders understand that the concept of community has the power to positively shape and influence lives, more than systems or other corporate structures do

The Daily Scrum is for the people transforming the Product Backlog items into an Increment. Only the people that are building the product should be present at the Daily Scrum. The Scrum Master enforces the rule that only Development Team members participate in the Daily Scrum to share information with each other that can help them to understand how to organize the work among the team members in a better way to meet the Sprint Goal.

There is no such thing as Sprint 0. It is not a valid Sprint from Scrum timeboxed events. "Sprint 0" has become a phrase misused to describe the planning that occurs prior to the first sprint like refining product backlog, architecture envisioning, prioritizing and release planning etc. This term is confused with the term  "Release 0". It is ideal to talk about Release 0 as opposed to Sprint 0

The development team can participate in the product backlog refinement anytime during the sprint. Product Backlog refinement is a continuous process in which the development team and the product owner collaborate anytime needed during the Sprint on the details of Product Backlog items. PBR is required in each and every Sprint to refine items to be ready for future Sprints. The Scrum team decides when and how refinement is done.

The Development Team and the Product Owner are responsible for product backlog refinement. During a product backlog refinement meeting, the product owner and the development team communicate and decide the top items on the product backlog. The team can raise queries during the sprint planning session if they find any unresolved issue. The Product Owner and team can discuss with the Stakeholders to find out “what” they want and “why” they want. Once if they are clear with the user needs then they can go for the cross-checking with teams.

Deliver an increment of releasable software, and develop and deliver at least one piece of functionality. The heart of Scrum is a Sprint, a time-box of one month or less during which a "Done", useable, and potentially releasable product Increment is created. This applies to every Sprint. The first Sprint conducted by the development team plays a key role in the Scrum. It also focuses on estimating the availability of the team, selecting the items from the product backlog, and final thoughts. During the first sprint, the development team delivers an increment of releasable software. They also Develop and deliver at least one piece of functionality.

The next sprint begins immediately after the conclusion of the previous Sprint. A sprint begins with Sprint planning meeting and concludes with Sprint Retro. In general, planning for the subsequent Sprint starts after the conclusion of the previous sprint. So, typically the plan for the next Sprint is fixed by the time the previous sprint ends. The actions from the retrospective and demo will go in the product backlog and can be prioritized in a future sprint.

This is the task of the Product Owner. The Product Owner is the sole person responsible for managing the Product Backlog, which includes that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next. The responsibility of achieving maximum business value for the project lies primarily with the Product Owner. The PO is also responsible for maintaining business justification for the project and articulating customer requirements. A PO represents the voice of the customer.

The Development Team is responsible for managing the progress of work during a Sprint. The Development team is comprised of professionals who work in a Sprint and deliver a potentially releasable product at the end of each Sprint. These increments are created by only the members of the Development team. The Development Team uses the Daily Scrum to inspect a progress toward the Sprint Goal and to inspect how progress is trending towards completing the work in the Sprint Backlog.

The Scrum Master arranges the Scrum meeting for the Development team. The Development team is the main player of the meeting.But, the Scrum Master guides the Development Team to keep the Daily Scrum within the 15-minute time-box. The Scrum Master enforces the rule that only the Development Team members participate in the Daily Scrum.

Inspection, Transparency, Adaptation. Scrum is founded on empirical process control theory or empiricism. Empiricism asserts that knowledge comes from experience and making decisions based on what is known. The three pillars uphold every implementation of empirical process control are transparency, inspection, and adaptation.

The Product Owner actively asks for stakeholder’s input and expectations to process into the Product Backlog. The Product Owner represents the Stakeholders to the Scrum Team, which includes representing their desired requirements in the form of Product Backlog. The Product Owner has the final call over the Product Backlog.

As much as told by the Product Owner, will be done for every Product Backlog item it selects in conformance with the definition of done. The purpose of each Sprint is to deliver Increments of potentially releasable functionality that adhere to the Scrum Team's current definition of "Done". To determine the progress and the next sprint item, Scrum teams do the Sprint Planning. During the Sprint Planning, the Product Owner and Development team agree on a sprint goal and define the goals to carry out in the upcoming sprint.

Scrum is a framework within which complex products in complex environments are developed. Scrum is not a process or a technique for building products; rather, it is a framework within which you can employ various processes and techniques. Scrum Framework is applied to the complex projects in the complex environments. If a Scrum team adheres to the Scrum practices, it will help in developing the best quality product within a specified timeframe.

During a sprint retrospective, the Scrum Master acts as a peer team member. The Scrum Master acts as a facilitator for the team. The role of the Scrum Master in the Sprint Retrospective is to facilitate the self-organized Scrum teams to resolve their issues. Sprint Retrospective is all about discussing what went well and what can be improved in the next Sprint. The Scrum Master facilitates the teams and works as a peer team member to speed up the project processes.

The length of a daily Scrum is fixed at 15 minutes for the development team to a create plan for the next 24 hours and synchronize activities, it does not change with the length of a Sprint. This optimizes team performance and collaboration by analyzing the work since the last Daily Scrum and predicting the forthcoming Sprint work. This Daily Scrum meeting is conducted at the same place and time each day to minimize complexity.

Ideally, it is 3-9. Scrum says team size of 6+ or -3 is the Scrum guide recommendation. Optimal Development Team size is small enough to remain nimble and large enough to complete significant work. Fewer than three Development Team members decrease interaction and results in smaller productivity gains. More than nine members simply require too much coordination.

Development team, product owner, scrum master. The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master. As the Scrum teams are cross-functional, the development team includes designers, ops engineers, and testers in addition to developers. Each of the Scrum roles has defined a set of responsibilities and they can complete a project successfully only if they accomplish these responsibilities, closely work and interact together.

The Product Owner is responsible for maximizing the value of the product and the work of the Development Team. He/she is the voice of the customer. PO determines the scope of a product and release dates. The PO can attend all the meetings to keep track of the team’s progress. If there are any changes that need to be done, it will be implemented immediately. The product owner wishes that the team will be able to achieve its goal with the timetable.

When the timebox expires.The duration of a Sprint is fixed and cannot be shortened or lengthened. For example, if all the items of a Sprint are not done, the Sprint is still marked as over and the remaining items are moved to the product backlog from where it can be scheduled to any of the following sprint based on the revised priority. Similarly, if all the items of a Sprint are done before time, the dev team is free to pick top PBIs and start working on it.

It is when the Scrum Team and stakeholders inspect the outcome of a Sprint and figure out what to do next.Every event in Scrum, besides the Sprint which is a container for the other events, is an opportunity to Inspect and Adapt. A Sprint Review is conducted at the end of the Sprint to inspect the increment and adapt the product backlog if required. During this, the Scrum Team and Stakeholders collaborate about what was done in the Sprint and figure out any changes to be done to the product backlog during the Sprint to optimize value.

Whatever is deemed most appropriate by the Product Owner.The Product Owner decides what makes the most sense to optimize the value of the work being done by the Development Team. The product backlog is ordered based on the value provided to the business. The value may be affected by various other factors like complexity, criticality, and risk but are not the direct basis for calculating the value. The item value being delivered is calculated by the product owner and he/she is responsible for ordering the product backlog.

The consistency reduces complexity.The purpose of the Daily Scrum meeting is to carry out a communication between the team members. The Scrum meeting is timeboxed to 15 minutes irrespective of the team-size and is held at the same time and place each day to reduce complexity. Also, it is usually held at the morning time when maximum team members gather to plan work for the day.

The ability to turn the Product Backlog items it selects into an increment of potentially releasable product functionality. The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of "Done" product at the end of each Sprint. The Development Teams are cross-functional teams, with all of the necessary skills as a team to create a product Increment.

To support the Product Owner with insights and information into high-value product and system capabilities and to support the Scrum Master to cause organizational change that fosters empiricism, self-organization, bottom-up intelligence, and intelligent release of the software. Management has no active role in the actual product development through Scrum. However, management external to the Scrum team is incredibly important in setting the vision and strategy to guide the overall process to the team for developing a product in the organization.

It means the event can take no more than a maximum amount of time. Time-boxed events are events that have a maximum defined duration. For Example- Daily Scrum meeting is one of the timeboxed ceremonies in the Scrum. This event is timeboxed for 15 minutes (not more than that) and usually held at the same time and place each day. Also, it is usually held at the morning time when maximum team members gather to plan work for the whole day. 

The Product Owner. The Product Owner is the sole person responsible for managing the Product Backlog. The PO prioritizes the product backlog during the Sprint Planning meeting for the team members. The PO keeps a vision of the product to build and convey that vision to the Scrum team. Also, the role of the PO is to motivate the team towards achieving a project goal.

8 hours for a monthly Sprint. For shorter Sprints, it is usually shorter. Each Sprint begins with the Sprint Planning meeting. Sprint Planning is time-boxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter. For example- for a two-week sprint, the Sprint Planning meeting can be of 4-hours.  

As needed, while taking into account a short-term reduction in Productivity. Teams typically go through some steps before achieving a state of increased performance. Changing membership typically reduces cohesion, affecting the performance and productivity in the short term.

No. Scrum does not have a defined role called “project manager”. A Scrum Team has a Scrum Master, a Product Owner, and a Development Team. As a whole, they have all the controls needed. The project manager role doesn’t exist in a Scrum environment, but the core responsibilities of a project manager do exist like the responsibility of date, scope, budget etc. Many of the responsibilities of a traditional project manager are fulfilled by these roles. So, there is no specific role called project manager when using Scrum.

The primary purpose of a Sprint is to produce a done increment of working product. The heart of Scrum is a Sprint, a time-box of one month or less during which a "Done", usable, and potentially releasable product Increment is created. The more “Done” the increment is, the more useful the feedback that is gathered will be. If something is 99% done, and only 1% work is remaining - it is still NOT DONE, and it has to be added back to the product backlog and re-estimated during the next sprint.

A Scrum Master does not have to be there; he or she only has to ensure the Development Team has a Daily Scrum. The Scrum Master enforces the rule that only Development Team members participate in the Daily Scrum. Although the Scrum Master or Product Owner can attend this meeting to facilitate the Daily Scrum, this is certainly not required by Scrum. The Development Team members synchronize their work, monitor their progress toward the Sprint Goal and if required they adapt the Sprint Backlog and the plan for the next 24 hours during the Daily Scrum.

By facilitating Development Team decisions and by removing impediments that hinder the Development Team. A Scrum Master is a servant-leader for the Development Team. Facilitation and removing impediments serves a team in achieving the best productivity possible. The Scrum Master within the Scrum Team facilitates the development of working software and help the development team in delivering the Product Increment. The Scrum Master does everything possible to help the development team to work at their highest level.

4 hours for a monthly Sprint. For shorter Sprints, it is usually shorter. Sprint Review is a four-hour time-boxed meeting for one-month Sprints. For shorter Sprints, the event is usually shorter.

Sprint Review is held at the end of each sprint. The scrum team shows what they achieved during the sprint in the retrospective meeting. Typically, the sprint review should not take more than one hour per week of sprint duration. It means a 30-day sprint would result in four-hour time-boxed sprint review. Similarly, two-hour review for two weeks sprint. Finally, the length of your sprint review depends on the length of your sprint.

They collaborate often so the Product Owner can make informed decisions in balancing effort and value of Product Backlog items. They also collaborate so the Development Team builds Increments keeping end-user and the Stakeholder concerns in mind. The Product owner clearly expresses Product Backlog items, ensuring the Development Team understands items in the Product Backlog to the level needed for developing them and creating the value the Product Owner envisions. The scope may be re-negotiated if the effort grows much higher than anticipated.

The Product Owner is responsible for maximizing the value of the product. The Product Owner is the sole person responsible for managing the Product Backlog. The PO prioritizes the product backlog during the Sprint Planning meeting for the team members. The PO keeps a vision of the product to build and convey that vision to the Scrum team. Also, the role of the PO is to motivate the team towards achieving a project goal.

The Product Backlog is an ordered list of everything that might be needed in the product and is the single source of requirements for any changes to be made to the product. It is a living artifact of product requirements that exists and evolves as long as a product exists. The Product Backlog evolves as the product and the environment in which it will be used evolves. Higher ordered Product Backlog items are usually clearer and more detailed than lower ordered ones. As long as a product exists, its Product Backlog also exists.

The Product Owner creates and sustains a product backlog that maximizes value and represents the needs of the stakeholders. The PO is also responsible for maximizing the value of the product and the work of the Development Team. The primary tool to do so is the Product Backlog. The Product Owner is the sole person responsible for managing the Product Backlog. The PO prioritizes the product backlog during the Sprint Planning meeting for the team members. The PO keeps a vision of the product to build and convey that vision to the Scrum team. Also, the role of the PO is to motivate the team towards achieving a project goal. 

Through the frequent delivery of Increments of the product into the market. The Product Owner manages Product Backlog against the assumption that value will be generated. This assumption remains invalidated when not checked against users and market. When a Sprint's horizon is too long, you increase the risk that what is being developed may no longer be desired. Sprints limit risk to one calendar month or less of work.

Technical debt causes a greater percentage of the product's budget to be spent on maintenance of the product.The velocity at which new functionality can be created is reduced when you have technical debt.

Within the Sprint, the Development Team makes the best decisions possible to assure progress toward the Sprint Goal, realigning with the Product Owner once he/she is available again. In a permanent state of unavailability, a new Product Owner needs to be appointed. Development efforts without a Product Owner are not employing Scrum.

Yes, it can start. The first Sprint requires no more than a Product Owner, a team, and enough ideas to potentially complete a full Sprint. It is not mandatory that the Product Owner should be ready with the complete and exhaustive Product Backlog for starting a first Sprint.

The Development Team. As a collective, they have a complete view of the work needed to transform Product Backlog items into Increments of product. The Product Owner is the sole person responsible for managing the Product Backlog. The PO prioritizes the product backlog during the Sprint Planning meeting for the team members. But, it is the Development Team who is responsible for all the estimates. The people who perform the tasks make the final estimate.

At any time when done by the Product Owner or at the Product Owner's discretion. The Product Backlog is dynamic; it constantly changes to identify what the product needs in order to be appropriate, competitive, and useful. Product Backlog items can be updated at any time by the Product Owner or at the Product Owner's discretion.

Based on the value of the items. Scrum Guide uses the term ‘ordered’ instead of ‘prioritized’ for the Product Backlog. The Product Backlog Items are ordered based on the value of the items. For this, the Development team discusses the PBI ordering with the Product Owner. In the end, the Development team has to has to order the items according to their relative importance to each other.

Yes. The Scrum guide recommends that the development team size should be between 3 and 9. We can change the team members as needed while taking into account the short-term reduction in productivity. If we add more team members according to the project requirements or if we subtract the team members, in the end, the Development team has to meet the Sprint goal. 

As much as needs to be Done based on the definition of Done. The Sprint Backlog consists of a set of items that deliver the product increment. It is the Development team members that decide what functionality should be included in the next increment. The Scrum Team defines “Done” at the end of the project and would not consider that the end-product is completed unless it matches with the definition of “Done”.

Yes. The Development Team should be cross-functional, capable of completing the Sprint Backlog items based on the definition of “Done”. Not every kind of delivery is acceptable in Scrum, it should be “potentially releasable Increments of the final product of the project”, to help the stakeholders to give feedback

At the end of each Sprint, a Sprint Review meeting is held. During the Sprint Review meeting, the Scrum team shows what they yielded during the sprint. This meeting is for the Scrum Team and Stakeholders to inspect the outcome of the Sprint and figure out what to do in the next Sprint. Typically, this meeting is a form of the demo of the new features.

Peer team member. The Sprint Retrospective provides an opportunity to inspect and adapt the progress for improvements. The Scrum Master plays the role of a facilitator for his/her team. In the Scrum framework, the teams are self-organized and open to making changes very quickly wherever needed.

There are five time-boxed events in Scrum: Sprint, Sprint Planning, Sprint Review, Sprint Retrospective, and Daily Scrum. The Scrum Backlog consists of a list of all the things that need to be done within the project. The Scrum Backlog is maintained all the way through the project. 

3 hours. The duration of the Sprint Retrospective meeting varies depending on the sprint length. For a one-week sprint, the meeting should last about one hour; for a two-week sprint, two hours. Teams running four-week sprints should allow three hours for this meeting. Sprint Retrospective is a time-box of 3 hours for a one month Sprint. It’s usually shorter when the Sprints are set shorter.

The main responsibility of the Product Owner is maximizing the value of the project by creating, clearing, and ordering the Product Backlog. The Product Owner is the sole person responsible for managing the Product Backlog. The PO prioritizes the product backlog during the Sprint Planning meeting for the team members. The PO keeps a vision of the product to build and convey that vision to the Scrum team. Also, the role of the PO is to motivate the team towards achieving a project goal.

No. The Sprint Backlog is the representation of the tasks that are drawn from the product backlog to achieve the Sprint goal by the development team.  During the Sprint Planning, the development team sets an objective which is called as a Sprint goal. Only the development team can make changes to the Sprint Backlog as they own it. None changes can be made without the authorization of the development team members.

Every event in Scrum, besides the Sprint which is a container for the other events, is an opportunity to inspect and adapt. Sometimes, Sprint is referred to as just a time frame. It is not an event like Scrum Planning, Scrum Review, Scrum Retrospective, and Daily Scrum.

Empiricism. Empiricism asserts that knowledge comes from experience and making decisions based on what is known. Scrum employs an iterative, incremental approach to optimize predictability and control risk. Transparency, Inspection, and Adaptation are the three pillars that uphold every implementation of the empirical process control.

Scrum does not order when and how to release the product increment. The product owner decides whether to actually release the product or not once the increment is usable and meets the Scrum Team’s Definition of Done. Each increment should be released possibly with no work left undone. This implies that the product owner should be in a position to release a delivered increment instantly and with no further dependency on the development team.     

It means that the team must have all the competencies to meet Sprint Goal as per definition of “Done”. Cross-functional teams can be inspected as a team of cross-functional members with domain and functional expertise. For instance, if one is declining a sprint cycle, then members with stronger skills in a cross-functional team can connect and work with other team members to finish the sprint on time. Cross-functional teams are more productive than teams with the same skilled individuals working on related projects. 

The value of the product backlog lies in transparency that permits the team members to know what work needs to be done in order to produce a minimum viable product (MVP). Value is an estimated value based on assumptions. It has also to be validated by releasing the increment to the customers. Scrum facilitates early validation.

Scrum Team together negotiates and reaches an agreement. They may use Velocity as a standard to calculate how much work they can take. Product Owner optimizes the teams work by keeping the Product backlog ordered. Only, the Development team can finalize how many Product backlog Items it can complete in the Sprint. The decision of finalizing the number of product backlog items is made by the Scrum team together. They collaboratively negotiate and reaches an agreement.

The Scrum team. The scrum team which includes PO, Scrum Master, and the development team decides the sprint length. The team during retrospective will inspect and adapt on the sprint length and arrive at an agreement. The scrum master acts as a facilitator to help the team arrive at an agreement and he/she will come in only when the team is unable to decide and helps to set the sprint length. Once decided, the duration of sprint usually remains the same throughout the project.

Sprint backlog.Team members are expected to update the sprint backlog at least once a day during the scrum sprint as new information is available. Most of the scrum teams will do this during the Daily Scrum. Scrum master estimates the amount of work remaining in the sprint each day and graphs the sprint burndown chart. The sprint backlog is a plan with ample detail that changes in development can be understood in the Daily Scrum.

They do not play an active role within Scrum, they influence it through other means. Product Owner makes a decision based on the inputs received.

It only lays out the initial known and best understood requirements. The product backlog is a living artifact that evolves and constantly changes to identify what the product needs to be appropriate, useful and competitive. A well-prioritized product backlog not just makes iteration and release planning easier but also reports all the things that team plans to spend time on, as it should be transparent for both the development team and the stakeholders.

Yes, and it may capture probable backlog items for next Sprint, but the scope of next Sprint is deferred until Sprint Planning. In Scrum, each sprint delivers a potentially shippable product increment at the end of each Sprint. In Scrum, every Scrum event is an opportunity to Inspect and Adapt. In Sprint Review, inspecting the product Increment provides insight and clarity. This newly improved knowledge is used to adapt the next steps i.e. find out what to do next.

The role of the Scrum Master majorly includes the facilitation. The SM facilitates the Daily Scrum for the development team to discuss the daily tasks and to increase the team collaboration. The Scrum Master also ensures that the team is strictly adhering to the Daily Scrum meeting rule that the meeting should be time-boxed to 15 minutes only.