But what is a waste? It is everything that does not add value to the end product. In this case, value is the sum of the customer’s demands with the product needs, all related to functionality and usability. Therefore, creating Value Stream means linking only the essential work processes to achieve the desired results. 

Important Milestones in Lean Software Development

The Lean methodology has a long history, intertwined with the Administrative Theory and with relevant connections to the cultural traits of its origins. It started at Toyota in the 1950s, where Taiichi Ohno, Head of Production at that time, worked on an alternative method of organization.

Instead of copying the North American model, which greatly adapted to the production in scale, Ohno was concerned with creating a method that handled properly the complexity of post-war Japan: scarce resources, inconstant orders, and the production of a variety of items.

Because it was developed at Toyota, the methodology became known as Toyota Production System (TPS). Forty years later, with the publication of the book The Machine That Changed The World (1990) by the Massachusetts Institute of Technology (MIT), the model attracted attention from the market. Through research studies, it was proven that it was much more efficient than the traditional production model, and was renamed as Lean to represent a new paradigm. 

It is interesting to remark, however, that the Lean methodology developed at Toyota included not only an approach to manufacturing production (TPS), but also approaches for supply chain management (Keiretsu) and for product development. The latter was adapted to the Software Development when, in 2003, Mary and Tom Poppendieck published Lean Software Development: an Agile Toolkit. 

Since then, the methodology has become popular in the IT area. Currently, it is mandatory in the creation of innovative digital products. 

Lean Software Development Principles

The book by Mary and Tom Poppendieck established principles specific to Lean Software Development, because, despite sharing Lean values applied to manufacturing, in the creation of digital solutions the goal is not having a single product on a large scale (achieved through repetition). The goal is to have a unique software development suitable to the product context and to the users’ needs. 

In this sense, Lean in the IT area is much more related to continuous improvement and to increased efficiency, getting close to Agile Methodology.

The principles of Lean Software Development are:

• Eliminate Waste: it looks a lot easier to think about wasting material products than wasting software, right? But the truth is that the idea is the same: it is necessary to look at the entire creation process, from the moment the work started with the client order to the delivery of the digital product, and remove all unnecessary activities that do not add value to the project. An example are features that will not be effectively used but are developed by the client’s request or to please users. Here, it is worth remembering the importance of a good Product Conception to guide the Lean Software Development. It is also worth mentioning that this method sees intermediate inventories as waste because every inventory generates additional work for its management. Mary and Tom explain that, in software universe, inventory is every “incomplete” work. For example: specifications that are ready but not being used yet, are a type of inventory; the same is said about software that is ready but not in production. 

• Build Quality In: we know that Test Analysts have a crucial role in any project, right? With Lean, more than finding errors afterward, these professionals must work with developers to ensure the construction with quality beforehand. A way to execute this principle is to test each small implementation, not just the entire functionality when it is ready. It is the famous prevention, based on process control to avoid possible errors. A very strong concept in Lean is “stop the line”: the idea that, if someone finds any issue throughout the process, they must stop the workflow to resolve it before it extends. In addition to a change in the way of handling quality, this also implies a cultural transformation: everyone becomes responsible for quality. 

• Create Knowledge: the days of only developing what was planned in the beginning of the project are gone. Creating knowledge is about learning during the work, observing the market, receiving feedback from users and reprioritizing. It is important to create a culture of accepting changes, provided such changes are duly managed and shared among all team members. 

• Defer Commitment: before deciding, reduce the uncertainties. This means having concrete facts as guides, not being based on speculations. Commitments are permanent decisions. This principle is strongly connected to the principle of Create Knowledge that is: learn, see and listen to determine. 

• Delivery Fast: it is no use releasing on the next year a product that is necessary now, right? In Lean Software Development, speed is related to market volatility but also to quickly correcting mistakes and collecting feedback. Now, being fast cannot mean losing quality. For this reason, plans, processes, organization, standardization and cohesive team are mandatory to work in this principle. 

• Respect People: here, we must look at respect broadly. Obviously, politeness is essential, but trust is also included in this case. This means understanding the expertise of each team member and believing in their potential; it means listening to everyone and assessing their ideas equally, regardless of their role. A team that respects itself works better and in harmony. 

