A DEFINITIVE GUIDE TO AGILE SOFTWARE DEVELOPMENT, a3 logics [notion reading list .txt] 📗

planning is much more effective when it occurs on two levels:

 

On the release level, the team pinpoints and prioritizes the features the product must have, would like to have, and can do without by the release deadline.

On the sprint level, the team chooses and plans for the next series of features to implement by priority. If certain features are too complex to be appropriately estimated or completed within a single, the team breaks them down further.

When features are prioritized and planned for a sprint, they are split into their technical tasks.

The rolling wave planning approach to software development is more manageable and accurate than any broad, upfront planning strategy because it positions the level of information available to the product team in line with the level of detail necessary at the time. It’s a waste of time trying to plan at a level of detail that the available data doesn’t support.

Relative Estimation

 

Many agile software development processes use the application of relative estimation for product features to expedite planning stages and eliminate complexity. Rather than estimating features against a range of unit lengths, the team selects a small number of relative estimation categories and estimates every feature against the terms of the categories. For example:

1 to 5 days

1, 2, or 3 story points

4, 8, 16, 40, or 80 hours

 

The notion of relative estimation prevents teams from wasting time debating the particulars of feature estimation. There is a significant amount of time and effort saved by using relative estimation, and the process often outweighs the costs of imprecise estimates. Just as with every other aspect of agile software development, product teams improve relative estimation as the project progresses and refine estimations successively.

If any feature overreaches the agreed maximum estimate, then it is separated into multiple features. Again, the features that emerge as a result of the separation also need to be completed in a single sprint. So if the product team establishes that features should not exceed 16 ideal hours, then any feature that exceeds that timeframe needs to be broken down. Using this process normalizes the granularity of product features: the ratio of feature sizes is never immeasurable.

Features Begin at High-Level

 

Rather than spending an extended period of time detailing feature requirements before development, agile software development projects often prioritize and estimate features, and refine the details on an ongoing basis. In most cases, the discovery phase of a project adheres to a design thinking framework to quickly produce a project timeline, documented product requirements, a product vision statement, user personas, and a list of marketable features. The features for a sprint become more detailed with input from customers, testers, and developers working together. No feature is described in detail until it’s prioritized for a sprint.

Continuous Testing

There is nothing riskier than postponing all testing until the end of a project. With continuous testing, product teams deterministically measure progress and prevent defects. This approach to testing dramatically reduces the risk of failure late in a project. Many waterfall projects collapse when they uncover, in an incessantly late project’s test- and-fix phase, that the architecture is terminally flawed, or particular components of the

 

33

system can’t be integrated, or features are unusable and entirely useless. All of these defects are discovered too late to make changes. By practicing continuous testing, product teams can avoid both the risk that these problems will happen and the constant apprehension of the worst possible outcome.

Continuous Improvement

 

In agile software development, product teams continuously refine both the system and the project. By reflecting on progress with sprint retrospectives using both hard metrics like running and tested features and more subjective data, product teams can adjust feature estimates and project plans accordingly. The continuous improvement aspect of agile software delivery becomes particularly important at the close of significant milestones within a project. Sometimes problems can arise with sprint planning, or with the build and integration process, or with knowledge transfer, or any number of issues.

It’s essential

to keep finding ways to adapt the process and to continue delivering as much value as possible per unit of time to the customer, the team, and the organization. Agile software development methodologies always mature and evolve like a living thing.

Small, Cross-Functional Teams

 

Small agile development teams are proven to be much more productive than more substantial teams. Typically, these small teams are known as squads. Each squad has no more than eight members, is cross-functional, plans together, and sits together. The benefit of squad-based agile development is teams work together to identify how to use each other’s skillsets best and mentor each other. Teams transition away from a top-down management approach, and each member helps do whatever needs to get done to complete the sprint. Individual team members begin to derive satisfaction from being a member of a productive and efficient team.

 

 

 

 

 

 

 

 

 

 

THE TAKEAWAY

Specific practices can vary across different agile methodologies, but there are common characteristics that mark the success of an agile software development process.

Fundamentally, actualizing success from agile software development is through early and

