We’re giving away 1,500 more DJI Tello drones. Enter to win ›
by Aiden Gallagher, Andy Garratt | Published February 27, 2019
As the pace of software development quickens, more companies are beginning to take an Agile approach to deliver projects incrementally. Team methods and communication can change to keep the project running smoothly and keep teams happy. When done effectively, using an Agile Method can have fantastic results. When done badly, projects can grind to a halt.
So, how can you keep your projects from grinding to a halt? In this article, we’ll share the top 10 lessons we’ve learned from Agile projects we’ve engaged in, give you a view into how Agile projects can go wrong, and tips you can use to learn from your own projects and make them succeed. By listening to the team, being willing to try new methods, and recognizing where improvements can be made, agile practices can be a driving force in any project.
Daily standups, whether through scrums or other methods, should be oriented around goals or tasks, need to be kept to a minimum number of minutes and people, and should always answer three main questions:
You need to keep your standup short (think 15-20 minutes) and limited to the people who need to be there (no more than 10). We often find ourselves in standups with an entire project team present — upwards of 150 people! Not only does this not fit into a 15- or even a 20-minute window, but people naturally become bored of the parts that don’t affect them. Remember, the standup is not an update from the top.
How do you prevent the time running over? Avoid complex discussions about the resolution to blockers, for example, architecting or code implementation. Not only is this the wrong forum, its also wasting other sprint members’ time. Consider using a visual aid — for example, a raised hand — that anyone on the team can use to express a desire to move on with the standup.
Another key factor to consider is that a standup should be just that — standing up and interacting. If you don’t make it too comfortable to attend, members will want to finish quickly and hence keep the session short. Consider standing during your standup, or even standing on one leg, or keeping your hands on your head if you are sitting.
Agile practices state that teams should be all of a certain type. Teams should either be co-located or they should be remote. The mixture of the two doesn’t work well because the co-located team becomes the center of the operation, and the remote workers become isolated.
We know from practice that sometimes you have to have a mixed team. For instance, a team might have a remote worker or two because of organizational requirements like contracts, skill dependencies, or the like. These are unavoidable, so remember that agile is a guideline to be followed as closely as possible – but one size does not fit all.
Where teams are remote or have remote team members, there should be adequate tools to collaborate on design, ideas, and work concepts. You need to plan ahead to provision your team for success. A seven-day lead time to get your remote workers ready to collaborate with slow clunky machines that never load is never going to get you the great results the team can achieve.
At a minimum, teams should be able to:
And do all of this with no technical difficulties.
And a quick note about webcams–use them! Not only do they encourage users to pay attention, but they also help build familiarity and a team feel.
In addition to resourcing your remotes well, you need to have mechanisms in place to evaluate if a remote worker is having an issue with their work. Body language like slamming things or hair wringing or a worried look can often tell you if someone is having trouble with a task. But if you’re not co-located, you’ll miss those body language queues, so prepare in advance for ways to flag when someone needs help with a task.
One Agile tool that you could try is a virtual mood marble at several points of the day. This might be linked to the scrum master by way of a dashboard for users to portray their busyness or need for help. For example, a red marble indicates that help is needed, a yellow one shows that the person is working on something tricky but could still finish the task on time, and a green marble shows that everything is good. Remember to tailor your solution to the needs of your team in a way that you all agree with and will participate in.
With remote workers, you also need to plan for “information radiation.” Imagine you sit in the office and overhear a nearby developer who is struggling to get access to a piece of software and is expressing that concern to the project manager. You gained access two days earlier and sped the process up by talking directly to someone in another department. By sharing this information with the developer, you quickly stop the project from falling behind without too much additional stress. This scenario is hard to replicate when a team member is remote. One way to alleviate is to have public-only conversations, this might be on a messaging application or a constant live call.
While potentially obvious, teams that are bored lose interest in what they are doing. The Agile Method is built on momentum, drive, and excitement. What triggers individuals to be excited and content in their work depends on their motivation.
Aiden is motivated by seeing a thing executed well and being useful to the end user. Andy is motivated by architecting new solutions and systems, taking a problem or requirements and shaping that into something tangible. Others will be motivated by going to work and keeping a system running. Others want to new use software and learn new skills and others like to enhance what exists to make it as efficient and usable as possible.
To keep an Agile team and project going, you need to pay attention to what motivates each member and encourage them in a way that motivates them.
A common problem we see and see littered across forums and blogs concerning the Agile Method is ticket-driven goal management. Because agile methods require a ticket per task, there can be 100s of tickets per team across multiple team goals. This can lead to some management and analyst roles focusing on the delivery and timescales over the delivery of the ticket’s essence.
We have four rules for every ticket created:
Let’s put a real example into a made up scenario. We’re working for a company who delivers parcels. Our project is to create a new app that allows drone delivery, and our team is creating the software for the drones’ mapping functionality.
The tickets could be put up onto a sprint board with “In Progress” “Done” or “Blocked”. But they could also be made to be engaging. A map could be made showing several locations for delivery and a warehouse where the drone gets its packages from. Each ticket is a parcel that needs to be delivered to a location with various zones showing the ticket progress.
If the ticket cannot be read by the team in their usual scrum formation e.g. around the board, the text is made bigger. The text can’t be read because it is written in red, you rewrite it in blue, if the text is too wordy or too short, it’s adapted so that everyone can understand. If there’s too much detail, rewrite it from a higher view. Too little detail? Add more detail.
The ticket system should be easy to follow by the whole team, easy to digest and everyone should be able to glance at the board and describe each ticket and its progress.
For a project to succeed, you need to have a realistic plan in place for the deliverables–and have it agreed upon by the team. Doing so every time alleviates frustration on team members’ parts. Consider this scenario:
It’s the start of a new sprint, you gather around your sprint board for your new scrum, and there’s a task raised with eight story points. The task is something you did last month when you were on another project, and it took two days. This time, you can design it in more detail and add the extra functionality you had wanted to add the previous time. Five story points later, and you’ve finished. It’s delivered, tested, and you’re helping the rest of the team with their deliverables. You consider it a sprint well done.
The next sprint, there’s a task that you’ve never done before. You understand the mechanics, but there’s some complex security concepts you’ll have to read through and play with to be familiar enough to start the project. You think it will take eight story points but the lead architect has said it will take three. You make up the hours in your own time to learn the concepts. You tell the scrum master it will take you much longer to complete and end up delivering a sub-standard piece of work that passes the right tests.
At the next sprint planning session an argument erupts between yourself and the lead architect on time scales and delivery promising.
This could all be alleviated through positive planning.
First off, techies should estimate the time spent, but the buck always lies with the delivery team. So the delivery team must agree to the delivery commitment (the estimate) before the task can be finalized as part of the sprint. Not only is this good practice, but it’s also respectful to the team delivering. Consider following the agile ‘pigs and chickens’ method that asks who has the most ‘skin’ in the game for the task at hand.
A way of resolving the planning issue is to complete ‘planning poker’ where each person at the sprint planning meeting puts forward their estimate. Between the project, a delivery time can be agreed based on the collective requirements and willingness of the deliverer.
Skill development is important. Don’t neglect it.
You should never have a team where one person has all of the expertise. That person becomes a filter for progress. They are a blocker when they are too busy, and development comes to a standstill if they leave.
Each team member should be given the ability to grow their skills. This not only enhances the team, but also keeps them motivated and excited by new challenges. Pair programming is great for helping to skill up. It might take both people longer this one time, but then both members are giving back to the project.
When performing a sprint retrospective, be sure to ask if the team is improving their skills and if everyone is happy with the tasks at hand. Asking for a show of hands for who has the skills to complete each sprint task will help you gauge where skills are concentrated or sparse.
In agile environments, documentation is sometimes sacrificed in order to get more stuff done. We’ve been there and seen the fallout. You need to document design decisions, guides, processes, and templates and make them easily accessible and searchable.
Let’s look at a couple of common scenarios where good documentation could have saved the day.
A new person joins the team and is right in the middle of a fast-paced sprint strategy with no idea how the system works together. A few months in, that person moves to another project which requires more people with skill X. Now you’re back to square one with a whole new education cycle that has to be done by other members of the team because the documentation is not up to scratch.
Or consider what happens at the start of a fresh quarter. You get a new scope and a new budget–plus a whole new project cohort: engineers, developers, project managers, scrum masters, architects. On top of that, a reorg in the group means that last year’s program lead is not this year’s program lead.
A few months into the project, the new cohort sees something they think they can do better. They start asking about how the team could leverage this capability, and another capability, and another capability. A lot has changed since the original decision, the documentation is out of date, and you can’t fully remember why everyone decided to do what was decided. Three weeks, ten calls, and five whiteboard sessions in, you come right back to where you already were: The same decision.
Good documentation could have helped you avoid these scenarios entirely. The Agile Manifesto does champion working software over comprehensive documentation, but doesn’t say not to document at all. Documentation is a tool, it needs to be written, and benefits the team greatly. Whether each sprint gets a different documenter or you choose a paired documentation or a dedicated documenter, it is vital that design decisions, guides, processes, and templates are documented and are easily accessible and searchable.
What do we mean when we say not to treat infrastructure like application software? Here are a few scenarios we’ve seen that will help us explain:
Case 1: A microservice needs changing to supply new credentials storage location for an integrated application. To alleviate this, the sprint involves a task to create a duplicate application with the new credentials to replace the existing microservice. The ticket has a couple of story points. The database and integrated application specialist are on hand after an interlock of sprints and the sprint goal is achieved.
Case 2: An on-premise operating system needs to be updated for a software solution. The software is updated but traffic hitting the software fails because of a new dependency on stricter input rules. This breaks three integrated applications in three separate teams who were calling the function with an old version of integration code that they were late aligning with. The ticket had expected a two-day long change, but the new operating system isn’t describing the error well enough to pinpoint it. It takes three days to fix, whereby none of the other sprint goals can be completed, which throws the deliverables for end-of-year off track.
Case 3: A virtual machine hypervisory is changing to a new file storage provider. During the upgrade, a user error reboots the hypervisor. There are ten virtual machines residing on the hypervisor and each has a set of temporary keys which are updated each quarter. The reboot reboots all the machines, knocking out ten highly important systems. Nobody is entirely sure what the error is which is causing repeated live traffic failures resulting in financial loss for the company from customer payouts, a loss of work days for the error to be found and fixes put in place, as well as the backlog caused by the systems being out.
If we consider a microservice which resides on a virtual machine, the virtual machine resides on a hypervisor which itself resides on a datacenter rack which is in a datacenter hall. This accounts for five ‘layers’ of a deployment. If we consider from the bottom upwards, we start to see things slightly differently. In each hall there are ten racks, which have ten hypervisors which have ten virtual machines, which host ten microservices which are each relied upon by at least two applications. At each stage, the loss or lack of correct management can cause more and more issues. For example, if a hall fails, we lose 10,000 microservices, affecting 20,000 applications.
The main point here is that when planning in an agile world, it’s important to get a perspective of the dependencies you have and that other teams have on what you’re building. You must understand that infrastructure is not the same as your applications and that changes have a much wider and deeper impact. Infrastructure might not fit into your regular sprints. The liaison team members may be in a different team, and the disruption caused by changes made will require a greater understanding throughout all connected teams.
An often overlooked part of an Agile team is the testing element. Developers are asked to “create tests” or ‘”test your code” as part of the development sprint cycle. The obvious flaw is that, in testing your own code, you are more likely to forgive its shortfalls.
But testing is an art in itself. Even more difficult is writing tests before you start getting into the code. Test-driven development and other techniques stress the importance of testing as the pivotal part of the development cycle.
From an agile perspective, the key piece of information to remember is that tests themselves are agile. In the same way requirements change, your tests need to change constantly to keep up with the constantly adapting demands from the users and sponsors. Tests should be made as constant as the code they are testing. A simple rule of thumb is this: If my previously passing code is changing, my tests should be changing, too.
When a team gains a good tester or testers, it strengthens the code, improves the developers’ working practices, and keeps the project on track. When you have specialists who are good at testing in an agile way, your team can move from firefighting to fire prevention.
The first thing to think about is what approach the program or functional team will use. Will you use an Agile Method or Waterfall Method or some other approach? ‘Fragile’ projects are sometimes used in the Agile community, which refers to when teams combine different methodologies. Anecdotally, this is often a confusing approach so our advice is: For single deliverables, you MUST use one methodology and one methodology only.
That is not to say projects as a whole cannot be hybrid. Where infrastructure might be best placed to work at a waterfall level, the application changes that reside on that software might be better handled and progressed in an Agile manner. Your methods should be complimentary.
For organizations, programs, and teams moving from Waterfall approaches to Agile practices, the difference can seem as far apart as a tree is to a squid. It might be tempting to fall back on what you know is comfortable, but if you persist through the hard parts, the benefits can be great!
Are you worried that all your code works in a production environment the same way it does locally? Join us…
Explore four paths to adopting or improving DevOps continuous software delivery in your organization.
Back to top