The Kin Agile Playground
In my post “Agile — why do we think it is good for Kin?” I explained why it’s important for Agile to be part of the Kin culture. We have three cross-functional teams, we have a vision, and now all we have to do is create what I like to call the Kin playground.
The Kin playground is the place where the Kin teamwork principles, project management tools, and process building blocks come together. The goal is to make this playground a friendly space for our tech teams, transparent to the management, and flexible enough to account for change. The processes that we are currently building to create this playground are meant to meet these goals, while simultaneously decreasing the amount of work that we need to invest in its conduct.
The Kin Teamwork Principles
We defined three principles to help the teams work efficiently together while achieving the best results:
- Extreme ownership and accountability
- Communication over documentation
- Quick delivery that enables fast learning
Extreme Ownership and accountability
We believe in extreme ownership. This means that as soon as someone assumes ownership he/she commits to delivering this block through the entire process, and to the time that it will take him/her to accomplish it. Even if there are other people in the process, the responsibility to deliver the task remains with the specific owner.
The process starts with the actual design and development, and only ends when the mission is complete, including the quality assurance and code review stages. The task always remains with the same assignee, and he/she is responsible for ensuring that all required stages are performed to reach an on time delivery.
The idea here is that rather than delegating responsibilities, the owner clearly communicates with everyone to make sure they understand the overall need and that their role in realizing it. For example, if I am accountable for a task and I finished development but a code review is now required, I will not simply delegate the responsibility to someone else. Instead, I will go to the person I need directly, or alert them during the daily stand up meeting, that I need their assistance.
Extreme ownership strengthens the accountability of each team member for their own tasks. This way, there is no uncertainty or ambiguity about each team member’s responsibilities. This helps them to work together to meet the goal.
Communication over documentation
Communication is an essential component of the day-to-day routine of the teams. One of the purposes of having the teams sit and work together is to encourage them to talk, share knowledge, and bounce ideas off one another. If for example one of the developers has a question for the product manager, they can simply turn around and ask him directly.
The entire team (developers, designers, quality assurance personnel, etc.) sit together and share the same goal at the same time. The more the team communicates throughout the process of development, the fewer bugs, issues and dependencies that will arise. Rather than over using documentation, long e-mails, or confluence documents with questions, they instead should talk, meet and solve issues together.
The entire agile process depends on clear communication between all team members. If the effort estimation is not communicated properly, the sprint planning will likely fail. If the team does not communicate, the process as a whole will probably fail.
In a way, you could imagine this to be similar to the Tower of Babel. There was a team of builders with no ability to communicate or finalize the project — and the tower collapsed.
We believe that communication is a key element in the process of creating great products.
Quick delivery that enables fast learning
The Kin marketplace is in the midst of being created, meaning that our playground is expansive and unknown. Basically, we are learning the market and its requirements in order to create great products. The best way to learn is to deliver as fast as possible and get immediate feedback. The only way to deliver fast enough is to examine whether we are focusing on the most important things and if/where we can do less. This is how we will be able to continuously improve the product in short iterations and meet community needs and requirements.
We have shortened the product development cycles using a process that has helped us learn a lot about the products at hand, on the market, and the actual users. The visualization of this process is therefore no less important than it’s actual occurrence. So, the tools we use have to help us visualize our process.
Project Management Tools
There are a vast number of project management tools that can help the organizing process. Which tool(s) a team decides to use is less important to us than whether it helps them reach the best results in a minimal time frame. The goal is not to use a tool that will overcome the process, or create extra work. We want to find tools that provide solutions to our needs without the necessity of investing too much time and effort. The tool should serve the process and not become a process in itself.
So, what are the elements a tool should have in order to help the teams in the development process:
- Backlog of tasks — There needs to be a complete view of all the user stories that compose the desired product.
- Macro view of the current active sprint — Each developer must know at all times what are the tasks at hand and how many he/she still has to finish by the end of the current iteration. This will help him/her assess the actual work capacity, announce setbacks and use their team members to assist. It also enables the product manager and the team lead to see where the fallbacks are and where they should invest more.
- Prioritization — The priority of each developer’s stories should be very clear, both to the developer and to the other team members. This helps create a better working process for everyone.
A good project management tool should enable each team member to better manage his/her time within the process and properly manage tasks within the current iteration, while providing them personal feedback on the effort estimation capabilities. And, of course, it should be easily managed by the product manager. User stories should be available at a glimpse, details should be easy to add, and prioritization should be flexible and transparent.
Throughout the process of re-arranging the Kin playground, we decided to try various tools that could help manage the process. We experimented with Jira, Monday, Github, Odoo and others. We spared no resource here, since it was important for us to find the best one to fit our needs. We discovered that most of the tools mentioned are capable of providing all of the above mentioned requirements, though in different manners. So in the end, each team was able to choose the tool that best served their purposes.
Process Building Blocks
The community’s ongoing feedback is invaluable for the continual improvement of the product, and Agile methodology allows us to adapt to these changing requirements.
The process building blocks are:
- Planning meetings are used to choose the user stories and tasks that will be handled in the upcoming sprint, while omitting others.
- Kickoff meetings are used to display the features at hand to the development team, answer questions and set a timeline.
- Daily stand-up meetings are used to focus the team on the tasks ahead and maintain the required flow of the sprint.
- Review/demo meetings are used to showcase the results of the sprint and review the actual outcome.
- Retrospective meetings are used to understand how to improve working procedures and processes for the next sprint.
Setting the Kin Agile Playground
Each team’s challenge is not only to create user stories for what is unknown turf, but also to guess which is the most relevant for the next product iteration. Which one will become a small step on the long road to achieve our end goals?
The teamwork principles are clear, the project management tools have been chosen, and the process management blocks are clear for everyone. With all of these things in place, we are able to open the actual playground where it all happens.
Over the course of the past few weeks, we created an agile routine. Each of the teams created a backlog where all the user stories were created, hence our short term road map. Our building blocks are basically the user stories. Each block represents a user story. All the user stories are piled up in the backlog along with general tasks or bugs that are discovered as we move through the building process.
In planning meetings the team consults on what are the most needed next steps that will help them get closer to the end goal — the product — and then choose the user stories that will be handled. Then, each team member assumes responsibility for the relevant user stories and makes sure they have all of the necessary information to accomplish the task. If they don’t, the product manager steps in to provide the missing data.
An effort estimation is attached to each of the tasks. This is not usually determined by means of development within hours or days, but in terms of size. For example, T-shirt sizes that represent small, medium, and large tasks. Or, alternately, exponential sizes of Fibonacci’s formula, where 1 and 2 represent relatively small tasks and above 7 large tasks. Tasks that will consume considerable effort, more than a few days, should be re-planned and re-sized. Meaning that the product manager should try and plan tasks that will not take more than a few hours and, at most, up to 2–3 days to accomplish. This minimizes risks and increases the accuracy of the final product.
The active sprint view, which shows the user stories that were chosen in the planning meeting, helps the team reach the goal faster and better. Through the sprint, all team members gather for a daily stand-up meeting where they update each other on the tasks at hand. They communicate and, if needed, set requirements such as QA, code review, etc.
The priority of each developer’s stories is set by one means only: the order of the tasks in the column. The higher the task, the more important it is. The person responsible for the order of the tasks is the product manager. Of course, the order might change from time to time according to changes in the product road map or requirements. But, the developers always work according to that prioritization in order to meet the final deadline. This way, the process can be organized in a gradual manner, with infrastructure tasks being performed before client side tasks.
At the end of each sprint, there are two meetings to help the team improve for the next one: the demo and retro meetings. In the demo meeting, the team actually displays the tasks that were accomplished during the sprint. This way, they reach the end of the task and are able to test it. The test can be internal by the team itself, through other development teams, or externally by actual end users.
The retrospective meeting helps us to improve. In this meeting, the team actually compares the actual plans and the results of the sprint. The idea here is to try to understand what the reasons were for any gaps between the plan and the result. By discussing the reasons for the gaps, the team learns to provide better estimates for the user stories and the actual time it takes to accomplish each. Through this, the team learns to communicate better and avoid misunderstandings and unsolved dependencies.
These are inseparable part of the process.
The Process should work for us
Each of the teams has different goals and they serve different communities, but they all have one common denominator — to make KIN shareable, usable and user-friendly. This is only possible by setting well defined processes with broad visibility, where everything is clear and flexible enough to adapt to ongoing change.
The only thing that truly matters is for us to reach our goal in the exciting Kin playground we’ve created. For this, all we need is a proper process.
Each of the teams is working at a different pace. Some have already released versions, others are about to release a version, and others are still working on the first iteration. However, all of them are using the same process to move forward, continually improve, and learn fast from the community what should be done next.
The end goal is to develop the best products for the Kin community.
