Understand better the beginning, middle and end of the Agility specialist’s performance within the digital product development team

By Fabricio Pequeno and Ricardo Avigro

Considered one of the 15 emerging professions in 2020 in Brazil – according to a study published by LinkedIn, o Agile, or Agile Coach, or Scrum Master, or Agile Master, or Agile Expert, among other names given to the role of the Specialist in Agility, it’s one of the fastest growing jobs in recent times… But, you know how Agile’s journey is, its development and /or growth in this career? Or what is the lifecycle of this role within a team? It was with this in mind that we, Ricardo Avigro and Fabricio Pequeno, decided to write this article! The idea of ​​the Agile Journey was not meant to be a definitive journey, it was conceived from the moment in which a recurrent behavior in agile teams was noticeable. It also doesn’t mean that following this journey, you will achieve absolute success. This path defends that the agilist has a life cycle to fulfill within a team and exposes some important milestones, which we must pay attention to before demanding maturity and self-organization from people. Think about how, at any time, when talking to agile practitioners, you came across doubts about “how successful is this role?”. The role of Agilista has always left very vague how you can do things and how much you can do them…. We are not here to limit your creativity, nor your work, nor your background, but it is very important that we have a way to go. And, with that, this journey was born, one among many others that can be a good path to be taken.

… Now let’s get down to business, the Agile Journey

Lots of things happening, rushing, partial deliveries, activities entering the middle of the sprint, develops in this sprint and in the other forehead, “daily, why is this?” there is nothing positive”, but, in general, the team is doing well, delivers and is self-organizing to carry out its activities. Did you identify any coincidence with something mentioned? Well, we’ve already been through some situations like this, and then we thought: “What to do? Where do I start? How to act?”. With this in mind, we mapped what we call “Agilista’s Journey”, based on our experiences that worked.

Step 1 – UNDERSTANDING

I arrived on a team, now what? We understand that it is necessary to read the environment. OK! You’ve read it everywhere, so here we go… How to read this or what we call it, “Understanding”, which is divided into four steps:

1 – Understand who your team is, who the people are, talk to each one and listen to their challenges, their moment and their difficulties, without judgment! Understand the technical profile too, this is very important. You don’t need to go into code detail, but it’s good to know minimally; 2 – Analyze the current workflow. Some teams think there’s a workflow when it’s actually a go horse in disguise and, in the madness of everyday life, they can’t see how much rework they generate for themselves. Also look at the constraints, as many companies have processes that stem from the traditional model and sometimes we need to live with that for a while. 3 – Understand the product backlog and its prioritization. Yes, the Agilista can help the Product Owner with the backlog, question the prioritizations and help generate more value in deliveries, and this directly influences the next point. 4 – Know the purpose of the team. A team with no purpose becomes a task team, a software factory and that discourages people. There is no time or order for all this analysis, we put it that way because they were the points that we thought were the most important and that provided the basis for the next action.

Step 2 – ACTIONS 

After you have all this understanding, comes the most challenging moment and it can be contradictory with some literatures, but, it is time to “ACT”!

• Identify the problems, put together a proposal and present it to the company hierarchy – it is very important to always be aligned with your superiors.
• Present this proposal to the team and seek allies to implement this plan. Although many say otherwise and in agility we preach that changes are part of it, people tend to resist them, so the more allies you have, the better for the implementation of the proposal.
• Make this proposal visible to everyone, share the development journey, work agreements and whatever else you think is necessary.

One of the most difficult and crucial points of this step is identifying the saboteurs. Not everyone is prepared for change for whatever reason – and yes, saboteurs do exist and we have to deal with them. Like? Eliminate them! A saboteur will not always be a person, sometimes it can be a not very intelligent process that generates waste, but in general they are people, and they can be people from the team, from other teams that we depend on or even a suspicious and centralizing manager. This is the trickiest part, as we haven’t read it (at least I’ve never read it directly). But, in practice, the saboteur has become an impediment to improving the team’s workflow, proposal implementation, and/or daily life. And speaking of impediment, we agilists remove like no one else!

For each type of saboteur, we have an action type to take:

• One Person on the Team: I’ve read that the team must or may not allow a certain person there and, as agile players, we only act when the team signals. However, sometimes the team does not have the maturity for this or has not yet realized that a certain person is a saboteur. Therefore, you Agilista, yes, yourself, must put on your “general” coat and order the saboteur to be removed from the team. (The way to do this will depend on the autonomy you will have within the organization, but you should report the case to the person’s direct manager for the action to be taken. Remembering that you should always have examples of the situations that led you to make this decision and after feedbacks with this “saboteur”.)

• Centralizing manager: The ideal is to understand and minimize the fear or insecurity he has about the work, whether it’s lack of visibility, thinking that the team does a lot of meetings and “coda” little, thinking that the lack of a schedule impairs the vision, so the ideal is to understand and remove this “saboteur”, because even unconsciously or indirectly these attitudes hinder the flow and consequently the deliveries.

What we mean here is that, regardless of what or who is in the way, the flow progress and established proposal must be removed.

Another important point is to always encourage the team to take actions that guarantee the flow of the development journey, once established, it must be fulfilled. Always consider refinements and have dependencies mapped. They will be extremely important for team engagement in relation to Quality and Delivery – these are things that cannot be negotiated and one cannot go without the other. At this point we will enter next – which is also controversial, as many say that the Product area is not part of the role of the Agilista, but, in practice, how we work together with the person who energizes the role of  Product Owner< /em>, it is very important to guide and help. And how can we do this?

• First, ensure that the backlog is clear, available and understood by the team, and then by the entire company.
• Next, we must also make it transparent to all team deliveries.

Step 3 – SPREADS 

Having the visibility of the team’s backlog and deliverables, we began to understand and question whether these deliverables are aligned with the purpose of the product. And, for this to be possible, we need to understand and get to know our client, looking through the eyes of UX and UI, to learn about your journey and your experience using this product.

At this point, it is very important that you and the person acting as PO stay close to the role of Designer and the Product Area specialist. In fact, this partnership is essential at all stages and, taking all this understanding to the team so that they can participate in strategic decisions, brings a sense of “owner of the product”, and you will see that this will make all the difference. Finally, always thinking about visibility, we created a panel in which it is possible to show all product deliveries, focused on user experiences, regardless of teams.

Literature vs. Reality

Some literatures provide models of what we should follow, events with sequences in which, regardless of whether they are effective or not, they are important to do. We don’t think this is wrong, the point is that few times we’ve seen an orientation really focused on the Agile in all this…. It is understood that the Agilista must know how to behave and that the evolution of the team will happen perfectly as described from the proposed situations. The understanding of cycles is often applied to products and to the maturity of the team, but it is not applied to the evolution of the Agilista from the perspective of progress of the team as a whole. Our proposal is to make everyone aware that there is a life cycle for the performance of the Agilista within a team and that this cycle, from its completeness, does not indicate that one should have a promotion, but a success criterion, aiming career direction. Thus, we can look for another team in which our performance will have more expressive results – aiming at maturity as a whole in a company. These were some of the actions we took and made us achieve success in the projects we operate. Of course, we don’t always get it right and here we only tell you what worked… Leave in the comments if you’ve been through something like this and how much this journey applies to your reality. Thanks, until next time!