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.

Agile Scrum for knowledge professionals: Bottom-up

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].

Bottom-up

Agile could be considered a "Bottom up" approach because everything from estimation to delivery is done by the team, not by leads. In the agile approach, leads become facilitators rather than gatekeepers and controllers. The goal of the facilitators is to ensure the team have everything they need to make decisions and execute their skills.  A common mistake, when moving from traditional process models to agile working, is that the leads continue to make decisions on behalf of the team.  That is no longer their role.

Agile assumes that end-user-value-add takes priority over traditional constraints (time, scope, resources, cost & quality). Everything the team works on, in the agile approach, is focused on the "story". The story is an end user value proposition. The story is more than a means to control scope because it focuses the attention, at all times, on the benefit, not the process.  Stories generally need to satisfy the INVEST  criteria.

Agile ensures decisions are made at the time when it is most appropriate (i.e. when the right information is available). Traditional approaches favour more up front decision making when the required information is not as readily available.

During estimation, the team focuses on the relative size of the story, not actual effort. During the planning stage, the team focuses on the velocity of story output, not the time things take. During the delivery phase, team effort is focused around an agreed set of stories and benefit they encapsulated rather than every part of the project.   The Story encapsulates the benefit and also protects the team’s ability to deliver value whilst not losing sight of the end game.

Agile Scrum for knowledge professionals: What is Agile Scrum?

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].

What is Agile Scrum?

Agile Scrum is a collaboration methodology that has seen great success in the software industry. There are two facets of the software industry that make Agile Scrum an interesting proposition for any group of knowledge professionals.


Firstly, the software industry is characterised by highly skilled knowledge professionals that do not take kindly to being told what to do.

Secondly, the software industry has accepted whilst re-use and repeatability are crucial to performance, rigid process stifles innovation, so processes that support flexible collaboration take priority over processes that enforce re-use and repeatability.

Whilst Agile Scrum is a relatively simplistic and flexible approach, it is far from being a lazy approach. In fact it is often the opposite. It is reported that people find they are working harder using the agile approach. However the news is good as most agree that whilst harder, the work is more fulfilling and far more enjoyable.

Agile Scrum isn't for every situation, or for everyone, as it is characterised by teams of highly collaborative individuals with exceptional discipline.