What is Agile?
When people refer to “agile” they are usually referring to the agile manifesto and the twelve agile principles written by Beck, Cunningham, Fowler, Schwaber, Sutherland, et al.
The Manifesto for Agile Software Development says: “We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:
- Individuals and interactions over processes and tools
- 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.”
For more information, including the 12 principles, please go to agilemanifesto.org
What is Scrum?
It’s impossible to describe the variations of Scrum in a few hundred words.
If you want a good introduction, come to one of my introduction workshops.
However, what I will do is describe how I’ve generally* used Scrum in the businesses I’ve helped:
- Scrum is one approach that applies the agile principles
- It is a framework; not a full methodology
- Scrum uses iterations to deliver regular working software
- Iterations are normally between 1 and 4 weeks in duration (I found 2 weeks is usually about right)
Scrum roles
The team comprises the people who write the code, run the tests, etc. I cheekily refer to the team as “the people who do the work”. Teams are typically 5 to 9 people. The team makes decisions as a whole, not as individuals (e.g. how much work to do in the next iteration).
The Product Owner is a decision-maker from the business. The PO owns the roadmap and the backlog of work that the business wants the team to deliver. The PO decides on the priority of this backlog and will answer questions that the team might have regarding these requirements.
A ScrumMaster is often referred to as a “servant leader”. He/she is not a decision-maker but works for the team to remove impediments, coach the team in agile/Scrum processes, shield the team from negative forces, facilitate meetings, etc. The ScrumMaster works towards the team becoming self-managing.
User stories **
Scrum doesn’t use lengthy specs; instead, the PO writes a short, simple description (in everyday language) of what the business wants. This is called a “user story”. Stories are written from the perspective of the person who will use the new capability. It is important to note that the story tells the team what the desired outcome is, but does not tell the team how to deliver the requirement.
A common format used to write user stories is:
As a <who>
I want <what>
So that <why>
For example, “As a customer I want to be able to edit my shipping address so that orders get delivered to my correct address.”
User stories are supported by Conditions of Satisfaction. These are a list of criteria that the story must satisfy once delivered. A story is not considered complete until all the Conditions of Satisfactions have been fulfilled.
Product Backlog
As mentioned above, the PO decides on the priority for all remaining work. This forms the “product backlog”. Items that are at the top of this queue will have a lot more detail than items towards the bottom. There is little value adding a lot of detail to stories that are at the bottom of the backlog because a lot might change before you get around to working on them.
Sprint planning
Teams decide how much work to complete in each iteration by taking the top items from the product backlog. The group of items that they agree to work on in the iteration is known as the “Sprint backlog” (or “iteration backlog”).
Estimation
But how do they know how much they will be able to complete? They estimate how big each story is but, rather than use time, they use story points.
The team discusses the story until they understand the requirements. They then compare the size of the story relative to other/past stories (including all testing required to make the story considered ‘done’). A popular method is for each person to choose a figure from the following sequence: 1, 2, 3, 5, 8, 13, 20, 40, 100. Everyone then declares their opinion at once. The people who choose the lowest and highest figures then explain why they chose those numbers, the team discusses, then votes again. Once a consensus is reached, that is declared the size of the story.
This information gives the PO the chance to descope and/or deprioritise the story (or, of course, to leave it as it was and in the same place in the prioritised list).
For more information on poker planning, check out Mike Cohn’s explanation of Planning Poker.
Agile boards
A method to visualise an iteration’s progress: a column for each step of the process. Each story is represented by a card (sometimes the story is broken down into smaller tasks which are also displayed on the board), which is then moved through the columns as it progresses to completion.
A basic board might have columns of just ‘To do’, ‘In progress’ and ‘Done’.
Daily Scrum (aka Daily Standup)
A short, daily meeting. This is not for the management’s benefit; it is to update the rest of the team on progress – and to allow the team to offer assistance if necessary.
Common format is for each person, in turn, to confirm:
- What I did yesterday
- What I plan on doing today
- Any impediments that I have
Velocity
Once you’ve run an iteration (or five), you will get an idea of how many story points you are likely to complete each iteration (by taking an average). This is your velocity.
Be careful! Velocity should not be seen as a promise, a target or a management metric; it is meant as a guide for the team to limit the amount of work they are saying they will complete in each iteration.
Sprint Review
A chance for the team to show-off what they have produced and get feedback from stakeholders and interested parties. This feedback feeds into the Product Backlog to help plan the next Sprint.
Note: this is a demonstration, not a training session.
Sprint Retrospective
At the end of each iteration, the team will get together to discuss how well they worked as a team and what they can do to improve.
It is not a meeting to discuss individual performances, nor is it the time to discuss feedback from users on individual stories.
A common format is to highlight:
- What we should start doing?
- What we should stop doing?
- What we should continue doing?
Definition of Done
Unlike Conditions of Satisfaction, this is criteria that all stories must satisfy before they can be considered done.
For example, the team might decide that every story should be code reviewed by at least two other people, must have undergone testing and must be merged to a specific place on the server.
It is important, again, to note that it is the team that agrees its definition of done.
The team’s Definition of Done is usually printed out and placed near the Scrum board.
Burndown chart
A burndown chart helps the team track progress.
The x axis is time. The y axis shows points/days/hours of work remaining.
Each day, the team will calculate the story points or time remaining, and plot it on the graph.
I struggle to see the benefit of calculating days or hours as we have already established that we struggle to estimate time more than we do relative size. But this is widely argued and is just my personal opinion.
I hope that helps give you an overview of the basics of Scrum. Please contact me if you have any questions.
Disclaimers
* Please also note that, in order to get a brief summary written, I have made some very large generalisations. If you would like to suggest how I improve this page without making it 20 times larger, please feel free to let me know.
** Some of the practices detailed actually originate from other frameworks, such as XP. However, they are now commonly used by teams using Scrum.
What is Kanban?
The Kanban Method was created by David Anderson. A full description can be found in the seminal book “Kanban: Successful Evolutionary Change for Your Technology Business”.
David Anderson confessed that, due to him failing to give his method a name, others called it The Kanban Method – which stuck! 
This is because it uses similar ideas to manufacturing’s kanban (such as in the Toyota Production System): a kanban, roughly translated to ‘signal card’, is used to identify when a point on the production line is ready for more work. This is known as a ‘pull system’.
What is a pull system?
Here is an example of how a pull system works:
- My job on the production line is to fit the wheels on cars
- I have two stacks of wheels next to me
- A car chassis comes along … and I fit the wheels … and move it on the production line
- Another car chassis comes along … I fit the wheels … and move it on the line
- Another car chassis comes along … I fit the wheels (using up one of the stacks of wheels next to me) … and move it on the line
- The guy in the wheels department sees that I have used one of my piles of wheels and produces another stack of wheels which he sends on to me
- I continue to fit wheels onto cars
In this example, the level of wheels I receive is dictated by the number of wheels that I already have. I cannot become overloaded with inventory, because the delivery of more wheels to me is dictated by my available capacity; when I have two piles of wheels, they know to stop producing wheels. I always have enough, but never too many. Equally important, should I stop working for any reason, the team that produces the wheels stops making them. In most companies, they would be producing wheels regardless of what I was doing, and my piles of wheels would just keep growing and growing.
Of course, money is tied up in any parts that have been made. The more inventory, the more money is tied up. Companies that don’t use a pull system, who just keep producing parts regardless of the demand from the other areas of the company, tie up a lot of money in inventory and gamble that these excess parts will be used. What if I had 1,000 wheels next to me but the company changed the design of the wheels?!
A pull system helps systems become ‘lean’.
So what is The Kanban Method?
In short, The Kanban Method has 4 foundational principles and uses 6 core properties to create a set of behaviours that help organisations be lean.
Foundational Principles
- Start with what you do now
- Agree to pursue evolutionary change
- Initially, respect current roles, responsibilities & job titles
- Encourage acts of leadership at all levels
Six core properties
1) Visualise workflow
Visualising your work enables you to understand how work proceeds through your system. This enables you to spot areas that need change. A common approach is to use cards on a board – with different columns for each step of your process.
The Kanban Method encourages you to start with what you have now. Don’t change your processes immediately, just identify your existing practices and processes. For example, how can you visualise the different types of work you do? How can you show who is working on which item? Can you display which items are blocked? Or those that relate to different areas of your business or different customers? (To name just a few)
2) Limit Work In Progress
Limiting the work that you have in progress at any one time helps you implement a pull system: work cannot be pushed to you just because someone before you in the chain has finished their work; it will only come to you if you have capacity. This has the benefit (as explained above) of not producing inventory that has potential to be discarded. It ensures that teams are working on the most appropriate item that the business needs at all times.
3) Measure and manage flow
By measuring the flow of work through your process, you can identify problems. Every process has at least one bottleneck and your system can only work as fast as your slowest bottleneck. So make changes to your processes in an attempt to improve flow. Measure the changes … then repeat the process … again … and again – to continually improve your processes.
4) Make process policies explicit
If you don’t know the rules, it is difficult to improve a situation. The Kanban Method asks us to make our processes clear … then you can have an objective discussion about improvements.
Explicit policies include identifying what must happen before an item can be pulled into a particular part of the process (known as ‘entry criteria’), defining what finished looks like (known as a ‘definition of done’), and acknowledging how you will action each of the different types of work you receive (known as ‘classes of service’).
5) Implement feedback loops
Do you review your performance and feedback regularly? You probably already do daily stand-ups and retrospectives: both of these are feedback loops. But, armed with data on the flow of work you now have more feedback. You are encouraged to get wider data about the company as a whole, and your departments contribution to the overall performance. Do you get feedback from customers and review that? What about other teams within your company that you work with? And stakeholders? There is a lot of feedback available out there: are you listening to enough of it?
6) Improve collaboratively, evolve experimentally (using models and the scientific method)
Improvements should not be revolutionary (remember, you’re starting with what you have already); you should look to make continuous, evolutionary and incremental improvements. The scientific method puts forward a theory then tests it – you should then keep what works and discard what doesn’t.
One particular area of improvement that will improve the flow of work through your process is to reduce the variations in the work that you have: when the work you do is similar, you should be able to deliver consistently; when it is varied, it is difficult to be consistent. Example of sources of variability are:
- Differing sizes of work items (e.g. putting tractor wheels on is going to take longer than car wheels)
- Differing work types (for example, asking me to work on wheels one hour, then fit doors the next hour, then windscreens the next is going to cause me to be slower than doing one type of work)
- Differing classes of service (e.g. having urgent work come in where I have to drop what I’m doing is going to cause the dropped work to take longer; whilst the urgent item is done quickly – variation)
- Having to rework items (e.g. doing a job right first time saves time in the long run)
- Accepting unknown work (e.g. agreeing to undertake work that is ill-defined)
- Problems with your working environment (e.g. if the factory keeps having power cuts, I’m going to find it difficult to work)