Agile Scrum for knowledge professionals: Organisational Flows

This piece is part of a series of articles exploring how Agile Scrum makes an interesting proposition for any group of knowledge professionals.  You can get the details in full via my white paper [download it here].

Organisational Flows

Agile Scrum operates around the concept of a “story”.  Groups of stories are known as Epics. Epics are “big stories” or “umbrella stories” and typically aligned to scope.  The story is the individual piece of work that delivers the scope.  The concept of a “Theme” is also used in Agile Scrum.  Themes can be used to group stories across epics, projects and programs.  Themes don’t always align directly to epics, but they can do.

To elaborate a requirement (or tender), the Product Owner and perhaps representatives of scrum team build up the set of epics and stories.  The epic could be thought of as a generalisation of the need, whilst the story is a specific piece.  The format used for describing epics and stories varies between implementations, but typically each contains a narrative that represents the need and associated value for that piece. Additionally, epics and stories typically have confirmation statements.  These confirmation statements are encapsulated in the Goal, Conditions of Satisfactions and perhaps Acceptance Criteria.  The Goal is a single statement or truth that needs be realised.  Conditions of Satisfaction are statements that must be true for the story to be deemed “done” when the team finishes working on it.  Acceptance Criteria are more technical in nature and depict specific scenarios that must be achievable for the story to be deemed “done”.

To estimate a requirement (or tender), the Product Owner conducts sessions with the entire scrum team (or teams) to estimate the relative size of each story.  Estimation is done via a method known as ‘Planning Poker’, where everyone in the team provides their estimate at the same time to avoid junior members of the team blindly following senior members.  Multiple rounds are often held to obtain consensus.  The relative size is typically recorded as “story points” using a Fibonacci sequence .  These points provide the basis for the release planning.  Release planning is the process by which the scrum master and the Product Owner maps out the delivery schedule.  Release planning uses historic data regarding the number of story points completed by the team over time.  The schedule that results is only a guide and must be revisited every time stories are added or completed.  Agile Scrum operates on the principle of fixed time and fixed resources, with scope being the main variable.  Therefore, release planning is more about projecting how much will be achieved by the team over given period, rather than when the team will be finished everything.

The boundaries on activities within the Agile Scrum approach are defined by Definitions of Done (DoD).  The DoD contains principles and rules that will guide the team in how they estimate, prepare and complete stories, sprints and projects.  Typically, teams will have a DoD for the project, a separate DoD for the sprints and a separate DoD for the story.  Story DoDs can be thought of as shared statements of confirmation, i.e. truths that all stories must meet in order for each story to be considered “Done”.

To deliver a requirement (or tender), the scrum team take groups of stories and work on them over set periods of time (also known as Sprints).  Sprints are typically between 1 and 4 weeks in duration.  The duration must be agreed upfront by the team, suit the type of work and be aligned to the story sizing.  The groups of stories in a sprint are generally taken on in the order of priority set by the Product Owner.  During the sprint the Product Owner cannot change or influence the work being done by the sprint team.  At the conclusion of each sprint the team presents the finished stories to the Product Owner for sign-off.  The Product Owner will generally only sign-off stories that satisfy the Conditions of Satisfaction, Acceptance Criteria and Definitions of Done.

A crucial component of any agile approach is on-going learning.  Sprints are designed to be small so that changes in priority can be accommodated but also so that process challenges and improvements can be addressed immediately.  Agile Scrum uses the concept of the Retrospectives at the conclusion of every sprint.  The retrospective is a structured and open forum conducted by the team to surface and then action areas for improvement and also to give praise for successes.

Agile Scrum for knowledge professionals: Organisational Design

This piece is part of a series of articles exploring how Agile Scrum makes an interesting proposition for any group of knowledge professionals.  You can get the details in full via my white paper [download it here].

Organisational Design

The organisation optimised to utilise Agile Scrum, is a collection of self-organising teams.  Each team, known as a ‘Scrum Team’, is self-contained.  Each team has sufficient resources and skills to elaborate, estimate, plan, deliver and support projects from tender right through to completion.  In effect the same people work together for the lifetime of the project.

Within organisations that utilise Agile Scrum, the value-add associated with the goal of the organisation’s end customers is owned by a single person.   In Agile Scrum, this person is known as the Product Owner.  In the consulting world, you could refer to this person as the Project Owner or Program Owner in the case of larger engagements.  Some refer to this person as the Product Champion.  The role of the Product Owner is to portray and communicate the needs of the stakeholders with the scrum teams.  The Product Owner must understand the need or goal of the project in great detail and equally appreciate the constraints and limitations of the scrum team.  Prioritisation of work activity therefore rests solely with the Product Owner.  The Product Owner isn’t the customer but an internal representative who takes responsibility for the customer.  The Product Owner is often referred to as the “Neck”.

The Scrum Teams will have between 5 to 7 members:  Teams with more than 7 members face challenges in communication and coordination; Teams with less than 5 members can’t provide adequate cover during absences or spikes in activity.

Everyone in the team is a “doer”, i.e. they have specific skills which bring value to the goal of the team.  Each team will have a “Scrum Master”.  The role of the scrum master is to facilitate the team’s activities.  The Scrum Master is there to ensure the agreed rules and principles are followed.  The Scrum Master aids in blockage removal and ultimately ensures the team has everything it needs to deliver on the goal of the team.  The role of Scrum Master can and should be shared around the more experienced members of the team.

Organisations that have multiple smallish projects running in parallel and that can’t individually justify full-time commitments from teams of 5-7 members, should look to have a single team focus on multiple projects.  That is to say, whilst it is acceptable for an individual to work across multiple projects, it crucial that key people don’t move across multiple teams.  The team as a whole then own the projects and share prioritisation and other aspects of risk.

Organisations that have large projects that require teams of more than 7, should look to have multiple teams working in parallel.   This form of operation requires the concept of Scrum of Scrums.  Scrum of Scrums is where representatives from each of the scrum teams meet and coordinate activities relating to the team as a whole.  For some aspects, specifically estimation and planning, the entire team should be involved.  For elaboration it may be sufficient for the scrum team representatives to work with the Product Owner.  For delivery and support, the individual teams must agree the level of commitment, not the scrum representatives.

To support the self-organising scrum teams, the organisation will typically invest in providing a business process support resource or small team.  The aim of Business Process Support (BPS) is to help setup the scrum teams and to help keep them running effectively.  BPS may also take on shared services, like Finance, HRM and ICT.  It isn’t typical for BPS to provide governance, but BPS may help the teams set the initial set of rules and principles which the scrum teams will operate by.  It is then up to the peers within the teams to adhere to those rules.  Ultimately, as the name suggested BPS is there to support the organisation not direct or control it.