The document discusses how agility in 2016 relies on cross-functional autonomous teams with insight into how their service behaves through monitoring, and the ability to deploy changes quickly and frequently through continuous delivery. These three aspects - cross-functional teams, monitoring, and continuous delivery - are enabled by practices like DevOps and help teams adapt quickly based on feedback.
31. Cross-functional autonomous teams
with insight into how their service behaves and is used
that can deploy changes quickly and frequently
=
Agility in 2016
Editor's Notes
First i want to talk about
cross-functional teams, which has always been an important element of agile.
5 or 10 years ago it was not uncommon to work like this.
Here we have a development team developing a new release and throwing it over the wall to a separate testing team.
There is not a lot of communication or collaboration.
which meant that the development team would get feedback very late in the process - after implementation.
The development team would not have easy access to the QA competence.
Agile software development helped us tear down that wall and integrate quality assurance into the development team.
Now it is very common to work like this. We have different roles with different competence working together in one team.
The result of this change was less waste and higher quality software.
However,
we are still doing this with operations.
It’s pretty common to have a separate operations department or team taking care of deployments, monitoring, infrastructure changes and other operational tasks.
So of course we experience the same problems and inefficiencies here, as we did with testing.
Fixing this problem is what DevOps is about.
We want to break down the wall and integrate development and operations, just as we did with development and testing.
So in this sense DevOps is not really new, it is rooted in the cross-functional aspect of agile software development.
According to Gartner, DevOps will be employed by 25% of the top 2000 public companies in the world, this year.
Visma is also moving in this direction, for instance with the Visma Cloud Delivery Model.
As you probably know, the VCDM is a collaboration between VES, PU and VITC, and describes a common modern approach to developing, delivering and operating cloud services.
Today there are 2 teams in PU working according to this model, and we expect many more teams to be onboarded, both from PU and VES, this year.
DevOps is a big part of VCDM. In the VCDM, there is no development team.
Instead there is a “Service Delivery Team” with a broader responsibility and competence than a traditional development team.
A service delivery team is not just responsible for building a product, but developing, delivering and operating cloud services.
So how does DevOps make us more agile?
When we move operational responsibility and competence inside the SDT,
that team is now less dependent on other parts of the organization because they are able to solve a wider range of tasks within the team
this is very important because as soon as you have work leaving the team, the time that it takes to get it done can increase by orders of magnitude
a team with less dependencies is a more efficient team
Also, when we have a new type of competence within the team
we have more opportunities to adapt in the development process
Example: If I want make a change to my service, and that change is bad for operational reasons, I can now get that feedback early, instead of me having to implement something and find out later when i have already implemented something and it has been deployed to Production.
The second thing I want to talk about is monitoring which is another form of feedback we can use to be agile.
If we are interested in delivering a good service to our customers (and not just building an application),
we need insight into what is going on in our Production environments!
How can you be agile if you have no idea what’s going on in Production?
Everybody in the SDT, as well as other parts of the organization, should be able to look at dashboards like this to understand how their service behaves, and how their users behave.
The SDT can use this information reactively to discover and fix problems quickly after they happen,
but the goal of course is to use this information proactively to improve our service before customers experience problems.
If the SDT can see
how users are using the service
which features are most popular
which parts of the service are getting slower
That’s valuable information that should be input to the development process.
This type of information is even more valuable if the SDT can react quickly, which brings me to the final topic.
Continuous delivery is already a priority in VES, and it is also a part of the VCDM.
We want the capability of deploying changes, quickly and frequently, which could mean many times a day.
Having that capability makes us more agile.
If we see a problem (or something that will soon be a problem) in Production, we want to be able to fix it in minutes. If we see a sudden market opportunity, we want to put an initial solution in the hands of new and existing customers as soon as we can without being constrained by planned release dates.
After we release something, we want to improve based on feedback from customers, from monitoring and from other sources. And repeat that cycle. Again, and again.
And this cycle is really the heart of all of this.
We want service delivery teams who can plan, code, build and test. That we are quite familiar with. But to be truly agile we need to become equally as familiar with the second part: Release, Deploy, Operate and Monitor.
Then we want to repeat this cycle quickly and frequently; quicker and more frequently than our competitors.
Then we are more likely to reduce waste and deliver high quality cloud services that meet the customer and market needs.