A DEFINITIVE GUIDE TO AGILE SOFTWARE DEVELOPMENT by a3 logics (the best books to read .TXT) 📖

so effective is the use of squads.

This chapter will take a further look into squad-based agile development, what it entails, and the benefits that squad-based agile development can bring to an organization looking to compete in today’s market.

WHAT IS A SQUAD?

Squads – a concept inspired by Spotify’s engineering culture – are small, flexible teams that are responsible for the end-to-end delivery of each product. Each squad has no more than 8 members, is cross-functional, plans together, and sits together. While “squad” is just a name for the way we organize our team, in practice it offers many advantages.

Each squad works in a collaborative, transparent environment and uses the strengths of each team member to get the highest quality product to market in the least amount of time. When combined, multiple squads make up a tribe. A tribe is considered a collection of squads within the same business area. For example, there can be a tribe focusing on mobile phones. As all While the size of a tribe varies based on the size and scale of an organization, there are usually less than 100 people per tribe.

THE BENEFITS OF SQUAD-BASED DEVELOPMENT

Intrinsic Knowledge

 

One of the biggest advantages of squads is that every member has full knowledge of every aspect of the project.

This makes knowledge transfer easy, eliminates silos, and allows the team to retain knowledge for product maintenance or future phases. Since the squad plans together, the developers, architects, designers, QA, and product owners are all aware of the roles and responsibilities of one another. This approach reduces both personnel risk and knowledge risk to help keep project velocity consistent and predictable.

Predictable Velocity

 

One of the most common risks in product development is time. As product needs evolve and new challenges arise, teams that aren’t flexible and adaptable struggle to meet deadlines. Since our squads plan together in relation to their capacity, share knowledge, and communicate frequently, they can remain flexible and adaptable. As a result, they can minimize downtime, rapidly overcome challenges, and offer predictable project velocity.

Faster Development

 

Squads allow us to reduce waste and minimize downtime. Each member of the squad is involved in sprint planning so that every person is allocated specific tasks that cumulatively match the capacity of the squad. Since we use rolling-wave planning, our squads can adapt and pivot quickly to meet evolving project demands. As a result, we can avoid common downtime issues like waiting, non-utilized talent, and excess processing. Squads allow us to reduce waste and minimize downtime. Each member of the squad is involved in sprint planning so that every person is allocated specific tasks that cumulatively match the capacity of the squad. Since we use rolling-wave planning

Co-Location

 

Co-location offers several often undervalued benefits. It helps streamline development time because teams can discuss issues face-to-face and reach solutions more quickly; it reduces unnecessary motion and travel, and it eases the transfer of knowledge. If one member of the squad needs another, they can turn and talk to them rather than hopping on a conference call or sending an email.

Furthermore, squads that share the same workspace for every project get to know each

 

 

26

other’s strengths and weaknesses and become familiar with each other, which helps them develop trust and become more efficient as a team.

Alignment & Autonomy

 

The concept of squad autonomy is another idea we adopted from the Spotify model. Each of our squads is aligned to work towards common goals in the product development process – for example, implementing a particular feature by a certain date.

Squads are autonomous in that they decide how they are going to reach their goals within the boundaries of the overall product strategy. While the user stories are created by the product owner following product goals, squads determine the best way to complete them. We’ve found that this practice makes our squads more efficient and creative, which ultimately results in better products.

Risk Reduction

 

Project teams typically face two significant challenges in product development: knowledge risk and personnel risk. The former is the result of poor communication and collaboration and results in knowledge silos where each person has the knowledge to do their part, but no knowledge of what other members are responsible for. The latter is the risk associated with the members of each project team; for example, if somebody resigns or has an emergency and needs time off.

THE TAKEAWAY

Squad-based agile development helps to reduce these risks by encouraging cross- functional teams that have a 360-degree view of the project. The easy transfer of knowledge within squads allows them to adapt quickly if there is a personnel issue, without having to start from the ground-up. We’ve chosen to organize our development teams into squads because of the clear benefits of this approach. Easy knowledge transfer, co-location, team alignment, and autonomy allow us to deliver better products more quickly with predictable velocity and lower risk.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

CHAPTER FIVE

TEN CHARACTERISTICS OF SUCCESSFUL AGILE SOFTWARE DEVELOPMENT

 

 

 

28

 

 

