Scaling Processes and Developing People in an Agile Development Team

Scaling Processes

Scaling Processes and Developing People in an Agile Development Team

Last month completed two years since I entered the rocket Product team of Digital Results  (RD) and it’s amazing to look back and see so much that I could do and to see here. In such a short time we had a great evolution, overcoming many barriers, but we are facing something new: the challenge of scale!

How to continue innovating within our team? How to search for the best practices in the market? How to engage our employees in continuous improvement? How to scale our internal processes? How to develop our employees in daily practice? These questions brought me this far and I want to share a little with you the answers I found on this path.

Results what?

The RD Station had a great evolution – believes he has been brown? -, we developed new and improved several features for our customers, we changed our structure as a team – we are now formed by tribes that constitute autonomous teams responsible for specific themes of our product -, we use OKRs to monitor our strategy, we started the practice of experiments within product, among many other new improvements that emerged in just 24 months.

Talking about numbers is also surprising, going back in 2015, RD had not yet reached the milestone of 200 employees and today we already have an army of more than 500 RDoers, more than 100 of which are part of our Product team. Blue World City went through rounds of investments, RD On the Road and RD Summit breaking audience records and today we have our more than 10 thousand customers. It really is breathtaking, isn’t it?

The pains of the scale

Still in 2015, returning to our old headquarters in Celta, I remember that the alignment between our team and the entire company was very simple to be done. My manager and Head of Product at RD, Diego Pereira, had a chair always free next to his where anyone could sit there and exchange an idea with him, whether feedback from RD Station, a chat about Roadmap or about ours practices and processes. From there, after just a few minutes of talking, everyone could be aligned, it was simple and effective!

With all the scale and proportion that our team was taking, just one conversation could no longer have the same effect to align a team, let alone a company. Since then, some processes have been created and implemented and some tools have been used – such as Slack, for example – to improve our communication and alignment as a whole.

With each new galaxy that this rocket arrives there are several new challenges. Today, our selection process and the environment we have within DR promote an extremely strong culture in which the practice of our values ​​in everyday activities is clearly seen. This is an essential factor for all the growth that the company has had in recent months. When a problem arises, whether in our product, in some process or tool, our RDoers have a great deal of ownership to embrace the cause and find solutions.

Having a team of people with this feeling of ownership helps a lot in each new challenge, but in the current scale of growth we are having, it is very risky to depend only on the cultural factor without having a structure that seeks to guarantee its continuity. Dealing with a startup with an agile team that has Lean as one of its values, one of our biggest concerns is to have a strong culture of continuous improvement in all aspects within the company. The scenario of a new challenge that I embrace in this journey inside the RD rocket is then set.

The Importance of the Problem

How to ensure the practice of continuous improvement in a team that has grown on an exponential scale? This is the question that has guided me in recent months here at RD.

When I stop to reflect on everything I’ve learned in this period within the RD Product team, I can score several learnings, both in terms of technical and interpersonal skills, but nothing compares to the greatest learning I can have and take to my life as a whole: the understanding of the problem.

It sounds so simple but in fact, the appalling majority of people have an immense addiction to thinking about solutions before they even understand the problem at hand. When they are faced with a problem their efforts are focused only on thinking of a solution. And that has a very negative consequence: developing a solution that won’t solve your problem. That is, you will spend time, effort, and other resources – which come at a cost – and in the end you will not be able to get the expected result: solving the problem.

Albert Einstein once remarked: “If I had an hour to solve a problem and my life depended on the answer, I would spend the first 55 minutes thinking about possible questions to ask. As soon as I had the right questions, I could solve the problem in less than 5 minutes”. Another famous observation I like to make about problem understanding is that of Henry Ford, who said, “If I had asked my customers what they wanted, they would have said a faster horse.”