• Optimize the Whole:  here comes an aspect that is heavily addressed in Lean: the important thing is to optimize the whole, not the parts. Aristotle said: the whole is greater than the sum of its parts. The end product is not the result only of codes, tests and interface designs. It involves initial client service, all meetings, all processes and all lessons learned. Optimizing the whole is about constant improvements from the beginning to the end of a project journey. This item is very difficult to follow since we are generally taught to optimize the parts: we are asked about individual productivity from each step or each person. Following this principle goes through learning how to see the forest, not only the trees. 

Source: https://www.remoteprogrammer.com/

A Cultural Change

Lean thinking is revolutionary to Software Development, but it is not simple. It requires a cultural change, absorption of principles, and transformation of long-standing attitudes in our corporates. 

Many times, we see teams capable of implementing Scrum, but having the feeling that there is something missing: agile culture. Studying Lean and its principles is one of the most valuable paths to absorb this culture, because in it we do not simply get the definition of a work methodology but look deeply into the principles. It is like it enabled us to truly understand the reasons for agile. 

Need help implementing Lean Software Development at your company? Fill out the form below so we can help you.

*Related Content: What is Lean Change Management?

O post Lean Software Development for Unique Products apareceu primeiro em SoftDesign.

In the world of technology, agility has become synonymous with results. With the consolidation of the Agile Methodology, it was noticed that taking this mentality to other areas such as Human Resources and Marketing, for example, was vital for the strategic alignment and planning of organizations. With that in mind, we share in this content concepts and benefits of Business Agility.   

In the article below, in addition to addressing the importance of Business Agility, we will also show you how SoftDesign’s Agile Consulting  diagnoses obstacles, removing impediments and boosting your company’s growth. Do you want to know how we can insert agility into your organization’s routine? Fill out the form below and talk to our experts right now. 

What is Business Agility?  

It’s not a method, nor a framework. However, with each passing year it becomes more popular and necessary for corporates that intend to survive and prosper in the future. According to the Business Agility Institute, “Business Agility is a set of organizational capabilities, behaviors, and ways of working that affords your business the freedom, flexibility, and resilience to achieve its purpose”. 

Through this purpose, Business Agility gained prominence among leaders and subordinates, and was also described as a modus operandi aimed at delivering value to the market. Therefore, it can be understood as a company’s ability to adapt to changes and respond flexibly to customer and user demands.   

In the podcast Os Agilitas, the CEO of Surya Digital – Business Agility Getting Real, Luiz C. Parzianello, stressed that to put this agile mentality into practice, you need to think with the head of the owner. “Business Agility is about accelerating business growth and positively impacting all stakeholders. But for that to happen, we need strategic leaders who act with visionary leadership”.  

Therefore, we can say that through Business Agility your company becomes:  

• Adaptive: becoming increasingly prepared to deal with changes in society and the market in which it operates.   
• Flexible: understanding that consumption habits, consumer behaviors and demands always change.   
• Agile: facing the fact that every business needs to respect the time-to-market and that quality delivery is the minimum expected, and no longer a competitive differential.  

Business Agility in practice  

The decentralization of information is essential to exercise Business Agility. Imagine a century-old company, which has a large structure and several departments. As in any organization, its board has a consolidated strategic plan. However, some areas act more strategically than others, and this ends up creating bottlenecks and bureaucracies that limit Business Agility.   

Over the years, what was noticed in practice was that the technology started to have a very efficient delivery capacity. However, there were barriers external to the IT sector. This became even clearer when the product teams, for example, reached high performance and delivery started to be made on time.   

Faced with this reality, an important question began to gain prominence: How can we achieve results and improve end-to-end delivery? For SoftDesign’s Agilist, Raphael Rodrigues, the answer is simple: all employees must observe the market, not just decision makers. “Corporates need to be more flexible and aligned. That’s the only way we can cross the borders of the board and bring knowledge to the entire organizational structure”.   

This means that there is no point in promoting Digital Transformation in isolation. It was precisely to solve this problem that Business Agility came up. “We don’t have control over many things. So, in some cases, the best we can do is seek adaptation. It’s this kind of thinking that helps shape the company. Remember that agility is flexible and aims at executing feasible strategies”, highlights Rodrigues. 

Diagnosing problems, finding solutions

With the Agile Methodology consolidated, we started to observe the problems of our customers in a broad way, analyzing not only their IT sector. The proof of this is that the first step in the diagnostic process is precisely to understand the scenario in its entirety, and not just what the client understands as their most latent pain.   