The companies that are the most successful embracing agile software development understand that agile is not something that companies do; instead, agile is something that companies become. It takes a long time to become agile, but the payoff is proven. Organizations across various sectors, from healthcare to banking, from the public sector to media, are actualizing the immense value that agile software development brings: better quality products, faster time-to-market, and higher-quality decision making.

Much has been written about agile mobile app development: its tools and methodologies, the benefits of cross-functional teams and short iterations, and the culture necessary to enable success. However, it’s essential to think about the fundamental characteristics of agile development and how they apply to the execution of practical software development projects.

Chapter six details the ten core characteristics of agile software development.

 

 

 

1. Fixed-Length Sprints

 

Agile software development methodologies have two central delivery units: sprints and releases. A release contains several sprints, each of which is essentially a small project alone. Feature, maintenance, and enhancement requests are all organized, estimated, and prioritized as sprints before being assigned to a release.

Development projects advance on a cadence of predictable fixed-length sprints. The stable delivery of new, working, and tested features at the close of each sprint supplies the

feedback that allows the product team to keep the project and system on track.

 

By using fixed-length (or time-boxed) sprints, product teams can effectively answer crucial questions like:

How much work did the team accomplish during the last sprint compared to the predicted amount?

How much work did the team complete compared to the sprint before?

How many features are feasible to complete before this sprint’s deadline?

 

The core benefit of fixed sprints is that the entire team remains focused on a few prioritized goals, rather than attempting to understand every single detail of the system. With highly visible results (both positive and negative) available from each previous sprint, the team can get the most out of the build-measure-learn process and identify areas to refine the process for the next sprint. Teams are more likely to prioritize features properly and less likely to fall victim to scope creep. Each team member helps each other stay focused on delivering the highest possible business value per unit of delivery.

Sprints Always Deliver Working Software

 

Delivering tested, accepted, and working product features at the end of every sprint are an agile software development team’s first measure of progress. Working features allow teams to improve collaboration, increase project visibility, and answer customer feedback strategically. Working software provides concrete evidence that the project is on track.

Throughout the first few sprints of a new project, the team may not deliver a large number of features. Still, as the project progresses, the team typically finds a predictable delivery cadence. As the system develops, the user experience (UX) design, architecture, and business objectives are continuously assessed. At every stage of the project, the team works to merge the latest input from customers, users, and other stakeholders to arrive at the most valuable business solution. Sprint by sprint, everyone involved can see whether the project is progressing to meet the most valuable business goals accurately. Repeatedly measuring progress against actual working software helps instill a level of confidence in engineers, customers, managers, and other stakeholders that can’t be matched by

traditional waterfall methods.

 

Value is a Priority

 

Agile software development adheres to diligently delivering business value early and consistently, as measured by tested, accepted, and working software. For this reason, product features are the central unit of planning, tracking, and delivery. From sprint to sprint, the product team measures the number of functional and tested features with each release. While other documents and artifacts are sometimes necessary, working features are of topmost importance. This approach to software development, in turn, requires that each feature is small enough to release in a single sprint. Feature prioritization is essential for reaching the goals of each sprint, as well as delivering business value.

Ongoing Rolling Wave Planning

It’s a misconception that agile methodologies rule out upfront planning; however, agile methods indeed dictate that any upfront planning be held accountable for depleted resources. More importantly, agile methods insist that planning be ongoing throughout the entire project. Any plan in agile software development must repeatedly demonstrate its validity.

At project kickoff, the product team does just enough planning to start the first sprint. This method of preparation is referred to as rolling wave planning (or just-in-time planning), and it is the practice of delaying product decisions until the team is in the best position to make them. Again, this doesn’t mean the team won’t plan; instead, the team makes more informed and actionable decisions as the product evolves, and more knowledge becomes available. Iteration is key to rolling wave planning. Imagine each sprint as a small-scale project that receives “just enough” of its plan. At the start of a sprint, the product team identifies a set of features to implement and estimates the technical requirements for each feature. This planning process repeats for each sprint and release cycle.

As it turns out, agile software development projects contain a lot more planning and better quality planning compared to waterfall methodologies. One of the significant pitfalls of waterfall methods is that the project reaches completion, and the product delivers

 

31

on all the technical requirements, but not what the stakeholders need from a business perspective. These shortcomings happen because waterfall methodologies don’t take into account new information or user research as the project progresses. Rolling wave planning is grounded in factual, accurate, recent data. It enables agile processes to allow flexible priorities and scope changes, within reason, to accommodate the unavoidable ways in which business needs and market demands continuously evolve.

Multi-Level Planning

 

Rolling wave