Agile Development in a Nutshell: 5 Things You Need to Know About Agile Development

Understanding how to use Agile Development makes for a smoother development cycle for you and your team. What is Agile Development though? How can I implement it to make my development team better all around? How can I be successful in using agile development? 

While there are many parts to agile development, I’ve compiled the top 5 things that are important to know about agile development and how it makes you and your development team work efficiently and successfully. 

What is Agile Development though?

There are two widely accepted schools of thought when completing new development, waterfall and agile. Waterfall development is a more rigid approach of development where you must complete each step of the life cycle in order and cannot move on to the next step until the previous one is completed. 

Agile development is being adapted more and more due to the flexibility to shorten the development cycle, and to yield tangible results faster. No matter which development strategy you adapt you will go through the following steps: planning, requirements, design, quality assurance, deployment/release, and maintenance.  

When is it appropriate to use Agile Development over a Waterfall approach?

This is widely debated and largely depends on the development manager, and stakeholders working on the project. Typically, a waterfall approach is used for a brand new implementation or a new module to an existing software platform whereas agile development is more acceptable when adding new functionality to an existing software platform such as adding a workflow and fields to track net promoter scores.

Top 5 Things you need to know about Agile Development

1. Identify the risk score

Each time a stakeholder or end-user submits a request, the project manager must ask the question: What is the risk to a production environment if we go ahead and speed it through the process and shorten the life cycle to get it done right away?

If we receive a risk score of 5, Catastrophic, signifying high risk as the released functionality could shut down the platform or have a negative financial impact to customers or the company, we have to ensure that each life cycle is completed in a development environment and put through a rigorous testing process. 

On the other hand, if the risk score is low, such as a score of 1, it’s going to have very little risk to the system, customers, and end-users.  A risk score not only helps to manage risk but also with time estimation and release planning. Below is an example of a risk matrix:

Likelihood in this matrix determines the likelihood/frequency of the problem occurring. The green color within the matrix shows that it is a low risk, and as you go higher in the level of risk and likelihood, the risk becomes greater. For example, if a client develops an app to process payments, this effort would be a 5 for consequences and a 5 for likelihood as it has the potential to impact numerous customers in a financial manner. Therefore, it should be concluded that this effort should go through all phases of the lifecycle and be fully tested in a development environment before deploying changes to customers.

2. Create a deployment/release schedule

One thing to know about the deployment stage, is to not deploy changes all the time. This can introduce constant disruptions to end users and can make it difficult to create a communication plan around daily changes. I recommend picking one day, specifically Friday’s, for the sole day to better plan for the changes that need to occur.

Some companies use tools that help plan for quarterly releases that launch big pieces of functionality. Depending on the size of the software determines if it needs to be released at the quarter because it takes more time to develop it. Other pieces of functionality can be released during other times besides the quarterly releases and these are referred to as “hotfixes”, where there is an issue that is urgent and must be fixed before the regular quarterly change. We encourage end users to wait until Friday so the development team can focus and eliminate disruptions throughout the week. 

It is preferred to stick to changes being released only on that specific day so that we can accomplish tasks such as sending out release notes that tell end users specifically what has been changed so there is no confusion. Also, take the time on Friday’s to anticipate bugs that will show up in the next week and plan to have the time in order to do this. By developing on a schedule, it will create a more organized way of addressing the issues and making time to deploy the changes without having constant disruptions. 

3. Develop a rank request 

When going through the strategy session, we need to define what items within our backlog is urgent compared to which items are less urgent. We do this by developing a ranking system, where we rank items: “urgent”, “high”, “medium”, “low”, etc. You can use any terminology that is suitable for you and your team that helps identify the items that are high priority and which ones are not. . 

Development tasks consist of both bugs, as well as new features, therefore items should be ranked based on their impact to end users and customers both negative and positive.  If it’s not an urgent item, we’re not going to stop our development team in order to work on it and the request  should wait  to  be reviewed on Friday during release planning.

4. Estimate time for items

Throughout the week, it’s inevitable that you’ll receive new requests that are going to come in even though you have a “release” of items already planned.  It’s important to estimate the time that each of these items take in order to organize how you’re going to approach your next week of work.

I recommend using an estimating tool or development tool in order to stay on track and I personally enjoy using the app, Jira, but there are many tools that you can use in order to get organized. Microsoft Excel could also work, but for bigger companies, if you were to use spreadsheets, I’d suggest using Google Sheets instead of Excel because of the ability to share the Google Sheets amongst multiple people. You’ll normally have multiple users who need to know where any given item is and with Excel, it’s hard to manage the passing of spreadsheets. 

We addressed how Friday’s are suggested for the days you plan your next release after releasing everything you’ve completed for the week. This is the best day to run through the backlog to ensure every ticketed item has a time estimate on it. For example, smaller development teams use T-shirt sizes, such as small, medium, large, etc, to quantify the effort needed in order to complete a task, where timeframes for developing are more fluid rather than being stringent. 

Though, for bigger development teams, they might need to be more stringent, so they use the Fibonacci model, which uses the hour increments that way you can add up the amount of time you have for developing. This allows for a more accurate project timeline for delivering functionality on a schedule. For each item there is a minimum and maximum score that determines the length of time it takes to complete. This means that, for example, if 2 developers each have 30 hours of development time, that means there are 60 total hours for developing and we can plan accordingly for items with the estimated time frame that’s within the priority ranking.  With those total hours, we can divide our tasks into smaller subtasks that allow us to work on multiple items per week instead of focusing on finishing 1 item per week. 

Also, be sure to account for 10 hours for the “hotfixes”, I mentioned earlier, in the following week because there are times where customers have an immediate request during the week that needs to take precedence and we need to be able to have the time to address it. 

5. Hold SCRUM meetings with your team

Because we’re constantly developing, going through quality assurance, and deploying items, it is important to have regular meetings with your team. You and your team must be on the same page regarding the expectations of the week and the plan. Also, it’s a perfect time to answer any questions they may have for you and talk about things that may have come up within the last few days that need to be addressed. It’s important to keep these meetings short and sweet, between 15 and 30 minutes because you don’t want to waste everyone’s time and keep them from the time they could be developing or working on “hotfixes”. Though, depending on the release cycle every week versus every two weeks with the exception of the Friday meeting to conduct release planning and time estimation, it may take an hour for the meeting. If you have more than 2 developers, I suggest having daily meetings where you’re answering any questions and making sure they’re working on what’s in the release and not getting sidetracked by new user requests that come in.