Agile is a process of software development. In the past you had waterfall, LEAN, RAD, XTreme and many others and although those still float around (especially Waterfall), most people will say they are doing Agile even if they are not. So, understand going in, it is rare that any two implementations of Agile “follow the book” or resemble each other. Most, and rightfully so, are customized tot he business and methods used by the team. That said, lets get some definitions out of the way.
Agile comes in two large flavors, SCRUM and KANBAN. SCRUM is the most common but I have a thing for KANBAN. KANBAN is, at its most basic, a backlog of tasks that move through a series of steps and each step has a maximum an dminimum number of tasks that can be in that column at one time. If you get too many, say, “In Progress” then you probably do not have enough bandwidth (read developers) and if you have less than the minimum then you have a lack of work feeding the backlog. This can make for a difficult to predict completion dates. Project managers and bosses do not like that. More on KANBAN in Part 2.
SCRUM, on the other hand, is broken into sprints (usually 2 weeks in length), then loaded with tasks and assigned out to developers to complete. This is a team effort that involves business stakeholders, a team lead called a SCRUM Master and the developers. In the end, you should have an easier time saying “We will complete X work by Y date”. This makes bosses and Project managers happy and so you usually see SCRUM implementations.
My bias is for KANBAN for the simple reason that it allows you to optimize process, I mean really get in there and analyze what is going right and what is going wrong, and do so in a non-pressure environment. You get speed and it just goes faster and faster if done correctly. Most folks will argue that you should only use it for managing support since it is not a time-blocked method. Those people are usually Project managers and bosses. 😉
What we do Everyday
Alright, that out of the way, let’s look this over. First, we will start with the most popular by far, SCRUM. Scrum comes from Rugby but roughly refers to the daily scrum (standup) that a group has in order to share three things:
- What did you accomplish yesterday
- What are you going to accomplish today
- What is in the way of you accomplishing there goals
Your personal statement of the above should not exceed 5 minutes, the overall should be less than 15 minutes for the group. Note, I said should. It happens but not often. I have had mixed experiences with daily standups. Some are absolutely useful, other groups do much better with just the lead (SCRUMmaster) walking around and talking with each member of the team and others yet, do better with weekly scrums. This has to do with the rhythm (cadence) that the group works at.
SCRUM has some moving parts. First is the task which I am sure you are all aware of. Second is a Sprint made up of a number of made up of a number of tasks. These tasks will have Story Points assigned to them and the Sprint will be loaded with an amount of Story Points that reflect the amount of work the team can complete in the agreed time for the Sprint. Clear as mud right? 😉
Story points are a point of contention in that they are never nor ever will be clearly defined. Certain Agile experts will say “OMG!!!! YOU are the problem!!! Story Points are clearly defined!!!” and then go on to vaguely define them as a unit of work * the risk of overruns. The best way I have found to look at Story Points (some folks just use hours of work) is to use what I call the Scotty Principle. Whatever you and your Product Owner (the business guy who knows what the end product should look like) and your SCRUM Master agree is a story point, double it and then expect to over shoot it.
It has been estimated that your team can handle 45 SP per 2 week sprint (about 15 per dev on your 3 man team). You have 5 x-small tasks (we will cover t-shirting later) at 1 point per task, and two medium tasks at 5 SP a piece. A small task may be a conf change to an Apache server or deployment of a WAR to a tomcat server. A medium task might be the writing of a service to create a shopping cart in the app (hint: it might also be large depending on the requirements).
Who are the players
Scrum Master – this is the person in charge of making sure the sprints happen in a timely manner, eliminates the blockers keeping you from completing your tasks, and generally functioning as a project manager for the effort.
Product Owner – this is the person who owns the business parts of the effort. They do not set the cadence (how fast the sprints run) or set the Story Points for the tasks, but feeds the requirements and sets the priorities for the tasks. For instance, they would say that the Conf change on the Apache server is highest priority while the new service for creating the cart is only a medium priority. They build out the backlog of that the team and scrum master can pull from to build sprints.
The Team – This is a group of developers, usually with the full range of skills from BA to QA to Dev to DevOps. They should be able to do it all but quite often, they are limited to coders with the usual range of QA and BAs mixed in. Regardless of the make up of the team, they will meet (called a scrum of scrums) to hash out how much they can do, the number of SP they can accomplish and what impediments that sprint will face.
Sprint – Sprints are some period of time that the team has agreed to, often it is two weeks. This is the time that development will take place. Some sprints can be a month in length or any amount of time that the team agrees to. Sprints are supposed to represent a complete piece of functionality such as a baseline, or a feature that can be released to production at the end of the time frame agreed to.
Cadence – Cadence is the frequency of the sprints reflected int heir duration. For example, team that releases every sprint and every sprint is 2 weeks, then the cadence is 2 weeks. However, you can have a release to production every 3 sprints and that would mean a cadence of 6 weeks.
Release – Releases are at the end of sprints. They are usually reflective of a feature or group of features that are complete and ready for review by the Product Owner as a candidate for Release to Production.
Release to Production – It is the gate that the Product Owners controls to release code when he thinks it is a complete product. This can happen when the Product Owner is waiting for a baseline list of features in a product, for example.
Retrospection – This usually happens at the end of a Sprint. It is exactly what it sounds like, a look back at the sprint to see what has worked and what has not.
Sprint Planning (Scrum of Scrums) – This is where the team gets together and plans the next two weeks,estimates the number of Story Points they have available for the sprint and what each task estimated effort is (assign Story Points to tasks). The Scrum of Scrums happens at the beginning of a project and sometime in the middle for adjustment purposes. This is where the team gets together and plans out multiple sprints and how the releases will fit together. You do not want to release your sign-on apps after you have the eCommerce released.
Story Points – Yeah, these are a real problem for most folks. The best I have been able to communicate to non-Agile thinkers is to think of them as Units of Work x Risk factor. So, common progressions a doubling (1, 2, 4, 8, 16) and Fibinocci (1, 2, 3, 5, 8, 13) but at the end it is easiest to think of it as x-small, small, medium, large and x-large. You can add more to the ranges for larges sizes but you should probably look at breaking those tasks up first. There are also a wide variety of processes for assigning these (Look up Agile Poker) but I prefer good old fashioned estimating. And no, everything cannot be a 16. 😉
Priority – Priority is the importance to the business and it is set by the Product Owner. This is not law in terms of how tasks are pulled off the backlog but they are important. The business may think that credit card processing is more important than e-payment, and thus credit card priority gets set higher.
Ranking – Ranking is done by the dev team and this is used for them to order their work. It is not always set but it can be useful to know that the credit card service will be available before the forms are written.
Backlog – The Product Owner puts tasks into the backlog. It is just what it sounds like, a list of tasks, assigned a priority and given detailed requirements (including completion criteria and expected outcome). These are then able to be pulled to In Progress as developers become available.
SCRUM is a useful process and can be and orderly way of approaching development…..or it is a bat to beat the developers with. It is not a coincidence that Cadence is the same word used to refer to the beat of a drummer setting the oar stroke on a Roman Slave Trieme. With that caution, I will say I have worked comfortably on SCRUM teams that understand that you do not just raise the Cadence to get faster work out of the team. You need to work as a team to understand what capacities are and review the total Story Points that a Sprint can sustain. If the SCRUM Master pushes the team’s Sprint totals from 20 to 30, they need to be able to go back to the team and explain why the total increased. In a HEALTHY team, the SCRUM Master should sit down with the team and in a Retrospection, review if the team easily completed the 20 SP or did they struggle. If they completed with ease, then an increase may be in order, if the struggled, perhaps a decrease.
Agile is supposed to be a better way, an I truly believe it is, but only if it is done right. The team needs to trust the business stake holders, and the stake holders must trust the team. If either party starts to lie (inflating SP estimates, ranking all tasks the highest priority) then trust fails and so will SCRUM. A point you will sometimes here about Agile is that it IS TRUST.