In this article, I will summarize some tips for a team that is getting started with Agile methods (Scrum, Kanban, etc). This is not always easy, especially if the team doesn’t have someone with experience walking that path with you, but there are many steps you can still do on your own to make a start in Agile project management.
First: Work as a team, not as a sum of individuals
Agile is a collective game. You can’t expect your team to do anything close to Agile without changing the way you work together.
Regardless of the company’s input on your roles within the team, you can make your own work agreements with your colleagues, respecting the limitations imposed. For example:
- even though you have a Project Manager, you can create a weekly plan altogether and agree on what DONE means to all of you,
- you can make your project plan fully transparent by sharing it on a board, check its progress every day as a team and help each other to tackle the obstacles found,
- you can also reflect collectively on how to improve those work agreements in order to achieve your goals while working at a sustainable pace.
(Kaleidos team working on discussion tables)
Second: You have to start somewhere
You don’t always have a green field to start with. That cannot be an impediment that will block you from getting into action– be flexible in your practices. Agile also means that you are compelled to explore the limits of the way you work. Remember that it’s part of the journey.
In the previous section, I gave you some examples of small changes you can try within your own team. Here you have some more that you may find useful at the beginning:
- Visualize the amount of work you have now. It’s a good practice to use a taskboard (a.k.a. Kanban board) with columns showing the status of each task, e.g. TO-DO, DOING, DONE. This way you can focus on “stop starting, start finishing”, which means that you give more priority to finish started tasks, instead of starting more work that will simply stay DOING for ages.
- Another good advice on visualizing work is to put a mark on the blocked tasks because unblocking them should be your priority.
- If you have too many defects or tasks that eventually get blocked, you can agree on standardizing the way you work. Write down those agreements (e.g. in a document, a wiki page, a paper in a wall…). Next step could be automating those agreements (partially or completely).
- It’s also key to agree on the expected result before starting to work. This is what we call “Acceptance Criteria” when applied to a specific piece of work or, in a more general sense, “Definition of Done (DoD)” which applies to how we consider that any task is DONE. This is one of the most productive conversations you can have because it avoids many misunderstandings and allows everyone to focus on “finishing things” instead of just “working on things”.
- You can also agree on the “Definition of Ready (DoR)”, i.e. a checklist of whatever that needs to be worked in advance before the team puts time on something, in order to facilitate their workflow. WARNING: Be careful with DoR because it easily becomes an incentive to isolate the team from the analysts, designers, etc, and to postpone starting on features “before everything has been clarified in a document”, etc.
I have focused my examples on the ability to deliver value to your customers with fewer mistakes because it’s key to having a successful Agile adoption, but this is just an example; your ability to find small improvement opportunities is key. I’m pretty sure that you will find many other topics where you can apply the same principle:
“It’s easier to ask forgiveness than it is to get permission”
— Grace Hopper
If you are in a software development team, you can adapt many of these tips:
- Writing and automating unit tests to make sure the new code is not breaking what has been already delivered.
- Installing a tool (or creating a script) to run all those unit tests. There are plenty of them in the open source world, for example, Jenkins.
- It’s also a best practice to publish all your code in a shared repository. If you don’t have any budget or there is some company restriction that prevents using a repository as a service like GitHub, Gitlab, etc… you can install your own local server or you can share your local git repository. The goal is to be able to automate the build of your software artifacts so that you can make changes very quickly.
(Taiga repositories at Github)
Even if your teammates do not agree with these practices or you are working in a solo team, don’t feel desperate –read this piece of advice from JB Rainsberger. After a few months of writing unit tests alone, the perception of your work may radically change thanks to the lack of issues. Other people will eventually get curious and start to ask for advice.
Third: Adapt your expectations to your context
Agile can be explained in just one or two pages, like the Agile Manifesto, but it can also be very hard to apply because of the constraints and inertias that we will find during that journey. There are many benefits of adopting Agile practices, but we can get frustrated very easily if we don’t consider the limitations of our context.
If you don’t have a weekly (or bi-weekly) plan, start by having a regular meeting to come up with a prioritised list of tasks at the beginning of that period, review it at the end, and adapt it accordingly with the new information. It would also be useful to have a daily meeting to check the progress of that plan, focusing on the impediments you are finding.
In my experience, visualizing the plan, the work in progress and the blocked tasks also has the good side effect of allowing you to measure the way you work. Metrics are excellent tools to manage expectations inside and outside of the team.
Finally, it’s very likely that many of your blocked tasks may be related to other teams. Look for allies within those teams, try to understand their own impediments and find ways to help each other. Because adapting your expectations to your context doesn’t mean that you settle for it and don’t try to change it.
Fourth: Adopt an empirical approach to your learning
One of the biggest challenges we find when adopting Agile is the predictive mindset. We are too used to creating a plan that predicts the future: “by the end of March we will have delivered these 3 features and our users will be very happy with them”. Curiously those plans are very likely to fail, mainly due to the high uncertainty when doing that prediction. Instead, we should adopt a different approach that allows us to change our minds while we are learning (i.e. reducing the uncertainty) during the building process.
This is the point where every Agile consultant talks about iterative and incremental planning cycles as the best way to reduce the risk of not meeting our customer’s expectations. My experience says that we also need to work on the mindset. If you find it difficult to start with a framework like XP or Scrum, remember my previous suggestions and begin with small changes. Try and experiment with different approaches to solve a problem and focus on principles, not on practices to validate the outcomes of your experiments.
I’d suggest following these steps:
- Write a hypothesis and make experiments, try ideas, explore, play, and share the learnings.
- Create a habit with those practices that seem positive. (Don’t forget to learn what may slow you down in the adoption of the habit or its outcomes).
- Make the process official (e.g. writing the agreements on a wiki) and ensure you follow your own new rules. (Don’t forget to keep learning from the exceptions you will make to those rules).
- Automate as much as you can (e.g. create a script or adopt a new tool) so that you avoid human errors and make sure the rule is always followed. (Don’t forget to update those automations while you learn new things).
The more you do this, the faster you’ll improve your way of working. And as a side effect, you will also create the habit of thinking in experiments instead of predictive plans. Eventually, you will find it easier to propose introducing something more formal like any of those Agile frameworks.
Fifth: Be kind to yourselves, but always look for self-improvement
Because you are following a trial-and-error process to build your software, it’s very easy for you to fail in your expectations, so you must prepare to adapt with modesty and a self-improvement mindset.
(Retro exercise from Taiga post A Series of Fun Retrospectives)
Retrospectives are an ideal practice to find actions for improvement. They are also an excellent exercise to share everyone’s ideas to make our work better, but if you are not able to overcome your own ego, those conversations can be difficult. From time to time I like to start retrospectives with the Prime Directive (not the Star Trek’s one) but this another one by Norman Kerth:
“Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”
You can find the Retrospective Prime Directive translated into many languages here.
Bad communication of our needs is the main source of conflicts among humans. Learning to give and receive feedback is one of the most helpful skills that any team can benefit from immediately. Ask your HR department for help with this or read about it, but you must put it into practice with empathy. This is a skill that needs to be developed in the right environment.
Don’t be afraid to change. Making small improvements continuously will produce an aggregated effect of a big improvement.
“To improve is to change; to be perfect is to change often.”
— Winston Churchill
But don’t obsess with perfection; being kind, also to yourself, is key to having a good environment where those improvements can happen continuously.
A corollary: You can’t expect good results from Agile methodologies if you don’t provide your team with proper context
From the previous tips you may easily deduce that Agile will not work if we don’t provide people with the proper context. I’m sure you will agree with me that “First the process, then the tool”, but remember that Agile has an intrinsic social component, so bear in mind that “First the context, then the culture, then the process and, finally, the tool”.
If you are a team leader and want to get a good output from the benefits of practicing Agile methods with any particular team, you must get involved with them. Treat them as if they were truly your team, and behave as part of that team. That’s the fastest and cheapest way to understand what must be changed in your team’s context.
If you don’t have time for that, adapt your expectations to what Agile can do for you. You may learn how to delegate. Delegation board is a good technique to start agreeing on new responsibilities with your team members and giving them more autonomy. Teams with low autonomy and a high cognitive load may go far, but don’t expect them to go fast. If you are not willing to change that, adapt your expectations, otherwise help them improve their context. It usually means changing the way they are organised. A good reading on this is the book Team Topologies or something about creating devops teams.
Be patient, there’s a long journey ahead, but remember:
“If you want to go fast, go alone; if you want to go far, go together.”
— African proverb
These are just my suggestions based on my experience. It would be great if you put some of them into practice, but it would be even greater if you share how it went. Also welcome if you share this article with others.
