Agile Transformation in Software Development. Part 2

Risks Associated With Outsourcing

Last time we looked at selection criteria for a 3rd party software development company. Also considered why Agile transformation may be important for software development companies competing in the outsourcing market. Today, we will look at what risks clients may face when outsourcing software development, and how to mitigate such risks. Furthermore, we’ll look at whether it is possible to determine if the processes of a potential service provider are Agile. And how to minimize risks associated with their quality.

Evaluating software developing companies, what risks does Thomas foresee?

1. Lack of transparency.
2. Little or none of the control over decision making.
3. Insufficient understanding of functional and nonfunctional requirements, which may lead to poor results and poor quality.
4. Missed deadlines due to the poor internal process of the contractor.
5. Decline in quality of produced work due to poor processes and/or lack of expertise of the team.
6. Missed deadlines and compromised quality due to human error, failures to perform, layoffs, lack of motivation, etc.

How can Thomas minimize these risks?

Lack of transparency and control over decision making

Solutions for these risks are similar.

1. Thomas can enter “Command and Control” mode, plunge into macro-management and control everything and everyone. That’s what Thomas would be required to do should he go for Crazy Llamas. Just as well if he was to hire a remote team alike.
2. There is an option of regular detailed reports. Although, it is not clear who will pay for the time spent producing such reports. The outsourced company will not welcome additional expenses. At the same time, the client will consider such reports an integral part of the service. A conflict of interests may occur. Though it will be subject to negotiations.
3. Lastly, Thomas can be a part of a clear, agile process set forth by Scrum with standups, demos, retrospectives. Besides fulfilling the role of a Product Owner, Thomas will get full transparency into the development process.

The optimal option for Thomas would be agile development. The requirement is that the development team of the chosen company fully understands the Scrum process. One can establish this fairly quickly, in a few minute conversations. Though the proof will be in the pudding. Once the work begins, it will be clear as to how well the team can work in this paradigm.

Lack of overall understanding of functional and nonfunctional requirements, which may lead to poor results and poor quality.

1. One of the solutions may be drawing up a thorough Requirement Specification document and setting out clear criteria for meeting the project’s success measures — time, budget and functionality. Possibly, drawing up a Project Charter as well. This approach works well in certain niches. But Thomas is from a different camp. He needs to build a product, rather than deliver a project.
2. Formulating hypothesis statement. Agreeing on the definition of acceptance criteria, restrictions, and nonfunctional requirements. As well as working out with the development team the definition of ready and definition of done. These are other ways of going about the lack of understanding of functional and nonfunctional requirements.

Thomas could do with a standard set of Agile methods and tools. The question is whether the team will be adept in applying them. Again, it will only take a few minutes to get an idea. But it will need a reality check to find out for sure.

Missed deadlines & decline in quality of software due to poor processes and/or lack of expertise.

1. Strict control points, penalties for exceeding timelines, strict limits for the number of defects, aka Waterfall. Effectively, the client can place all the responsibility on the development team. Yes, the timelines will be dragged out regardless. Bugs will be found and fixed anyway. At least, the client can be entitled to compensation… As long as the client gets the compensation and the software, the quality of the processes doesn’t really matter. The software development company will remain a black box.
2. Another solution may be for the client and the software development company to create a common process. They could monitor burndown charts for each sprint and the project as a whole, manage priorities and scope. Thomas will always have the option of either pushing deadlines or reducing scope without changing the initial agreements. From the outset, they can draw an SLA specifying the acceptable level of failures. Thus, Thomas can make the developer responsible for fixing, at their expense, any failures that occur over the agreed level.
3. Rigid control of technical realization. In this scenario, Thomas will have two options. He either closely monitors every single detail of technical implementation himself or delegates it to a manager from his company. The development team will have a certain degree of flexibility at the level of tasks. The user stories will be controlled by the client. Hm…why, bother then? Hiring a remote team would be a more straightforward option.

Option 2 looks the most attractive. Though, again, it is not clear how it will work in reality. It is very difficult to verify risks in a conversation. The outcome will be the gauge.