With that in mind, at Agile Consulting we talk about the organization’s entire workflow, from where ideas come up to actual delivery. “As we started to understand how the organization works, we started to exercise visibility and transparency practices to identify bottlenecks and pain”, explains Rodrigues.  

Throughout this process, we realized that sometimes people are so immersed in their problems that they cannot think holistically. For this, we work with improvement practices, and facilitate conversations between collaborators and senior management, always in search of value and significant changes.    

SoftDesign’s Agile Consulting service is led by an Agilist. Generally, when we address technology issues, and software engineering problems begin to arise, the participation of a Programmer becomes necessary, who suggests less costly practices that accelerate the delivery process.    

In other cases, we connect Designers to the client to show that we need to apply interviews to really understand the users of an application, for example. Recently, with the evolution of Product Marketing, we have also started to look at sales strategies and the positioning of corporates in their communication channels, which resulted in a specific consulting in this area. 

This is only possible because at SoftDesign we have a variety of professionals and skills, which allow us to see problems in a multidisciplinary way. In addition, we have been in business for 25 years, creating transformative digital solutions. 

Our way of consulting

As we have several profiles of collaborating people, we seek support in this knowledge to promote occasional collaborations throughout consulting. Depending on the problem identified, this participation can become a workforce, with greater dedication and more attention and intention from the customer.   

After the diagnosis, we present options to reduce the identified pain. So, we started a journey together with the company, showing through training how certain tasks and activities can be done quickly, with continuous feedback.   

We believe that it is not possible to manage changes in just one month, so we understand that three months is the ideal period to carry out this type of consulting. “We have a lot of respect for the client’s culture and investment. We bring our team and skills to solve problems, pains and impediments. We promote meetings with our specialists, and encourage critical thinking”, emphasizes the SoftDesign Agilist.

Accelerate the evolution of your business! 

If you’re a manager and looking for innovation, but can’t put the strategy into practice, or if you’re part of the organization’s decision-making team and find limitations to evolve projects, Agile Consulting is the solution to your problems.   

With the help of our team of specialists, we started the change process with lean management models and methods such as Lean Change Management (LCM) and  Kanban. From our delivery, we give more capacity to your company, which now has other challenges than operational ones.    

For Raphael Rodrigues, the company that undergoes Agile Consulting develops a better delivery capacity and strategic alignment. “Every company has knowledge management, and we effectively increase the knowledge an organization has. That is, it now has more earning potential, since people are more qualified. That’s a competitive advantage. Every company that wants to survive needs Business Agility“.  

Now that you know what the benefits of Business Agility are, and why it boosts your organization, contact us to put new strategies into practice!

O post Why Does Your Company Need Business Agility? apareceu primeiro em SoftDesign.

Our Agilist, Raphael Rodrigues, took advantage of SoftDrops* to tell this story, highlight the principles of the Manifesto and explore the characteristics of the Agile Method. Below, we share the most important moments of his presentation.

The evolution of processes

Among the consultants present at the February 2001 Conference, Raphael highlighted: Kent Beck, Rod Jeffries and Ward Cunningham, creators of the Extreme Programming (XP); Ken Schwaber and Jeff Sutherland, creators of Scrum; Alistair CockBurn, creator of Crystal Clear; Martin Fowler, author of leading books on design patterns and the UML; and Robert C. Martin, author of fundamental books on programming and clean code.

However, it should be noted that before the meeting, the topic of process improvements was already under discussion in the product area. Some of the Agile Methods mentioned in the previous paragraph took their first steps even before the Conference.

But it is worth mentioning that in 1945, William Edwards Deming revolutionized production processes in Japan and the United States by proposing the application of statistical methods (influencer of the Toyota Production System); and Hirotaka Takeuchi and Ikujiru Nonaka, who in 1986 created the New Product Development Game approach, streamlining and making product development more flexible (at companies such as Canon, IBM, 3M, among others).

With all these initiatives happening over time, what was then the motivation for the February 2001 Conference? The consultants involved were looking for a common model, an alternative to software development processes that, structured in the Waterfall Method (created within the Engineering area), were considered cumbersome and too documentation-oriented.

A method based on empiricism

