Agility Practitioners

Agile and scrum 

The agile software development approach continues to grow in popularity and practitioner continue to get confused even more trying to navigate their way in it. The iterative, response nature of the approach can be very conducive to integrating ongoing research but doing so successfully can be a real challenge. 

Overview

Agile is an approach to developing software that became popular in the early 2000s. Traditional software development practices “Waterfall” called for an initial period of requirements gathering and design work, then a long development stage wherein requirements cannot be adapted to new learnings. 

A variety of software developers practitioners realized that this was not always the most effective way to build software that people really wanted and needed, and they began experimenting with methods to craft teams to work more efficiently and flexibly. The blending of these methods became the overall approach called agile. Agile is not a specific prescriptive process, but, rather, a shared set of values and principles that guide teams. The core values described in the agile manifesto are

1. individuals and interactions over processes and tools,

2. working software over comprehensive documentation,

3. customer collaboration over contract negotiation

4. responding to change over following a plan.

Also, there are then 12 principles spelled out in detail based on these values, outlining a commitment to satisfying customers and responding to feedback or changing environments, releasing working code on a regular basis, active collaboration across cross-functional teams, and relying on teams to work their own processes and outcomes to be the most effective. In practice, agile teams use a variety of specific frameworks to guide themselves. The most common framework is called Scrum & Kanban. Scrum teams are made up of individual contributors designing, developing, or building things, a tester, and a product owner who is responsible for representing both users and business stakeholders, and managing the backlog. The scrum master on the other hand helps facilitate the successful implementation of Scrum practices and is intended to remove barriers for the team. Scrum calls for teams to gather their work into a backlog, break down work into chunks called user stories or product backlog items and regularly estimate the effort to complete those stories, prioritize the most important elements, then plan work into short chunks of iterative time called sprints. 

Each sprint is recommended to be the same length, and, at the end of each sprint, the team should theoretically be able to ship anything they build. Scrum also defines a regular workflow cadence, including planning meetings at the beginning of every sprint cycle, daily stand-up meetings to check progress and plan the day to deliver everything in progress as fast as possible with high quality, reviews to demonstrate what was done at the end of each sprint, and retrospectives for the team to reflect on the prior sprint and discuss any process changes that need to be made. 

Each team sets its own definition of done, or standards set of acceptance criteria across stories. Code is only released if the product owner agrees that a story meets those criteria at the end of a sprint. Scrum prescribes meeting cadence and process but puts a large focus on the team to organize themselves, alter practices to best fit their context, and adjust to changing needs or requirements. This means that Scrum teams within different organizations and even within the same organization might operate differently.

There are other frameworks apart from Scrum and Kanban: -

You might already be aware by now that Scrum is not the only framework within agile. Other popular frameworks are Kanban, Extreme Programming, commonly known as XP, Feature-Driven Development, and Lean Product development, among many others. 

Each of these frameworks supports core agile values but suggest different specific processes. For instance.

Rather than prescribing roles in work cadence like Scrum, Kanban calls for a continuous flow of work and suggests limiting the number of items in progress, plus allows for releases as soon as an item is done. Some teams combine the time box concept of sprints and the team roles from Scrum, and the focus of limiting work in progress from Kanban.

When talking about agile practices, you will hear the terms Lean, Lean Product development, and Lean Startup. These terms also often get used interchangeably with agile but have some distinct elements. In general, the term Lean is used to refer to holistic business and management practices that aim to maximize customer value while minimizing waste. The approach is derived from Lean Manufacturing best practices and promotes organizational efficiency across entire value streams. Lean development was champion by Toyota motor company. 

There are seven core principles and several associated practices that focus on increasing efficiency and value, removing waste, and designing the system and teams in place to maximize those efforts. Meanwhile, the lean startup approach has gained popularity as a broader business and product development strategy. It pulls inspiration from lean manufacturing principles as well but also emphasizes incorporating cycles of experimentation to inform decisions and decrease the risks associated with moving into new directions. These are not mutually exclusive practices. 

Often, companies will embrace the ideas of including constant validated learning from the lean startup, approaches to reduce waste from lean, and may use any of the agile development frameworks to organize their teams and work structure. It is important to note that there is no one standard or correct implementation of these approaches and there is a definite variance between organizations and sometimes the teams. Regardless of specific practices, each agile environment will have self-organizing, cross-functional teams that focus on adapting to changing needs and frequently delivering valuable working code. 

Now it is common to see Waterfall development referred to as some evil type of way to develop a product, do not get confused. The waterfall is not evil at all.  There are definitely instances where doing something in a waterfall approach of software development is useful or even necessary where scrum, Kanban, or lean is not.