The world may be in a constant state of flux, but the development of products and services requires steady work toward a set goal. This can prove challenging in an environment that in a relatively short time can witness several changes, such as product launches, opening up new service channels and entering new markets. The needs and preferences of the customer can also change, or key individuals may suddenly switch jobs, affecting the properties of the solution under development.
An Agile approach can make managing these changes easier. The Agile operating model is based on dividing the work into short periods, or iterations. The process and output are under constant scrutiny, which enables learning and allows for changing the course of action before it’s too late. “In Agile solution development, the process is divided into small parts and then carried out little by little. That way, it’s possible to take all types of changes into account and react to them,” says Heikki Koskela, Head of Projects at Bonsky Digital.
How can Agile practices lead the way?
So far so good, but how can you make sure that development will keep on the right track over the long haul? Aren’t companies usually accused of not following through on their strategy and instead going wherever the winds of the quartile economy take them? Koskela has an answer:
“Development needs to be based on the needs of the business, and the direction of both business activities and development projects have to be continuously checked against the organization’s objectives. The direction of a company can only be as clear as its objectives.”
Projects can involve failures or get sidetracked, but the organization may still be heading in the right direction. Vincit’s Agile Coach Eetu Kaivola explains:
“An Agile developer can never be entirely sure that what they’re doing is taking them where they need to be. But quick iterations make learning fast, which increases the probability of being on course.” Kaivola comes up with an example: “When people in the past realized that horses could get them where they wanted to go faster, they started taming horses. They had an objective, but no real knowledge of how to achieve it. A lot must have gone wrong in the process before humans came up with a model that worked.”
In other words, Agile isn’t about acting on a whim; instead, its methodologies are guided by a recognized need or objective. These measurable objectives form the core of Agile development planning, and they’re also used to assess the successfulness of project outcomes. Ironically, once you’ve defined a clear objective, you need to accept the fact that the experiences you’re going to gain, together with the changing environment, are going to change your development needs and consequently the development plan – even the objective at its core.
“In the end, business is driven by reality and objectives are only tools for reflection,” Kaivola explains.
Making sure that your entire process is heading in the right direction is hard and something that needs to be taken seriously. Unfortunately, an Agile operations model doesn’t provide any ready-made answers in this regard, either. For example, it’s possible to optimize a production line in a highly Agile and advanced manner and carry out product development in an innovative and Agile way and still end up with a failing business.
“Seeing reality and change for what they are takes guts when they don't support your own understanding of the world or when they present a threat to your current business,” Vincit’s Agile Coach Marko Hirsimäki says and continues: “If you’re about to ride down Niagara Falls, there’s no point in throwing cushions into the stream in hope of a softer landing. Similarly, if you’ve been going in the wrong direction for a year, the game may be over. But even big organizations can change their direction if the problems are spotted early enough.”
Another factor that can keep organizations on track is the expertise and self-discipline of development teams. Wild ideas are allowed but experts won’t give any of them the green light before they've been considered carefully. In an Agile model, an idea can always be tested for a couple of hours. However, if the beginning isn’t promising, the testing needs to stop. The team’s work involves making assessments, providing arguments for and against, gathering empirical experience, making reassessments and learning.
“You may end up with something that’s just useless. However, if it provides learning points, that’s valuable too,” Hirsimäki points out.
Adapting to change is important but still not enough. Winners don’t merely react to change, they engender it.
“Nothing’s preventing business management from adopting an Agile mindset. Just as services can be designed and carried out in an Agile way, so too can Agile practices be used to develop and do business – through innovations, for example. By providing input for solution development, a business can manage change across an organization,” Koskela explains.
An Agile operating model can permeate the entire organization from business management to grass-roots level development work.
Customer decides your success
Typical companies seem to think that they’re well aware of their customer’s needs and that they know how to develop products and services that the customer wants to use. However, during the commercialization stage the company may notice that they don’t really know how to tell the potential customer about the value of a product. The company may also realize that the number of customers ready to pay for the product is not as high as initially thought.
Because design thinking and collaborating with customers and end users are essential Agile approaches, an Agile developer is one step ahead. When the end customer or user is engaged in the development project, the developers learn to understand their world and the end result is more likely to align with the needs of the customer. The benefits of customer-centric design become highlighted in industrial companies that produce solutions for a fairly limited group of customers.
In many cases, the challenge of service design is that the customer claims to want one thing while they really need another. For example, the end user may wish for use-friendliness, when they really need a change in behavior – something they don’t even realize to ask for. This is why service design, a cognate of conceptual solution design, maps out the user’s goals, needs, sore points and modes of operation by means of qualitative methods and attempts to gain a more profound understanding of what people truly want.
During concept development, the customer is presented with alternative solutions which are all based on the customer’s needs, and the customer must choose which solutions to try. Little by little, the end user realizes the potential they can tap into and the concept becomes better articulated. In the end, the move from concept to production and genuine market feedback should be swift.
“Sometimes there’s a discrepancy between what customer surveys say and how customers act. When the customer is finally forced to buy something, the criteria for the purchase may be quite different from what the concept design initially predicted,” Kaivola explains. Koskela adds another important viewpoint and points out that in B2B, carrying out development work together with the customer can offer surprising value: “The end customers overcome a number of hurdles working with the development team and become emotionally involved with the solution provider in the process. Overall, the experience builds trust, which can promote business across the board.”
Same delivery, but faster?
Many managers seem to hope that applying an Agile method will not only give them all that they need but that the process will be fast. That isn’t what Agile is about, however, since turning hopes and dreams into reality is never easy. There will always be more problems to solve than initially expected, which is why, according to Koskela, you should never try to anticipate all the solutions you’re going to need. This is also the fundamental principle of Agile – the outcome or scope of a project should never be defined in advance.
Agile isn’t something faster or better as such. It’s based on the idea that, as a project progresses, any project-related decisions will be made on the basis of gained experience, set objectives and the users’ recognized needs. Following these guidelines fairly effectively creates a solution for the service of business.
All this requires resources like time and money, which are normally available in limited supply. That’s why it’s important to prioritize those features along the lifecycle of the solution that, in their particular stage of development, best meet the set objectives and the needs of the users. In the beginning, as you’re getting started, only the most critical features will make the cut.
The pre-defined scope, fixed schedule and budget of a traditional development project often backfire and result in rushed executions, postponed testing and turning a blind eye to problems. An Agile operating model produces a much better outcome.
“Agile teams typically fix any issues as quickly as possible and invest in continuous testing. They learn from their mistakes and never make the same mistake twice,” Hirsimäki says.
The acceptance of change and the desire to develop and learn are at the core of Agile, but Agile development processes vary from one situation to the next. The development of a new solution or service typically involves five stages.
Is an Agile project like an open check?
Agile is gaining in popularity despite the fact that its principles are often misunderstood. For example, a customer may say that they want something Agile as long as the desired result is achieved within a certain budget, revealing they have not grasped the fundamentals of Agile and its open-ended process.
“I understand that going Agile can be quite difficult. Think about it: we tell our customers that it may be possible to do everything they ask for in the time they have specified, but then add that in the end it all depends on how things will change during the process,” Kaivola muses. Hirsimäki continues: “Becoming Agile requires not only a proper understanding of the method but also belief in the model. To make things even more complicated, Agile activities are partly based on trust, which makes investing in them all the more difficult”.
Often, the practical problem is that those members of top management who sit on the money do not seem to understand the benefits or conditions of Agile, unlike those in charge of projects. It’s only natural that those responsible are afraid of losing control and feel worried that Agile will turn development meetings into unruly playgrounds that yield no results. Management can also be on the project owners’ backs about giving the development partner an ‘blank check’.
“When you buy a package deal, you know what the price tag will get you. Whether it’s something you can actually use is a different matter and something you realize only long after the purchase. Why wouldn’t you use the same money for something that actually caters to you particular needs?” Koskela asks. Hirsimäki continues: “If you decide to play it safe and buy an all-inclusive IT project, you need to add another zero to the price tag – but even that won’t guarantee the desired results.”
Sometimes going Agile can be made easier by signing the contract for one month at a time. Vincit also builds trust by providing a quality guarantee. The main thing is to guide the top management of a company towards Agile thinking.
“This is a big challenge for us suppliers. We have to think about how we can help decision-makers understand the advantages of Agile and convince them to buy an operations model that they may not be familiar with. It’s our job to show them what the customer is paying for and how success is measured. I’m always especially interested in knowing what the customer thinks a successful project is,” Koskela says.
Business management may find comfort in the fact that an Agile model doesn’t prevent the setting up of a schedule or a budget as long as the scope of the project remains undefined. For instance, if the project is to renew an access system, a deadline can be set for its launch. Although the solutions used won’t be determined in advance, all activities will be carried out according to the schedule. In Agile operations, each decision is transparent and made together with the customer.
“The transparency of Agile development is highly valuable for management, as it allows for better assessment of each step,” Kaivola explains.
In Agile, the produced value is realized quickly
“When value is produced and deployed in short iterations, we won’t store it. Instead, we will realize it as quickly as possible,” Hirsimäki says.
Assessing the value of Agile operations needs to be done with great care. The benefits of Agile can be relatively big in small development projects, where the value-producing solutions quickly move to the production phase. By contrast, big projects can involve a lot of time-consuming change work, which makes the immediate benefits smaller. The advantages Agile can bring to value production are usually not readily perceivable when looking at the business as a whole. In the long run, however, their significance can prove vital. This becomes apparent when looking at innovation investments, for example, which aim at creating value over the long haul. Another thing to consider is scale: if the entire business goes up by half a percent, the increase in value may be more significant than when substantial progress is made in the development of a small solution.
When considering value, sometimes too much emphasis is put on the cost of a development project.
“When we’re talking about the digitalization of business, it’s ridiculous to claim that the value of the project has something to do with its cost. Value lies in thinking about what the solution will bring to the business, not in minimizing expenditure,” Koskela summarizes.
Agile is not a silver bullet
Getting stuck in a never-ending planning stage and maintaining the status quo is highly risky. However, Agile methods and their penchant for failure may also sound daunting since they seem likely to present a risk to the quality of processes and systems. These things are also typically developed through their respective management methods, such as total quality management. It would make sense to discuss whether an Agile operations model can sometimes be at odds with other development models or whether Agile methods sometimes pose risks that should be prevented.
The principle behind Agile activities is to provide support to all kinds of operations that aim to develop over time and highlight the benefits of learning. In that sense it’s not at odds with quality or process development. Koskela adds that being Agile is particularly well suited for dynamic environments and complex problems, where not all variables can be identified in advance or where an experimental approach is needed to analyze solutions.
Be that as it may, the risks of Agile need to be recognized in the development of crucial operations, whose functionality has to be guaranteed in every situation. However, if these types of systems are built in a modular way, it is still possible to use Agile development methods inside the modules.
The illusion of foreignness
In industrial companies, Agile is often thought of as something new and strange. This can prove to be a misconception.
“Cost-effective operative action is often based on Toyota’s Lean principles, which have provided many of the basic ideas of Agile,” Hirsimäki begins. This means that in many industrial companies the development of operative processes is already Agile. Kaivola continues:
“Let's say you have a hammer and you want to learn how to use as effectively as possible in your production line. You listen to what the users of the hammer have to say and learn new things from their experiences. That’s Agile.”
Many organizations feel that they need to have two parallel systems in place: one for cost-effective operative action and another for innovative experimental operation. There’s no reason why both of these systems can’t be Agile.
“Innovative operations can be about creating a truckload of experimental concepts and seeing what works, whereas operative action be about moving the aforementioned hammer to another location as far as it brings some benefit,” Kaivola explains. “Being Agile is about focusing on quality and aiming to learn and develop,” Hirsimäki summarizes. Maybe it’s not so foreign or new after all.
Organizational structure and culture affect Agile opportunities
The structures and culture of an organization have an effect on the manifestations of Agile.
“Switching to an Agile model typically transforms design, budgeting, management and decision-making as well as performance meters, reporting and rewarding,” Koskela lists. In addition, Agile often calls for the tearing down of organizational silos and engaging everyone from different parts of the organization. The aim is to get everyone to commit to common development goals, which are first defined in order to ensure that everyone understands them the same way.
A traditional authoritarian and hierarchical organization may have a problem with Agile. This may be the case if things like decision-making are slow due to a long chain of command or if failure is not an option.
“Don’t forget that military units, for instance, can still be Agile even though they are authoritarian. The commander first gives the soldiers an order to hold their position, but once intel receives new information, the plan is suddenly changed,” Kaivola clarifies.
Agile changes the role of the leader as well.
“An Agile leader can provide an objective and point to a direction, as long as they don’t determine how to achieve the goal,” Hirsimäki says. If the manager is in the habit of having all the answers, the change can be a hard one.
Koskela points out that Agile is well suited for self-directing teams, which are autonomous, customer-oriented and quick to learn. “Such teams should also have their own budget and they should be responsible for their own time management,” he says. It should be added that even self-directing organizations usually have someone who assumes ultimate responsibility and, therefore, has the power of decision. However, the higher authority is only needed in special circumstances when the team is unable to otherwise move forward.
Different roles, new types of skills
People can’t obviously be expected to suddenly turn Agile without any relevant skills. In general, Agile requires that the entire teams be disciplined, organized and cooperative and that they can relate to the customer. Even though no advance plan is drawn up for deploying the solution, knowing how to carry out planning during the iterations and continuously assessing the results require skills. People skills are also important in the transparent cooperation with the customer.
Competence of the development teams is the key to success, but the company doesn’t need to be in possession of all necessary skills. Skills can be acquired along the way from those who have it. Having good partners is a great start, and the sharing of skills also distributes the risks.
In an Agile model, the customer partners up with a cross-functional team. The developers’, or devs’, role in the team is the easiest to understand, but other roles are needed too. Service designers, for example, facilitate cooperation between different experts and help recognize the needs of both business and users, which are then used in creating solution proposals. Another key role is that of Scrum Master, who makes sure that the team gets to work uninterrupted. This entails finding solutions to potential problems when the team itself is unable to do so.
According to Koskela, by far the most important role in a development project is the Product Owner, who represents the customer and who is responsible for connecting the ongoing project and business needs. The Product Owner also serves as a link between the stakeholders’ demands and the technical requirements of the solutions, prioritizing those that best promote the development of business.
"A good Product Owner is worth their weight in gold. They understand development needs from the business point of view and know how to prioritize accordingly. A partner can provide support in many ways, but in the end the customer always has the power and responsibility,” Koskela says.
The many skills of a development team are used as needed.
Which Agile method should you choose?
There are several available Agile methods, including Scrum and Kanban, which are typically preferred by technical developers, as well as Scaled Agile Framework (SAFe), which scales to the needs of an organization. Method selection isn’t one of the essential points of Agile, however. All Agile methods are based on the same type of thinking, where new designs are deployed to production little by little and the final outcome takes shape along the way.
Koskela points out that all Agile methods require common channels and platforms that enable discussion, help with gathering ideas and assist in documenting and monitoring progress. A good electronic tool shows the task list of the team as well as the remaining tasks of the project in real time, providing a quick overview of the phase of the project. At the moment, most teams use Jira or Confluence. “The tools of the team need to support the objectives and processes of the project,” Hirsimäki says.
Regardless of the framework in place, holding regular retrospectives, or retros, is a good practice. In the retros, team members reflect on their work and the things they have achieved together. They discuss their positive as well as their negative experiences and identify points of development. The emphasis is on learning and prioritizing future choices together.
Learning is one of the most challenging things to ensure.
“There’s no easy way to do it,” Koskela admits and continues that the key to learning is not putting the blame for failure on any individual: “Problems and failures need to be brought up and discussed so that people can learn from them. You have to remember that accepting failures and learning from them are two different things. Communicating what you have learned to the entire organization is the hardest part of all. This is something we’re committed to improving, and I’d be more than happy to hear about people’s experiences of how this challenge has been tackled in the past.”
Scrum is an Agile development model.
Step toward an Agile development model:
1. The revolutionary advantages of Agile for business emerge when Agile is applied across the organization from business development to service development and on to daily technical development. The first step is to make top-level management understand the benefits and operating models of Agile.
2. Agile development is based on not trying to predict all the things the project is going to achieve or need. The scope of the project will become apparent as time goes on and the team gets more information on the needs of the stakeholders and the feasibility of the various aspects of the project. Project-related selection processes are governed by the needs of the business and the objectives of the project. Since the development cycle is kept short, corrections can be made quickly and in time.
3. Agile development becomes more effective when the structures, culture and skills support the self-direction, customer-orientedness and learning of development teams.
4. A good development partner shares part of the risk and pushes you forward even though you wouldn’t have all the knowledge and skills in your team.
Vincit and Bonsky have joined forces to help industrial companies face the future with confidence and gusto. Vincit focuses on the transformation of business and digitalization and seeks to control changes through strategic choices, new business models and thought leaderships. Bonsky Digital develops digital business and architecture with Agile design methods that engage their customers.
Feedback or questions? Contact Vincit's industry experts
, SVP, Strategy & Partnerships, (480) 438-7450
, VP of Business Development, (949) 241-1151