This meeting gave life to the Agile Alliance, which still dictates and contributes to the organization of processes in the area; and originated the Manifesto for Agile Software Development, with its mindset, values and principles. Such values provide guidance on how to create and respond to change, and on how to deal with uncertainty:

“This work method is based on empiricism. So, what we do today is a scientific method in which we don’t know the truth, we don’t know what will emerge during the process. Before (in Waterfall), what we did was plan and stick to the plan, documenting the steps as scheduled. With the Agile Method, we assume hypotheses, carry out experiments and tests to validate them, which generates learning”, explained Raphael.

The Conference impacted the following years and boosted the emergence of several work models such as Test-Driven Development (TDD); Lean Software Development, Large Scale Scrum (LeSS), Kanban Software Development, DevOps, Mob Programming and Disciplined Agile Delivery (DAD), among many others.

Values and Principles of the Agile Manifesto

There are four core values of the Agile Manifesto, which began to be valued after February 2001 in software development practices:

• Individuals and interactions more than processes and tools;
• Software in operation more than comprehensive documentation;
• Collaboration with the client more than negotiating contracts;
• Responding to changes more than following a plan.

Raphael explained that it is necessary to understand that it does not mean that the items on the right are not important and should not be carried out, but rather that in this mentality adaptation, they are inferior to the items on the left, which must be prioritized. Such values summarize the 12 Agile Principles that can be seen in the image below – the first four are aimed at customers; the next four to management, and the final four to the team:

The Agility Umbrella

Agility is a big umbrella that encompasses several practices, from lighter processes for small teams, to more robust processes for larger teams. We can mention Scrum, Kanban, XP, TDD and Crystal as lightweight approaches, and LeSS, DAD, Agile Project Management (Agile PM) and Open Unified Process (OpenUP) as heavier approaches, for example.

For Raphael, Agile Methods are conventions that teams choose to follow. “If the team is working according to agile principles, they are trying to be agile. What matters is not the framework (Scrum, Kanban, etc.), but the agreements that are made within the team. The framework brings a condensation of ideas that worked, but it needs to be adapted to the context and reality of each team”.

In this regard, it is important to point out that it is possible to use several practices in the same project. It is not essential to follow only one framework from start to finish, but to use practices that generate the best results in that case. In fact, in the image below, we can see how the different practices of frameworks can interact.

The Future of Agility

Even with many changes in the world, by observing the agilist it is possible to see a growing movement of agile practices in contexts outside of software development or product creation, where there is greater integration with design practices. And, also, in areas such as Marketing and HR – the latter even has its own manifesto.

For Raphael, the future of what we call agility is more related to best practices in management, leadership and organizational culture, focusing on collaboration and people development – being pragmatic in terms of frameworks or methods. Thus, we guarantee that the creation of products will be focused on customers, and on the end-to-end value stream.

O post Agile Manifesto: Principles and Future apareceu primeiro em SoftDesign.

The software has a set of requirements that are divided into Functional (FRs) and Non-Functional (NFRs). This classification makes it easier to understand them, as we will see below. 

Do you need help defining your Software Requirements? Fill in the form so we can help you.

Functional Requirements

Functional requirements concern the functions and information that the software must have, that is, its behavior: how it must react to specific inputs, how it will behave in certain situations, and even establish what the system must not do. 

For example, an application for a financial institution must be able to carry out transactions, payment slips, and make investments. These are three digital product requirements that allow users to perform such functions. 

Functional Software Requirements can still be classified according to their level: the most common differentiation is in relation to business requirements, user requirements, and technical requirements. 

Non-Functional Requirements

Non-Functional Requirements can refer to the criteria that qualify the functional requirements: they are related to specific qualities and restrictions that the software must meet, that is, they do not refer to functionalities themselves, but are part of the product’s scope. 

Non-Functional Software Requirements are sometimes called quality attributes, which means that they are a structured and categorized definition of what is needed to express that a product has quality, according to its specific context. 

Like Functional Requirements, they are subdivided into product requirements such as reliability, efficiency, portability, usability, performance, and space; organizational requirements such as delivery, implementation, and standards; and external requirements such as interoperability, ethical, security, privacy, and legislative requirements. 

We can exemplify by citing compliance with the GDPR (General Data Protection Regulation), which is a very common NFR nowadays. Another example is stating that software needs to be cross-platform, operating on Android and iOS. Yet another is when we define that a solution needs to use encryption because it handles sensitive user data. 

The Transversality of Non-Functional Requirements

For the team building the product, Non-Functional Requirements can be restrictions, standards to follow, or requiring very specific solutions. It is normal, for example, that they need to be resolved at the software architecture level and not in programming because NFRs are “transversal”, that is, they affect all functionalities. 

Once, we developed a product that had a very critical Non-Functional Requirement in relation to availability: the application needed to operate 24×7, for three months, as it was one of the applications used in the operation of a reality show. For this type of requirement, an architectural analysis is needed: you need to identify and remove points of failure, create fallback (plan b), and self-healing solutions. The requirement even affects the hardware and infrastructure, which need to work with high-availability solutions so that maintenance can be carried out without affecting the availability of the software. 

Where Are the Requirements?

Have you noticed that, despite being one of the central concepts in Software Engineering, it is not so common to hear about requirements? This happens because they ended up associated with a waterfall workflow model, which is bureaucratic and predictive. 

It’s not the requirements that are to blame, it’s the professionals: analysts who expected the customer or user to define their requirements and then stick with that list until the delivery. There was no room for learning, feedback, or strategic changes. 

This behavior became meaningless when the technology market evolved towards agile, product-focused approaches. The area sought other tools that would help change the relationship between the team and stakeholders, adopting concepts such as OKRs (Objectives and Key Results), product metrics, business objectives, user stories, BDD (Behavior Driven Development), and acceptance criteria. 

However, that doesn’t mean the “end of requirements’. These tools represent yet another evolution in the way of defining them, as well as other techniques that had previously appeared. Regarding current tools, they have the following advantages: 

● Data-driven and more focused on business impact; 

● User-centered – focused on people; 

● Less verbose, more focused on interaction than documentation; 

● More collaborative, because the work is less centralized in an analyst, as it is more distributed in an interdisciplinary team; 

● More change-friendly, that is, they create a dynamic that better accepts product changes and evolutions. 

Who Defines the Requirements and When?

This depends on the type of process and life cycle adopted; two concepts that also come from Software Engineering. In an older lifecycle, the norm was for requirements to be defined all at the beginning of the project. It was common to use the term “collect” or “elicit”, that is: the idea was that a Systems or Business Analyst would obtain requirements from users. 

Nowadays, in current methods, we start from slightly different assumptions. We understand that for innovative products it is impossible to discover all the requirements at the beginning of the project; that the user needs to provide usage feedback; and that it is the product team’s job to translate that feedback into requirements. 

For this reason, building requirements is a collaborative process. The configuration varies a lot, but we can have a Product Manager (PM) working at the business level, defining the product vision, metrics, and business objectives. The Product Owner (PO), who is in direct contact with the development team, facilitates the process of turning big goals into user stories. Finally, the team participates in this refinement, as it is responsible for defining the technical solution that will meet the proposed needs. 

O post Software Requirements for the Success of your Digital Product apareceu primeiro em SoftDesign.

Its mission is to influence the team’s work and inspire a mindset of constant improvement, capable of resulting in frequent and valuable deliveries and highly desirable products. However, exerting influence among groups of experienced and qualified professionals is not an easy task. Moreover, to positively impact the behavior of a product team, there are a series of skills and specific characteristics that must support the Agile Coach’s management and leadership model. 

Therefore, in the following article, we will explore some of them. We spoke with Raphael Rodrigues, Agile Coach at SoftDesign, to understand the role of this professional in the development of digital solutions. 

The Evolution of The Agile Coach

The role of the Agile Coach is constantly changing. In the past, its performance was based on frameworks such as Scrum and Kanban, for example, people worked with a greater focus on the functioning of the team, helping everyone to understand the phases and status of development. The objective was to propose evolutionary changes through a process of thinking and improvement, capable of increasing the delivery of value.  

However, with the maturation of the processes, it was realized that limiting the Agile Coach’s performance only to the product team was not enough, because people are part of an organization. It was concluded that this role needed to transcend the Discovery and Delivery process. When Agile Coaches stopped working only on development teams, their collaborations began to help reduce noise within companies. One of the results is the execution of tasks in an agile and less expensive way. However, when we talk about Agility in the business world (Business Agility), this role is more focused on strategy, guiding people to share information through micro-interactions.

Wanna Be Agile?

