Post-pandemic instability, increased competition, transforming markets, a shift to customer-centered culture – all these factors force companies to seek a more flexible approach to running a business. Many of them are looking at how to adopt Agile to overcome these challenges.
As a CEO of a software development company, I’ve been practicing Agile for around 7 years. First as a software methodology, and later for other processes at MindK – marketing, human resources, and so on. From my own experience, the shift to the Agile mindset is full of challenges. It took several months of trial and error to work out a strategy that fits our company goals. The result was improved workflows, increased business performance, higher revenues, reduced time to market, and satisfied customers.
I’ve packed everything I learned during this time into 6 simple lessons you can use to quickly reform your own business processes.
Table of contents:
- Lesson #1: You need to thoroughly explore the Agile concept
- Lesson #2: Not all projects are suited to Agile
- Lesson #3: Use a shared vision to drive the transformation
- Lesson #4: Agile doesn’t mean an absence of planning
- Lesson #5: Experimentation and continuous learning are essential at all levels
- Lesson #6: Leaders need to shift from authority to partnership
Lesson #1:You need to explore the Agile concept up and down
Most businesses start shifting to Agile without understanding it clearly. There are two reasons you need to delve deeper.
The first is expectations. You need to understand how Agile works to define an intended outcome. Even in software development, we start a new project by acquainting our clients with the basics of Agile terminology and workflows. We even wrote a step-by-step guide to Agile. It has everything you need to know about Agile, including, what to expect from the process and how to determine areas of responsibility.
The second reason is to define your company’s ability to apply Agile principles or adjust them to the needs of your organization. If you are unfamiliar with Agile, its main idea is to split the project into small parts (called iterations). Each iteration focuses on releasing a small piece of the product as quickly as possible then improving it based on user feedback.
Agile Manifesto lays out the founding principles of this process. One of its authors, Dave Thomas, says that to improve the agility of the whole organization, you should follow a cycle of simple actions:
- Find out where you are at the moment;
- take small steps to your goal;
- adapt your understanding in view of what you’ve learned; and
- repeat.
Not all our clients have an understanding of Agile principles. To help them embrace a more flexible approach to development, we often start our partnership with a short kickoff meeting. During this time, our team explains the basics of Agile methodologies like Scrum and Kanban. Here are the main terms we detail in this meeting:
- Epic – a large piece of work, broken into a number of smaller user stories.
- User Story – a short and simple description of a feature written from the point of view of a person who needs the new capability.
- Product backlog – a prioritized list of all user stories the team should work on. User stories that need to be completed within an iteration form a sprint backlog.
- Iteration (or sprint) – a small, manageable part of the project. It contains tasks that the team should complete in a certain period of time (for example, 2 weeks). The iteration, as a rule, starts with Sprint planning, which specifies user stories to be included in the next sprint, and ends with a Sprint review.
- Sprint Review – a live demonstration to the client where the team shows developed functionality and gathers feedback.
Once the main terms are explained, it’s time to discuss the client’s goals, expectations, and roles on the project:
- Product Owner (PO) – the person responsible for maximizing the product value. Typically, it’s a client’s representative that understands the product vision and can adequately communicate it to the team. POs for important products often come from the company’s senior leadership and have a personal interest in the product’s success. One place where MindK deviates from the standard Scrum practice is that we often employ professional Business Analysts in the role of a PO. The reason is simple – most of our clients are new to the software industry. They find it hard to analyze requirements and write them as user stories. So we help them perform this role.
- Scrum master – a team protector that does everything possible to achieve optimal performance. They protect the team from outside interruptions, ensure healthy relationships, and establish an effective working environment
- Development team – engineers that write the application code, test it for bugs, and release it to the public. In Scrum, there’s no clear distinction between developers and testers. Both are expected to step in for their coworkers, performing the tasks needed at the moment.
Lesson #2: Not all projects are suited to Agile
Although Agile can bring huge business value, it’s more successful in certain situations than others. The whole concept of Agile is based on principles of flexibility, teamwork, small units, and transparency. That’s why adopting it in large organizations may present certain challenges.
It’s quite an issue to apply changes across an entire corporate chain, from processes to operation and culture. The critical thing Agile demands is a shift in behavior. This should be evident for each and every team and department, including delivery, marketing, HR, finance, and so on. As an outcome, embracing Agile for big companies may reveal certain problems which are not evident with individual projects at small and medium-sized companies.
Additionally, there are certain types of projects when full Agile adoption is questionable. These are mostly long-term projects with a stable set of requirements where mistakes can be catastrophic for the whole company. Accounting, legal branches, and other strictly regulated units may have trouble embracing Agile.
What’s more, Agile software projects require you to spend some time with the development team. You have to take part in sprint planning, provide feedback, and monitor the team’s progress. If you can’t spare enough time, it’s better to choose a mixed approach.
A similar situation happened to us on the project for one of the largest recruiting agencies in Western Europe. The company needed to build a massive Application Tracking System. With a traditional Waterfall approach, it would take us 1.5 years to get the app to a usable state. So there was a huge risk we’d spend all that time building a product that differed from the client’s expectations.
To decrease this risk, we split the project into four iterations. After each sprint, we’d meet the client for a live demo. They could use the completed features and leave feedback for the next iterations.
It took us 5 months to release a Minimum Viable Product. As a result, our client can now fill a vacancy 2x faster and achieve the same success rate with 5x fewer recruitment efforts.
While a mixed approach is sometimes an optimal choice, Agile is better suited for projects where:
- the problem is complex.
- solutions are still unknown.
- changes are possible during the process, and
- the team works in close collaboration.
Such conditions are common for product development, marketing campaigns, supply-chain operations, sales activities, recruiting, allocation of resources, and so on.
While working with all sorts of companies, I’ve learned that the best way forward is to analyze the operational model of departments in your organization. Then decide which activities are better suited for Agile, that is, where you can break a complex problem into parts and hand it to a multifunctional transparent team.
Lesson #3: Use a shared vision to drive the transformation
Business results are a collective effort. Employees feel a personal and emotional commitment when working towards a common goal. This rule works perfectly in the Agile transformation process, too.
A clearly stated vision is more than a mission or value statement. It is what guides your company through the changing environments. This means all team members should base their work on the same list of priorities. A shared vision during the Agile adoption will help you measure the progress and success, as well as make major decisions.
CEO of Zappos Tony Hsieh states that one of the pillars of their success is explicit and transparent purpose statements on all the organizational levels. The whole company is operating like a city, where decentralized decision-makers are united by common values.
Lesson #4: Agile doesn’t mean an absence of planning
Starting has never been easy, so start small. Identify parts of the company you want to transform and how. After this, decide what Agile practices you will use, taking into account all the elements such as processes, people that will drive the Agile adoption, and technology. Then, define the time frames needed for such a transformation.
Over time, I’ve learned to appreciate the value of Agile roadmaps. They are essentially a very high-level plan that sets the direction for your product in the next year or a quarter. During a roadmap brainstorming session, our teams like to ask clients about their goals, priorities, competitors, user feedback, and so on.
It’s not necessary to create a detailed list of features you’d like to complete by the end of the year. Sometimes, it’s better to outline the business problems you’d like to solve or target metrics and let the team find an optimal way to achieve them and let the team find the best way to make it happen.
As this is Agile, nothing is set in stone. It is OK to change your priorities or adjust your plans on the go. By sharing the roadmap with stakeholders, you can align everybody around a common vision and set the direction of your product.
An example of a simple roadmap, created by MindK at a pre-sales stage
Lesson #5: Experimentation and continuous learning are critical at all levels
Innovations are intimately related to Agile. In general, you can define them as effective use of creativity to solve a problem in the most cost-effective and flexible way. The process is based on experimenting, testing, and learning from mistakes.
This is great for startups, but you can benefit from Agile in other ways. Just think about how your company works toward developing business strategies, guidelines for senior executives, or product launch strategies. As a rule, these processes involve too much guesswork. In the end, you might even find out that you followed the wrong plan.
Instead, try to involve the stakeholders during the whole process, keep yourself up to date, thus ensuring your team is focused on what really matters. Testing, creating “safe to fail” tryouts, and learning from mistakes give you a great opportunity to respond quickly to changes.
Embracing the Agile approach to building machines helped the farm equipment company John Deere shorten the innovation project cycle up to 75%. Previously, they required about nine months to identify a new market opportunity and another five to ten more years to develop the product and bring it to market. With the Agile approach, they were able to go from an idea to a working prototype in just eight months.
Build, measure, learn feedback loop, favored by Lean startups
Lesson #6: Leaders need to shift from authority to partnership
Agile organizations reject authority. Instead, they opt for autonomous cross-disciplinary teams. This requires partnership based on freedom, trust, mutual respect, and managing by agreement. Without this critical shift, Agile is a waste of breath.
Leaders in Agile companies are not inspectors. Their efforts are aimed at supporting rather than micromanaging. Executives are creating environments where each employee is welcome to contribute to the process, take part in problem-solving, and take responsibility for results. Seniority is based on the depth of knowledge and behavior.
A massive two-year research by Google found out that one of the common characteristics of high-performing teams is a sense of psychological safety. It makes employees feel comfortable, talk openly, suggest ideas, disagree, or admit they don’t know something.
Since my company started using the Agile methodology 7 years ago, I’ve seen many developers acquire what I call a product mindset. They don’t simply implement features according to the client’s requirements. They take ownership and actively shape the product’s future, thinking like entrepreneurs in a startup. A true transformation happens with a change in the company’s mindset, adoption of Agile frameworks like Scrum, and a laser focus on business agility.
Conclusion
Implementing Agile thinking in a firmly established company is no easy thing. The lessons above are the pivot point in Agile adoption aimed at changing the mindset of the business.
Sure, it’s only a start and much more work should be done. But correctly applied Agile workflows will allow you to move faster than before, drive innovations, and adapt to the changing environment of the here and now. Remember, any attempts to implement Agile practices may appear challenging until combined with a truly Agile mindset.
MindK has embraced Agile since 2015. We have delivered more than 170 complex projects for companies all over the world using this approach. So if you want to develop a solution for your business, just fill the contact us form to get a free consultation with our Agile experts.
