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.

In-Control™ Optimise Programme for Businesses

You may have noticed my new "twitter" theme this morning - "[I'm] passionate about helping others get more done with greater fun and less effort".


Behind this theme is the new "Optimise" programme for businesses. You can read a little more about the service on the web site. To get the real story, connect with me and I share the details.

Are you perceived as being responsive?

For a long time, I would get frustrated and stressed over what I labelled “poor responsiveness”. I would apply this label to people I worked with, friends and even family members. Mind you, not everyone got this label, only those I knew I needed to “track and follow-up” in order see a commitment carried out.

This behaviour is typically associated with procrastination, but manifests itself in all aspects of life. For example, you could be in a meeting where your colleague commits to taking an action after the meeting. Equally, you could be chatting to a friend on the phone and agree to talk next Thursday regarding going to a coffee or pint. Sometime after the event you realise neither has occurred.

In order to “manage” those that I felt weren’t responsive, I would create reminders in my “To-Do” system and then chase people down when I hadn’t got what I needed. This created unnecessary effort and the associated stress for all parties involved, because no-one likes being reminded of something they didn’t do.

I now know better.

I now understand what creates the perception that someone doesn’t respond appropriately. And I know how to be more effective in situations when someone doesn’t deliver on a commitment.

The first revelation is that the concept of “responding appropriately” is different across cultures, companies and communication mediums.For example, in your business you may expect a response to an e-mail query to a colleague on the same day. However you may not expect a response from an external customer for up to 3 days. On the other hand, if you receive a SMS Text message from a loved one, they may get concerned if you don’t respond almost instantly. Therefore, we must understand who we are communicating with and what is accepted as the “normal” level of responsiveness.

The other revelation, and more critical aspect, is to do with an unfortunate inadequacy in the tools and techniques most of us employ. For example, things just don’t get done because it is “accepted” that e-mail queries with-in the office should be answered on the same day or even actions taken on minutes during a meeting need to be completed before the next meeting. Unfortunately, whilst I believe most people honestly aim to deliver on a commitment at the time the commitment was made, their system for managing that commitment lets them down.
The root cause in our “system” in most cases is our short-term memory. Unfortunately short-term memory is very flippant; it is easily distracted by the latest and loudest thing that comes into our world. Therefore, whilst we may have honestly committed to do something, that something will be replaced in our consciousness at some point, be it later in the day, tomorrow, next week or even as you leave the meeting and get into a conversation with someone on your way back to your desk. Even if a commitment is written down in your notepad, if your personal system for reviewing and organising these notes isn’t adequate, you will still be relying on your short-term memory to get back to the notes and those agreed meeting actions.

Now that I understand what is behind my misconception, I am better able to manage it. For example, when looking for something from someone else, I will be very specific about the outcome I expect and by when. Where as previously a meeting action might read “Quarterly results report (Joe)”, it would now read “Joe to export October to December transactions into the reports spreadsheet and forward to Brad by Wednesday lunchtime”.

Furthermore, if someone is still struggling with their commitments and exhibiting stress is doing so, I help them understand more about how they might better manage their “to-do lists” and inadequacies of short-term memory.

How are you perceived by your colleagues, customers, friends and family? Are you seen as “responsive”? Do you know someone who is non-responsive? What actions do you take?

The Humble Task List isn’t enough

Why do we use task lists? When used properly, task lists can help us track what we need to do, when we need it done and for whom it needs to be done. We can use lists to manage our commitments and reach our goals. Even “Ticking” tasks as complete does provide you with a list of mini-achievements.

Is it enough? So does the humble, yet powerful task list offer a path to an ultimately happy and fulfilling life? Well no. Why? Because I believe, we need to do things in the context of what is most important to us. I propose that the underlying and fundamental human need here is linked to goal recognition or having a sense of accomplishment. If we do not often reach this sense of accomplishment we slowly but surely get tired, worn-out and bored with what we are doing. The things that used to have us bouncing out of bed in the morning do not matter any more. A sense of accomplishment comes simply by seeing in every action one takes, no matter how small, progress against a greater goal.

Where is the utopia? If we frame or categorise what we do in relation to where it fits into our lives, every little “tick” will bring us closer to where we want to be.
For example, suppose we have a list of things we need to get done today. When used in isolation this list may not totally excite us and have us humming through our day. However if we were to add some categorisation to each task that provides a link to a goal or even a greater purpose, then we have a better chance of seeing the bigger picture and end point.

By seeing completed tasks as steps towards a goal we will have a better chance of achieving the sense of accomplishment on a daily, hourly or even minute-by-minute basis.

Do you frame or categorise your individual tasks in terms of a goal or greater purpose?

Maximise your performance by minimising your interference?

Why is performance important?

To really perform at what we do, we need to constantly and consistently move things forward. To move things forward, we need to give each specific part of that thing our full attention, even if only for short burst. Giving something our full attention improves the quality and reduces the overall time it takes to get it done.

What is stopping us maximising our performance?

To answer that question, you should look at the work by Timothy Gallwey, called the Inner Game. The Inner Game as developed by Gallwey in 1974 builds on the notion of “Potential” and “Performance”. There is a gap between potential and performance which Gallwey describes as the thoughts which you have when going about an activity. These thoughts can be better described as “Interference”. Interference then is the self doubting thoughts you have that get in the way of your potential and reduce your resulting performance.

As Gallwey proposes, our performance is limited by interference caused by our thoughts. In a typical work place, that is not the only place interference comes from.

We are subject to continual bombardment, more so than ever before, from things we allow into our space, like e-mail, Facebook, Twitter and SMS text messages. Then there are the external things that we have no control over, like the phone ringing or perhaps the boss or a colleague wandering by and requesting something. And what about the meeting culture? Have you ever felt your whole day was full of meetings? How much can you get done if you are in meetings all day, surely that is interference also?

So how do we minimise the interference and maximise our performance?

The obvious answer is to just remove the inference right? So maybe lock yourself away from your colleagues, the phone, the computer, your mobile phone. And how about your own thoughts? Should you just stop thinking? Ok, so none of that is realistic, because you need your thoughts, you need your colleagues and you need all the tools.

What you can do however, is two things. Firstly, for short periods you should limit the interference from the things you can control, i.e. turn off e-mail notifications and try to give yourself the permission to not answer phone or text for a period. The second thing we can do is to clarify the things in our head, get on top of our commitments by writing them down in a list, then when done doing the thing you need to get done, you can review that list and get back to the other million and one things to do. Being clear and in control for these short periods by reducing the interference will enable you to perform much closer to your true potential.

Where does your interference come from and how do you reduce it?