Agile in practice #2 - How to implement Agile?
It’s easy to become infatuated with Agile. But, in can be challenging to actually make it work. In this article, we will take a look at best practices for implementing Agile. What are the common pitfalls and how to avoid them? And how did we do it at Boldare? Read on to find out.
Table of contents
Start with a vision plan
First, you need to figure out what it is that you want to achieve with Agile. Is it a shorter delivery time? Better products? These are results that you can expect when implementing Agile. Then, you need to take a good look at your business objectives. Your goals and your business objectives need to be aligned with Agile. Otherwise, whatever action you will take might end up being counterproductive (source).
Once you decide that implementing Agile is the right move, you need to sell that idea to others: be it your managers, stakeholders, shareholders, even clients. They all need to be convinced that going Agile is exactly what your company needs at the moment. Only then can you proceed.
Is your organization ready to implement Agile?
Implementing Agile in your organization comes with some radical changes. In fact, there is an entire Agile Manifesto that explains what mindset your organization should adopt. In short, the key to Agile is to focus on:
- working software,
- responding to change,
- collaboration with the client,
- prioritizing individuals and interactions.
How can you tell if your organization is ready for these changes? It all comes down to skills. You need to see if your team can work transparently and if your management is comfortable with being flexible - especially in terms of the goals and milestones of each project. As a rule of thumb, you can assume this: if your leaders work well under pressure, make quick decisions, and are good at adjusting to a new environment, then your organization has the necessary skills (source).
Which Agile framework is right for you?
Implementing Agile usually means following one of the already existing frameworks. Currently, the most popular frameworks are:
- eXtreme Programming
- Kanban
- Scrum
- Lean development
We won’t be getting into details of each one of them in this article. All that you need to know is that your vision and your goals will dictate the choice of framework. For example, if your goal is to simplify your development process, you might want to consider lean development. But, if you’re looking for a way to deliver highly innovative products, scrum should be your top choice (source). When adapting the framework to your development process it’s a good idea to start with small projects first - it will help iron out all the kinks before moving on to the big projects.
When implementing Agile it’s best to start from the top
You need to make sure that leaders of your organization truly understand what it means to be Agile. Because it’s more than just sprints and time boxes. According to the Agile Manifesto, it’s about managing the workload, not the workers. Also, it’s quite likely that as you proceed with the implementation of Agile software development, there will be problems that will need to be explained to your leaders.
For example, during the transition period, your team will still be adjusting to the new work environment. As a result, delivery times for individual projects will increase. Would you like to explain yourself after every sprint? It’s best to talk to your management first and warn them that delays are expected as part of the learning process.
Stick to the plan, but be Agile as you go along
Once you decide which Agile framework suits your business best, it’s time to try it out. Choose one project that you will carry out using your chosen Agile methodology. Get together with your team after every sprint/programming session. Chances are, there will be things that are confusing to your team. But with every sprint and every project, their understanding will improve. And they will tell you what’s working and what’s not. That’s why it’s important to nurture a culture of feedback and transparency.
Find people that will follow
Successful implementation of Agile comes down to one, single element: your employees. In the perfect world, your team would be asking for a more Agile approach. And while that’s not always the case, your employees should at least be excited about the idea of going Agile. Because once you do start implementing it, they are more likely to spread the word within your organization. As a result, you should see more and more people buying into this approach. But unfortunately, not everyone will be happy with all the changes. When implementing Agile you need to be prepared to see some of your people leave.
Let your best people tailor their Agile framework
After a few months, you will notice that some teams are doing better than others. It’s only natural. When that happens, it’s good practice to give “a little freedom” to those who are doing well. Do they prefer to hold daily meetings over lunch? Let them! Do they prefer to do their planning using pen and sticky notes, rather than with an online tool? Great! Let them find their own way of Agile working. It will only improve their performance (source).
Agile at Boldare
Boldare hasn’t always been Agile. In fact, Boldare hasn’t always been Boldare. Back in 2006, when we were still a small software house, we were calling ourselves XSolve. We had a small team of developers but big plans for the future. It was then that we decided to become more Agile. But how we went about it is another story.
We started off with something called ScrumBut - which is an imperfect version of the scrum (source). In ScrumBut, a company can freely choose which elements of scrum they want to implement. And so, we started with daily meetings and sprints. That’s how our employees remember these times:
… back then, we used to print burndowns (a type of report showing what was accomplished) on paper and stick them on the wall every day.
And what about scrum masters? They didn’t come about until 5 years later. But even then, it wasn’t even a separate role. Since many of our developers had a scrum certification, they took on that job part-time. We only began to specialize in scrum in 2012. And we’ve come a long way since then. These days, we have a team of dedicated scrum masters and digital tools to organize our work.
Share this article:
