Types Of Agile Coaches And What Do They Do?

People may or may not have heard about the word “Scrum”, but for those who have, a question most commonly asked by them might be “What can Scrum do for me to improve my business?” or “How do I use Scrum to grow?” – A topic most discussed by CEOs, CTOs, project managers, and other senior level executives in a development company or organisation when they are faced with choices of adopting a framework to better their work processes and increase the investment returns for their organisation. It is important to understand that for a business new to Agile and Scrum a lot depends upon what type of Agile or Scrum coach it hires, and how successfully the coach can help the organisation to adopt Agile principles.

Agile can work wonders for you provided it is implemented in an effective way. Agile coaches ensure that business implement the framework in a proper manner. Therefore, a lot depends upon what type of Agile coach do you actually need? You may feel unsure about Agile adoption but serious enough to “give it a try” and see if it can benefit you. On the other hand, you may be aware about the benefits of using Agile but not certain how to start. It’s worth considering about the level of Agile coaching you actually need to get started.

What is an Agile coach?

What is an Agile coach? When the question is asked to different people you’re sure to get different types of answers depending upon whom you’ve asked. The perception of Agile coaching changes from individual to individual, and from company to company. Perhaps the main reason why this happens is because there are no standard definitions explaining Agile coaching, and people have the liberty to interpret the terminology in a manner they deem correct.

So, rather than trying to define exactly what an “Agile coach” is, it would be more worthwhile to comprehend what activities Agile coaching includes, and what does an Agile coach do when he/she is appointed by an organisation to facilitate or implement Scrum in their business processes. Coaching needs and activities vary from businesses to businesses based upon the type of product to be developed. However, in a typical organisation, there are three main areas where managements often decide Agile coaching is needed.

Agile Team Facilitator

An Agile facilitator may or may not possess a coaching certification from a reputed or known Scrum body. His/her primary role involves facilitating Scrum activities and mentoring Agile teams in achieving Scrum agility. The person usually engages with one or two Scrum teams – not more – and may lack experience or skill sets required for adopting and implementing Scrum to the fullest extent in the entire organisation.

Small organisations, or businesses having a limited Scrum budget but still interested in implementing Scrum may opt for Agile team facilitators to introduce Scrum in their organisations before deciding upon a concrete Scrum adoption plan. Usually, the objective of hiring an Agile team facilitator is to familiarise managements and development teams with the Scrum process and get an idea about how to go ahead with Scrum adoption, or, at times, to decide whether Scrum adoption is needed or not.

Agile Coach

An Agile coach can have one or more certifications from a well-known Scrum certification body. Unlike getting certified as a chartered account or a medical practitioner in a particular state or country, there are no formal or authorized “government recognized Scrum certification issuing authorities. Certification availed from a few Scrum entities like Scrum.Org, Scrum Alliance, Agile Coaching Institute, etc. carry value in the Scrum market, and employers generally search for coaches who have qualified or hold certifications from these type of institutes.

Agile coaches have a sound and relevant experience in at least one Agile discipline – Scrum, XP, or Kanban. They are certified Agile professionals who have achieved a high level of proficiency in their respective fields. They possess sufficient domain knowledge and coaching skills to facilitate and mentor the Scrum process in an organisation. An Agile coach trains the development team and the management in Agile principles and practices.  He/she contributes at both macro and micro levels, and in addition resolves all Scrum related issues. Often, Agile coaches promote and act as Scrum ambassadors in organisations which appoint them.

Businesses appoint Agile and Scrum coaches when they decide to go “all the way” with Scrum, and want to make sure they benefit from Scrum principles. Coaches are also consulted to discuss ways and means to develop better products, increase the ROI, and improve the current business processes.

Enterprise Agile Coach

An Enterprise Agile coach is a person who has achieved some additional skills such as advanced systems coaching, understanding work culture, training organisations in specialized business processes, implementing change management, and creating collaboration and leadership qualities amongst individuals which “regular” Agile coaches may not possess.

An Enterprise Agile coach may work at all levels in an organisation and help managements in using Agile as a strategic asset for generating consistent and reliable business value by improving current processes through Agile.

Salient Features Of Scrum

Agile - The base of Scrum

