To understand Being Agile as an approach it is useful to explore aspects of the Agile Landscape we saw earlier in more detail.
As we saw on the Tube Map graphic in the Agile Approaches section there are many flavours and styles of agile.
In this next section we will look at two of the most popular agile styles, Kanban and Sprints.
The Being Agile core approach combines and adapts these methods and tools, with coaching and lean methods and tools to create an approach that works effectively to help create a sustainable pace, maximise performance, deliver projects successfully and build viable and valuable solutions.
Modern Kanban comes in a variety of styles too, in it’s simplest form it is a simple pull request system, this means that the latest highest priority item is acted on next, activities that are urgent and important are prioritised.
Kanban is a highly responsive agile approach. It is incredibly valuable in environments where all work is ad-hoc, for example a support team responding to support requests. A Kanban project plans on a day to day basis, in effect running a one day sprint.
A Kanban board in its simplest for has 3 columns, To Do, Doing and Done. And each item on the board is given a priority highest to lowest.
The challenge with Kanban is since urgent/important work is always prioritised, work that is lower priority may never get to the top of the list. It is difficult to plan in improvement work since other activities are always prioritised and there is no provision for planned work.
If you are a list person (you like writing lists) then think of this board as a dynamic to do list. Each item on your list is a sticky note on the board. Instead of crossing off, adding and rewriting your list, you simply move the sticky note to the relevant place on the board to show its status (to do, in progress, or complete) and when you have a new item to do, you simply add a new sticky note to the To Do column.
You can also expand your Kanban board to show other stages or status of activity.
A key element of kanban is to limit work in progress, a team can only work on one or a small number of tasks concurrently. This is to help ensure we do not start lots of things and not finish them creating bottlenecks.
A waiting box is a useful status on a board to help park tasks that have been started but cannot be completed because they are waiting on something that is outside the control of the team.
Kanban board with waiting and testing status included:
I often say, in its simplest form agile is a brilliant dynamic to do list, each item is on a mobile card that can move across status’s, no need to ever write a to do list again!
Read more about Kanban and its various formats and styles – https://en.wikipedia.org/wiki/Kanban_board
The Sprint method is one of the most popular adopted by tech teams, and has been widely adopted in other business areas and functions too such as Research, Marketing, Sales, HR, Business Improvement and Innovation.
The Sprint method shares many similarities with Kanban, however it takes a slightly different approach to managing workload, it that it batches work into sprints. These sprints of work are fixed, defined and planned at the beginning of the sprint, worked upon, and then reviewed at the end of the sprint. Each sprint should have a sprint goal or outcomes, there should be a deliverable at the end of each sprint.
Scrum is a popular style of agile (if agile were shoes, scrum would be Reebok, a brand and style of agile) Scrum has evolved and adapted in recent years, early adoptions were very strict on sprints, allowing no changes during the sprint, any new work has to wait until the next sprint to be considered. Scrum is a standardised form of agile working designed for tech teams.
Let’s look at a product development project and walk through a sprint in scrum using the above diagram.
On the left we have our product backlog, this backlog is continuously refreshing with new ideas, updates and revisions to the backlog.
At the beginning of the sprint the team plan their sprint, they pull a batch of work from the back log based on priorities in the backlog and the objective of the sprint.
The Product Owner (the user/customer or a representative of) is a member of the team and helps the team to understand the current customer/users priorities, and based on time, resources, materials available, the team plan the sprint and the work is locked in. I like to call this role the Product Guide Hat, when wearing this hat we are the user/customer. Who and how the role is filled is very dependant on the type of project and the style of agile being adopted.
Once the sprint plan is agreed, the team work on this batch of work throughout the sprint. They can work on any item of work included in the sprint in the order they wish. The team are able to self-organise how they choose to deliver the work included in the sprint.
During the sprint they have a ‘daily scrum’ meeting to update each other and their board on progress of activities. What they have completed, what they are working on, and what they plan to complete next. Its also an opportunity to flag up impediments or issues
At the end of the sprint there is a sprint review, to review the work completed and release the work completed for testing and feedback. Any work not completed is returned to the backlog.
The team hold a retrospective at the end of each sprint, considering the sprint review outcomes, and the response from testing and release to reflect on what is going well, what could be better, and what improvements should be made. These are then fed into the backlog of work as new improvement tasks.
The team then begin the cycle again, selecting their next batch of work for the next sprint.
During the sprint a member of the team will wear the ‘Scrum Master’ hat, this maybe a part time or a full time role depending on the context, scale, type of application. This role is a team facilitator, I call this role the ‘Sprint Facilitator’ hat. When wearing the hat we are a facilitator of agile thinking, methods and tools for the team, we ensure meetings are organised and held and we facilitate the team to help them make decisions, we work with the team to sustain and enhance their agility for growth, performance and well-being.
We do not manage the content, rather we manage the process, and support the team to plan, run and review their progress before, during and after sprints. The Sprint Facilitator is a servant leader, they ensure the team has the environment, skills, resources and support they need to complete the sprint and to continuously improve. Again there are variations of this role/hat needed within teams dependant on the context of the situation.
In an ideal world, every member of the team takes responsibility and ownership of the agility of the team, their own agility and the agility of their work, the sprint facilitator helps to guide and facilitate this.
Agile characters and personas, team roles and hats is something I would like to write much more about! But back to my overview of the sprint method..!
With sprints we can visualise our work on an agile board as we can with Kanban. Instead of one prioritised to do list like in Kanban, a simple Sprint board has a backlog, a Sprint to do list, and it shows the current sprint in progress and the status of tasks as started or complete.
This is great for teams that are working on developing products or services where changes are not being received regularly, or at least can wait a few weeks if they are.
The challenge with a fixed sprint method I find, is that I am yet to meet a team that can wholly define and fix their work for the duration of a sprint that is 1-4 weeks long. Something urgent and/or important will inevitably pop into the inbox that must be responded to immediately, it simply cannot wait a week or two for the next sprint.
It is unrealistic to plan our sprint to 100% capacity with planned work, because of unforeseen new work that is urgent and important, yet this is what many teams do!
So while kanban is great for highly responsive teams that are constantly dealing with new requests, Sprints are great for teams that are able to plan and fix their work ahead for at least a sprint. Most teams I work with lie somewhere in-between, a mix of planned and unplanned work.
Teams generally always have a mix of work to do. We can usually categorise this work into our Planned, day to day, scheduled work – doing the day to day work, running the business. And then ad-hoc unplanned work, projects, improvements, work that is focused on changing and improving our work.
By using agile methods to visualise our work we can understand better our ratio and mix of work. We can establish how much work we are able to complete, and compare our plans and estimations, with feedback from releasing our work in progress, data and results.
Scrum is a lightweight, iterative and incremental framework for developing, delivering, and sustaining complex products.https://resources.scrumalliance.org/Article/quick-guide-things-scrum
https://en.wikipedia.org/wiki/Scrum_(software_development)
The Being Agile Method combines popular methods from agile, lean, coaching, together with experience to create an adaptive method that can be used for managing workflow, projects, building solutions, team work, leadership and more.
Being agile uses a sprint approach that allows for a mix of planned and responsive work to be delivered each sprint. It enables teams to manage inbound work, monitor their backlog of work and work in progress, and ensure they are regularly reflecting and improving plans and ways of working to account for learning and change.
As with other methods one of the key tools used is an agile sprint board to help visualise work. This board can be physical or digital.
I do love physical boards, for their tactility and visibility, it creates an actual physical representation of your workflow, project activities, or features of a solution.
The Being Agile Canvas can work physically or digitally. You can print it as a poster, re-create it on a white board, or re-create it on a digital tool like Trello or Miro.
The canvas is available to download for you to use
The Being Agile Canvas helps to guide you through the Being Agile Method, and an initial template for you to use for your adoption of agile.
Canvas PDFYou will need a copy of the canvas for the next section. Download your PDF copy below as a one page that can be printed A4-A0, or as an 8 page that can be printed and collated to create an A1 poster
In this section we will go through the Being Agile Canvas step by step to get a better understanding of how it helps us to visualise, plan, manage and monitor our workflow, project progress, or solution development.
The left hand side of the Canvas holds our new and planned back log of work for the future – imagine this as everything on your current to do list.
For this example Blue notes represent work we know about, our known backlog of work, these items are held in the Future Work area.
Orange notes represent new work, unplanned, inbound new requests. New requests are managed through the Inbox on the board. Work cannot be placed directly into To Do, or Doing, this helps to control inbound work, ensuring that a sprint doesn’t get overloaded with work, or that unimportant, or non-urgent work is prioritised.
The right hand side of the board shows us our current sprint and work in progress.
It has a To Do, Doing and Done box rather like previous Kanban and Sprint boards, and also a waiting/blocked box, feedback box, and also an area in To Do for Slack.
To Do – Work to complete in the current sprint.
Doing – Work in progress in the current sprint.
Done – Work completed in the current sprint.
Waiting – work that has been started but cannot be completed as it is blocked or waiting on something before it can be completed.
Feedback – this area is for tasks that have been done, but need to be tested, or signed off as accepted before they are validated as ‘done’ and put in the Done box. For example a report that needs to be signed off by another party, or, a piece of work for a customer that needs to be accepted.
Slack – this is a new area of the board designed to create slack within each sprint for new and unplanned work that is urgent and important so needs to be actioned within the sprint.
Let’s work through a simple example to help understand how items move around the Canvas.
Before we start our first sprint, we map all our known and planned ‘to do’ items onto Blue notes into the future work area of the board, this is our backlog of work to be done.
At the start of our first sprint we plan our sprint out, selecting items from the backlog we want to complete during the sprint. For this example we will think of our sprint as the current week, and it includes this agile training. If we have a goal for the sprint we will select work that will help us to achieve that goal.
We put the selected items for the sprint into the To Do box to show they have been selected to work on this sprint. We keep our slack area free for new, urgent and important requests we might receive.
Day one of our sprint, work has commenced on a task, and therefore is placed into Doing.
Two new requests have been received and they have been noted and placed into the inbox.
We review Inbox items and decide if they are Urgent and Important?
If they are Urgent and Important, we estimate their size and as long as there is sufficient slack we place them in our slack for the current sprint so that we can work on them as soon as possible.
If they are NOT urgent, or important, they are placed in Future Work with other work in the back log to be reviewed and become planned work that will be considered for future sprints.
In the example, we have one item that is Urgent/Important and has been placed in the sprint slack to be actioned. The other item is not urgent/important and so has been placed in Future Work with other work in the backlog. Work on the current ‘doing’ item continues.
This board represents Today in our sprint, we are ‘Doing’ agile training, and we are also working on that Urgent/Important task too. The initial item started has been completed, another has started but has been blocked so has been placed in ‘Waiting’ and there is still one more task to start.
This board shows us ‘tomorrow’ in our sprint, it shows our Agile Training completed, along with other items, work on the final item has been started and is in progress, and one other remaining item is caught in waiting.
At the end of our sprint ideally all work items have been completed. This however isn’t always the case! The status of items at the end of our sprint shows us whether we have under-planned, or over-planned our sprint, whether we had too much or not enough slack, and how much new inbound work was accepted during the sprint.
At the end of the sprint we may have the above scenario where tasks have gotten caught in waiting and have not been resolved before the end of the sprint.
By reviewing our board we can understand better our mix and ratio of planned/new work, types of work and variations to better inform our sprint planning in the future. Initially when using a board we can get a better idea of how work is currently flowing and look for opportunities to make improvements, such as reduce time in ‘Waiting’, or ‘Feedback’, or manage New work requests better.
In the next section we will use the Being Agile Canvas to map your own work into sprints, and reflect and review your own volume of work, mix of work, your work ratio and flow, or lack of!
In this session you will practically use the Being Agile Canvas to map your current work so that you can create and plan your own sprint, monitor progress, and then review it.
To begin with I recommend you try out the Canvas with your own current workload, or you may have a specific project or a product in mind that you want to map out using the Canvas. I would suggest to begin with you choose something simple, or known, so that you can focus on the trying out the method rather than thinking about the content.
Action – Map all your to do’s into future work.
You can use different colours to represent different types of work. For example on my board I have a different colours for : large, medium and small clients, my teaching time, and also a colour for life, like dentist appointments, school plays, meeting friends.
You can always add to this later, get as many items out of your head and onto notes as you can, you can always refer to your to do list or other current ways of remembering your to dos!
Decision – How long will your sprint will be?
Next we need to decide how long your first sprint will be, its good to experiment with sprint lengths to find out what length works best for you. Sprints usually vary from 1 to 4 weeks, to start I would recommend one week, and then try two, or three week sprints and compare to see which works best for you.
Action – map and plan your sprint of work
Next based on the length of your sprint, select work from your back log of ‘Future Work’ to complete over the next sprint.
You probably already have some work in progress happening or planned for the next sprint, if you do, capture this work on sticky notes and place it into to do, or doing. Perhaps it is stuck in waiting, as you think of items, map them to your board.
Action – Review the items that you have selected to work on for your next sprint.
Question – Do you think you have enough work, too much, or not enough for the sprint? Tweak your plan as needed by moving items back and forth between Future Work and your Sprint To Do box until you are happy with the balance of work for the sprint ahead. We will review at the end of your sprint if you have over or under planned it.
Now – Action – Now you have your own Agile Canvas with your next sprint mapped out, you can start your sprint and begin work.
Next – Action – During your sprint update your board with progress of your planned tasks, add new tasks to your board to record and monitor these too. Use the Inbox and the Important/Urgent decision matrix to manage inbound work requests and whether they should, and can be added to the slack time in your sprint, or whether they will be placed in the backlog for review for future sprints.
Later – Action – At the end of your sprint review your board, consider:
Then, when you have completed your first sprint, plan your next sprint of work!
Now you have created your own Being Agile Canvas you can put agile into practice!
Over the next week, update your board regularly with the work you are doing, add, move and update your sticky or virtual notes across your board.
Initially using a board is a great way to create a visual picture of what is happening currently in your work, project, or build. Capture your tasks and by the end of your sprint you will have a snapshot of the mix of work you have worked on, what flowed, what got stuck, how much unplanned work was received and acted upon, or added to the backlog and more.
I am a great believer in developing your own style of agile that works for the context and purpose for which you are using it. Think of the Being Agile method and canvas as your first version of agile.
There’s a great phrase ‘Minimum Viable Product’ in Agile, this is your minimum viable agile solution, it is a starting point from which you can learn more about your mix of work, your flow of work, and where your gains and pains lie.
With this method you can literally put the writing on the wall to show you how agile your work currently is. And, if you listen to what it shows you, you can improve your agility, and that is the difference between doing agile, and being agile.
Explore Guides and Resources for further tools and techniques to help plan, monitor and manage your Canvas and use these to review and improve your workflow, performance and well-being.
What is agile — The Being Agile Mix
Digital Agile Boards — Agile Trello Board
Agile Planning – Prioritisation – Moscow & Urgent/Important
Agile Methods – T-Shirt Estimation – Estimating Size
Agile Planning – Considering complexity
Book a 30 minute conversation to chat more about being agile in your world!