Both observations bring out the importance of understanding the problem. This is not to say that listening to your customer is not important, on the contrary, you should listen to your customer but asking the right questions and that will get the problem resolved quickly. Creative and innovative people seek to redefine the problem before devising a solution. This approach involves looking at the problem from various perspectives to first gain a deeper understanding of it. With this, it is possible to develop a better understanding of the problem and that will help to solve it more efficiently and innovatively.

The image above is well known and can be compared to a Swiss army knife because we can use it for various applications, such as explaining communication failures in projects or even as an example of problem understanding. But actually, I want to address it even more deeply in the cadence of a project, not only in communication but also in alignment with stakeholders, two major flaws of unsuccessful projects.

When it comes to an agile team’s continuous improvement project, communication to the team members is extremely important to notify everyone about the news that will benefit them. In addition, the monitoring of projects with visible management works on points of transparency with the team and control of deliveries. And this is where the main message of the image above comes in, the alignment with the stakeholders. Certainly, this alignment cannot be done only in the planning and final delivery of the project. The image portrays this situation in which expectation and reality may not be compatible when we talk about misaligned projects. Therefore, the importance of continuous deliveries and alignments between everyone involved in a given project is important.

So far we have raised several challenges regarding the understanding of the problem and the cadence of the projects, but this is small when we think about our great strength: our army of RDoers. Why do I say this? Because it was facing the challenge of continuous improvement that I studied the 70:20:10 learning model. It basically states that employee development in a company goes beyond seminars and certifications.

This model defines that 70% of employee learning comes from their professional experience, challenges and experience through problem solving and activities in the organization. Learning through interaction with co-workers, feedback received and questions that arise in daily life add up to 20% and only 10% is equivalent to the learning obtained through training, seminars and courses. Thus, companies that apply this model provide a work environment that allows the three areas mentioned to work, integrating theory and practice in the professional experience of employees.

With the understanding of the challenges regarding this theme, I was able to return to the question that guided me in this challenge and establish three main objectives:

  1. Increase the number of projects in the area with effective solutions, ensuring the continuous improvement of our practices;
  2. Increase the ownership of participation by Product RDoers in the area, providing support with methodology and tools;
  3. Assist RDoers’ personal development, understanding the practical importance of project management.

The methodology is important yes!

In vast research on the subject of continuous improvement, methodologies, tools, and processes I start to get very worried because there is nothing very applicable to our team. Much of what is found on the internet and literature on project management is extremely bureaucratic, involving several documents and meetings that have stagnated this theme in the industry. And that’s exactly why talking about processes within an agile team is not recommended at all – people are easily scared to hear this word – and it’s not without reason. But our challenges involved establishing processes and not just relying on the culture, so it was a barrier I had to overcome. The terms that most applied to the problem that needed to be solved were Project Office and Continuous Improvement Teams.

The Project Office is a well-known structure responsible for supporting project managers. He is responsible for conducting the company’s projects in an integrated manner, providing all the support and structure of resources and services necessary for the development of each initiative. Unlike products and processes, projects are collaborative endeavors with a beginning, middle and end. In addition, for its execution, it is necessary to use resources, both people and tools, and a deliverable is sought as a final result, and that is why the structure discussed above is so necessary to manage all the stages of each project.

While the Project Office is responsible for supporting and planning projects, project managers are part of what is known as the Continuous Improvement Team, which is responsible for executing these projects. This team is a rotating team in which its members volunteer to be project managers for as long as their respective projects are in progress.

As these references did not apply to our team because they were too bureaucratic, I sought, taking a more internal look, to understand our pains to propose solutions that could be applied to an agile team. With an understanding of our problems, I based myself on two models that reflected our culture to build an innovative and effective solution. These models are the PDCA Cycle and Lean Startup concepts.

The PDCA Cycle is an iterative management method used for the control and continuous improvement of processes. The main objective of this methodology is to make processes more agile, clear and objective. It is divided into 4 steps:

  1. Plan: the first step is to plan the work to be carried out, identifying the problem and drawing up an action plan;
  2. Do (Execution): in this step, the planned work must be carried out in accordance with the action plan defined above;
  3. Check: now you evaluate what was done, identifying the difference between what was planned and what was executed;
  4. Act (Action): in the last step of the cycle, corrective action is taken on the difference found, or if there is no difference in the previous step, there is standardization and completion of the plan defined at the beginning of the process.

