What is Agile?
Agile has become a very common term within the software development industry. So what is agile? Some of the concepts of agile software development have been around from the early days of software development but as a cohesive concept, agile software development was defined by the creation of a very short document called The Agile Manifesto included below.
“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.
Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler James Grenning Jim HighsmithAndrew Hunt Ron Jeffries Jon Kern Brian Marick Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas
© 2001, the above authors this declaration may be freely copied in any form, but only in its entirety through this notice.”
The Agile Manifesto promotes the importance of individuals and interactions, working software, customer collaboration, and responding to change. These tenets of agile software development define the goals and intentions of using an agile methodology, but they are very non-specific about how to go about achieving these goals. There are numerous methodologies that different individuals, groups, and companies have come up with to document a specific implementation of a set of rules to accomplish the goals of the Agile Manifesto. Some of the most prominent implementations are probably recognizable to anyone who has heard about Agile before including Scrum, Kanban, Extreme Programming, Adaptive Software Development, and others. There are also numerous agile concepts that cross multiple implementations of agile software development including backlogs, sprints, cross-functional teams, iterative and incremental development, pair programming, planning poker, user stories, retrospectives, velocity tracking, and much more. The important thing to remember when you hear that someone is “using agile,” is that their goals should be centered around individuals and interactions, working software, customer collaboration, and responding to change.
Classy Llama’s Implementation
Because of the wide variety of practices surrounding agile software development, there is a great deal of variety and inconsistency about what a company means when they say they build software using an agile methodology. To combat confusion and help answer the question of “what does Classy Llama mean when they talk about agile?”, I am going to document a number of the most important pieces of our implementation of agile software development. I will not be discussing every single thing that we at Classy Llama do to implement agile nor will this blog post always match what we do on every project, but my goal is to document some of the things that we at Classy Llama prioritize and emphasize when doing software development.
As we endeavored to implement agile as a company, we found that many of the traditional agile training, books, and coaching available were designed for people building a product instead of those doing very targeted custom development for a broad range of clients. This has caused us to implement pieces of agile whenever possible while being very open to the possibility that a particular brand of agile development may not work for our clients. It would even be fair to say that our implementation of agile has been an agile process. One of the things that were really challenging at first was that we did not have a comprehensive set of guidelines handed to us as we switched from waterfall to agile project management. We simply began following some agile processes, and as people mastered those, we introduced a few more, and a few more, and a few more. This has at times led to resistance from people who prefer to have everything well documented and clear before doing anything. Ultimately though, I am proud to say that our transition to agile went very smoothly.
Below, I detail the agile practices that are most closely linked to the day to day process of working with the project management and development teams and moving your project forward. I may in a future blog post detail some of the methodologies that we use to track a project’s progress vs. the plan and how we learn and build our process iteratively from project to project.
Backlogs and Sprints
Probably the most client visible agile practices that we use are backlogs and sprints. A backlog is a prioritized list of features. It should encompass all features that are needed to complete the project at any given time. Estimates and details associated with these features help us to have conversations about priority and planning for the project. This backlog gains definition as a project moves forward. Initially, this backlog starts with a list of items taken directly from a proposal which was delivered to a client merged with a list of the basic tasks that every website build needs in order to launch successfully. This often ends up being as much as 70% or more of what the backlog will contain over the course of the project. It is important to understand, that this backlog is not a fixed list. It changes as tasks gain more definition (splitting one task into multiple), as new tasks are discovered, as tasks are completed, and as tasks are deemed unnecessary. The goal of using this backlog is to have a central place to document all of the features that a project will include. We use the backlog to sort things by priority and have a central place to pull development tasks from as well as to track the estimated amount of time remaining on the project against the budget for the project.
Sprints are inextricably linked to the backlog. Without sprints, the backlog would only grow in size and definition. This is where one of the key differences between a waterfall and an agile methodology comes to the surface. Using agile, you could use something similar to a backlog, but you would be building it to what was considered completion before starting any development. When we introduce sprints, the backlog is growing, changing, and resorting while we are completing items contained within it. A sprint is an instance of an agreed upon period of time that is designated for completing the next most important features from the backlog. This means that if Classy Llama and a given client agree that two-week sprints will be best for moving a project forward, in the first sprint, we will spend two weeks working on the most important items for the completion of the project that we have sufficient information to work on. These items will be pulled from what is considered the top of the backlog and will be put into the sprint during the sprint planning meeting which proceeds the sprint. So if we are going to be doing twelve days of development (between all developers) during the first two-week sprint, we will put as many of the items on the top of the backlog into the sprint as we estimate will fit into twelve development days.
User Stories
We have talked about the backlog and sprints, both of which are made up of tasks. A task is a single item which can be identified and estimated independently that corresponds to a feature, bug fix or another work item. The user story is one tool that we use to clearly define a task’s goal and purpose. A user story is defined as a sentence with three major components. The components of the user story, in order, are the who, the what, and the why. These three components are placed into a template to create what we know as a user store. “As a[n] ____________, I want ____________ so that ____________.” For example, say there is a situation where a merchant wants to capture a customer’s employee identification number to allow verification of an employee’s status as a purchasing representative for the company. A potential user story to describe this situation would like something like this: “As a customer, I want to be able to easily verify my identity on the website so that I do not have to call or email identification before I can purchase items on the website.” After seeing the previous user story, you may be thinking that you were expecting it to talk from an entirely different perspective. The same situation can absolutely be described from different perspectives. Another user story representing the same situation might be: “As a website administrator, I want to be able to easily gather employment verification information so that I can quickly verify employment status without having to take additional, unnecessary steps.” Interestingly, both of the above user stories have told a relatively similar story, but there is one key difference between them. In the first user story, it is implied that the customer will likely be the one who would have to call or write providing verification before they can shop. However, the second story indicates that the burden of verification would typically fall on the website administrator. There are situations where both of the user stories may be helpful in accurately describing the purpose for this feature. There is at least one other distinct user story that could be told about this task that would drastically alter the context around the task. “As a manager, I want to be able to easily see information about the employees that are allowed to purchase items on my company’s behalf, so that I can appropriately track and administer employee activities.” In this user story, the context is totally different. This is no longer a field used to simply pass information back and forth between the customer and website administrator. There is now a company administrator that is likely involved in the verification process directly on the website. This user story may be related to a larger user story that talks about a larger set of features being developed like: “As a manager, I want to have a portal to track my employee’s use of this website’s purchasing features so that I can approve, track, and manage their activities.” User stories are a tool that not all of our clients use but can be very helpful for the client to be able to communicate context to us or for us to be able to demonstrate an understanding of the context for a task to our client.
Conclusion
Agile is a huge topic and not something that I can cover in a single blog post. I have talked about how agile is largely a mindset around software development, how everyone using agile means something slightly or drastically different when using the term, and how we use backlogs, sprints, and user stories to organize and communicate with our clients what the most important things on their project are. The most important reasons we choose to use agile are (1) to increase visibility and (2) to simultaneously decrease risk for our clients and our company. We have found that agile has helped us to do this by eliminating unnecessary items from the project and making sure that the most important items are done first. By giving our clients the tools to guide the direction of their project as the needs of the business change and are clarified over the course of the project, we have been able to build more successful projects and come in on budget and on time more consistently and reliably.