In my prior blog post, Understanding Software Development Methodologies, I highlighted the two most common methodologies for managing software development projects, Waterfall and Iterative, including Agile. In this post I’m going to discuss three of the most common Agile frameworks, Scrum, Kanban and Extreme Programming (XP).
Scrum is an agile project management framework that helps teams work together more effectively. When we hear about scrum, it most often refers to software development teams. But its principles and lessons can be applied to all types of teamwork. In fact, the scrum framework is used by product development, marketing, finance, HR teams and more.
Scrum describes a set of meetings, tools, and roles that work to help teams structure and manage their work. The term scrum is borrowed from rugby, where a scrum is a formation of players. This term was chosen because it emphasizes teamwork.
The Scrum Framework
People often think scrum and agile are the same thing because scrum is centered around continuous improvement, which is a core principle of agile. However, scrum is a framework for getting work done, where agile is a mindset. You can’t “go agile”overnight as it takes dedication from the entire team to change the way they think about delivering value. But any team can use a framework like scrum to help you start thinking agile and to practice building agile principles into your everyday workflow.
The scrum framework is heuristic, it’s based on continuous learning and adjustment to fluctuating factors. It acknowledges that the team doesn’t know everything at the start of a project and will evolve through experience. Scrum is structured to help teams naturally adapt to changing conditions and user requirements. Reprioritization is built into the process in the form of sprints, or short release cycles. A sprint is when the design team works together to finish an increment of the project. This allows teams to constantly learn and improve.
Scrum uses three artifacts to help manage work. Artifacts are work products that teams make like a tool, test case, design specification document or a traceability matrix. In scrum, the three artifacts that manage work are a product backlog, a sprint backlog, and potential releasable product increments. These are the three constants that scrum teams continue to revisit and invest in over time.
The product backlog is an ordered list of everything that is known to be needed in a product based on the product goal. It is constantly evolving and is never complete. The product backlog includes the primary list of work that needs to get done. This is a dynamic list of features, requirements, enhancements, and fixes that act as the input for the sprint backlog. It is the team’s “To Do” list. The product backlog is constantly revisited, re-prioritized and maintained by the Product Owner because, as teams learn more or as the market changes, items may no longer be relevant or problems may get solved by other means.
The sprint backlog is a list of everything that the team commits to achieve in a given sprint. Once created, no one can add to the sprint backlog except the development team. Before each sprint, in the sprint planning meeting the team chooses which items from the product backlog it will work on. A sprint backlog can evolve during a sprint. However, when teams decide on what they want to achieve from the current sprint, this fundamental sprint goal cannot be compromised.
Potentially Releasable Product Increment (Sprint Goal)
At the end of every sprint, the team delivers a product increment that is potentially releasable. This means that it meets their agreed-upon definition of done. For example, a team might define “done” as fully tested and fully approved. It just depends on how the team defines “done” and how you define your sprint goals. For example, some teams choose to release something to their customers at the end of every sprint. So their definition of ‘done’ would be ‘product shipped’. However, this may not be realistic for other teams.
The more well-known components of the scrum framework are the set of sequential events, which can be called ceremonies or meetings, that scrum teams perform on a regular basis. They include the following:
- Organize the Backlog: Sometimes known as backlog grooming, this event is the responsibility of the product owner. The product owner’s main jobs are to drive the product towards its product vision and have a constant pulse on the market and the customer. Therefore, he/she maintains this list using feedback from users and the development team to help prioritize and keep the list clean and ready to be worked on at any given time.
- Sprint Planning: This is a meeting where the entire development team plans the work that will be performed during the current sprint. The scrum master leads the meeting and the team decides on the sprint goal. Specific user stories are then added to the sprint from the product backlog. A user story is an informal, general explanation of a software feature written from the perspective of the end user. Its purpose is to articulate how a software feature will provide value to the customer. These stories are intended to be short descriptions of things users want to be able to do with the product that can be used for planning. These stories always align with the goal and there is consensus among the scrum team that the stories are feasible to implement. At the end of the planning meeting, every scrum member needs to be clear on what can be delivered in the sprint and how.
- Sprint: A sprint is the actual time period when the scrum team works together to finish an increment. Two weeks is a pretty typical length for a sprint, though some teams find a week to be easier to scope or a month to be easier to deliver a valuable increment. All the events — from planning to retrospective — happen during the sprint. Once a certain time interval for a sprint is established, it has to remain consistent throughout the period. This helps the team learn from past experiences and apply that insight to future sprints.
- Daily Scrum or Stand Up: This is a super-short daily meeting that happens at the same time and place. Many teams try to complete the meeting in 15 minutes, but that’s just a guideline. This meeting is also called a ‘daily stand-up’ emphasizing that it needs to be a quick one. The goal of the daily scrum is for everyone on the team to be on the same page, aligned with the sprint goal, and to get a plan out for the next 24 hours. The stand up is the time where team members voice any concerns with meeting the sprint goal or any blockers.
- Sprint Review: At the end of the sprint, the team gets together for an informal session to view a demo or inspect the increment. The development team showcases the backlog items that are now ‘Done’ to stakeholders and teammates for feedback. The product owner can decide whether or not to release the increment. In most cases, the increment is released. This review meeting is also when the product owner reworks the product backlog based on the current sprint, which can feed into the next sprint planning session.
- Sprint Retrospective: The sprint retrospective is where the team comes together to document and discuss what worked and what didn’t work in a sprint, a project, people or relationships, tools, or even for certain ceremonies. The idea is to create a place where the team can focus on what went well and what needs to be improved for the next time.
Three Essential Roles for Scrum Teams
A scrum team needs three specific roles: product owner, scrum master, and the development team. And because scrum teams are cross-functional, the development team includes testers, designers, UX specialists, and ops engineers in addition to developers.
The Scrum Product Owner
Product owners are the champions for their product. They are focused on understanding business, customer, and market requirements, then prioritizing the work to be done by the engineering team accordingly. Effective product owners:
- Build and manage the product backlog.
- Closely partner with the business and the team to ensure everyone understands the work items in the product backlog.
- Give the team clear guidance on which features to deliver next.
- Decide when to ship the product with a predisposition towards more frequent delivery.
The product owner is not always the product manager. Product owners focus on ensuring the development team delivers the most value to the business. Also, it's important that the product owner be a single individual. No development team wants mixed guidance from multiple product owners.
The Scrum Master
Scrum masters are the champions for scrum within their teams. They coach teams, product owners, and the business on the scrum process, and look for ways to fine-tune their practice of it. An effective scrum master deeply understands the work being done by the team and can help the team optimize their transparency and delivery flow. As the facilitator-in-chief, he/she schedules the needed resources (both human and logistical) for sprint planning, stand-up, sprint review, and the sprint retrospective.
The Scrum Development Team
The scrum development team are the champions for sustainable development practices. The most effective scrum teams are tight-knit, co-located, and usually five to seven members. Team members have differing skill sets, and cross-train each other so no one person becomes a bottleneck in the delivery of work. Strong scrum teams are self-organizing and approach their projects with a clear ‘we’ attitude. All members of the team help one another to ensure a successful sprint completion.
The scrum team drives the plan for each sprint. They forecast how much work they believe they can complete over the iteration using their historical velocity as a guide. Keeping the iteration length fixed gives the development team important feedback on their estimation and delivery process, which in turn makes their forecasts increasingly accurate over time.
The scrum framework itself is simple. The rules, artifacts, events, and roles are easy to understand. Its semi-prescriptive approach actually helps remove the ambiguities in the development process, while giving sufficient space for companies to introduce their individual flavor to it.
The organization of complex tasks into manageable user stories makes it ideal for difficult projects. Also, the clear boundaries of roles and planned events ensure that there is transparency and collective ownership throughout the development cycle. Quick releases keep the team motivated and the users happy as they can see progress in a short amount of time.
While Scrum has many positive benefits, it can take time to fully understand, especially if the development team is accustomed to a traditional waterfall model. The concepts of smaller iterations, daily scrum meetings, sprint reviews, and identifying a scrum master can be a challenging cultural shift. But, the long-term benefits far outweigh the initial learning curve.
Kanban is the Japanese word for "visual signal." Kanban is a popular framework used for implementing agile and DevOps software development. It requires real-time communication of capacity and full transparency of work. Work items are represented visually on a kanban board, allowing team members to see the state of every piece of work at any time.
The work of all kanban teams revolves around a kanban board. This board is an agile project management tool used to visualize work, optimize workflow among the team and maximize efficiency. It also limits work-in-progress, and ensures all blockers and dependencies are immediately identified and resolved. While physical boards are popular among some teams, virtual boards are a crucial feature in any agile software development tool. Virtual boards allow for easier collaboration, traceability and accessibility.
Regardless of whether a team's Kanban board is physical or digital, they follow a three-step workflow: To Do, In Progress, and Done.
Kanban boards use cards, columns, and continuous improvement to help technology and service teams commit to the right amount of work.
Elements of a Kanban Board
Kanban boards can be broken down into five components: visual signals, columns, work-in-progress limits, a commitment point, and a delivery point.
- Visual Signals — One of the first things you’ll notice are the visual cards (stickies, tickets, or otherwise). Kanban teams write all of their projects and work items onto cards, usually one per card. For agile teams, each card could encapsulate one user story. These visual signals help teammates and stakeholders quickly understand what the team is working on.
- Columns — Each column represents a specific activity that together compose a “workflow”. Cards flow through the workflow until completion. Workflows can be as simple as “To Do,” “In Progress,” “Complete,” or much more complex.
- Work In Progress (WIP) Limits — WIP limits are the maximum number of cards that can be in one column at any given time. A column with a WIP limit of three cannot have more than three cards in it. When the column is “maxed-out” the team needs to swarm on those cards and move them forward before new cards can move into that stage of the workflow. These WIP limits are critical for maximizing workflow and exposing bottlenecks. WIP limits give you an early warning sign that you committed to too much work.
- Commitment point — Kanban teams often have a backlog for their board. This is where customers and teammates put ideas for projects that the team can pick up when they are ready. The commitment point is the moment when an idea is picked up by the team and work starts on the project.
- Delivery point — The delivery point is the end of a kanban team’s workflow. For most teams, the delivery point is when the product or service is in the hands of the customer. The team’s goal is to take cards from the commitment point to the delivery point as fast as possible. The elapsed time between the two is called Lead Time. Kanban teams are continuously improving to decrease their lead time as much as possible.
Extreme Programming (XP)
Extreme Programming (XP) is an agile software development framework that is designed for improving the quality of the software, the development team’s work process, and customer satisfaction. It is a method devised for a smoother and efficient software development life cycle (SDLC).
Extreme Programming works towards providing iterative and recurrent software releases throughout the project, rather than delivering everything together after a single, long project development lifecycle.
These short iterative cycles help both team members and customers to assess and review the project’s progress throughout its development.
XP is guided by five core principles:
Software development is inherently a team sport that relies on communication to transfer knowledge from one team member to everyone else on the team. XP stresses the importance of the appropriate kind of communication. This mostly means face to face discussions with the aid of a white board or other drawing mechanism.
Simplicity means “what is the simplest thing that will work?” The purpose of simplicity is to avoid waste and do only things that are absolutely necessary things. This often means keeping the design of the system as simple as possible so that it is easier to maintain, support, and revise. Simplicity also means addressing only the requirements that you know about; engineers should not try to predict the future.
Feedback plays an important role in project improvement. XP encourages instantaneous feedback. This helps the team identify room for improvement and revise practices.
Kent Beck, the creator of Extreme programming, defined courage as “effective action in the face of fear.” This definition shows a preference for action based on other principles so that the results aren’t harmful to the team. Team members need courage to raise organizational issues that reduce a team’s effectiveness. Team members need courage to stop doing something that doesn’t work and try something else. Team members need courage to listen to and act on feedback, even when it’s difficult to accept.
The members of a team need to respect each other in order to communicate with each other. They also need to provide and accept feedback that honors the relationship, and work together to identify simple designs and solutions.
The core of XP is an interconnected set of software development practices. While it is possible to implement these practices in isolation, many teams have found that some practices reinforce the others and should be done in conjunction. This can enable fully eliminating the risks you often face in software development.
Since communication is one of the five values of XP, and most people agree that face to face conversation is the best form of communication, have your team sit together in the same space without barriers to communication, such as cubicle walls.
A cross functional group of people with the necessary roles for a product form a single team. This means people with a need and all the people who play a part in satisfying that need all work together on a daily basis to accomplish a specific outcome.
Set up your team space to facilitate face to face communication. Allow people to have some privacy when they need it, and make the work of the team transparent to each other and to interested parties outside the team. Utilize Information Radiators to actively communicate up-to-date information.
Pair Programming means all production software is developed by two people sitting at the same machine. The idea behind this practice is that two brains and four eyes are better than one brain and two eyes. You effectively get a continuous code review and quicker response to nagging problems that may stop one person dead in their tracks.
Teams that have used pair programming have found that it improves quality and does not actually take twice as long because they are able to work through problems quicker and they stay more focused on the task at hand, thereby creating less code to accomplish the same thing.
User stories describe what the product should do in terms meaningful to customers and users. These stories are intended to be short descriptions of things users want to be able to do with the product that can be used for planning and serve as reminders for more detailed conversations when the team gets around to realizing that particular story.
The Weekly Cycle is synonymous to an iteration. In the case of XP, the team meets on the first day of the week to reflect on progress to date, the customer picks the stories they would like delivered in that week, and the team determines how they will approach those stories. The goal by the end of the week is to have running tested features that realize the selected stories. The intent behind the time boxed delivery period is to produce something to show to the customer for feedback.
The Quarterly Cycle is synonymous with a release. The purpose is to keep the detailed work of each weekly cycle in context of the overall project. The customer lays out the overall plan for the team in terms of features desired within a particular quarter. This provides the team with a view of the forest while they are in the trees to give them a zoomed out vision of the project.
Slack is a type of Agile practice in Extreme programming (XP) that enables sprints to yield consistent and high-quality results. Because building software products can be unpredictable, engineers need to build in slack, or buffers, to protect critical deadlines and allow their projects to proceed smoothly. Any task that can be instantly postponed indefinitely is slack. It’s far better to create a buffer to keep task completion on schedule rather than overestimate each task. Slack enables teams to deliver, even in the face of unexpected delays. Slack also builds trust with the customer or end users and eliminates waste.
The 10-minute build is an extreme programming practice where the code base is designed by the developer to be built automatically. The code base is also designed to test run in ten minutes or less. The 10-minute build derives its name from the amount of time required for the code base to finish running all tests. This practice encourages teams to automate their build process so they are more likely to do it on a regular basis and to use that automated process to run all of the tests.