Here in the RD Product team, we are used to working with Lean Startup concepts, and for this project, it was no different. In particular, the Minimum Viable Product concept was used to ensure continuous delivery of a project and to have alignment between stakeholders before its final delivery.

Continuous Improvement Program, the MVP!

Having very clear the challenges involved in the continuous improvement of our practices and in the development of RDoers with projects and having knowledge of important concepts to develop agile processes for a development team, the Continuous Improvement Program was created.

Basically, the proposal of the PMC is to promote a project management methodology so that any RDoer can develop them. This includes a kanban for defining the phases of each project and monitoring and control by stakeholders. The visible management of projects also facilitates transparency for all RDoers who become aware of the news that the area is developing with regard to the improvement of our practices. The methodology also has tools and templates that guide each project from understanding the problem to the final deliverable. In this way, the operational load is on the Project Office responsible for ensuring the operation of the entire project machine, also ensuring an ideal flow through a backlog. Project managers, on the other hand, should only be responsible for ongoing deliverables.

Currently, for each project, there are 3 fundamental people who work on this Kanban: the manager – project owner and responsible for deliveries -, the customer – a person technically qualified to monitor and charge for the project deliveries – and the leader – direct manager of the project manager. These three individuals are essential in the project planning phase: manager and client aligned on project deliverables and the leader aligned with the manager’s dedicated time on this project, after all, it is a parallel activity to your development team’s activities.

The simplified framework of the developed methodology is defined in 4 steps:

  1. Idea: the first step of the methodology involves understanding the problem, defining project success criteria and defending a proposal for its execution in front of the client and other stakeholders;
  2. Problem: with the proposal approved, the project manager starts to carry out an in-depth study of the problem, benchmarks with other companies that have already solved the problem and are a reference in the market and raises hypotheses for a solution;
  3. Solution: with the hypotheses prioritized with the client, the project goes through MVP phases for validation and if it obtains positive results, the solution gains scale so that a final version can be developed;
  4. Closing: Finally, the project is released to its stakeholders and closed with the Project Office, ensuring knowledge management of the documents and deliveries made.

And in practice?

We are currently running the Continuous Improvement Program with the Product team, we have a good adoption of RDoers entering with problems that turned into projects in our Kanban and proudly 100% of them are active in the methodology. In the first stage of the framework, we were able to work on the understanding of the problem with the project managers, managing to break the addiction to thinking about a solution without initially breaking the problem. We are defining the cadence of projects with follow-up carried out by customers and ensuring continuous delivery at each stage within the methodology.

RDoers who have already adopted the PMC are benefiting “because it gives clarity on the steps to be followed and ensures confidence in the progress to completion of the project.” In addition, some say that “working on projects made them more proactive, working on problems and ideas they believed were important, they feel they are, in fact, making a difference and improving HR as a whole.” With the opportunity to develop new projects in addition to the development tasks of their teams, the RDoers “can be monitored by the Team leaders and receive excellent feedback that drives them forward as a professional and as a person.”

This is just a taste of what we are developing here inside our rocket for our army of RDoers, just a few concepts that we cherish along with our strong culture for the continuous improvement of our practices and the development of people in our teams. Soon I hope to be able to explain more about the solution we developed and the results we are getting, bringing this opportunity to employees. If you identify with our values ​​and the way we face challenges and solve problems, check out the opportunities here on our team!

If you know of other continuous improvement practices and want to share with us, or have any questions or want to give your opinion, I will be very happy to follow you here in the comments!

 

Last month completed two years since I entered the rocket Product team of Digital Results  (RD) and it’s amazing to look back and see so much that I could do and to see here. In such a short time we had a great evolution, overcoming many barriers, but we are facing something new: the challenge of scale! How to continue innovating within…