Having the power to influence others is not necessarily everyone’s gift. With that in mind, Agile Coaches must have specific skills. According to Raphael Rodrigues, resilience is perhaps the main one. “To play this role, it is necessary to be a resilient person, since we do not directly execute the actions, but we influence the team to complete them. In addition, it is necessary to encourage the search for problem-solving through individual and group conversations”.

Horizontal management and leadership are also key characteristics.

“Good Agile Coaches have great communication skills. After all, knowing how to communicate well is essential to guide teams, and this leads us to empathy, something crucial to understand one’s work process. At SoftDesign, we operate with Management 3.0, a movement that renounces command/control to make room for the trust and autonomy of employees”. 

Another important skill is facilitation. Agile Coaches are responsible for facilitating conversations, ceremonies, schedules, and group dynamics. “Our day-to-day is based on processes and people, and these are constantly changing. Our journey is continuous, that is, there is no actual end due to the current business model. Therefore, Agile Coaches must be attentive people and very focused on improving things around them”, highlights Rodrigues.

Influencing Product Teams

In a diverse world, influencing product teams can be quite a challenge. Each company has a culture and a set of people with the most varied characteristics. Therefore, getting the best out of each one involves a lot of strategy and dedication. “In my daily life, I need to be connected to what is happening, to what people are talking about, and, above all, to what they are not communicating. For this, we hold one-on-one (1:1) meetings, and facilitate meetings to generate interactions and create agreements”.

In addition, Agility involves management practices oriented to business objectives. To execute them, it is necessary to give everyone a voice, as this is the only way to develop products that simplify users’ lives. “In interactions, we get in touch with people with the most different levels of maturity, experience, and age group. In the end, what keeps us engaged is the purpose of the work and the challenge of winning something together. When we unite different perspectives and experiences, the result is a plural development process. Without diversity, the ability to solve problems is reduced”, he highlights.

Agile Coaches encourage, guide, and help generate paths and options. In summary, Agile does not oblige us to follow a single direction until the end of the development of a digital product or service, on the contrary, it creates milestones for us to navigate, allowing moments of analysis that allow us to measure whether choices are resulting in desirable results. Therefore, to boost team performance, Agile Coaches seek to create awareness between what the group has committed to deliver, and what is actually being delivered. “We look for results, and we help people to do what needs to be done within the agreed time frame. We reduce conflicts to achieve goals through more fluid processes, clearing obstacles”, emphasizes Raphael.

Agility Is Not Just Speed

When using Agile, companies seek feedback as quickly as possible, respecting the nature of what is being developed. After all, everything has a maturation time. This is complex, as we are unique people, that is, each of us has our own task execution time, based on an individual creative process. 

So the key question is: how do we get the best out of each one without getting lost in the process, and without taking longer than expected? Through ceremonies. In a diverse and knowledge-filled environment, replicating processes can be a great challenge, since getting the best out of the group is something that can be achieved with conversation, rhythm, and follow-up. 

With this in mind, Agile Coaches analyze project boards daily to diagnose stages and possible obstacles. Based on this analysis, they interfere and help improve processes, or even assist in completing activities.

“I help connect people and solve problems. In ceremonies, we make it easy for everyone to put themselves in a state of awareness, so we can influence the team to make good decisions”. 

Ideally, each Agile Coach should work on a maximum of three projects, interacting with 15 to 20 people. That way, the Agile Coach can connect and follow up properly. “Expanding these numbers results in a superficial process, and this impacts the essence of Agility. We are knowledge workers: therefore, when we don’t have time to reflect and create, we are not able to innovate. If the schedule is full and we are just completing tasks, the teams become burdensome. After all, the value of our work lies in the ability to think and be creative”, concludes Rodrigues. 

Let’s accelerate the evolution of your business?

If your team is just completing tasks, then it’s time to wake up and put Agile to work. In addition, if problems and bugs are reducing the rhythm of deliveries, to the point that people are unable to reflect and propose solutions, our Agile Consulting can be an important ally.  

To accelerate the adoption of a culture based on Agile Methods, we work with a customized mentorship according to your needs. During the consulting process, we transfer our knowledge in Scrum, Kanban, and DevOps to your team. The objective is to increase transparency and dialogue between people, to generate more frequent and valuable deliveries. Watch the video below and learn more about this service:

Want to know how we can help you more specifically? Fill out the form below and chat with one of our experts.

