Here is a bit of an intro into the world of Scrum, what it is, and why it matters, I will also touch on Agile and talk a bit about frameworks. I originally looked into ScrumAlliance.org and did some training with them. I will talk about the kind of things they teach, but I think you have to be pretty serious to do it, with a willingness to retrain because each certificate is supposed to only be valid for a year and then you need to retrain. This doesn’t favor people who are transitioning into, for example product management from something else, and instead people who already have management experience are more likely to get a job as, say a Scrum Master. Without further adue, what’s it all about then?
The general consensus is that the term Agile evolved from waterfall as a framework for managing software development. Originally, the whole process was planned in advance, with different amounts of time set aside for research, development testing and delivering software. This included using tools like Gannt charts where for example project managers could plan to develop certain parts of systems in parallel. To reduce the amount of problems in the process and increase the liklehod of success a new framework began to emerge, which involved building in small increments and scaling when problems ocurred. This general framework was called Agile, and there is an Agile Manifesto, which was created to give a general indication as to the types of ways of using Agile thinking.
One of the main ones which stands out to me is responding to change. I think that pretty much sums up what Agile is about, it’s the fact that at the time of planning you can’t estimate or know in advance which problems you will have, so if you try and work in an iterative cycle of planning and changing requirements then there will be a higher liklehood of success. At the same time as Agile was being thought about there were other frameworks, these included Extreme Programming and Lean development. I don’t think Extreme Programming ever caught on in industry, but it’s ideas focussed more on choosing time frames and going at a problem intensely whilst being mindful of the amount of time you are going at the problem intensely (e.g. no working at weekends programming every 2nd week), and also doing pair programming with short release cycles.
More popular than Extreme Programming was Lean Development, which had some of it’s origins in manufacturing principles at Toyota. There are some great books which I haven’t worked my way through completely which talk about Lean Development, the most important being The Lean Startup by Eric Reis. Lean Development includes the idea of failing fast, and eliminating tasks which do not provide value to the product. Lean favors ideas like A/B testing to attempt to find the optimal path to the correct product. It has been used a lot by startup companies to build an MVP and beyond, but Lean tended to be a surrounding framework, used more by Product Management. Other techniques such as Scrum were being used in day to day software development in nearly every situation.
The ideas invovled in Scrum were are lot more applicable to the types of activities that happen on a day to day basis. The general idea of Scrum is that you pick either one week or two week sprints, which may include a few weeks lead time for the team to self organise. You then follow a practise of attempting to reach a team development goal (see definition of done below). You then pick up a certain amount of tickets each week, which the Developers are responsible for self estimating and then you work to get these finished by the end of the ‘sprint’. This then repeats indefinitely.
In parallel with this development activity, each day there would be a daily ‘stand up’ meeting, where Developers would talk about the progress they had made on the ticket they were working on, any ‘blockers’ they were experiencing, which may for instance include that certain developers had merge conflicts in their branches. With this there would be a meeting at the beginning of the Sprint, to do Sprint planning. In a lot of daily standups there would be the idea of throwing a ball to different people who were to give their Sprint planning update, the idea behind this is to allow the Developer to give their full update without being interrupted.
Sprint planning involves pulling in tickets (features/bugs/stories etc.) from the backlog; a large list of things that the ‘Scrum Master/Product Manager/CEO’ wanted, into the sprint and then using tools like Planning Poker to estimate using Fibonacci points scoring or similar, e.g. (1, 2, 3, 5, 8, 13) or (1, 3, 5, 10). Each unit, was supposed to give an indication of difficulty, e.g. a 3 was deemed to be harder than for example a 1 and would take more time, also seperately there could be other estimation tools, such as MoSCoW scoring systems. Initial points scoring lead managers into the line of thining of trying to second guess what a developers estimation was and to use this to force the developers into conceeding that they did not know why they had given a certain ticket a certain score. For example, a developer could mark one ticket as 1 because it was in his/her knowledge domain; a Developer could give a ticket a smaller score because he/she wanted that ticket in the Sprint because they had the techinal expertise to do it, or a ticket they didn’t know how to do a large estimation.
More usually however, the team would turn around and say, well what makes you believe that this ticket was a 5, for example. And then there would either be a technical reason which noone understood, or a Developer would explain that not enough knowledge was known at the time. Following this process a ticket which was estimated as a ten, could be labelled as an Epic, and this ticket would have to be split up into smaller tickets, and either pushed back onto the backlog for resitmation or pulled into the Sprint with a smaller tickets which had to be resitmated. Scrum Masters would then have to have an additional meeting to discuss the smaller tickets.
After the sprint had finished there would be two additional meetings, one which is called the Sprint Retrospective meeting, was there such that the Scrum Team, (latered organised into a Squad of max ten people in large organisations), could discuss what went well in the Sprint and what didn’t go well in the Sprint in terms of Scrum processes or tools. For example the team could discuss why there was not enough time to adequately discuss the amount of time they needed to spend on testing, or deployment, or review. They could sometimes use terms such as the process needed more Rigour or less Ceremony. Having more Ceremonly meant there being less Rigour and conversely the same was true. More Ceremony meant more meetings and processes, and more Rigour meant the opposite where people spent as much time as possible on the tickets at hand in order.
Also at the end of the Sprint was the Sprint Reflection meeting. In this meeting the Scrum Master would ask all of the Developers what had been produced in that Sprint and discussed if they had collectively met their Scrum goal. The Scrum master could also produce a Burndown Chart which was a graph which showed the day of the week that that a ticket had been completed and showed how fast the estimation scores were moving downwards towards the agreed amount of total points in the sprint estimation.
Agile also emcompasses some of the ideas that were in part extensions of clean coding and refactoring practises, which were thought about more deeply if a team all agreed a ticket was an Epic and it couldn’t be split up because not enough was known about at that time. In this process the team could all agree that a Developer could pick up a ticket which was known as a Spike. The Spike ticket would involve spending some time trying to understand the problem more deeply in order to understand how to go about adding it or splitting it up. More importantly this process probably involved coding a part or all of a solution without the requirement that the code would go into the code base.
Finally a more recent addition to Scrum was the definition of done, this meant that when developers were estimating their code they had to do so with the agreement that it would conform to the Definition Of Done.
Definition Of Done can include:
- Does it meet the acceptance criteria on the ticket.
- Does the code have adequate test coverage, e.g. unit tests.
- Has the code been reviewed by someone else on the team.
- Has the code been merged the required branch, or is the pull request marked as ready.
- Do the commits in the branch belong to one commit (e.g. squashed), or has the branch been merged with for example a rebase.
- Is there adequate documentation for the code or deploying it.
- Has the code passed CI.
- someone from QA has looked at it and agreed it’s ok.
- Is the code of the required quality by passing a style checker etc.
In addition to the amount of work each week from development, it is usual that there would be a wider team meeting, at least every two weeks,and part of this would be to keep the team up to date with the tickets that were about the be released, and to discuss for example, what client that would affect. There could also be quarterly review meetings to keep people informed of how that fit into the roadmap. Some teams also could pick out KPI’s for each quarter.
Kanban is not mentioned here, although it is a framework in itself, Kanban can be used just as an additional estimation/visualisation tool. It involves writing down tickets on sticky notes and placing them into columns, e.g. backlog, development, testing, done, deployed so that the Scrum team had a better idea of what was happening and if there would be any potential blockers. There are many ticketing/planning tools which can be used in which a version of this Kanban board can be used. There can be a physical one and an online ticket system and they can be used in conjunction.
Scrum has been around a while now, and the Kanban baord was a part of Scrum before it was called the Kanban board, that’s why it is possible to see that there are lot’s of differenences in between using a different framework exclusively. For example I guess it would be possible for a team to say, we are just using Kanban and that’s about continuous improvemnt. At 37Signals they have developed a new framework called Shape Up, you can read about ShapeUp here.