Agile For Two
Many Agile coaches talk about the challenges of scaling Agile to larger teams, but more often than not, a common challenge that many smaller organizations face is, how do you practice Agile, when the whole team is only composed of two?
I ran into this interesting dilemma in Penbrothers, where there were only 2 people on the development team, the web developer, Ruben, and I.
Now, for those who aren’t familiar with standard composition of Agile teams the roles are usually divided like this:
- The SCRUMM Master to act as the facilitator for the project.
2. The Product Owner to champion the product, and define the user stories
3. The Developers to well…..build the product.
When the almighty development team only composes of two people, there is a tendency for the duo to throw any process into the bin, and jump straight into building the shit out of the website.
But the developer can only commit to doing two days in the week, and I also had to other roles to attend to, meaning that we strictly needed to build processes to ensure that we can make the most efficient use of our short time together.
The most common misconception about Agile is that it’s just a process for teams to build and ship quickly, but Agile is more than than that.
Agile, is summed up perfectly by coach Ian Pestelos:
“A way of working, a mindset that guides behaviors and creates habits”
Since my background is in user experience, and design, I acted as the SCRUMM master, and the Product Owner. This gave Ruben the freedom to focus on coding.
We made a backlog of features that the website needed, and prioritised them based on the business needs of the marketing and sales team. In order to keep tabs on each other, we held quick 5 minute stand up meetings every development day, and made use of Kanban Flow, Trello, and Slack.
Honestly, it wasn’t any different to how you would operate in teams of 5 or more, but subscribing to Agile versus nothing, makes all the difference.
What Agile does is empower all the team members to take ownership of the product.
I’ve worked with teams where there is no framework at all, no Agile culture. The “product owner” would just dump the brief onto the team for us to execute, and with us barely being able to pitch in ideas.
We ended up with standard plug-and-play solutions, with the development team barely being involved in the creative process. Not the best way to develop talent.
With Agile, we all became involved in the creative and decision-making process. There were many times during our stand-ups wherein Ruben would be the one to define the user story, and give his inputs on how to make things work. I also learned a lot more about development, and how to interact with programmers.
I hope this helps in letting product managers and developers, know that Agile is applicable for teams as big as 30, to as small as 2.