O post Agile Coach: The Power Of Influence apareceu primeiro em SoftDesign.

Validating Change Process

Strategic Change Canvas. Source: https://leanchange.org/

5 Universal Dimensions of Change

• Cause and Purpose: what is urgent for you may not be for the other, and this situation can generate stress among team members. However, when we come together for a collective purpose, we are more likely to move towards a solution in a light and collaborative way.
• Significant Dialogue:  Communication is very important in the change process. When working with complex changes, it is necessary to create an environment conducive to dialogue, where practices from the Lean Change Management model and the Agile Manifesto are important tools.
• Response to Change: resisting change and innovation can be common in some companies, especially in more traditional ones, and this is one of the reasons why the Agile Method can fail during its adoption process. If people are very resistant to change, it can also mean that they do not feel invited to participate in this moment of company transformation. Remember that being inclusive and diverse is crucial.
• Co-creation: to make everyone believe and accept change, it is necessary to empower people. The Culture of Collaboration is essential to promote understanding and alignment among all. For this, it is necessary to make room for people to co-create together.
• Experimentation: it is necessary to run experiments instead of tasks. It’s not possible to predict what will happen with complex changes, which is why trusting cycles of experimentation and feedback is so important. Only in this way can you modify and adapt plans as you go along.

Lean Change Management X Traditional Change Management

LCM at SoftDesign

Change is Our Only Certainty

O post What is Lean Change Management apareceu primeiro em SoftDesign.

Projects of any kind always involve three main restrictions known as the Iron Triangle of Project Management: cost, time, and scope. Cost refers to how much will be invested to carry out the project in items such as resources, acquisitions, and even risks; time concerns the deadline for it to be delivered, and scope explains what will be contained in the job; it is the definition of the “border” between what will be done and what will not be done.

Such restrictions are present in both closed-scope and open-scope projects, but they are worked differently in each. In software development, it is common to hear that traditional projects are closed-scope and agile projects are open-scope.

So, what does Closed or Open actually mean?

It is necessary to understand that to define cost, time, and scope, estimates are made. Since estimates are not exact, it is not possible to fix the three variables of the Triangle. For example, let’s say you leave home for a bike ride. Within your scope, there is a 10km ride and the time you estimated is 30 minutes. Which of these variables are you going to fix, and which are you going to make flexible? Well, it depends on your needs!

• If you only have 30 minutes available, you will fix the time and try to do 10km within that period, which can result in a variation to 8km, 9km, or even 11km.
• However, if you need to get to a place that is 10km from your home, then you will fix the distance, and maybe get there in 25 minutes, or 35 minutes.

Therefore, when we talk about closed-scope projects, we are referring to the scenario in which the project is fixed in scope, and thus time and cost may vary. In open-scope projects, the process is the opposite: time and cost are fixed, and the scope may vary. Let us learn more about this, shall we?

Source: Leandro Faria’s Lecture

Closed-Scope

When the fixed variable is the scope, the first issue that arises is the need to detail the scope we want to fix. Therefore, closed-scope projects often involve a long planning stage.

This very detailed planning often creates a sense of security, predictability, and control. However, it is important to remember that this security is only real in situations where the defined scope is stable – which can happen in some areas such as civil engineering but does not usually happen in the software world.

In closed-scope projects, it is also common for the participation of the customer or the user of the solution to be concentrated at the beginning and at the end of the project, without the need for frequent monitoring: after all, everything that will be developed in the middle is already defined. This can be seen as an advantage in environments where all the knowledge about what needs to be done is already mature and stable, but in projects that involve the development of new knowledge, this type of approach is a source of failure, as it does not consider the need for interaction and feedback.

Think: how many times, while starting a project of any kind, did you know exactly what needed to be done during execution? How many times have you or someone on your team changed your mind when looking from new perspectives?

Closed-Scope Problems

First, there is a set of problems related to scoping itself. The closed-scope process is quite naive and unfair to users and stakeholders, as it requires them to define all the requirements at the beginning of the project. Well, how can you really know how the features will work before you even try them?

Problems with scoping include:

• Understanding: when describing all the requirements for the product, clients may believe they are being clear about what they want, but the team’s interpretation may be different.
• Completeness: Providers of requirements rarely design all possible user journeys, and the lack of this study ultimately results in multiple uncovered usage scenarios.
• Adaptation to innovation: The worst case is trying to define the scope of an innovative project in advance. Think: If we already know all the details in advance, what is innovative about it?

