What does Agile mean in software development?
The Agile Manifesto lists a set of principles that differed from the prevailing method of most software development at the time. The prevailing method in the 1980s and 1990s is often referred to as “Waterfall”. These principles still ring true for most developers in mosts contexts, and have been adopted by frameworks such as Scrum, Extreme Programming, and Kanban to create better processes for delivering software solutions.
The selection of the word ‘Agile’ reflects the philosophy of the principles that software developers should be able to quickly and easily correct their course of development when they learn they could be doing better, and this also implies that need more feedback faster in order to make those course corrections. These, in turn, imply more frequent communication with product owners and quicker delivery of features in order to get feedback.
Agile advocates delivering software in small increments, measuring what works, adjusting your process based on what you have learned, and continually trying to improve your process of delivery.
Why adopt Agile?
Teams usually adopt Agile to replace their current waterfall development practices. They seek to release software more quickly and do a better job and delivery what the product owner wants. They want to avoid wasting a lot of time developing software that they end up discarding.
Why not adopt Agile?
This writer is aware of no reason to choose waterfall over Agile. A team may continue to deliver software once a year, yet still develop it using Agile techniques such as getting product owner feedback all along the way, and accepting new requirements throughout the year. Even when a team spends months creating a very precise estimate for a client, and then the team goes away for months to build it, the team can be agile during their construction by focusing on finishing what they start instead of starting many of the software features at the same time.
As you read through the considerations below, keep in mind that your aspects of your context that although some elements in your context may make the adoption of Agile more difficult, this does not mean you shouldn’t adopt Agile. It may mean that you just need to change your context to help make the Agile adoption more successful.
How does your context affect the probability that adopting the agile philosophies will add value to your process?
*1. How does the Organizational Structure in your context impact the probability that Agile will add value to your process?
Agile based software development usually relies on a lot of interaction between the product owner, that represents and understands what the users of the product want, and the development team. If an organization doesn’t prioritize providing a product owner representative to the development team, then the team may often deliver software that is not what the product owner desired. Estimating the cost of delivering a finished software product is very difficult, and cost estimate for Agile solutions probably vary much more than for waterfall solutions, though they are likely to come in at a lower cost overall. If near accurate or fixed cost estimates are required, teams may desire to use a waterfall approach, though a lot of cost will then be incurred just to produce the estimate.
Agile team members benefit from clear guidance about their priorities and goals. Organizations that can show how a project aligns with their strategic goals, and organizations willing to put more decision-making power into the hands of the team doing work are more likely to have success with Agile. Some organizations have a structure called a ‘matrix’ where team members have one boss for the project but a different boss for their department. These different bosses from different teams may have different and conflicting goals which can make it difficult for team members to make the best decisions for the organization overall.
*2. How does the Development Team Culture in your context impact the probability that Agile will add value to your process?
Going from waterfall to agile is a significant change, especially for development teams. If team members are “set in their ways”, you can expect that resistance to change to make the adoption difficult. If the team feels they are tasked with similar process changes every few years which always fail, then you can also expect resistance. If it is the team members advocating for Agile, then you can certainly expect a greater chance of success, providing the impact on the rest of the organization can be handled. Like many changes you might try to introduce, a poor team culture and disgruntled team members will make the change more difficult and you should probably consider how to improve team morale first.
3. How does the Hiring Process in your context impact the probability that Agile will add value to your process?
The hiring process of your organization may have some impact on the value agile processes may bring to your team. Agile processes are more team-focused development than waterfall and demand more interactions between individuals, therefore you want to hire individuals that can interact with others well; and it is probably beneficial to have the potential team members interview the person that is to become part of their team.
*4. How does the Team Composition in your context impact the probability that Agile will add value to your process?
It seems that the only scenarios in which a team would be considering the adoption of agile principles is when the team is a waterfall team or they have no process. In either case, the team will benefit greatly from having experienced developers, particularly those experienced with agile when attempting to make the changes. If the team is comprised primarily of junior developers, the attempt to adopt significant process changes as they are still attempting to learn language skills, project management skills, teamwork skills, deployment skills, and more is likely to be too overwhelming for a good transition.
You will benefit a lot from having experienced developers if you are going from a well-defined waterfall process to agile process. If you have no process, agile practices can be adopted more easily as needed. This is likely to work better for experienced developers, but is very achievable for junior developers.
Some former team member roles come into question with a transition to agile. Most notable is the role of the “project manager”. Projects still need to be managed in agile but many aspects of that management may be spread across team members, and the team may be broadened to include quality assurance members and product owners and business analysts; as well as DBAs and IT staff.
5. How does the Training Provided on Code in your context impact the probability that Agile will add value to your process?
The training your company provides on code has no impact on the value agile principles may bring to your team.
6. How does the Training Provided on ‘Our Ways of Doing Things’ in your context impact the probability that Agile will add value to your process?
The training your company provides on your way of doing things has little impact on the value agile principles may bring to your team. Mostly you probably want to provide some training of your agile process to new team members as they join.
7. How does the Environment in your context impact the probability that Agile will add value to your process?
Your environment may have some impact on the value Scrum may bring to your team. Teams need to meet to communicate, so rooms without distractions, or technologies such as Zoom that everyone can use well are important. Visible boards to see the status of items, the backlogs, and understand what everyone is working on are very beneficial.
8. How does the Project Selection in your context impact the probability that Agile will add value to your process?
How projects are selected probably has little impact on the value agile principles may bring to your team, provided that the product owners are equally committed to utilizing the agile process for delivery of the software. When transitioning from waterfall to agile, teams should prioritize projects with willing product owners.
9. How does the Solution Purpose in your context impact the probability that Agile will add value to your process?
The solution purpose probably has little impact on the value agile principles may bring to your team.
*10. How do the Application Architecture Priorities in your context impact the probability that Agile will add value to your process?
Agile principles are noted for their ability to begin delivering value more quickly, so if quick delivery is extremely important to your solution, you should certainly consider an agile process. Likewise, if adaptability during production of the solution, and after it is initially deployed, agile processes usually perform much better than waterfall processes. But in regards to building a solution that is more secure or more performant, agile processes don’t offer any advantage, nor disadvantage, to waterfall processes.
11. How do the Security Demands in your context impact the probability that Agile will add value to your process?
The security demands of your solution have little impact on the value agile principles may bring to your team.
*12. How do the Requirements, Features, and Priorities in your context impact the probability that Agile will add value to your process?
As mentioned previously, agile processes expect a lot of product owner collaboration to work well. That collaboration is used to gather requirements as needed, select features to work on each sprint, and set priorities based on the ROI they can provide. Perhaps it can be done well without the product owner by someone else that has a good idea of what the product owner wants, but lack of such input will likely cause a return toward waterfall methods.
13. How do the Regulations in your context impact the probability that Agile will add value to your process?
Your regulations and auditing requirements probably have no impact on the value agile principles may bring to your team. However, as your team adopts agile processes you may need to work with some auditors to develop new auditing policies for your agile development processes.
*14. How does Who Decides What To Do in your context impact the probability that Agile will add value to your process?
The people that make the daily decisions about what a team and team members should do is greatly affected by agile processes when compared to waterfall. Decisions need to be made more frequently and by those that know the work best to avoid time being wasted. Producing a software feature, at the same time as developing a software product, at the same time as making improvements to development processes, at the same time as trying to improve DevOps, requires the ability to consider dozens of factors about the most valuable use of time of team members. That decision should not fall to a product owner, or a project manager, or a Scrum master, or individual developer. Ideally stakeholders can work together to guide decisions, otherwise a team can become unbalanced. For example, they may focus on just delivering features as fast as they can, when they could eventually deliver them faster if they took time for automating builds, taking a few days for training, or fixing some bugs that consistently consume time. Conversely, a development team may seek to build the optimal framework and devops automation prior to delivering many features and may waste a lot of valuable time building robustness that is vastly under-utilized.
*15. How does Project Management in your context impact the probability that Agile will add value to your process?
Project management tools and processes can make a significant impact on your success with agile processes. Good backlog management tools and task boards easily accessible by all stakeholders greatly facilitate communication in timely manner so that good decisions can be made quickly when needed.
*16. How do the Quality Processes in your context impact the probability that Agile will add value to your process?
The quality processes you have in place may be impacted by the adoption of agile processes if you currently follow a waterfall process. Most waterfall processes include little quality assurance other than reviews, but use extensive testing after the majority of the code is written. Agile approaches expect testing to occur right away as code becomes testable early in the project. Many agile practices support quality processes such as writing tests and testable requirements before writing code, or having quality assurance team members sit with developers as they code. Of course unit tests, integration tests, static code analysis, and automated deploys to quality assurance environments are often employed. In short, adopting agile processes facilitates the adoption of many new quality processes.
*17. How does the Architecture Forecasting in your context impact the probability that Agile will add value to your process?
The way a team plans and implements architectural changes, such as rewriting a web application to use REST on the backend, probably changes significantly with a transition from waterfall to agile processes. In waterfall, an architecture team may mandate the architecture to be used on a project, or may create a project the singular goal of changing the architecture. Agile teams usually gradually migrate from one architecture to another across the deployment of many features and projects. So the impact of this element goes both ways. How your organization currently evolves the architecture is probably going to impact your ability to use agile processes, but also the implementation of agile processes is going to affect how your teams evolve architectures.
*18. How do your DevOps in your context impact the probability that Agile will add value to your process?
Like architectural forecasting, your current DevOps processes are likely to impact or hinder your ability to use agile processes, and your implementation of agile processes is likely to cause significant changes to your DevOps processes if it is to be successful. Delivering working software frequently is a key part of the definition of Agile. Software doesn’t necessarily need to be delivered to production for a team to be agile. The software could be delivered to a test environment where product owners can do enough evaluation to make a really good assessment about it meeting their production needs. If changes can’t be delivered until they have gone through months of testing environments and integrations, the value gained from an agile process is greatly curtailed, especially in the initial transition to agile. Therefore, the adoption of agile processes will most likely include the demand to improve DevOps so that deployments can be made swiftly and often.
As with any consideration though, many teams use agile processes yet deliver working solutions to customers only once or twice per year. They can do this by delivering more frequently to an internal quality assurance team or product owner liaison who can evaluate and approve the changes more frequently. All those changes over the months usually accumulate, having passed all testing, and are bundled together in a product released annually.
19. How does the Architecture in your context impact the probability that Agile will add value to your process?
The architecture of your solution has little impact on the value agile principles may bring to your team.
20. How does the Code in your context impact the probability that Agile will add value to your process?
The coding languages and tools in your solution has little impact on the value agile principles may bring to your team.
21. How does the Code Quality in your context impact the probability that Agile will add value to your process?
The quality of the code in your solution has little impact on the value agile principles may bring to your team. However, many of the agile practices can help your team improve the code quality, especially with more frequent deployments which provides quicker feedback about problems.
22. How does the Application Quality in your context impact the probability that Agile will add value to your process?
The current quality of your application has little impact on the value agile principles may bring to your team.
23. How does the Deployment Environment in your context impact the probability that Agile will add value to your process?
The deployment environment of your solution has little impact on the value agile principles may bring to your team. It may impact how frequently you can deploy to “production”, but most Agile teams will have a test environment they can deploy to more frequently for testing before delivering the accumulated changes in a single package to production. It is generally easier to deploy frequently to production when production is a web site. Deployments to phone App Stores can be a little more difficult, as can deployments of desktop applications. Deployments to some environments, such as code embedded into hardware happens once. Some software is purchased and downloaded by customers so deployments, aka, new versions of the software, are only made available periodically.
24. How does the Product Training in your context impact the probability that Agile will add value to your process?
The product training your organization provides for your product has little impact on the value agile principles may bring to your team. But if frequent product updates are deployed as part of your agile process, you may need to re-evaluate how training is provided as features change more frequently.
25. How does the Support in your context impact the probability that Agile will add value to your process?
The support your organization provides for your product has little impact on the value agile principles may bring to your team. But if frequent product updates are deployed as part of your agile process, you may need to re-evaluate how support is provided as features change more frequently.