Top 10 tips for delivering agile project
Want to benefit from Tier 2’s hard-won experience in delivering agile projects using Scrum? Read on to see our top tips for the agile delivery of web, mobile and integration projects…..
Keep talking the talk
First and foremost, you’ll want to ensure that communication channels are always open. This helps because it means fewer surprises and fewer surprises mean more ground covered in a sprint. Getting bad news early allows the team to make necessary decisions in good time, as such, they can focus on the most important aspects of the application
Stick to the Scrum guide
Agile projects are about flexibility, but developing through agile frameworks definitely does not mean ‘make it up as you go along’. Cutting corners at the beginning will mean patching those corners as you go and they will only get bigger. If you stick to the Scrum’s agile project management process, your team won’t be taken by surprise
Let’s all get on the same page
From start to finish, make sure the whole team are on the same page in understanding the requirements of the project. Even though initial conversations will be had by a select few, i.e. project manager, business analyst, tech lead; as soon as possible, bring the whole team on board with the clients’ requirements. Give as much context and background as possible, not only so that the team can understand the whats, but also the whys.
Stories are a good way to describe the what and the why, for example: As a < >, I want to < >, so that < >. The ‘so that’ doesn’t always tie into the immediate requirement, but used effectively, it can provide an insight into why the client wants a particular story
A picture paints a thousand words
Use lots of pictures/sketches/mockups for front-end apps when discussing the requirements of an agile project. Everybody’s background is different and ideas are built upon various experiences, so when discussing front-end apps, everybody will walk away with a slightly different interpretation of the requirements. You can chat to the clients until the cows come home, but nothing really cements the discussions until it’s drawn up
Change – it is inevitable
Be flexible by keeping the door open for change. It is quite normal for a client to see an application which does match their (original) requirements. However, on seeing and reviewing it, the client can change their mind and re-think. This is natural and should be encouraged; ultimately the goal is to build an application with features most important to the client
Feedback here and now!
It’s really important to review the work done at regular intervals, ideally at the end of each sprint. Showing the client after weeks and weeks of development could result in more (re-)work compared to if the misunderstandings were dealt with immediately. There is an increased risk of misconceptions/miscommunications when putting a brand new idea/client/team together, so it is even more important to review at the early stages of a project
Release me!
Near the end of a sprint, the question that needs to be asked is – is there anything critical that won’t allow this feature to go to production? Getting to a potentially releasable state at the end of a sprint is ideal, it allows the team to then focus on the next important set of requirements. It also provides a sense of achievement to the team; the client and end users will also see the advantages of regularly pushing into production
Size matters
Small releasable chunks of functionality is a good way to ensure a steady flow of deployments up to production. It sounds obvious, but if there is less to deal with in a sprint, this will be done quicker. Smaller releases also mean lower risk to the rest of the application
Push that button and don’t look back
With all things automated; testing, deploying, releasing, etc. Initial adoption is sometimes slow, but getting these early into a project will help to build confidence in these tools. The earlier these processes are automated, the sooner the team can reap their benefits (i.e. saving time/removal of human error) and truly concentrate on building the application.
Don’t be too hard on yourself… okay, maybe a little bit
Embrace constructive self-inspection. The retrospective plays a key role in allowing the team to openly and constructively discuss (and implement) ideas to help build momentum and increase velocity sprint on sprint. At the end of the day, there is satisfaction in pleasing the client by building them a working solution, which matches their exact needs, but doing this efficiently, with as little fuss as possible, really helps to grow the team not only for the current project, but for future ones as well.
If your team could use some help with understanding agile project management with Scrum, get in touch with the Tier 2 Consulting team. We’re always available to provide top-level consultation advice for a variety of software development projects.
