Development process

Introduction

The development process is the heart of the network automation practice. A well working, documented, straight forward process that is designed to deliver high quality output (releases) will increase the success rate. However, to make it a success, all involved people (Automation group members) need to understand where they fit in and how they contribute to the process. Continuously and incrementally developing and improving the development process is a mindset and behaviour that has shown to be efficient, rather than fewer and larger reviews and updates. The majority of this section is basic software development ways of working and knowledge. Therefore, recruiting and engaging people with extensive software experience will both increase quality of the process and remove risk of inventing things that already exists.

Why a development process

Defining and structuring the development process is important for many reasons:

Decrease potential confusion regarding how the teams' works
Good for new team members to quickly understand how the team operates
Everyone have the same context and potential improvements can more easily be discussed and implemented

Below is a conceptual picture of a what a development process could look like

Methodology

There are many software development methodologies (agile and non-agile) available and as many opinions about which one that is the best. It is not about choosing the right one, is rather finding a way to work that suits your organization. Below is a list of some of the most popular methodologies:

Scrum
Kanban
Extreme programming
Waterfall

Focusing on an agile software development methodology is highly recommended due to that they have the flexibility (that software delivery requires) built-in. Another recommendation is to choose one method, learn from it and then do the proper adjustments to better fit the organization.

Key principles of agile software development

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

To read more about software development methodologies, a visit at the https://en.wikipedia.org/wiki/Software_development_process could be a good start.

Stakeholders

There are many stakeholders involved in the development process. To simplify, we divide them into external stakeholders and internal stakeholders:

External stakeholders

External stakeholders could be people/groups that have direct or indirect impact on the development. Examples of external stakeholders:

Operations team that operates the use cases
Business owners that want something to be automated with help from the Automation group
Support organization that needs to get a bug fixed

Keeping the external stakeholders up to date with ways of working tend to be on a need to know-basis and therefor kind of scattered. The point is not to involve all external stakeholders (if any) in the process, rather it is about setting the right expectations based on how the process is designed and the current workload. Much time is spent on stakeholder management and handling escalations. Describing the processes, on a regular basis, for the external stakeholders could therefore be a good investment in the long run.

Internal stakeholders

The internal stakeholders is anyone within the Automation group (i.e developers, architects, automaton director etc.). As the team grows, both in numbers but also competence wise, it is suggested to review the development process on a regular basis. Getting the team members to feel committed to the process and its potential improvement is something to strive for. Having someone owning for the development process is highly recommended.

Process owner

Having a dedicated owner for the entire development process is suggested. The main responsibility would be:

Continuously review, improve and update the process
Make sure the process is documented and easy to access
Be the go-to person for questions that regards the development process

Suggested roles that could own the development process are:

Product owner
Program manager
Team lead

Workflow and process activities

The core flow within the development process is the Workflow. It defines what stages a ticket is going through before it ends up in a release. There are many dialects of workflows but they usually begins with a NEW state and ends up with a DONE state. In between there could be many stages and the most important is to find a workflow that works for the purpose.

Test

Testing is a corner stone in the development process. Please see separate section about testing and CI/CD.

Issue types

Issue types are the categories of tickets. Example of issue types are:

Bug
Feature
Enhancement
Story
Epic

A general recommendation is to use as few issue types as possible (four-five issue types would be enough). Organizations that chose too many issue types risk to spend more time on choosing the right issue type rather than just choosing one. For more information and inspiration, Atlassian has defined issue types in a straight forward and understandable way: https://confluence.atlassian.com/adminjiracloud/issue-types-844500742.html.

Prioritization

Prioritization is a central and critical part of all software development projects and organizations. The key is to not mix prioritization and planning. Prioritization should solely focus on which items that are most important. This activity often requires both architects (to cover the technical aspects) and business owners (to cover the commercial perspectives). The priority of items is reflected in the backlog and the higher up an item is in the backlog, they higher priority the item has. Establishing a clear and straight forward prioritization process where stakeholders know what they can expect in terms of communication and transparency will save a lot of time for the accountable person/group that owns prioritization (usually the Product owner). A recommendation would be to schedule weekly prioritization meetings where business owners, Product owner and architect(s) review the priority and discuss incoming requests. It is then up to the teams to plan the work stated in the backlog.

Planning

Planning the development work in an agile context can sometime be tough. Many organizations origins from a waterfall way of operating with plans that stretches over long time while many agile methodologies are built upon a changing environment and therefore promote less longterm planning. To succeed with the planning in an agile organization, the priority needs to be clear. If the priority is clear to the team managers, they can plan the coming weeks' development and better forecast what will be included in the next release. The collaboration between the person who owns the prioritization (often the Product owner) and the development teams is therefore essential in order to get successful in software development. Setting up a process for this collaboration is a good approach but the process needs to be supported by the right behaviour from all involved parties in order to work. This is nothing unique for software development (that all processes need the proper behaviour support to work) but many immature software development organizations tend to rely more on processes then on the human interactions.

To summarize, the main purpose of planning is to forecast what will be developed given the current priority.

Retrospective Retrospective is another word for reflection and a well known term within the software development community. Reflection focuses on learning from previous actions and is a fundamental part of all personal and team development in any organization in any industry.

Retrospectives are a good way to reflect and something most software developers are used to from working with agile methods. Conduct a retrospective on a bi-weekly routine could help the team perform better and also encourage a good and positive work environment. There are several flavours of retrospectives and the point is more to have one than have the right one.

Example of retrospective structure and content:

What went well? (10 mins)

Start the session on a positive note. Have each team member use green sticky notes to write down what they feel went well (one idea per sticky). As people post their stickies on the whiteboard, the facilitator should group similar or duplicate ideas together.

Discuss your ideas briefly as a team.

What needs improvement? (15 mins)

Same structure as above, but using pink or red stickies. Remind your team that this is about actions and outcomes – not about specific people.

Next steps (5 mins) Having identified what didn't go so well, what concrete actions can the team take to improve those things? Have your team use blue sticky notes to place ideas on the board. Group them and then discuss as a team, agree to which actions you will take, assign owners and a due date to get them DONE.

Thank everyone for their involvement and their honesty. Quickly run through the list of follow-up items, their owners and due dates.

Source: Atlassian

Definition of done

Definition of done is a well used term and concept in software development and basically means: What needs to be achieved (developed/tested) in order to define that it is done. Many software development teams have defined a list of actions that every developer should check before they can declare the development as done. Generally this is applied both to each ticket/user stories and at the end of a use case.

This is just an example of what a definition of done could look like, yours might leave out some steps and add in others. Getting to know the chosen development tool and adjust it to work according to your defined development process (i.e the stages in your workflow is represented in the tool) is a good start. Focusing on how to integrate with build servers and test framework will increase both quality and efficiency. Working towards automating manual steps within the workflow will pay off.

Documentation

Documenting the entire development process is hygiene. Also documenting and providing guides for how to work with the separate tools and sub-processes is good.

Tools and integrations

There are many tools available to support software development. Example of tools are:

Jira
Trello
Github
Bitbucket
Jenkins
Bitten
Sonarqube

If your team doesn't have any experience of the tools mentioned above, a recommendation would be to start looking at Jira (part of the Atlassian suite). It is a well functioning tool and have lots of integrations towards other useful tools.

Best practises

Implement a software development process and invest time and resources in automating tests and a solid CI/CD pipeline
Mindset of establishing an “automation factory”
Establish continuous improvements

Checklist

A structured software development process is followed
Retrospectives have been conducted and learnings documented and are available to use for next use case
Documented and continuously updated processes