frequent iterations. From sprint to sprint, the product team uses continuous planning to define and redefine the scope of the release plan as new information presents itself and requirements change. The sprint plans become more accurate as the team learns more about velocity (the measured work accomplished per unit of time). By implementing the above characteristics into the software development lifecycle, product teams increase the likelihood of delivering successful mobile products.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

THE IMPORTANCE OF FLEXIBILITY IN AGILE SOFTWARE DEVELOPMENT

 

 

36

In agile app development, the project management triangle is comprised of three project constraints time, scope, and cost. The best mobile app development companies understand that flexibility is often required in at least one of these boundaries. As needs and objectives evolve, knowing which is flexible lets product teams adapt seamlessly without affecting your ability to deliver a successful mobile product.

The core benefit of building flexibility into the agile app development process is that it mitigates risk. The key is understanding exactly where flexibility is a priority.

WHERE TO PRIORITIZE FLEXIBILITY IN THE AGILE APP DEVELOPMENT PROCESS

Knowing which boundary is flexible lets product teams adapt seamlessly without affecting your ability to deliver a successful product.

Time

 

There are some projects where the delivery date is set in stone. The product may need to be released simultaneously with another launch; for example, a preloaded app that needs to be ready for the release of a new device or prior to a scheduled event. When this is the case, one of the other two boundaries will need to be flexible.

For other projects, time may not be the most important aspect. If your business goals dictate that the product needs a certain amount of features and functionalities or needs to be developed within a particular budget, time will be the flexible boundary.

Scope

 

When time or budget are rigid, the scope is the flexible constraint. There is nothing wrong with having to scale back features and functionalities; on the contrary, going to market with a minimum viable product (MVP) and following a rapid and frequent delivery model allows you to collect data and use insights to add value to users on an ongoing basis. There are significant benefits to choosing an iterative, agile development process over an all-or-nothing approach, like building a business case for additional budget or funding from stakeholders.

37

Budget

 

If there is scope creep or project scope increases but the timeline is rigid, the budget needs to become the flexible boundary. When more resources, more features, and more functionalities are required then the budget must be able to accommodate those changes.

IDENTIFYING YOUR FLEXIBLE BOUNDARY

While there are variations in every agile development process, a foundational aspect of agile methodology is the ability to adapt and respond to changes without losing velocity. To achieve this, flexibility is a necessity.

In an ideal world, agile development projects wouldn’t need flexible time, scope, or budget constraints. However, failing to account for the fact that product teams might have to bend as products evolve or new needs arise is very risky; if something does change, there is no contingency plan that allows the team to deliver a market-ready product.

Enter flexibility. By identifying which project boundary is flexible, product teams can adapt without losing velocity. Consider the following scenario:

You have identified that scope is your flexible boundary. You know which features and functionalities are critical for your minimum viable product, and there are others on the product roadmap that are highly desired and nice to have. You prioritize tasks accordingly using the MoSCoW technique (must have, should have, could have, won’t Have), aiming for a particular number of features/functionalities. But, you have accounted for the fact that if there are issues, you can scale back and still have the capacity to deliver your MVP within the other two boundaries. As a result, if there is a snag, you are now able to focus resources on the critical aspects of the project and save lower priorities for future releases.

Failing to account for the fact that product teams might have to bend as products evolve or new needs arise is very risky.

In this scenario, if the scope wasn’t identified as a flexible boundary, the result would be a sub-par product with partially completed or improperly tested features, delivered in a rush

38

and likely defective. Trying to deliver everything would essentially give the user nothing

– except a poor user experience.

The same principle applies to time and budget. If you plan for the possibility that things may not go as planned, you are able to adapt.

BUILDING FLEXIBILITY INTO AN AGILE APP DEVELOPMENT PROCESS

There are practices that allow you to bake flexibility into the agile app development process itself. These practices help with time, scope, and budget management, but also allow for rapid adaptability to changing needs.

Squad-based agile development: Squads are small co-located teams that are responsible for the end-to-end delivery of a product. They plan together, share knowledge, and have a known capacity. This reduces risk and allows for predictable velocity.

Rolling wave planning: Rolling wave planning involves delaying product decisions until you’re in the best position to make them. This technique lets product teams analyze and act upon the knowledge that wasn’t available at project kick-off. This lowers your risk, minimizes downtime, and