One of the techniques that we learn from Scrum.org and apply in every consulting process we do is “ Why Agile?”. This practice is the starting point of our work within an organization and you can also apply it in your day-to-day to be more successful in agile transformation.
But why the answer to “Why Agile?” is that important? Because if you don’t clearly define why you’re looking for Agility for your business; if you don’t establish what the expected benefits of this initiative are, the big chance is that this work will be done only by the method and not by the results.
So when we start an agile transformation process within an organization, we do a series of dynamics and this involves several steps, bringing together several stakeholders to understand the “why agile?”.
At first, there is no consensus, nor much clarity of the reason, and these are one of the dynamics that help us to build this, consolidating and landing…
Five common reasons for those seeking Agility
Among the many answers we hear when we apply this dynamic of “Why Agile?”, in this text, I want to introduce you to the five most common and that can help you to be more successful in the agile transformation. Check out:
“Because the market is doing this, so are other companies and I need to do it.”
The “why it’s fashionable” is one of the answers we hear most when asking why you want to implement Agility in an organization. Maybe that’s not the answer we like to hear the most, but, without judgment, it’s a pretty common reason.
“Because I want to be more agile.”
Okay, but what is being more agile for you? This is another common response, but one in which many people don’t have a clear definition of “being more agile”. To better understand this scenario, we do a coaching process to understand the real reason behind this answer.
Is being more agile to deliver more value? Is it delivering more tasks in less time? Is it to have more productivity? With these feedbacks, it is possible to better define what Agility is for that organization and for that group of leaders. Most people want to be more agile to be more productive and deliver more value.
“Because I want to have better deliveries.”
It is common to hear that teams work too much, work overtime, have a super exhausting routine and some even end up leaving the company. This has a huge impact on deliveries, which could be better and with less suffering. Therefore, they want to implement Agility to have a more fluid routine and deliver more quality.
“With the agility I will be able to better govern teams and projects.”
In many companies, the main reason Agility is being pursued is to have more transparency, more visibility, remove the impediments and be able to help unlock people’s potential and make things flow better.
“I want to mitigate the risks in my area.”
Finally, this is also a very common response… Many leaders want to be more agile to take control of risk. Likewise, they want to have shorter deliveries, they need a clearer definition of the product objective and good interaction between the stakeholders.
These are the main reasons we see in our daily lives why companies seek agile transformation. In short, when you clearly define what it ispoint B, that is, the place where you want to go and what you expect results, it is much easier to trace the path to get there.
“If you are not clear where you want to go, any path will do.”
I hope this technique can help you start your agile transformation process. If you want a little more details about this dynamic, how we do it and how long it takes, or something related, send a message here for us!
Having this answer is very important to help you not only to have a clear purpose when implementing agility in your organization, but to reach another level of productivity and get the maximum benefits from this process, in a much simpler way.
Now, if you want to apply this technique in your area to really know your objective with agile – and thereby shorten the path to transformation, we provide expert advice that will help you successfully make the agile transformation, getting more value with less pain.
Understand now how the application of agile methodologies works in practice to have a more efficient and agile team
Much is said about the benefits of using agile methodologies, not only in the technology area, but in several others such as Marketing, HR, Sales, Finance, etc… However, one of the most frequent questions related to this subject is “as a process organized agile does it really work in practice?”. Questions like, “Okay, I want to be more agile, but how can this work for me?”
Before answering this question, it is worth mentioning that, if you do not have a well-structured and well-implemented work process, your team is likely to be using waste or being very unproductive on a day-to-day basis. And this happens for several reasons:
Lack of clear purpose and purpose
Lack of clarity about roles and responsibilities
Uncertainties in the organization
A lot of rework and waste
In other words, it is no use having an organized work process, stored in a document within a network, and not implemented, that people do not live on a daily basis.
Benefits of an agile team
Furthermore, if you have a well-defined process and it is not traditional, if it has agile concepts incorporated, and it is practiced by each person, in the team’s daily routine, the benefits are immense.
When implementing agile concepts and methodologies in a team, he starts to:
Have chances to produce much more
Be more assertive in tasks
Enter continuous improvement cycles
Avoid waste and rework
Be more coordinated and give more visibility to the leadership
Improve communication between everyone involved
Be more effective and efficient as a whole
How to implement these changes in practice
Everything looks beautiful in theory, but what about in practice? To make your team more agile and with a better structured process, it is first necessary to understand that each team and company will have a different solution. That is, there is no right or wrong, but an organized method to meet YOUR needs and help you achieve YOUR goals.
This is our model for implementing an agile process for a marketing area, in this case. It’s not necessarily what will work for you, but it can already serve as a basis and help you discover your ideal format.
Photo of a model used in a Marketing area
To help you in this process, we selected the main points of an agile process implementation:
Set goals clearly
It’s no use wanting to use new work concepts within a team if it doesn’t have a clear vision of the purpose of the initiatives. OKR techniques are ideal for defining objectives and key results to achieve goals and get clear on what is happening in your day-to-day work.
“If you don’t know where to go, your team will probably always be losing.”
Structuring the to-do list
When we define the project or product vision, we start a backlog structuring, that is, we create an ordered list of tasks to be performed to achieve a certain goal. We used several dynamics and techniques to select these items (Design Sprint, Lean Inception, etc) and so created the Product Backlog.
Next, it is very important to make the correct prioritization and ordering of this backlog, starting the work with the most important tasks, or those that have more dependency, identifying and removing the impediments, etc.
Starting Sprints
After refining the items and defining the Sprint Backlog we started working on the Sprints – which are constant cycles with pre-defined periods to develop the deliverables. In this example of the marketing campaign, as the team was very volatile, we did one-week Sprints, because in addition to the still uncertain scenario, everything was adaptation and people were being trained and working in this new format, to Same time.
In this first cycle, the team must work focused on the Sprint Goal (goal for that period) and, at the end of each Sprint, we call a series of stakeholders to talk about the deliverables, the results, have the moment of feedbacks and adjust any item for the next work cycle.
It is noteworthy here that transparency and visual management are essential in this new work format. We use several techniques and concepts from Scrum, Kanban, Management 3.0, among others.
Enter a continuous improvement process
At the end of this new work cycle, stop and think: if we could go back in the past and do it all over again, would we do everything the same? Or would we have done something different? In this retrospectiva, it is possible to identify and select a point of improvement, and have a plan of action to work on it, along with the other backlog items, in the next Sprint … Thus initiating a process of continuous improvement.
Train people
One of the most important phases of implementing agile methodologies is acculturation. This is the moment when people go through a series of trainings, aiming not only to learn new concepts, but to really change the paradigm and reach the goals. We apply several official trainings (with certification) to raise people’s level of knowledge and practical experience.
Have metrics and data
This new work format is useless if it is not possible to measure! Have data and metrics, both result (outcome) and task (output) metrics. They serve to understand how this initiative is being positive or needs adjustments. It’s these indicators that help guide the team to be better every Sprint!
Remembering that, if you don’t have the right people to help you, this whole initiative to have an agile, more organized and structured process may fail. If you still have any questions about this transformation, speak with one of our consultantsif you request a diagnosis to find out if the methodologies Agile will work for your team.
Want your team to work in a more agile and structured way?
Understand how agile methods can help different areas and teams to have more productivity and organization
In 90% of cases, the answer is YES.
When we talked a little more with these people, we mentioned some common situations in teams that need to be more agile. Some of these issues are:
Lots of external interference
Things that prevent you from delivering your tasks, and that would often need leadership help
Priority changes – sometimes you get lost not knowing what the next priority is
Little visibility of what is happening in the organization
Poor visibility of peers – sometimes some are quite overloaded, and others not so much
A lot of uncertainties about what the real purpose of the project is, like knowing if what I’m doing is really generating value
Productivity and delivery issues
Sometimes bureaucratic processes
And, sometimes, we even ask the leadership, in addition to the characteristics in the list above, if they have any of these problems:
Low visibility and team transparency;
Difficulty of organizing between teams;
Difficulty in having dates and deadlines;
Complex structure to lead;
Problems for decision making;
Basically, if any of these points above are present in your team’s day-to-day, whatever your area, our answer will be: “YES, agile methods can help you increase control and productivity” .
People often spend too much time on things that don’t generate real value, neither for their deliverables nor for the organization as a whole. As a result, a very large loss of productivity is generated!
It is as if an area or a certain team were a machine, which is not being efficient and is causing various wastes…</p >
How to use Agile methods to be more efficient in any area?
Being agile is not just going through a process to be more efficient and have more results. It is going through a paradigm shift, of mindset, using not only agile methods, but several tools and techniques that make this process a true Agile Transformation.
Essentially, we use the concepts of Scrum, Kanban, Management 3.0 and OKRs to define roles and responsibilities, events and details of this team’s new work processes.
The principles and characteristics of a truly agile team are:
People who have information transparency, with a lot of visual management, escalating problems quickly;
Teams with clear and engaged goals, working in SQUADs;
customer centric product view, mapped to a single backlog;
Have important visible metrics;
They can solve complex problems;
They deliver in short cycles (they are iterative and incremental);
Promote continuous improvement;
Quickly identify and remove impediments.
How we apply it in practice
To help you better visualize this process of change, here are some examples of Agile Transformation in different areas:
Legal Area
A team of a project formed by specialists from the Financial, Logistics, Accountants and Lawyers area, had the challenge of changing the structure of production of consumer goods, with the goal of having fiscal gains reaching millions per year.
Several months passed and this problem was not resolved. With a mini Lean Inception, they created the backlog, set up the Squad and, with visual management and indicators, started running the Sprints . In a short time, problems and impediments appeared and were escalated to the board. Little by little, the situations were resolved, focusing on the objective of that indictment and the benefits began to be achieved.
Marketing Area
Some teams in a marketing area wanted to have more control over demands and processes. With some agility concepts applied – and also agile scaled – a governance process was created, in addition to helping the teams deliver in the operation. Quickly, teams entered a stream of continuous improvement, until they reached the ideal process to really be more efficient and agile as a whole.
Human Resources Area
An HR department needed to make its deliveries more agile, but with more value to the organization. For this, the journey of employees was mapped – since when they entered the company; when they had doubts; when they use the month-to-month process and when they leave the company.
For each part of this user journey – in this case, the collaborator, a Squad was assembled, with a backlog, using Kanban, working with < em>Sprints and OKRs. Week by week, the employee’s journey was improved, aiming at achieving the area’s objectives.
Company-wide training
In this case, the concepts mentioned above need to be applied to the entire company, but not in their entirety. This means that, many times, an organization will not have Squads, Sprints, etc., in every organization, but many of these practices and the paradigm shift are the main points that will help in productivity as a whole. .
For this, training such as Agil Beyond IT is made for the entire company. Each employee will identify what can or cannot be applied – flow visualization techniques, mapping of impediments, daily meetings, sprints, among other topics. It is worth mentioning here that, by empowering your team, it becomes more productive!
We hope that you really can make your team, your area or your company more agile and more efficient with these tips.
Understand how these multidisciplinary teams help a company to deliver more
By Antonio Costa< /h6>
We visit several areas and companies throughout our consulting process, whether in the product development, programming, human resources, financial, sales, business area, among others, and a very common question is:
Does the SQUAD format really work for organizing teams?If it works, is the way we’re doing it really effective? Is it possible to improve something?
Basically, SQUADs are an organizational structure of people of different abilities, who have a very clear objective: to have more value delivery. Different from the Traditional model, SQUADS are multidisciplinary teams, with fewer silos, less hierarchy, more autonomy, focused on their principles and objectives, that work to solve a problem or challenge within an organization.
Spotify created this model to solve a challenge they had in the time and, as it became popular, many people began to copy this format of organizing people. And so it became a herd, gained a giant proportion, many began to organize themselves in SQUADS, but without the slightest notion of Agility, of Product development, believing that having SQUADs already made them agile companies.
As there is no body that determines and regulates this issue, in this text, we will address this issue based on our experience on this issue.
The pillars for good SQUADs
But, in fact, what is the purpose behind them? As mentioned above, SQUADs are focused on maximizing the delivery of value, and for that, they are anchored by four pillars:
– Multidisciplinary team
They are made up of people with different abilities who, together, have the mission of solving problems in a certain area of the company or challenges in product development.
– Autonomy
Within a SQUAD, people have autonomy to say how they solve a given problem. It is very common to see teams in which the members only perform various actions that the boss determines. If there is still an external command with a lot of control, you are hurting this principle of autonomy inside a SQUAD.
The idea is to bring people of different abilities together in a team, making it as productive and creative as possible, giving autonomy to these people to solve a problem.
– Clear objective
None of this works if the goals are not clear! That’s right. It is necessary to have the purpose of this initiative very explicit: “which problem must be solved?”.
– Restrictions
These limits should be created so that people can do what they want, as long as they don’t violate any of these restrictions. Some common restrictions are: setting a time to create and develop that product; or amount of money; or even a restriction that does not violate the organization’s principles.
The SQUAD concept comes from squad, platoon – just like in a war room – you assemble a squad, in which “mission given is mission accomplished”. In other words, a SQUAD on the first day of work is practically a “war room”: you bring people of different abilities together, with a very clear purpose, give some restand they work to solve that problem.
But can you scale this format to every organization?
Yes! The Spotify model suggests several ways to solve a very complex problem, with several SQUADS, through other structures such as tribes, chapters and guilds. .. But that yields another article! If you want to know more about how this scaling part of the Spotify model works, leave your suggestion here in the comments that we can say yes about it!
In addition to all the scaling techniques, Spotify’s SQUAD model also has a series of principles such as:
Waste aversion – where they continually seek improvement points to avoid wasting time or money;
100% predictability equals zero percent innovation – that is, if you want to do something really innovative, you can’t be totally predictable… You have to allow people to fail, or failure to be better viewed , as long as it stops in search of solving that particular problem;
Among other principles…
If you want to know more about the principles, leave your suggestion here in the comments and we can talk about it too!
Don’t try to fit into a template!
The big message I want to leave to finish this text is from an error I saw in a company and that I should bring here to exemplify something you should not do: just change the name from “team” to “squad” and do not incorporate really the principles that the model has.
Aren’t you also trying to fit your area or business into a box, in a ready-made format?Do not copy Spotify! Understand the principles, purposes and learn with him to create YOUR MODEL, the one that best matches your reality. Spotify itself would not use this model today, as they learned with this format, used various techniques such as Scrum, Kanban and were adapting it to use it in the way that fits best today, always focusing on the goal of develop good products, efficiently and effectiveness.
You want to achieve these results, like Spotify, be more digital and deliver more value to your organization, but you don’t know where to start, we help you!
Many companies want to make the agile transformation so that they can better organize their teams, in order to deliver more value and ensure more competitive advantage for the organization. However, throughout this movement of change, as we went through several companies with our consulting or assembles squads, we have identified some very common behaviors.
And we’ve resolved to bundle these top mistakes during an agile transformation, which are holding companies back from achieving results and getting the most benefit out of this process. Check out:
No short deliveries
Both in the transformation process (we perform the Agile Transformation process, in an Agile / incremental way – click here and learn more), as well as in the day-to-day of the teams that work in the development of the Product, it is essential to have short films delivered in order to be really agile. It is these deliveries, made with correct slicing and prioritization, that promote the inspection and adaptation mechanism – one of the main pillars of agility.
Think only about process and forget about Engineering
Another typical mistake we see within companies undergoing an agile transformation is to focus too much on the process and leave software engineering behind. To extract the maximum benefits from this journey of change, you need to pay attention to the quality of your engineering.
One of the items of the Agile Manifesto is precisely having a good software architecture and an adequate design to enable teams to have more shorter deliveries that can make Agility concepts be well used within the teams routine.
Do the mechanic and think it’s okay
Another failure that happens a lot is to think that the concepts and pillars of the Agile or Digital Transformation are just more processes and not giving the correct depth they have. It is not possible to have a traditional mindset (waterfall), using only some techniques or mechanical processes of the agile frameworks and achieving the estimated results. It takes a real mindset change!
Do you really want to change your organization’s mindset and have more engaged teams with more productivity? Click here and schedule a conversation with us.
Climbing too early
Still talking about depth, if you haven’t managed to make this transformation in a small cell within your company yet, don’t start scaling this initiative to the entire organization. This process of transformation, whether agile or digital, is based on a cultural change, a turning point in people’s thinking… And this change calls for the correct training to be carried out, the breaking of ties that exist in the daily lives of teams – that make them not have the necessary performance, among other characteristics, which take time to be modified. So it’s important to know the right time to start climbing!
Don’t measure and learn during transformation
The fifth mistake we most identify in companies during the agile transformation is not measuring and not learning along this process. Deliveries are being short, software engineering is getting the right attention, you’re putting agile principles into practice in the right way, you’re scaling at the right time, but do you have indicators for all of this?
You need to be data driven and use the data to measure theWhat’s happening. This will help you know if you are really delivering more value to the organization with these initiatives. Is the teams’ productivity higher? Is the number of impediments decreasing? Is lead time decreasing? Are users and customers satisfied with the product? These are some questions that need answers, data and analysis to help you measure and learn from this transformation process.
Low product and customer focus
When we talk about agile transformation, we have three main pillars: processes and/or management, engineering and product/customer. When you don’t focus properly on the product and the customer, you don’t have, for example, prioritization techniques and you don’t know what is really value and what is success for a project. You can work with any method, but if you don’t give proper attention to the product and its user, you are probably generating a lot of waste in developing this business.
Read more: You seem agile, but not focused on the Customer? You’re probably losing the game!
Finding that Agile is an end and not a means
The seventh mistake we see most in agile transformation processes practically consolidates all the previous failures, which is to think that Agile is an end and not a means. This is very common! During our consultations, we hear a lot of people say that they want to be more agile, they want to implement the Spotify model, etc… But what organizations should want is not these formats, but:
Get more results
Doing more with less
Increase Efficiency and Effectiveness
Competitive advantage
Making the technology area a protagonist within the organization
Delivering more value to the business
And, to achieve the above goals, Agility comes as a means! If for this you need to use other principles and concepts other than Agile, that’s fine. The important thing in this transformation initiative is to achieve the goals, that’s the end.
If you have identified some of these errors in your daily life and want to correct them, contact us. We can make this diagnosis in your company and help you to have more results!
The way we develop products is constantly changing. Currently, companies around the world are adopting agile product development, using some of its frameworks (Scrum, Kanban, Lean…).
This new way of working affects all traditional roles, including Test Analysts, or QA (Quality Assurance).
In this article, we’ll talk in a basic way about the differences between traditional QAs and Agile QAs, as well as a brief concept about agility and the Scrum framework.
Traditional context vs. Agile context
In a traditional context, project steps are planned in advance, before the start. The scope is defined and cannot be changed once development has started. Any change requires an approval and a new contract between the parties. The delivery date is also defined.
Moving from one stage to the next requires inspection and approval. This context is also called a waterfall (waterfall), and generally follows the model in the figure below:
In the agile model, the software is delivered in small pieces, usually already functional, within a period that varies from one week to one month, in the case of Scrum framework. With these small functional increments, you can quickly adapt to changes. Being agile is not being fast, but being adaptive!
Traditional QA
Based on the figure above, we see that testing only happens in the fourth stage of the project. At this stage, the software is practically ready.
Generally, in the traditional context, QAs do not have direct contact with developers. In this situation, QAs practically hunt bugs, sometimes the number of bugs found being a measure of performance.
Under these circumstances, only QAs are responsible for the quality of the product. It is they who ensure that the requirements have been met correctly. Any error in the software, or non-compliance with the requirements, is the sole responsibility of the QA person.
The Testing Manifest
The Agile Manifesto was created by a group of people who wanted to change the way software was developed. A few years later, following in the footsteps of the Agile Manifesto, the Testing Manifesto was created :
Test through all steps MORE test at the end;
Prevent bugs MORE find bugs;
Test understanding MORE THAN check functionality;
Build the best system MORE THAN break the system;
Team responsible for quality MORE THAN QAs sole responsibility.
Agile QA
Taking the Test Manifestos as a reference, we will describe here a little bit of how Agile QAs should behave. As in the Agile Manifesto, the item on the left is more valued than the item on the right – it’s not a replacement, you’ll keep doing what’s on the right, however, you’ll prioritize the left (not to be confused with politics ok!?) . Therefore, Agile QA must:
Test through all steps [more than] test at the end
Testing should start at the planning meeting. Based on the defined acceptance criteria, it is already possible to think about the test cases/scenarios that will be carried out.
If the team already has a test-oriented mindset and performs TDD, BDD or another technique, it’s time to combine the division of tests (application of the pyramid or another strategy); define what is worth being automated; how will the continuous integration be, etc.
It is also recommended that QAs do code review and pair programming. Many bugs and inconsistencies can be caught during development just by looking at the code, which leads to the next topic…
Preventing bugs [more than] finding bugs
With testing being done during development, the chance of a bug going into production is much smaller. At this stage the bug fix can be immediate, as the development team is working on the functionality.
Depending on knowledge, the moment the bug is discovered, the QA person can fix it himself.
Test understanding [more than] checking functionality
Quality goes beyond verifying that the software works as described. This can be done by a robot.
Quality also encompasses understanding the user’s need and ensuring that the need is really what the user needs. For this, the user must also participate together with the team in the development, as much as possible.
Build the best system [more than] break the system
As part of a team, pinpointing bugs and finding ways to break the system goes against the goal of delivering the best software possible. We have to keep in mind that flawless software does not always mean quality software.
The best system is the one that solves the pains of its users. Work for it.
Team responsible for quality [more than] QAs sole responsibility
Placing quality responsibility on just one person or area is to exempt other people involved in the process from any problems that will be identified.
Everyone who takes part, directly or indirectly, in developing a solution must be responsible for delivering the best possible within their role.
QAs may not be developers in the sense of being the person who codes the application, but they develop tests and are part of the development team. Everyone who contributes to product development, including designers/UX, is a developer and must be responsible for the quality of what will be delivered.
Working together
As the team is responsible for quality, QAs must be present at all stages of development, helping the team to deliver the best product. The figure below shows how, at each stage of the Sprint, QAs can contribute their own responsibilities and help team members.
Also, as part of the team:
help you find the right product;
collaborate to specify;
think of examples;
refine the specifications created by the team;
automate the specifications;
help maintain Continuous Integration;
help keep the Living Documentation up-to-date and accessible.
Traditional QAs vs. Agile QAs
Summarizing in topics the differences between traditional QAs and Agile QAs are:
Also, Agile QAs:
they are always learning new skills and technologies, adapting to change;
practice clear and effective communication, collaborating with technical and non-technical people;
understand the business, defend the product and collaborate with the customer;
disseminate the culture of quality and take care of the team’s health;
promote and get feedback, having the courage to expose what is wrong and praising what is right;
keeps simple and self-organized, not depending on instructions to carry out its activities;
like what they do 🙂
Are you in the traditional or agile context? If in traditional, would you like to go to agile? If in agile, does it do what was described in the text or is it already beyond? Leave a comment here!
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!
Understand how the focus on the user and their journey should be the central point of development for a successful digital product
By Antonio Costa
Many companies that are in the Transformation process, whether Digital or Agile, are making a very serious mistake in their Product Development wake. There is a strong focus on the Product and a low focus on the Customer. This makes the organization even have more organized and faster deliveries, but still ineffective.
And do you know why this happens? Sometimes the company has a big focus on making money and doesn’t realize that if it pays more attention to the customer’s pain and tackles those pains in a more organized way, the profit follows.
For this, there needs to be a change in thinking, which we call here “Focus on Products to Focus on Journey and Customer”. I’ll explain better what this concept consists of.
Product Focus
It is when an organization looks only at its product, forgetting its customer – the product comes first. It may even have an agile team or agile practices, but probably the predominant thinking will be traditional thinking, which makes the team seek operational efficiency. Companies focused on excessive efficiency, or with a great focus on the product, have some characteristics, such as:
Begin analysis for product or feature creation, by internal systems – the internal system will shape the solution;
Focus on closing requirements, getting everything detailed;
Business and IT areas still working separately, where there is not great trust between them;
Development teams looking only at their delivery, looking to deliver more tasks;
Malignment of channels, as the focus is on efficiency, one channel does not need to wait for the other;
Great focus on team productivity;
Changes to requirements are not welcome;
Focus on releasing new features, without measuring what already exists;
Delivering the product is more important than the quality of what is already done.
This list can be extensive and a new text would fit here to enumerate more features and even detail them…. However, let’s talk about what really matters: the correct model – Focus on the Journey and on the Client.
Focus on Journey and Client
When a team focuses on the journey and the customer, it means the end user is REALLY at the center of all product development. Understand a little better about the characteristics of this team:
It starts with the customer’s need to define the viable solution;
The journey of users and personas is clear;
Business and IT areas working together daily in a collaborative way;
Teams orchestrating deliveries, with a focus on value;
Equal experiences in all channels (omnichannel);
Short cycles for collecting feedback from customers;
Analysis based on customer data;
Opening for scope change;
Focus on the customer as well as their emotions;
Company goals focused on business or customer, not project delivery goals;
Great concern with product quality (because if you launch something that doesn’t work right, nothing will add to the customer;
concern about measuring used and unused features and simplifying features – rather than releasing more new stuff;
This list doesn’t end here either, but it contains the main points we see in the market. The big change, in general terms, is to be concerned with the customer’s experience, in their journey using that digital product.
Exercise
Having seen the points above, I suggest you go back to these lists and reflect: “How many items above can you identify in your team? Are they working with customer focus or more product focus?”
I also suggest you put yourself in the customer’s shoes, but in the following way, for a moment:
Remember a service or product you recently consumed that provided a very unpleasant experience for you… Remember before you go.
What did you feel? Anger, impotence? Did you think or speak ill of this brand? What was your attitude?
Now ask yourself: could the product you are creating be generating these same feelings in your user? Could he be complaining about your brand or is he disappointed with the experience he had using this product?
Finally, keep in mind that the customer will consume your product not because you use Scrum or Kanban or any other agile method; not because you have legacy or disruptive technologies; the customer will buy your product or service, because it generates some benefit for him or solves a pain in his daily life.
And if you want to ask any questions or talk more about this subject, leave your comment here or contact us!
Your team releases several features, works hard, but the results don’t show up? Now understand the main causes of all this
By Filipe Machado and Thiago Fregni
In any business, whether it is a digital product or not, one of the main concerns is to meet the needs of the stakeholders and this ends up becoming one of the main goals to be achieved. With this, the team works hard, strives to launch several features, but is leaving aside a very important goal: maximizing the value and return on investment of that initiative.
In other words, even though Agility has been implemented and deliveries are happening more quickly, there are still stakeholders who are super unhappy. “There is nothing so useless as to do with great efficiency, what should not be done.” This quote by Peter Drucker is one of those that can summarize this scenario in a simple way. The team is working well, with a lot of functionality in production, but are they doing something really useful?
Does this sound common to you? Because it really happens in many businesses that are starting a digital transformation and for three main reasons:
Value maximization and Return on Investment
Generally, the Product Owner is very concerned about serving the stakeholders and ends up leaving aside one of their main responsibilities, which is maximizing the return on investment</strong >.
Sense of purpose
It is common for the team (Agilista, PO and Devs) not to know clearly what the objective of the product is or to have no vision as to why they are working on a certain demand. They know what it is, how it should be done, but not why – have no sense of purpose!
Discovery/Ideation/Upstream
Product value maximization, that is, what the customer receives at the end, needs to go through a process of discovery and refinement, before starting development. And that’s not always the case!
But what is the root cause of this problem?
It is possible to identify some signs that cause these situations described above. The main ones are:
Low autonomy for the Product Owner, who depends on other people to make decisions and clarify details;
Product Owner who does not have the correct competence;
PO order taker (Proxy/Scribe PO), which does not have ownership of the product. It takes note of the requests without understanding the reason for the request and what the expected results are;
Time is concerned with filling the capacity. That is, during Planning meetings, there is a greater concern with “fixing” enough backlog to keep everyone occupied, than actually generating value for the customer;
PO that doesn’t know how much each PBI costs and has no idea of the team’s cost, which makes it impossible to make trade-offs based on RoI;
Teams that do not have clear goals, making it impossible for them to make choices and stay focused on what generates the most value;
Does not have Discovery (UX). That is, as soon as the request arrives, it goes straight to the team to develop. There is no process in which the customer is involved and hypotheses are treated as truths;
There is no Customer Centric view, focused on the consumer/user.
When we identify this scenario – which is quite common, we do a very intense job of coaching with the Product Owner, with the Scrum Master and with the stakeholders. For this, we perform techniques such as:
– Create a discovery team: in order to find out which features should be implemented to meet the users’ needs;
– Techniques for sorting the backlog: the backlog must be sorted and these techniques help us sort them according to the goals to be achieved ;
– Create an agile treadmill very clearly using Flight Levels: this technique gives portfolio visibility until reaching the end user’s hand;
– We organize teams by Value Stream linked to the users, with clear objectives, using OKR’s, for example;
– Definition of product objective and make it clear what value (increase sales by 10%, increase conversion rate by 5%, among others) expected to be achieved by that item, plus value of items;
– Roadmap: an overview of the product’s next steps;
– Use data for decision making in backlog items;
– Hypothesis Concept Creation: a great way of working that helps to validate hypotheses is called HDD (Hypothesis Driven Development). This method helps in writing our backlog, aimed at validating hypotheses.
In general, we try to give the correct purpose to the team as a whole, linked to value for the customer or business… Because when you don’t know where you want to go, any path will do. And so work becomes efficient, but not really effective!
More value delivered, with less investment
Solving these flaws during the product development process with an agile team, it is possible to have several benefits, including:
Be able to work in the empirical process, always focusing on the desired objective;
It makes it easier to manage stakeholder anxiety about results;
The stakeholder is happier with the delivery, as it is linked to the purpose, with a focus on really generating value with the initiative;
The stakeholder’s trust with the team improves;
In short, more value delivered, with less investment and a focus on maximizing the initiative’s value and return on investment.
We hope you can apply these suggestions in your daily life. Any questions, we are available to help… Just contact us!
Initiating a transformation in a company, be it agile, digital or cultural, really is a very significant decision, considering the impact it has. Even though positive and with so many benefits, this journey of change still generates many questions in the minds of leaders. And so, let’s share some of the common questions about implementing an agile transformation that we’ve heard of lately.
“Is open scope a blank check?”
This is the first of six common questions when implementing an agile transformation, especially from IT managers: “Is open scope a blank check?” Agility is often confused with mess and lack of commitment to delivery goals. Therefore, the first way to mitigate this stigma is precisely to understand the purpose of what should be done.
Here’s one of the differences between features delivery and value delivery:
Another feature that is very important in the SCRUM is the delivery of value increment in each Sprint . A project that, every 14 days, has a software delivery running, generates much more transparency for the client.
By the way, another characteristic that should be taken into account when these doubts arise when implementing an agile transformation is transparency. A scoped project quickly introduces the typical blocks, that prevent software from going to production. Proceeding on these points in an honest and non-personified manner allows the stakeholders to act and resolve these blocks so that the whole project succeeds.
Finally, the development of a project can undergo several adaptations. Whether by changing the target of the project, some block or a change in the market. Open scope doesn’t hide behind a pre-defined contract, but engages customer and supplier around one goal: delivery in production.
“But what will I get?”
We talked a little about the differences between scope and value. Invariably, this value means software in production – and fast. Therefore, this second question arises, one that is very common among the common questions when implementing an agile transformation.
Agility offers this delivery of value in a very simple way. Purpose-engaged teams are able to make small deliveries in production, every time. And these small deliveries serve to keep the client and teams engaged, and give the possibility to prioritize next steps with “software in hand”.
So, small deliveries in production give the customer the comfort of knowing what is being done, at any time.
“How do I track the evolution of development?”
This is one of the questions we hear the most! Therefore, it is important to emphasize that the customer is part of the team, either as Product Owner or stakeholder. Therefore, the follow-up is automatic and fluid.
Therefore, the client is an integral part of the status report. He, like the rest of the team, is responsible for mitigating, adapting and publicizing on a daily basis.
It is worth mentioning the old PMO (Project Management Office) for closed scope projects. The traditional PMO charges and delivers a status report. And this status doesn’t usually show exactly what’s going on in the project.
“My boss won’t let me do this.”
This is another speech that is part of the common doubts when implementing an agile transformation. However, we believe this “boss” position is there for a very good reason. Or he spent many years in his company, climbing positions and conquering his space. Or he is very competent at what he does and was brought in to lead and solve problems in his organization.
In this situation, the ideal is to understand his motivations to stay in the traditional model. There are usually two big reasons:
– For multinationals, it can be a directive from the head office (although it is very infrequent);
– The company is used to “having someone to blame” if the project goes wrong.
In the first case, the most obvious way out is to start creating the culture of agility within the organization. And the Human Resources department can help you with that!
In the second scenario, we have a lot of real arguments that make Agility a good way out for the transition from the traditional model to deliveries with more sense and more added value.
“And what are my guarantees?”
The customer’s main guarantee is precisely the continuous delivery of value. We know that Agility exposes the facts quickly and the client is constantly informed – taking into account that the client is part of the project, as PO.
And then the question arises: “but if the software is not ready by date?”
We come across fatal dates all the time: Mother’s Day, Father’s Day, Christmas, brand launch, investment round, among others. The main tool to mitigate delivery is prioritization. Assessing what is most important, working in small delivery cycles, adapting at all times, focused on delivering the best product on the date… This is the best successful technique for us to meet that date!
“We are still very traditional and Agility is not for us.”
In addition to all these questions, finally, we still hear this statement a lot during the negotiation of a transformation as big as this one.
But, once again, it is necessary to understand that the world has changed. Not only because of the ignorance virus that causes COVID-19, but because of the professionals’ eagerness to be happier in their work, at all scales.
The Cartesian organizations (those “my boss orders and I execute”), is increasingly decaying.
Continuous deliveries make more and more sense in this VUCA world, in which we’ve talked a lot this article here.
