Rawpixel - Fotolia
The Agile development process can transform a Waterfall development organization from slow, mammoth releases to a quick, iterative release cycle. Once an organization picks up Agile basics, it can move from a yearly release cycle to a weekly one, or weekly to hourly.
Small, frequent software releases provide several advantages over large and infrequent ones. The development team can demonstrate business value faster, as it releases important features earlier. The organization can also adapt quickly to changing software requirements. No longer will a project require months of hard work only to find the customer's needs were misunderstood.
But the switch to an Agile software development methodology is easier said than done. Many project teams struggle with the basics of Agile. Some organizations can't keep up with the pace of software releases, changes in priorities or, simply, the scale of the methodology shift.
In this Agile FAQ, we dig into common questions that software industry professionals ask as they change practices and principles. Master these Agile basics to adjust your organizational structure and achieve more operational efficiency.
What are some Agile practices for developers?
The Agile software development methodology is all about pushing quality releases to customers with higher frequency. To achieve that goal, a project team -- and developers, in particular -- need to rethink how software development works.
The Agile Manifesto doesn't provide explicit instruction for how developers should work, but there are several common Agile practices these teams can adopt. Each approach promotes short development cycles and rapid releases.
Continuous integration and continuous delivery. These continuous processes, also called CI/CD, promote automation throughout the software development lifecycle (SDLC) to push code to production without wait times. With continuous integration, developers commit code to a version control repository as they work. That code is then verified through automated builds and tests. Once code is accepted, continuous delivery ensures that new code or updates reach customers quickly and, often, automatically.
Behavior-driven development (BDD). This development approach, also called specification by example, connects a user story to a business outcome. When organizations define system behaviors and valid user scenarios in plain language, it helps the product owner, developers, testers and other stakeholders gain a shared understanding of the work to be done. With BDD, developers write tests before they code. This sequence ensures a quick feedback loop and prevents wasted work.
Test-driven development (TDD). Similar to BDD, TDD relies on short feedback cycles and validation of user stories. TDD limits the scope of development to focus on code passing specific test cases. If a feature or function does not pass its specific tests, developers must immediately refactor the code until it does.
Pair programming. In pair programming, two developers sit at the same workstation -- or, if distributed, watch the same virtual terminal. One programmer writes code while the other actively reviews it for errors. By replacing lengthy code reviews with a real-time approach, collaborative pair programming enables faster code integration, testing and release.
How does collaboration happen in Agile?
The Agile methodology isn't only about releasing software more quickly. It also promotes team collaboration and empowerment. Agile leadership must enforce and encourage ways for teams to work together more effectively, including investment in specialized tools.
In Agile software development, project teams should have the freedom to experiment and improve how they work. Agile teams should reward efficiency and problem-solving capabilities, and promote characteristics like:
- open communication
Development teams can also better communicate with outside stakeholders. Developers should learn customer needs through feedback loops and changing requirements. Also, product owners can provide direct input to ensure goals and requirements are met.
What are some Agile frameworks?
The Agile basics are simple concepts, yet there are many comprehensive ideas about how to achieve them. Organized frameworks offer roadmaps for Agile adoption. Each of these are common Agile methodology approaches -- with common objectives too. With any Agile framework or process, leadership and patience are required to see the benefits.
Scrum. Scrum is an Agile framework where teams can address collaborative challenges to accelerate product development and delivery. A Scrum Master works with a product owner and developers. The five key values of Scrum are commitment, courage, focus, openness and respect.
Extreme Programming. As the name suggests, Extreme Programming follows Agile concepts but with even shorter development cycles and more frequent software releases than other frameworks. Extreme Programming prioritizes values like simplicity, communication, feedback, respect and courage to release quality products quickly.
Lean. Lean software development aims to eliminate waste, such as excessive planning. Lean is all about optimizing the development process and the people involved with it, which includes promoting knowledge to create what's called a learning organization. This approach shares techniques with Lean Manufacturing and Lean Startup for different types of businesses.
Rapid Application Development (RAD). While RAD preceded Agile, it is still a common approach for Agile organizations. A RAD organization creates prototypes and product iterations as quickly as possible, then gathers user feedback before the testing and release stages.
Scaled Agile. Large IT organizations and enterprises face a steep challenge to implement consistent and effective Agile processes. The problem is twofold:
- There are many more workers than smaller organizations, all with different skills.
- There are technology and compliance challenges to work through before the business can overhaul its development approach.
Large and enterprise IT organizations might benefit from an Agile scaling framework, which offers a broad set of prescriptive measures. These Agile frameworks include:
- Scaled Agile Framework, commonly referred to as SAFe;
- Large Scale Scrum, commonly called LeSS; and
- Disciplined Agile Delivery.
What does Agile mean for software testing?
Quality control should be a key objective for any software development methodology. In Agile testing, cross-functional teams assess the product to ensure that it meets the organization's goals. By testing earlier in the SDLC, as opposed to later as in Waterfall, organizations can eliminate potential defects more quickly and at less cost.
Agile testers must keep up with incremental coding to deliver features and products quickly. Often, these QA professionals write specifications for expected user behaviors upfront for the developer, then test accordingly.
Techniques such as shift left, shift right and continuous testing are all focused on software quality for Agile teams. In all three approaches, developers take on some of the testing burden, and automated testing is key. These techniques increase test coverage and velocity when used effectively.
Who drives Agile planning, design and requirements gathering?
The person who steps up and leads in an Agile organization could hold a number of roles. Common Agile leaders include:
Scrum Master. If the organization adopts Scrum for its Agile transformation, the Scrum Master makes sure things run smoothly. The Scrum Master:
- maximizes values and prioritizes the backlog;
- ensures everyone adheres to Scrum principles and removes impediments; and
- helps development team members work.
Product owner or product champion. This person comes from the business side of the company, and uses that knowledge to make development projects succeed. The product owner or champion often brings together different teams and individuals to work at the intersection of business, customer and technology needs.
QA or dev lead. A QA professional could step up on behalf of testers and advocate for more detailed plans to improve quality in an Agile workflow. Similarly, a lead programmer could become the designated voice of development, up to and including choice of tools and approach.
No one person is the leader in every instance. Team leadership can be fluid depending on the situation. Someone on the technology side, for example, might lead the effort to replatform a software product. A product owner will often guide the team on a new feature launch. Above all else, remember that an Agile effort comes from the whole team -- it might not require any leader.
What does Agile mean for documentation and requirements?
The Agile Manifesto prioritizes working software over comprehensive documentation -- though don't ignore the latter completely. This is an Agile FAQ for newcomers and experienced practitioners alike, as many people mistakenly think they should avoid comprehensive documentation in Agile.
The Agile team should produce software documentation. Project managers and teams should determine what kind of documentation will deliver the most value. Product documentation, for example, helps customers understand, use and troubleshoot the product. Process documentation represents all of the information about planning, development and release.
Similarly, Agile requirements are difficult to gather, as they change frequently, but they're still valuable. Rather than set firm requirements at the start of a project, developers change requirements during a project to best suit customer wishes and needs. Agile teams iterate regularly, and they should likewise adapt requirements accordingly.
How do you measure the length of an Agile project?
When developers start a new project, it can be hard to estimate how long each piece of the project will take. Agile teams can typically gauge how complex or difficult a requirement will be to fulfill, relative to the other requirements. That complexity maps fairly well to actual delivery times once the team begins the new project through user story points.
Story points help teams measure the length of Agile projects, even if they will undergo a lot of change. Story points calcify those relative guesses made at the beginning of the project. By making story points measurable, an Agile team can gauge project progress and improve future work timeline estimates.
While they're used in other Agile frameworks as well, story points are particularly useful in Scrum. At the end of each iteration, the team has a certain number of user story points completed. This number informs a calculation of the team's velocity: how quickly the team is moving. The velocity might fluctuate at first, but it will generally level out and become stable as team members and project managers settle into the project. The story point system might start with a WAG estimate, but that's better than spending time on a bogus timetable when the requirements will change and evolve from iteration to iteration.
What should a project manager do when an Agile project gets stuck?
A root-cause analysis can jump-start a stalled Agile project. Often, the team is not producing anything, or the wrong things entirely. When the team is producing steady work, but there's still no progress, examine key performance indicators. But, in Agile project management, you can't just trust the metrics, as teams will often focus on whatever a manager prioritizes.
How can a single person manage multiple Agile teams?
When a project manager leads a pilot Agile team to success, they often take on additional leadership responsibilities -- sometimes managing multiple teams. Leading an Agile team is a time-intensive role that can be difficult to scale out to multiple teams -- but it can be done.
To lead multiple teams, a project manager must foremost eliminate outside distractions. A Scrum Master who will lead two or more teams must focus only on the requests that come from inside those Agile teams. Anything else, even a project that would improve the Scrum Master group, will take away crucial time and focus. One distraction opens the door for more.
How do you outsource Agile?
Many organizations outsource software development. However, they can still request that a vendor complete a project in an Agile cadence.
As with internal development, it's not as simple as flipping a switch to go Agile. Pay close attention to the language in an Agile development contract. Conventional software development contracts are often an ill fit for Agile projects, as it can be difficult to estimate the amount of work to be done. Instead, issue a contract tied to incremental delivery or bonuses that incentivize the vendor to get quality work done quickly.