An agile team for a rapidly changing world
How Planet 4 team works with agile methodologies
In the midst of a climate emergency and its unpredictable effects, an adaptive mindset and ability to rapid response are crucial. People and organisations operating on the frontline of these issues need to be able to react fast to rapidly changing needs. That is why in 2016 Greenpeace decided to adopt agile methodologies to develop its new engagement platform to be more flexible and quickly adapt to changing realities.
How Planet 4 uses agile
The product team is composed by a team of 18 people working on different areas or tracks of the product. Throughout the project we have tried different methodologies for each track just to realise that there is not a one-size-fits-all approach to achieve optimal collaboration. Different frameworks work for different teams, depending on the size of the team, nature of the work, or even personal preference. In our team we have adopted a Scrum framework for the development track and a Kanban framework for the Data, Design and Infrastructure tracks. Both frameworks allow transparency on the respective progress and encourage rapid delivery through iterating cycles, ultimately aiming to reduce major leaps between deliveries and optimise efficiency.
Kanban offers a simple visual way of monitoring progress of our Design, Data and Infra team, displaying all the tasks related to their track in a board with different columns for each status (e.g To Do | In Progress | In Review | Done). This overview allows for better coordination across different members and mitigates bottlenecks. There is no specific work cycle length defined, but we usually do a weekly or bi-weekly review meeting to go through the work done and refine new tickets in the board.
Scrum offers a way to monitor progress too, but it also involves daily standups and sprints with specific events like sprint planning, review and retrospective. The sprint length of the development team is one week, and the goal is to create a shippable product after each sprint that meets our definition of done: Each task under a user story is completed and the code is developed according to our coding standards, peer reviewed, and tested.
The scrum board is made up of a sprint board, which is similar to a kanban board, except it only shows the tickets added to each sprint; and a backlog.
The development workflow for most of the features starts from the vision. Before ending up in the product backlog, the feature is broken into epics and stories to be analysed, designed, and tested. Only then it gets picked up by the development team and delivered as a product increment or shippable code that adds value to the product. Even though we release weekly, a release is not always in our definition of done. We are also trying to release more often those features that are ready to be shipped, so our team is currently trying out some changes in the process to achieve continuous delivery — an update about this coming soon.
On the infrastructure side, this track is also considered part of the development team but the tasks are collected in a different board to be picked up at a different pace, without being constrained in the sprint timeframes. More information about each track workflow can be found in our handbook.
Agile practices that work for Planet 4
- Measuring, evaluating and improving frequently. Agile works for us because it allows you to build faster by validating, learning, and adjusting. Working with one-week-sprints gives us plenty of opportunities to get and give feedback, review priorities, define and execute action points to improve. Having a dashboard to visualise sprint data also helps to keep an eye on the sprint metrics.
- Focusing on effort completed instead of team velocity. Our team has been changing a lot in the past years which makes it hard to stabilise the velocity and measure performance based on that. Instead of focusing on velocity we focus on the completed percentage of each sprint against the total committed.
- Self-organising team. Having a team that chooses how best to accomplish their work, rather than being directed by others outside the team, increases motivation in the team and high quality work performance. The daily stand-ups help ensure the team is aligned in priorities so that proactiveness of motivated individuals goes in the right direction.
- Doing what you can with what you have. Being adaptive and planning each work cycle with the information, tools and people available at that moment — considering shortfalls and designing work around them — prevents from being stalled because of the lack of resources (knowledge, people, budget) at a given moment.
- Visualising work in progress. Having a board that portrays the stories that are currently worked on helps visualise the focus of effort of each sprint. This way is easier to disperse team effort in different areas of the product like bug fixes, technical debt reduction and new features — to meet the needs of both users and P4 team members to better do our work.
- Updating the team frequently. Working in multiple tracks across a fully dispersed team involves a high risk of silos, especially if tracks are made up of 1 person. To avoid isolation we do a bi-weekly team meeting where teams from different tracks can demo what they have been working on. Apart from this, a weekly email is sent with an update of each track.
- Receiving constant feedback. Frequent retrospectives allow the team to stop and think about what is working, what is not working and how it can be improved. This helps identify problems faster and act on them before they hold up the entire project.
Where agile can go wrong
- Following the agile manifesto by the book just to try to develop faster without adopting an agile culture can be counterproductive. Scrum and Kanban are frameworks but agile is a mindset, and it requires the rest of the organisation outside of your team to be agile as well, otherwise your team will instantly see itself blocked by others.
- Agile is not only doing sprints and using JIRA. It is about iterating often on your product by releasing increments that add value, considering your users’ feedback.
- Moving fast can distract the team from making the right product decisions. Make sure you take the time to review the priorities considering the high level vision, have frequent retrospectives and follow up on the areas of improvement identified there.
- Having a plan or a roadmap with a strict timeline. It is important to have a roadmap that provides some direction, but these should be adopted on a rolling wave approach by identifying milestones and leaving room for flexibility to develop them and for milestones to change.
By following agile methodologies across our teams we can have a view of the progress from start to finish in every area of the product which aids in decision-making about what, when and how to develop. The agile focus on individuals and interactions, transparency and better collaboration, helps in keeping a team motivated and engaged. At the end, methods and workflows don’t build software, people do.
Get in touch!
Planet 4 is an open source project and we invite everyone to contribute so that together we make it the right tool that empowers people to make this world a better place.
Please reach out if you want to further discuss the article; if you want to know how to contribute, or if you are a full stack developer and you are interested in joining our team please reach out by email or commenting in this post.
We’d love to meet you!