Missed deadlines and compromised quality due to human error, failures to perform, layoffs, lack of motivation, etc.

1. A “black box” approach whereby the responsibility is transferred to the service provider. This might work if it is a one-off and there are no further plans to work together.

This isn’t the right option for Thomas. Should the developers burn out, and Thomas is unaware, sooner or later the knock-on effect will become his problem. Regardless of the agreements in place between himself and the software development company. Thomas will risk losing the entire team along with the context of the project, domain knowledge and accumulated practical experience.

2. Thomas can opt to keep a close eye on the overall process. With the help of standups and retrospectives, Thomas can spot early signs of fatigue among the team members. These Scrum ceremonies reduce the chances of errors as well as prevent exhaustion and burn out.

This option isn’t as straightforward as it seems, though. Thomas either will have to submerge himself in the problems of the team, delegate internally or to a manager of the 3rd party company. And only time will tell how effective this manger will be.

Having weighed up the options, Thomas decided that one of the major criteria specifically for him will be the ability of a development team to adopt, maintain, and work effectively within agile processes. Scrum will do, to begin with. But potentially, with the increase of the volume and complexity of work, more teams may be needed. This will call for scaling of the agile process. For example, the 3rd party should be willing to implement a Scaled Agile Framework or Scrum of Scrums.

Companies can claim to be Agile and say they implement Agile frameworks, tools, and practices. It doesn’t mean that they do it well. Thomas concludes that there are very few means to establish beforehand whether a software development company is truly agile.

Determining if the software development company is Agile

So, how does one determine? Sadly, there isn’t a bulletproof way. You can hear lots of clever words and abbreviations. Scrum, DSDM, DAD, benefit hypothesis, Lean canvas, and Growth mindset. All of your questions will be answered. Every step of the process will be spelled out using LESS or SAFe. And elaborate diagrams from ADO will lull you into something that it is not.

A picture-perfect will unfold before you… You’ll see yourself on a white cruise ship. The fresh sea breeze will play in your hair. The music of ocean waves will fill the air, and the sunset will paint the sky in the glowing colors. A dream-like vision may tarnish when signs of something going wrong first to appear. For it to transform into a nightmare when the deadlines are missed, software quality is poor, and the team is burning out.

Unless you understand how Lean-Agile supplier should work, just as Thomas does, you may not be able to spot the early signs of trouble before things go pear-shaped. It’s hard to tell how much resources you would have committed to the project by then. Creating a common process and building a relationship with the team takes time and effort. All that would have gone to waste.

There is no way of saying at which point you will be able to confidently say it is no longer the minor shortcomings caused by the adjustment of two companies and the people to each other but rather systematic errors in the process.

How to minimize this risk?

Quite logically, an external IT and software development process audit can shed light on how the company’s processes function. It should be a thorough review of a specific project. Better yet a few projects, where you can see the real state of things and not the picture-perfect.

We carried out a software development process audit for an in-house IT department of an automobile parts distribution company. The IT department was responsible for the development and support of a product that supports the core business process.

IT Reengineering

In this case, the request for an audit came from within the company. The senior management saw that something wasn’t quite right and needed to understand what exactly was not working. We were brought in to identify the limitations of the process, evaluate the performance and provide recommendations for improvement. Unlike Thomas, who would have carried out the assessment and evaluation using his company resources and his competencies, our client had to use external professional help.

We closely monitored the development process for a week. We saw that the way the team was operating was not even close to Scrum. The process of setting, formalizing, and reporting completion of tasks was lacking clarity and structure. We compiled a list of necessary improvements and general recommendations.

Over the next few months, we helped our client to build and optimize the process. This led to increased motivation and effectiveness of the team and improved communications with other departments of the company. The development department evolved from a “black hole” consuming the budget to a value-delivering department working within a process that is clear and transparent.

To sum up, convincing words do not always mean a well-working process. The devil is in the detail. And it is not always possible to quickly pinpoint what risks may one come across when outsourcing software development.

Next time we’ll talk about what options are available to software developing companies when it comes to Agile transformation, as well as when SAFe may not be a good option for scaling Agile across an entire company.