Agile, and the path to Agility is now becoming a much sought after norm for many businesses across the world. There is a huge demand for understanding, and implementing, Agile based frameworks. Perhaps one of the main reasons why Agile is becoming increasingly popular is because consumer demands are changing radically and people now desire more. And, people are not ready to wait. They want products which offer good value for money, and that too with enhanced features. This has created a need to develop products which are:

• Competitive
• Feature rich
• Quickly available
• Fulfil specific end user requirements

Agile proposes to satisfy these requirements without adding on to the product costs.

The basic issue with all Agile frameworks is that they are – frameworks. They offer guidelines how the Agile process can and should be implemented in a project. For that, it becomes imperative to understand what a framework is, and how it differs from a methodology. Many individuals still feel Agile is a methodology and they could not be more wrong.

Agile methodology misconception

There is still a misconception regarding Agile – some people still tend to refer to Agile as a methodology. This is not true. A methodology offers a set of rules, principles, tools, or practices that can be used to conduct processes and achieve certain goals. A framework, on the other hand, is a loose structure that leaves enough room for other tools and practices to be included, and only provides the process required. In simple terms, a methodology is like a doctor’s prescription – you have to “take” it as per instructions provided, while a framework is like trying out home remedies – you know what can be done to achieve a particular objective, but it is up to you how to implement the remedy, and when to implement it. An Agile framework has to be implemented in a project to be successful, and there are no specific rules about how to do it. You have to follow certain guidelines and configure your project to function as per the rules specified in the framework. This is very much the case with Agile. Agile is a framework.

Agile Scrum salient features

Of all Agile frameworks, Scrum and Extreme Programming “XP” are the most popular. Even though Scrum framework is more generally used for developing software projects, it can also be used for developing non-IT projects. Scrum constitutes a collection of ideas and rules pertaining to effective project management. The framework supports collaboration and self-organisation. The team members work jointly and develop the project. They collaborate and share their ideas and findings. Scrum teams self-manage their activities. The most important aspect of Scrum is that all activities are time boxed. The client receives working versions of the product features on a continued basis through product incremental cycles – sprints – at regular intervals ranging from a week up to a maximum of one month. Cycles keep on repeating until all product features are developed and the product is ready.  

A unique aspect about Scrum is that the framework has a capability of adapting itself to changing market conditions, and incorporates those changes in the product development cycle even late during the development process. The Scrum process focuses upon responding quickly and efficiently to changing environments and assimilating those changes in the product design. The client benefits though the development of a product that is in tune with the most recent market demands. Moreover, participation from the end users and incorporating their suggestions while developing the product features further ensures that the product developed is most likely to assume a high business value or worth.  

• Scrum - an agile process – focuses upon delivering high business values to the client in the shortest time possible.
• It supports rapid and repeated inspection of the actual working software.
• The product is developed in stages through the product incremental cycles known as sprints.
• The client benefits from shippable product releases at the end of incremental cycle.
• Frequent and consistent product increments should be delivered to the client.
• The client, and the business, sets the priority.
• The working process responds quickly and efficiently to the changes occurring in the market conditions, and in incorporating those changes into the product features in the least time possible.
• Scrum teams self-organise and self-manage to determine the most efficient and quick way of delivering high priority features.

Scrum principles

Scrum functions as per certain rules or principles which are very important for its efficient working:

Individuals and interactions	over	Process and tools
Working software	over	Comprehensive documentation
Customer collaboration	over	Contract negotiation
Responding to change	over	Following a plan

Breaking Down The Agile Manifesto And Understanding It

The popularity of Agile frameworks, especially XP and Scrum, is increasing by the day, and more and more organisations are deciding in favour of using these frameworks to execute their projects. Agile proposes many advantages – frequent and reliable product increments, delivering product features having high business values, and above all – delivery of shippable product features even while the development process is underway. However, a major issue with Agile, and all Agile based frameworks is that the framework has to be properly understood and later implemented in the project. Moreover, the implementation should be carried out keeping Agile principles in mind. More than often, businesses fail to benefit from Agile simply because the management has not understood the basic principles behind the framework, or has failed to implement those principles in a proper manner.

The Agile manifesto

Since it was developed in 2001, thousands of individuals including project managers, software professionals, and C level executives have endorsed the Agile manifesto. Hundreds of books and references have been written to discuss what the guide has to say, and how it should be interpreted. The manifesto has drastically changed the way in which organisations and individuals develop software projects. The manifesto packs a lot of punch for its 68 words which have been written by 17 software professionals over a two days meet at a ski resort.

