What is Agile?
Agile is the new black. You hear about it everywhere, and it gets worse: you hear Scrum, Kanban, and your head starts spinnin′.
That′s what′s happened to me, so I decided to figure stuff out.
As you may guess, “agile” has something to do with being quick, mobile and flexible. Indeed, Agile software development unites several methodologies that function on 12 basic principles that mostly imply “communication” , “adaptability to change” and “continuous improvement” .
The Agile methodology principles are listed in what′s pompously called “The Agile Manifesto” .
Quoting Martin Fowler, one of the initial signatories: “In February 2001 a group of seventeen software pundits got together in Snowbird UT to discuss the growing field of what used to be called lightweight methods.” They did some heavy thinking and held a discussion on the tendencies and best practices of software development.
Dave Thomas, another signatory, gave a very curious interview, where he described the summit: “There were 17 people and everyone had their own ax to grind and their own particular viewpoint on what was best. And within a couple of hours, we′d come up with a way of working that let us discuss the principles behind what we were doing without going into the details.” Here′s what they came up with:
We 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.” Sounds nice, right? Here′s the original: http://agilemanifesto.org/ (you can also find the 12 principles there).
It′s important to understand the idea behind the very last phrase in the quotation. There′s a misconception that the Agile Manifesto creators rejected methodologies, planning and documentation, which is not true. On the contrary, they wanted the methodologies to respond to the reality of software development, i.e. to be open to change that is inevitable on all stages of the process, to guarantee effective communication between everyone involved and, ultimately, to deliver the software that really works.
The next step was forming the Agile Alliance, which issued the Guide to Agile Practices in 2011. It′s, essentially, a “comprehensive list of Agile practices” . You can go into further research here.
Agile Methodologies
Agile methodologies are quite numerous. It′s important to understand that Agile isn′t just a methodology, it′s a group of methods united by some basic principles and common ideas. There′s also a slight difference between a “methodology” and a “framework” . A methodology is a set of principles, tools, and practices which can be used to guide processes to achieve a particular goal. A framework is a loose but incomplete structure which leaves room for other practices and tools to be included but provides much of the process required. You can read more here.
For your convenience, here′s a list to give you a basic idea (with links) :
- Adaptive software development (ASD)
- Agile modeling
- Agile Unified Process (AUP)
- Crystal Clear Methods
- Disciplined agile delivery
- Dynamic systems development method (DSDM)
- Extreme programming (XP)
- Feature-driven development (FDD)
- Lean software development
- Kanban (development)
- Scrum
- Scrum-ban
You′ve probably heard about the last four, and you definitely heard about Scrum.
How Scrum Appeared
So, getting closer to the actual topic of the article: Scrum.
Ken Schwaber and Jeff Sutherland, the initial signatories of the Agile Manifesto, formulated Scrum as a way to incarnate the Agile principles in 1995. Both used what would become Scrum in their companies first.
Out of all the Agile methodologies, Scrum is probably the most popular and renowned one. This is why so many people confuse Agile and Scrum and find it difficult to distinguish between the two: Scrum has become the unspoken standard of Agile development.
It′s important to understand that Scrum is not actually a very detailed methodology, it′s mostly a framework that defines the main roles, activities and artifacts in the process of software development. Most teams have to incorporate some features from other methodologies
How Scrum Works (on paper)
Basically, it all boils down to iterations (also called sprints) – short periods of time (1-4 weeks; 2 weeks are probably the most popular/convenient duration), or time boxes, by the end of which some piece of working software is presented. It′s not the final version of the product (mostly), but it′s something that can be demonstrated to the stakeholder. The whole project is a sequence of such iterations.
There are three main roles in Scrum: Product Owner, Development Team and Scrum Master.
- The Product Owner is a representative of the customer. He/she articulates what he wants to get from the product/feature and defines the guidelines for the team. For example, as a system user, he/she wants to see a report where all the payments can be found, sorted out by week, where on the left there would be an “amount” column, and on the right there will be the payment description; it should be PDF printable, etc. It′s called the acceptance criteria, i.e. the requirements that have to be met for the project to be considered successfully completed (more here). These criteria become the Product Backlog Item (see Scrum Artefacts). The items are prioritized based on the importance of the feature/ how difficult it is to develop the feature/ how much time it will take (more details here).
- The Product Backlog Item gets into the sprint, and the work of the Development Team begins. The work is broken down into tasks, and each team member takes on some task based on their abilities.
- The Scrum Master is responsible for ensuring effective communication between the team members and between the team and the product owner (stakeholders), so that the team can just focus on getting their job done. He conducts the daily Scrum meetings (see Scrum Activities). There are multiple ways of how a person becomes a Scrum Master, here′s a nice post on how a Scrum Master is chosen.
According to the Scrum Alliance, Scrum features three tangible artefacts:
- Product increment – an integrated, transportable subset of the product
- Product backlog – the list of ideas for the product, in order of priority
- Sprint backlog – the detailed plan for development during the next sprint
The team displays its plans and progress so that all team members and stakeholders can always see what the team is accomplishing.
As you see, there are two different types of backlogs. The Product Backlog Items make the Product backlog and are then broken down into smaller bits, which become tasks that each team member accomplishes (in the Sprint backlog).
A Sprint Backlog is usually just a blackboard that has a set of product backlog items on it. There are several columns: one for the tasks that need to be accomplished, one for the tasks in progress, one for the tasks that are complete (there can also be an additional column for completed tasks that need to be checked again).
Each sprint then can be seen as a certain amount of work: the team takes up as much work as they can possibly complete in, say, 2 weeks (for the teams with two-week sprints). As one feature gets completed, the team shifts to the next one).
Finally, Scrum includes five activities or meetings:
- Product backlog refinement
- Sprint planning
- Daily Scrum
- Sprint review
- Sprint retrospective
After the planning and refinement is done, the work begins. To ensure that everything runs smooth, there are Daily Scrums – meetings where the whole team discuss their progress under the supervision of the Scrum Master. The objective is to identify problems before they start presenting any danger to the overall success – each member of the team is responsible for the final result, that′s why they try to solve the problems as soon as possible and move on.
When the sprint′s over, a sprint review (team and stakeholders) and a sprint retrospective (team) take place, both taking about an hour for one-week sprints, two hours for two-week sprints, etc.
Everything is described in greater detail here.
Scrum Best Practices (+ examples)
Now, we live in the real world, don′t we? What looks good on paper doesn′t always work the same way when faced with real-life situations.
I interviewed our team, and here′s what they have to say about using Scrum on a daily basis:
1. Not all the tasks are created equal
When product backlog items get into the sprint, the team starts breaking it into tasks that each team member is able to accomplish. Then, each member takes up a task (this is how it should be). In reality, not every team member is equally good in terms of performing a certain task (writing code, or doing HTML-markup, etc.), not all the tasks are equal, etc.
2. It′s hard to follow the initial plan/schedule
There is NO way to say exactly what you will be doing at a particular moment. This happens because:
- There is always unplanned work that distracts the team from the initial plan. Usually, this work comes from the clients, who can suddenly require minor (or major) customizations, whose performance suddenly drops or whose systems suddenly crash. These types of problems should also be solved really quickly because there′s no way someone would want to let their clients down.
- It′s hard to preserve a “clear” flow.
How it should be: When one feature is finished, the next one starts, each feature finished by the end of the sprint.
Reality: Sometimes one has to work on several features at once. The team can get time estimates wrong. Then “Wow, we didn′t consider some dependencies” happens. Result: the feature′s not ready by the end of the sprint, APOCALYPSE.
3. It′s time-consuming
Planning takes A LOT of time. Actually, the whole thing does. If the sprint takes two weeks, at least one day is spent on planning, and then there are demos, then meetings” ¦ Let your imagination fill in the rest.
4. Scrum was designed for 7 ±2 teams (5,7,9). Which is not exactly what all the teams look like. This is an issue for several reasons:
- If you decide to keep your team as it is, scrum won′t work – it′s too hard to keep focus. Daily meetings don′t usually require all the team members to be present, but they still have to, and they feel they are wasting time. By the time the last person describes what he/she′s done, everybody forgets what was told before.
- If you decide to break your team down to smaller teams, communication becomes a problem. Additional meetings/conversations are required to coordinate the work of the teams. Plus, not all the team members exist in doubles, some are plain irreplaceable 🙂
However, as I mentioned before, Scrum was developed as a framework that each team develops and tunes according to their own needs. What matters is the continuous communication, teamwork and collective responsibility, adaptability to change and a working product in the end.
Scrum is not an “answer to all the questions” ; even Jeff Sutherland, it′s creator, agrees that “The best Scrum teams implement XP engineering practices inside the Scrum. The best XP teams wrap Scrum around XP as it allows them to scale and take advantage of the high performance gains possible with Scrum.” (Quora)
Follow us
