Articles

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!

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:

1. Remember a service or product you recently consumed that provided a very unpleasant experience for you… Remember before you go.
2. What did you feel? Anger, impotence? Did you think or speak ill of this brand? What was your attitude?
3. 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!  

How do we clarify the main questions that arise in this initial process of implementing agility in a company

By Eduardo Alcaraz

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.
• So our answer is: “YES, Agility is for everyone!”

Do you have any more questions on this subject? Contact us and we will help you. Learn some of our success stories.

Understand now the five bases necessary to succeed and competitive advantage in this Digital Transformation process

Every day we can see how the world is changing and how it is happening faster and faster. “We are on the cusp of a technological revolution that will fundamentally transform the way we live, work and interact. In its scale, scope and complexity, the transformation will be unlike anything human beings have experienced before,” said Klaus Schwab, Founder and Executive President of the World Economic Forum, on the unfathomable, ambiguous and open future of the Fourth Revolution Industrial. In this scenario, Digital Transformation ended up becoming a new buzzword in the market, in which many say they make this journey of change, but few actually do it efficiently, with a holistic view of the subject. It is noteworthy that some companies were born in the Digital age and in a Digital way, while other companies were born Traditional and are only now trying to migrate to a Digital world. With this, it is not uncommon to see people who have tried to transform traditional companies without success, break away from these corporations and create a new company, now with the digital culture ingrained, since its birth. Therefore, we currently classify companies into two groups:

• Companies that were born in the traditional way and are now trying to migrate;
• Companies that were born with digital culture.

As we have already explained more deeply in a another text here on the blog, we mean by Digital Transformation as a fundamental change in the way the company is organized, using technology, people, processes and business models, in order to be adapted to the a more complex and dynamic universe, where it is essential to focus on generating customer value. This will be decisive in the life of companies: the more digital mindset the organization has, the greater competitive advantage in the market it will have in this new world VUCA. For this change to happen, that is, for the company to leave Traditional and become more Digital, we at Agile.Inc created a model that helps in this migration process. This concept was developed by our team after many studies and daily practice. So we have five pillars for a correct Digital Transformation:

CULTURE

The culture change is the first pillar for the true Digital Transformation to happen, not by chance. After all, it all boils down to a change of culture and mindset. Among the various changes in culture, we can highlight:

• Really put the customer at the center of your business;
• Having a culture of applied innovation;
• Empower teams, but with high alignment;
• Create a culture of “not being afraid of failure” and
• be more transparent in actions, decisions and plans

These are some examples of how cultural change is the primary point of transformation. “You make a lot of mistakes along the way, but that’s okay. It’s okay to make mistakes as long as you learn from them. (My father and CEO) Vince has an expression: ‘It’s OK to make mistakes, but never make the same mistake twice.’” – Stephanie McMahon, WWE Brand Director during debate, 2018. – https:/ /www.istoedinheiro.com.br/confira-10-frases-inspiradoras-do-forum-economico-mundial-de-davos/

INTERNAL CAPACITIES

In addition to culture, companies need new internal capabilities, that is, teams need to have new skills to solve more complex problems. Among these skills, we can highlight some such as:

• Working with new technologies (Big Data, Blockchain, Machine Learning, among others);
• Agility in product development,
• Lean management in product design;
• Use Design Strategically.

These are just a few examples of internal capabilities that need to be developed depending on the context of each business.

STRUCTURE AND GOVERNANCE

This pillar consists of rethinking the way the company is organized. Companies that are already digital organize themselves differently from traditional ones:

• How are the areas of the company structured?
• How to break the organization’s silos?
• How is the budget defined?
• How are initiatives prioritized?
• How is work tracking done transparently?
• How to create greater operational efficiency, for example with automation?

Again, these are some examples of questions that are addressed during this transition from Traditional companies to the Digital age, in terms of structure and governance, which vary greatly for each type of business.

PEOPLE

Having the right people, in the right places and with the right direction is critical. In this pillar of true Digital Transformation, we look at:

• Roles and responsibilities (noting that, it’s no use just being defined, but must be followed and monitored in a natural way by everyone),
• How is people’s motivation?
• And which leadership model to apply.

As we think here at Agile.Inc – at the end of the day, it’s always people working with people to create products to other people. But, unfortunately, we still see many companies treating people as resources, in a very “commoditized” way, in which it is enough to just hire employees from the consultancy that is cheaper,for example.

BUSINESS MODELS

The fifth pillar of Digital Transformation is to think of new business models for the VUCA world. The way people buy and consume services is changing and companies need to adapt as quickly as possible. For example, the typical case of a bank that starts charging something without you seeing it and knowing it, is no longer accepted by everyone. If this happens, people will soon go to social networks or complaint sites to talk about it, creating problems for the institution’s image. Thus, new service models appear more frequently, such as Subscription, Freemium, OnDemand, among others, always aiming at the user experience. The work then consists of developing these five pillars for a correct Digital Transformation in organizations. We feel that each company has one of the pillars more or less developed, or with the need to develop a pillar first, etc. However, we strongly believe that some points are levers for transformation, meaning that not everything will happen at the same time. The levers are:

• Developing leadership
• Enabling teams
• Applying Agility Concepts

If we start with these three points, everything else ends up being positively encouraged. Count on us in this transformation process – we increasingly want to bring true digital transformation to companies and people.