Since 2011, I have had the opportunity to work with project management and agile concepts. This path brought me many learnings, especially in the last five years when I focused almost only on agile practices. In 2019, I started working as an Agile Consultant, advising more and executing less. At Nubank, where I have been working since February 2020, I kept on doing the same kind of job.
By working for a relevant client, I clearly remember my first challenge as a consultant: a lot of pieces of information, data, opinions, tools, situations, and, of course, the client’s expectations around my job. That is how the first version of this framework was born. So, how can I know if my advice will be helpful and correct? What will I recommend to my client?
I have been improving this framework ever since. So I believe it is time to share my work with a broader audience as I have reached a certain maturity by testing it during all this time. Whether you are an Agile Coach, Agile Specialist, Agile Consultant, or simply an Agilist, you are probably looking for ways to help one or more teams in your company. I believe this framework will be valuable for that purpose.
Convergence: it is all about context
The main question is: What do we need to find? Problems that agile values and practices can solve! The pillar of this framework is to work in a problem-oriented way.
It is not about implementing a method to run in the team or an extensive methodology in all the company. It is all about the context of the team. So, in the beginning, spend time understanding correctly what the people and the work environment require.
When we start to help a group of people as a consultant, I believe we can observe these three spheres:
- You (including your expertise in the agile subject);
- The team (a squad, a Business Unit, or any part of the company);
- The work system (e.g., workflows, practices, business concepts).
An appropriate disclaimer about the word problem: when a person speaks to you about a problem, it is not necessarily a problem. It could be just an effect of a real problem. Verifying it will be your job.
Finding the convergence through three fields
And how can we find problems? I will suggest a way for you.
In the first field, you will observe what is happening within the team. So we are talking about group sessions (e.g., daily meetings, retrospectives, systems, workflows, documents, and whatever you have the opportunity to examine. Take a look at these three examples about what we are looking for:
- Group sessions: during a retrospective, for example, you examined a team debating relevant topics of the last work period, but the team is not registering action items from these conversations, or even the team has no registered plans from past retrospectives. It can be a real problem because discussions to find improvement points without action plans are just conversations;
- Workflows: for example, your team is working in a pull system way. You asked to check the system responsible for managing work items (demands, as user stories). But the team does not have good practices configured in this system, like different issue types for each demand type, a WIP (work in progress) limit established, explicit policies, or other plausible procedures. These situations can indicate lower maturity in good agile practices, a lack of specific knowledge, or another problem;
- Documents: imagine that you obtained the documentation of a specific project. You observed and verified it has no sufficient details about the solution in development or no precise expected results for the company. Furthermore, there is no connection between the company strategy and the project. Well, how can we know if this project is an excellent option to develop now? It is an example of how we can find points of improvement in documentation or similar things.
Exploring the last example above, what could be a piece of good advice to improve this situation? Is “you all need to document your projects better” a reasonable suggestion? Or “we need to have lessons to improve our project documentation skills.” This kind of advice is probably wrong because we need to check the situation behind these facts.
Perhaps the team has no time to write good documentation (a project one-pager, for example), and there is no time because the workflow is chaotic (causing lack of prioritization and work overload due to lack of control in the work process). Perhaps there is no company strategy to consider in the project prioritization, or the team does not have access to the business plan (both cases would be interesting to solve, by the way).
For now, record what you are observing. Understanding if what was observed is a problem, or if these situations are effects of other problems, will be your task later.
The second step is about opinions, and you can collect these points of view with the team. You will organize conversations and interviews with team members to collect perceptions about their work, possible problems, explanations about how they work, and so on.
I want to share the questions I frequently do during my interviews (you can adapt each sentence considering the context):
- What does your team do?
- What group sessions does the team have to organize all activities? Also, tell me more about the routine, tools, and similar stuff;
- How are the activities/projects prioritized? How does the team know what is most important to do?
- What are your expectations about my activities here?
- What are the team’s pains? What bothers the team?
Take a look at the word pain in the last question. It is related to perceptions, as I have said in the disclaimer above. Pain is about feelings, no matter if it is a real problem or just an effect. Use this word to be more assertive in your interviews.
If it is a small team, you can talk with everyone. But if you are working in a large structure (more than 40 people, I think), it will be relevant to choose correctly which people you will talk to. Two or three people per role, managers, and senior professionals could be appropriate options. You can organize these conversations in groups or in one-on-one form.
Furthermore, try to check before if the team members get along. For example, if a person has a problem with their direct manager, it will be hard to extract accurate information from them if the boss is in the same room during the interview. If you observe it, perhaps you already found one pain to work on (organizing a team-building group session, maybe?).
Finally, the third field is about the work system, and you will analyze DATA. NPS score, KPIs, flow metrics (e.g., CFD, Throughput, Cycle time), Burndown charts, and so on. Try to discover what is relevant to see about the work environment. As an Agilist, you need to find good pieces of information from data.
You can detect a problem in this step: the team has no data collected, much less analyzed. In this case, perhaps we have two options:
- Plan A: Extract data from systems and build graphics, reports, or other stuff to analyze this data;
- Plan B: Ask the team to collect data from the demands management system or build a survey to collect customer feedback.
In the worst possible case, the team has no data or a demand management system. If this situation comes up, I think the Agilist may have one more problem to help them solve. It is a bad idea to work without data in such a computerized world. We have a lot of good options to track our work and collect customer feedback. Do that!
Okay, but what are we looking for? Convergences between observations, opinions, and data. Which pieces of information are revealing the same situation? Or, in other words, which possible problems do you see as an Agilist in these three fields simultaneously?
Convergence in action: my first case
I remember my first insight about applying convergences, and my experience could be a proven example to understand this idea better. I was working in a software development company that builds digital products as an Agile Consultant.
During that time, I conducted some user interviews to learn more about the pain points and gaps. One of the interview outcomes revealed that teams often work on fixing bugs rather than working on innovative ideas and spending time on building new products due to lack of enough time. Two interview groups told me the same situation. This bothered some teams, but I did not know the number of bugs (vital information to understand if this really was a problem).
I then requested the team to share their flow metrics (for my luck, they had it done), and then I built new graphics that provide insights on all the teams working in that software development unit. There was interesting information revealed after merging the throughput graphics (organizing by issue type): almost 60% of deliveries in the last few weeks were bugs.
Is it a bad situation? Not necessarily, because it can be a temporary business strategy to solve problems on the product, but it was not in this case. It was an undesirable situation: the obligation to fix bugs was overwhelming the effort for delivering new features. And is this amount a problem? Again, not necessarily, as I commented before. In this real case, it was an effect of a problem: situations in the software quality flow, only to sum up the whole story.
You might be wondering: why did not I look at the metrics straight away? Could I have found this situation without the interviews? Yes, but the interviews were essential to guide my work and look for specific conditions. It is almost impractical to look at all possible metrics and try to find some problem to solve. Even if you discover something suspicious, it would not necessarily be a problem or even a priority for the team to solve right now.
Building your work plan: the diagnostic step
Okay, we have our records about observations, opinions registered, and data from the work system. You will need to organize all this per field. For example, mind maps are an excellent tool to organize all opinions obtained, mainly because you need to group them into big topics.
You do not need to have an action item for each item registered. For example, if many people have told you about the work’s lack of visibility, it is good to merge them in the same topic called “lack of visibility.” Take a look at this example for the fifth question above – “what are the team’s pains? What bothers the team?”:
The observations recorded and data collected (especially graphics) can be organized together in the same virtual environment. Take a look at another part of this real example:
- On the left side, a part of a mind map with five questions to collect opinions from the team’s members (the same image that I shared previously). There is another part about expectations of the main stakeholder (it is possible to observe above);
- On the top, data from the operation and flow metrics (Cumulative Flow Diagrams and Cycle Time Scatterplots from all teams);
- On the right side, some observations and thoughts about the future (the cloud has a phrase “where do we want to go?”). I collected these items organizing a group session to discuss the main characteristics of the team (good and bad), team’s history, challenges, and other things;
- On the bottom, NPS (Net Promoter Score) and other analysis;
- Finally, in the middle, we can see my initial plan and strategies to work in all identified opportunities (problems and goals, basically). Each card inside the purple rectangle is an action item to do. It is your time to shine and find possible plausible solutions for the situations identified.
Prioritizing the work plan
Is it time to get down to business? Not yet. You will need to validate your work plan with all the people interviewed to check if you understood the current situation correctly and prioritize the action items. Yes, perhaps you will have no time to address everything, and, of course, some problems and goals are more relevant than others, and you cannot identify it alone.
For this case, I used a simple doting-vote technique to choose which action items are more relevant and a value-effort matrix to prioritize them. Also, we agreed to review this plan every month.
How long did I spend doing these things?
Just over a month (it is a typical duration). Also, we have another fundamental part of the framework: quick wins. During this job, it is natural to find some situations easy to solve.
For example, I found a team using a kanban board with a step called blocked items. Okay, it is not necessarily an error, but it can be a problem for some reasons, so I explained the situation and recommended a slight change in the workflow.
In addition, I started retrospective sessions with some teams to find more opportunities for improvement because they did not have a continuously well-established improvement mechanism.
Time to work: the execution step
Now we have the second part of the framework: the execution step. During these years as an Agilist, I understood that we have two ways to work: in a directive way or in a constructive way. And these ways can change during your performance on the team (many times, by the way).
1. The directive way
As an Agilist, the directive way is to be the team’s knowledge reference: do more, determine how we should do something, and improve processes.
For example, we need to do better group sessions to discover new features for our digital product because it is a solution for a specific problem identified. For this, you suggested using the User Story Mapping technique. All right, who will execute it?
At this stage, you can do that to be the reference and teach other people by example. With time, you will only be the people’s mentor and probably will not need to help the team anymore in the future. The same scenario can happen in workflow improvements, group sessions facilitation, agile practices implementation, etc.
2. The constructive way
As an Agilist, the constructive way is about finding solutions with the team and involving many people in discussions: more support and less direct actions.
For example, the team needs to define their goals better. As an Agilist, you suggested a meeting to show some good practices to build it. So you will support the conversations and show the pros and cons of each technique.
In this case, imagine the team chose the Objective and Key-Results (OKR) methodology. Instead of facilitating the group session to help them find their objectives, you will teach them how to write great OKRs and support them to do it well.
In terms of time, it is easier to work in a directive way than in a constructive way. However, the team needs to trust you, and it can probably happen only after some time. So be careful with your choice.
Using a kanban board
Thinking about our work, do you remember the story about merging problems into big topics?
Previously, I showed an example called “lack of visibility.” So, you can build a simple kanban board for you and organize each big topic as an epic, and each action item as a task, putting all of them inside the epics.
Why? Because we need to be an example in terms of organization and measure our results too. It will help you prioritize your actions better and provide visibility to your stakeholders about your work. Also, we can use these big topics inside surveys to collect feedback about all improvements and changes that are occurring. I will leave another real example below (on the right side, you can observe some survey results):
By the way, I like so much to use the Likert scale in my surveys. For example, you can show this sentence to your audience: “The way we prioritize our work has improved.” Of course, prioritization needs to be a big topic of your work plan. Each person can respond if they “strongly disagree,” “disagree,” “agree,” or “strongly agree.” It will help you check if you are working well and support the team to solve the problems identified.
Focus on three areas
Finally, in this framework, there are three areas that we need to focus on during our work as an Agilist:
- Agile practices: as an Agilist, you need to know agile practices that can solve team problems. And of course, remember the values and principles of the Agile Manifesto, Modern Agile, and so on;
- Group sessions: you must be an excellent facilitator to organize and facilitate group sessions (e.g., retrospectives, complex meetings, team building, User Story Mapping, daily meetings);
- Management: you will need to manage your actions, stakeholder expectations, your work deliverables, and perhaps other things such as delivery effectiveness, continuous process improvement, and workflow management. All these things are about management.
The Convergence Framework
This framework provides a way to merge your observations as an Agilist, customer opinions (internal or external), and data in a problem-oriented work plan based on the convergence between these three fields. As a result, you will discover how to identify real problems and strategies to solve them, helping your team be more efficient and promoting an environment of continuous improvement based on agile practices.
I built the above summary to compile the framework. I sincerely do not know if it will work in many contexts, but it is still working for me. I made it in an empirical model (using what I have learned during my job). There are other specific situations, but as you know, it is a framework: you can add more things as much as you need. However, try to keep it simple.
As Agilists, we will face several challenges. Be sure to pay attention to what people are saying, always try to be organized, and continuously learn.
I hope this framework can help you in your path. If you wish, leave comments below. Thanks for reading!