Cloud-technology is a tool

Us engineers are eager to get our hands dirty and dive into difficult architectural- and implementation tasks. We love to speak about technology and how to implement wonderful constructs. Good architecture and implementation is crucial, but we should not forget to put the customer to the spotlight. Do we have a solid business case and most important where is the value?

To project hardened seniors reading this, what would resonate in the manner to get you chills.

You know the feeling, when things really click. Your peer colleague succeeds in difficult project or the architecture comes together.

To us, who have experienced dozens of projects and clients, we tend to know the direction for the chills for success.

Meaning, we have created models from the past experiences. These models are formal structures explaining the world around.

The models

If we master and understand the models, it improves our communication, enables us to explain difficult scenarios, reason and cooperate with our teammates, predict the outcome from a solution and furthermore explore different options.

When our thinking is logical, consistent and based on past experiences, we are more likely to make wise choices. No matter if we speak about development team trying to implement difficult business case or just us cooking for our family.

The same is true, when a salesperson tries to find out what a customer truly needs or when we are implementing the next cloud-enabled solution for the customer.

Building value

It is all about building value. Is the food you prepare the value or is it merely a tool for you to have energy to play with your children?

Nevertheless I’m sure each and everyone of us have made up models, how to build value and get the chills in different situations.

Good architecture and implementation is crucial, but we should not forget to put the customer to the spotlight.

Do we have a solid business case and most important where is the value? We should not ask what  the customer wants, but what the customer needs.

Try 3 whys the next time you’re thinking of making a big decision:

“Why we are building the infrastructure to the cloud?”

“We need to grow our capacity and we need to be highly available and resilient”

“Why it is important to improve scalability and resilience?”

“The old infrastructure can not handle the increased traffic”

“Why the old infrastructure is not enough anymore?”

“We have analysed the platform usage. If we get more capacity on the rush hours, we can serve more customers.”

Productise

All right! We are convinced the customer needs the cloud migration and start working with the implementation.

Solita has productised the whole cloud journey, so we can quickly get into speed.

Ready made instructions, battle proven implementations and peer-support from earlier projects will help you up to speed.

Technical solutions follow a model, meaning there are few ways to provision a database, few ways to do networking in the cloud, few ways to optimize expenditure.

When we do not plan and develop everything from scratch, we build value.

Re-use

According to study published in the book Accelerate: The Science of Lean Software and DevOps, to be productive, everything should be in version control.

For sure the application code is already in the version control, but also system configuration, application configuration and scripts for automated build, test and delivery should be in version control.

The study revealed, keeping configurations and scripts in the version control correlated more to the software delivery performance than keeping the application code in the version control.

When building for cloud, the infrastructure must be defined in code. And the code should reside.. in version control!

This enables us to move faster without trade offs. We can recognise modules, implement them once, create automated tests and then re-use the codebase in customer repositories.

Every time we are able to do this, we build value.

Automate

Humans are erroneous. This is an experience based model. When computers handle the repetitive work, it enables people to solve problems.

We know from experience, automation requires investments and should be implemented from day one. Investments done here will result smaller development lead time, easier deployments and more quality code.

In cloud, we describe our infrastructure as code. This goes hand in hand with automation. Based on this model, we choose to automate recurring tasks such as building code, testing and making the deployments.

As a result we speed up the feedback loops, have repeatable results each time and enable developers make quality code and automated tests. We test our infrastructure in the pipeline and once again build value.

Deliver

Deliver continuously in small chunks is an experience based model.

You most surely want to have your piece of code tested and delivered to production before you forget, what you were doing.

Short lived branches or Trunk-Based Development predict performance. Failures in small changes are far easier to fix.

Also test automation is key part of continuous delivery. Reliable automated tests predict performance and improves quality. Diagram below is from the book Accelerate. 

High Performers who had adopted the Continuous Delivery model spent far more time on new work than in unplanned or rework.

Although unplanned, emergency and refactoring work is a necessity, value is built when implementing new features.

Software Delivery Performance

Measuring software delivery performance is difficult. An incorrect productivity metric can easily lead to poor decisions.

If you want to deliver the feature as quickly as possible without trading for quality, one key metric is development Lead Time. This is because code not in production is a waste.

For example Software Delivery Performance can be split to 4 topics:

  • Lead Time (from starting implementation to delivery to production)
  • Deployment Frequency (more often results smaller changes)
  • Mean Time to Restore (how to recover from failure)
  • Change Failure Rate (how often the changes cause a failure)

According to the study made by the authors of the book Accelerate, these are the measures from different types of Organisations:

Conclusion

Past experiences makes us what we are. Stop and think the models you have crafted. Challenge yourself, interact with your peers, find out new models for building value.

Together with the team and with the customer, you’ll will find the best solution for the opportunity at hand. Remember the actual implementation is only a fraction of the whole journey.