The principles of Agile are stated in the official guide written by Ken Schwaber and Jeff Sutherland. The guide functions as a bible for all Agile groups and Agile professionals. People refer to the guide when in doubt, or when they wish to clarify a particular point during Agile framework implementation. For individuals interested in Agile, it is very important to understand the guide and interpret what it has to say.

Manifesto for Agile Software Development

We are uncovering better ways of developing software by doing it and helping others do it.

Through this work we have come to value:

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.

 
We

To start with, the manifesto states “We” i.e. it emphasis that Agile is not a solo endeavour. It involves group activity and people have to collaborate while working, at every level, and at every instant. Development teams, project teams, and organisation have to work jointly as a composite unit, and rely upon each other for completing work.

 
are uncovering 
Here, the guide suggests that Agile does not offer one-size-fits-all type of solutions. Agile cannot be standardised and implemented in a project. People involved with Agile processes have to put in efforts, and strive to seek answers through discussions and collaborations. Answers have to be discovered through experimentation, and the “adapt” and “inspect” principles which are... Read more

Scrum Product Owner Role And Sprint Planning Meeting Agenda

In many ways, in a Scrum project, the sprint planning meeting agenda plays a very significant part in determining the success of delivering shippable product increments through the sprint iterative cycles. The product owner is very closely involved in the sprint planning agenda, and is responsible for the outcome of the sprint cycle, since he or she is primarily responsible for taking the initiative and “designing” the sprint – the PO decides which user stories should be ideally taken up for development purposes based upon their business values. Moreover, the product backlog needs to be refined on a regular basis. The PO may invite and seek the help of Agile team members to keep the backlog refined so “granular” and developable user stories are available at the time of Scrum planning meeting.

The main issue with Agile Scrum today is that the role of a PO cannot be “standardised” based upon assumptions as to how Scrum ought to be implemented in a project, and what the PO should ideally do to make the project a distinct success. In addition, while considering Scrum sprint planning, the same thoughts might be applicable to it as those associated with the PO’s – it is difficult to create generalised rules regarding how a sprint should be ideally designed. The primary reason is products and requirements change as per fluctuating market conditions, and stakeholders too are liable to change their thoughts as and when end user demand user-specific requirements and development. However, after considering the fact that scaled Scrum versions are likely to “dominate” the Agile scenario over the coming years, it is worthwhile thinking that “some” of the duties of a PO and certain sprint planning “characteristics” are likely to remain common – irrespective of which scaled version is used, and the manner in which Scrum should be, or can be, implemented in a project. In addition, while the sprint planning meeting was traditionally conducted in two parts, the Scrum event has now evolved to be conducted as a whole – as a single event – and include two topics in it, rather than two parts:

• What can be done in this (currently being planned) sprint – the “What” aspect
• How should the chosen “work” be ideally “done” – the “How” aspect

It is interesting to think about how the product owner’s role is likely to modify itself in the future, and what features the sprint planning event is likely to include. The suggestions are open for debate, and the reader is invited to present his or her viewpoints.

Scrum product owner role and responsibilities likely to remain “common”

• Creation of the product backlog based upon the vision as seen by the stakeholders. Defining user stories having high business values so the project “worth” is maintained at all times.
• Monitoring all Scrum related activities in project. Even if the PO’s role may be demanding and “difficult to play”, the PO still has to deal with changing market conditions, stakeholders requests, and negotiate with the development team with regards delivering shippable stories and maintaining team velocity... Read more at Scrum Product Owner Role And Sprint Planning Meeting Agenda

Scrum Product Owner’s Role

Agile professionals have often discussed what the exact role of a product owner should be in Scrum. What virtues should a product owner possess to be considered a “good” PO? The answers are many. And this is not surprising because Scrum is a framework, and its implementation in a project depends upon the requirements specific to the project. When requirements change, the role of the PO also changes. Therefore, it may not be possible to standardise the exact role a PO should play in a Scrum project.

A certain process flow remains common to almost all Scrum projects. The role of a product owner can be thought about in terms of what POs actually do in a typical Scrum project. Here are a few suggestions:

Common role or activities of a Scrum product owner

· Creating the product backlog as per the product vision seen by the stakeholders. Defining user stories having high business values in the backlog so the project “value” is constantly maintained.