Secondly, there is a set of issues related to the false sense of security created by detailed estimates. Estimating means analyzing probability based on available information. In the case of closed-scope projects, this happens only in the planning stage: time and cost are calculated due to the scope implementation effort.

Issues with estimates include:

• Not meeting the deadline: as we explained before when you decide to fix the scope, it is known that the other variables will fluctuate! However, as estimates were presented at the beginning of the project, expectations were created in the stakeholders, and now any fluctuation will be seen as a delay.
• Excessive buffers: in order not to run the risk of missing strict deadlines and failing at the expectations that were created, time estimates end up being purposely increased by the team – it’s the famous overestimate of buffers. More time, consequently, results in a greater cost. And as Parkinson’s Law says, “work expands so as to fill the time available for its completion”.
• Compromising Quality: To meet expectations created about budget and deadline estimates, it is a common solution to think about cutting quality and verification steps, causing products to be delivered without proper testing.

Open-Scope

Open-scope projects, on the other hand, have a fixed time (and resources), which makes it possible to set their budget; but the scope is variable. Thus, the goal is to deliver the highest priority product in the shortest time and with the highest possible quality.

In practice, instead of just a planning stage, in open-scope projects, there are work cycles that go through inspection and adaptation. Deliveries are made in every Sprint (two weeks) or in every completed item (which can generate a daily cadence, for example). This way it is possible to readjust the scope frequently, within the fixed time and cost.

Also, with the customer following the work closely and users testing the product, changes become a more agile and less bureaucratic reality. See: every two weeks, with the delivered items at hand, it is possible to analyze the product and get new insights, which can be included in the next Sprint.

Advantages of Open-Scope Projects

The main objective of agility is to eliminate waste and focus on Value-Driven Deliveries. That is, the value that a specific part of the scope has for the business is considered in each planning session, and this analysis is the basis for prioritizing items. As a result, the following advantages emerge:

• Prioritizing what matters: With the fixed-time strategy, it makes sense to start with what delivers the most value rather than what is most comfortable or most obvious. Thus, the whole work logic changes, and the famous Student Syndrome (delivering at the last moment) is naturally fought by the process.
• Adaptive planning: As it is carried out constantly during the project, planning is molded to the project’s current scenario. This means that if the customer’s business undergoes any changes, for example, it is possible to include, exclude or modify items in view of this new reality.
• Constant learning: Customer and user participation ensures frequent feedback, which generates learning about the project and the product. At each new Sprint, the team adds new knowledge that is applied during development.
• Mitigation of uncertainties: Predictability becomes more real than in closed-scope projects. After all, after a few Sprints, the team can be surer about its delivery capacity, and thus it becomes possible to carry out projections based on reliable data.
• Quality first: The definition of a project’s quality requirements is an essential part of its scope composition. Open-Scope allows spaces to be created for modifications necessary for quality. This way, the development team has the flexibility to solve the real problems of the product’s users’, and there is assurance that it will not be outdated at the end of the project.
• Value assurance: With constant monitoring, the value of the project is not lost, that is: it continues to solve the issue proposed, even if this issue changes during development.

A Paradigm Shift

Despite the benefits, open-scope projects suffer resistance in medium and large companies that fear losing control over their work. There is a belief that agile projects would not have proper management and would represent greater risks for the client.

In the book Agile Project Management, Jim Highsmith talks about this paradigm shift in management methods. He explains why, in a knowledge-based economy, traditional projects fail to achieve results: they limit products. This is a disadvantage in a competitive and innovative market and can cost any business its own survival.

Also, in closed-scope projects, the client pays for activities that do not add value to the business – since all activities were initially planned and “must” be delivered, even if they no longer make sense. It is a change in mindset: instead of measuring success by the list of deliverables, success is now measured by the impact caused by the product.

Collaboration and Value Delivery

At SoftDesign, our development method is agile and therefore involves an open-scope. Our contracts prioritize trust and collaboration, and our multidisciplinary teams are ready to build your digital product with quality.

Please contact us to discuss scope, cost, and time and find the best way to put your project into practice.

O post Open or Closed-Scope: which one is ideal? apareceu primeiro em SoftDesign.