On pure technical aspect, we should re-use as much as possible and we should automate as much as possible. When talking about cloud migration, infrastructure must be described as code (IaC).

Does your organisation understand and use the models?

Does your organisation productise and re-use the codebase?

Let’s build value!

 

Azure boards – does it make sprint planning enjoyable?

There are many different kind of services that aim to control development teams activities. Azure boards is one of them but it takes integration a one step further (into azure of course, why someone would want to use something else?)

Azure boards aims to make sprint planning easier and faster than ever before. Combining ease of use and plenty of customization options it sounds pretty good but is it worth a try?

I would say that if you are heavily using Azure already this is something you cannot miss. Boards takes everything one step further than its competitors. Sure you can have the same features on Jira too but it takes lot more work to get it done.

Boards uses Kanban -style board to manage tasks and combines that into deep integration into source control and Azure DevOps.

I am not going to go into every detail here but just to overview how we have used this board to manage sprint activities.
And also how to get relevant info into different stakeholders.

Lets Scrum

With this view we are building we have a different view for developers and people who want to have oversight on how things are progressing.

We use Scrum process as a starting point where views are divided into backlog items and features.

 

 

 

If you are starting a new board choose “Scrum” as the process when creating a board under advanced options

 

 

 

If you already have a boards in use and you are not using “Scrum” you need to change the current process into scrum. To change it go to organizational settings and choose process under boards.

There we see all the available processes.
Choose Basic by clicking it. This is the default process that boards assigns to your board when creating.

Then select projects and under this you see your board, in this case “Test board”. Press the three dots and select “change process”

Select “Scrum” from the dropdown menu and off you go.

 

Depending on how much items you already have on your board you might need to resolve some conflicts like wrong type of items.

Now go to your board see that there is now different views for backlog item and features. Structural flow is that backlog items are child items for features.  Features simply define a feature that is being implemented and backlog items are steps to get it done.

Let’s start by creating a feature.
Make sure you are at Feature view at boards. This can be changed at top right corner dropdown menu. (choose Features)

 

Click “New item” and name the Feature, in this case i named it as Testi feature nro 3 as i have couple of items done already. Then we proceed to make a backlog item belonging into this feature.

 

Click the three dots on the right hand corner of the item and choose “Add product backlog item” to add a child backlog item. Name the item as you like.

 

Once you made a first backlog item under feature you don’t need to go through that three dots menu again to make more backlog items. Because now there is a “Add product backlog item” straight at the card.

And you can add more items by just clicking it.

 

 

Now we have some content on our board and we can see how this is structured. We have two views now. A backlog item view and feature view.

Backlog item view is used mainly by developers where they see individual tasks and what is their status.
Choose this board by clicking upper right hand corner drop down menu and select “Backlog items”

This presents a view of backlog items and their statuses. This is pretty standard view, there are items and they are assigned to developers

By clicking open one item you can see more info like which feature is a parent for that item.

 

 

 

 

Another view that we use here is a feature view. This is to be used by people who are supervising developers or a client who would like to see how things are progressing.

Choose this board by clicking top hand corner dropdown menu and choose “Features”

The beef here is that this view presents immediate visualization on what is the status of features and how many backlog items under that feature are done. And we don’t want use same view for everyone as this would be a compromise.

Customize

Now lets look a bit into customizing the Scrum process. As it is often a case that we need something that is not part of the standard process.

 

Click Azure DevOps logo on the left top corner and click “Organizational Settings” at the bottom

 

 

 

Select “Process” under Boards

 

For us to be able to make customizations into processes we need to make a copy of them. Original processes cannot be customized.

Click the three dots next to “Scrum” and click “Create inherited process”

Name the process as “Scrum customize”
And once done select and choose “Set as default process” to take this into use.

Click “Scrum customize” process to open the following screen.

Click “Product Backlog Item” to make a customization for that item type and how board handles it.

Choose “Rules” and “New Rule”.
Customization we are doing here is that we want to assign a product backlog item automatically into person once that item is moved into “Committed”

See the following screenshot on how this is done.

First we make sure we don’t overwrite assignee with this rule as we check that “Assigned To” field is empty. Then we check that when the state is changed from “Approved” to “Committed”. As with Scrum this is the normal flow, once item is appoved a developer can start to work on that and then state is “Committed”

once all the previous rules are met we change the “Assigned To” for the person moving the item into “Committed” state.

With this kind of simple changes we make it faster to handle items on boards and take away those annoying things that you need to do manually everytime.

There are lots of other stuff that you can do with boards. But this was just a small look into what is possible and how we have seen this is best used.

If you have any questions about Azure Boards or any cloud related matters please do not hesitate to contact me

toni.kuokkanen@solita.fi
+358 40 1897586
https://www.linkedin.com/in/tonikuokkanen/