· Monitoring and tracking all Scrum activities. The role of a product owner may be difficult to act since a project might be demanding, and the product owner may have to cater to market related issues and still monitor the work carried out by the team. Balancing both the aspects can prove to be trying.

· Make sure that the product backlog is kept refined at all times. Moreover, the product backlog should be accessible by the entire team.

· Each product backlog item “PBI” should be properly stated and defined in the product backlog. The story description, appropriate business value, and the acceptance criteria should be stated precisely in the story card and explained to the entire team so the team members can develop effective stories and develop shippable product features.

· To be available whenever needed, to remain present, and share information, knowledge, as well as expertise with other team members.

· The PO responsibility should also include defining productive sprint goals just before a sprint commences.

· A product owner’s responsibility should also include... Read more at Scrum Product Owner's Role

What is Role of Scrum Product Owner?

Several discussions have been carried out by Agile professionals regarding the Scrum product owner role. What virtues make a product owner an “ideal” one? How should a PO delegate authority? Should it be as per traditional management models, or should a servant-leader role be employed? How should the person handle stakeholders when there are issues? There are many questions. The debate can keep on extending indefinitely since newer “scaled” versions of Scrum keep on coming, and the PO has to change his or her role based upon the traditional, or scaled, version of Scrum the management decides to follow.

It would be more practical to concentrate upon some of the most important, and the most common, activities of a PO.

Read more at  Scrum Product Owner Role

What is Sprint planning meeting agenda?

In a Scrum project, the Sprint planning meeting agenda is one of the most important activities undertaken by the team. The product owner plays an important part in the agenda. In Scrum, out of the many important duties carried out by a PO, a very important one is to create the product backlog based upon the vision of the stakeholders, and subsequently maintain or “groom” it with the help of team members (preferably). However, once the backlog is created and all required product backlog items are properly defined in it, it becomes necessary to “prepare” for the next step in the Agile product development cycle – plan and develop effective sprints so shippable user stories are delivered at the end of sprint cycles. Offering consistent development over successive sprint iterations is an inherent feature of Agile Scrum. In a sprint planning agenda, the objective of a sprint meeting is to prepare productive sprints so the team can develop meaningful stories.

So, what does a sprint planning meeting actually consist of? In practice, the meeting is conducted in two parts – the first part is dominated by the product owner while in the second part the development team actually prepares tasks from user stories taken up for development in the sprint backlog.

1st part of sprint planning

The product owner is the most “conversant” person as far as user stories are concerned since he or she actually “creates” the product backlog. The stories need to be explained to the team members. During the first part of the Scrum sprint planning meeting, the PO selects some of the most important product backlog items from the top of the backlog, and creates a “sprint backlog” by transferring the selected stories into it. So, the sprint backlog is a subset of the main backlog, and contains a “chunk” of stories which carry high business values. The PO explains how the development of a particular story should be carried out by the development team. The acceptance criteria is explained and the team is briefed regarding what it should do to ensure their “development” is shippable i.e. the stories are bug free and satisfy the benchmarks or acceptance criteria linked with each story. The PO also answers any doubts or queries put up by the team.



The first part is attended by the entire team – the product owner, scrum master, and the development team members. It is not necessary for the stakeholders and project owners to attend the meeting, but if they desire to do so, they can attend the meeting as “passive” invitees, and not disturb the proceedings with their suggestions or even try to get “involved” in the meeting.

2nd part of sprint planning

User stories form the base of all development activity in Scrum. The entire product is developed by creating shippable stories, which are later integrated to “form” the complete product. During the second part of the Scrum planning meeting, the team starts discussing how it will carry out the actual development activity and create the stories in the sprint backlog. Generally, a Scrum team is “multi-talented” i.e. each team member possesses more than one type of expertise. However, it is important to know that this may not always be the case in all Scrum projects, since the product requirements and resources may vary depending upon the nature of product to be developed.

The team members – developers, programmers, designers, QA personnel, and technical writers – decide amongst themselves how the user stories should be split up into parts that are more “manageable”. Each such “part” is referred to as a “task” in Scrum. Tasks are developed to create shippable user stories. A developer can develop each task individually. Certain Scrum teams may even work in “pairs”. Members collaborate, and decide amongst themselves as to who should take up which task depending upon the experience and levels of expertise possessed by them. Once the tasks are “distributed” the actual sprint can begin.Read more at

Sprint planning meeting agenda