The agile way of working, benefit or micromanagement?

Agile, a word since year is the world of development and also more and more a word within businesses. Everyone wants to switch their working model to be more agile. But what does it really mean and how have I experienced this buzzword bingo around agile?

My experience working agile

I first stumbled across agile when I started working on developing scripts for process improvements. I was always wondering how I can speed up the development process to deliver something in small iterations but already something that can improve process flows or reduce the manual work of myself or my team colleagues.

The first baby steps

After some research how other software companies are doing their software development I started digging deeper in the concept of agile development with its baseline the agile manifesto. And this was eye opening. It was not about planning everything in detail at the beginning before you get something useful, you start by splitting your expectation into smaller junks but you deliver already a piece of software that you can use.

So I started by getting my team colleagues together to start some brainstorming around topics we hate doing manually or that were so boring and time consuming that we wanted to change that. After some iterations we came up with a short list of 10 activities. Based on that list we tried to figure out what could be an improvement with little risk, so we can explore the creation of scripts and learn how agile development works.

Within one week working on this side project we had a simple script that helped us disabling users automatically in Active Directory, moving it to a special organizational unit and remove all licensing groups that are no longer needed. This saved us roughly 5 minutes per user that got off-boarded. That doesn’t sound much and luckily we didn’t have much off-boards back at that time but even with 40 off-boards per year we saved 200 minutes of manual, boring work. The script development to get this working with some error handling was in total around 120 minutes. So we were able to save around 80 minutes per year already and could even save more when we have to handle more off-boards. But the real benefit was to see the team moving away from boring work and think more about automation and options it can free up time to do stuff where they can grow.

This first small success helped us to structure some aspects of agile working into our day-to-day operational job. We were not a development team, we were a service desk support team, so agile was used mostly for these side projects. But based on our first session and first success we had already a backlog and from that we picked more and more things into our side projects where we reserved around 2-3 hours per week to work on. The improvements we made were so significant that we were able to shift more knowledgable work from tier 2 support to tier 1 support and even automate stuff to improve data quality and reduce workload.

All of this was around 2013 and since than it saved us a lot of time because we had more off-boards in between and even added additional functionality to that script logic that saves us now around 20 minutes per off-board.

The next evolution

After the success we had since our first touchpoint with agile, we improved our methodologies and even hired a full time developer who helped us speed up the delivery part. Within a year we had so many ideas in our backlog and delivered constantly every two weeks new scripts and functionality. We even started writing our small little service desk toolkit including a UI, logging, etc.

With the change of my role and the purchase of ServiceNow as a platform for various areas like ITSM or SPM agile became a totally different way of working. Now I had assembled a team that was dedicated to work 60% of their time on implementing ServiceNow and delivering constant improvements our business requesters wanted. IT wanted more automation through workflows, business areas wanted a clear approach on how they can prioritize demands and projects and automate creation of team channels in Microsoft Teams etc. And ideally nobody has to take care about permission handling, data maintenance etc.

This caused me and my team some trouble at the beginning because agile was still something we were exploring. So we looked at different ways how agile development can be done, e.g. Scrum or extreme programming. We started out like probably most teams nowadays using Scrum. We digged deeper into the framework and were did everything that was mentioned in there - sprint planning, dailies, retro, two week sprints, demos, etc.

Unfortunately it felt wrong for us. We were so overwhelmed with meetings, structuring our work, discussing best ways to use the framework but actually we didn’t really improve in shipping working software. So I had made a hard cut to this framework stuff and went back to what agile is about. Use the system to ship quality software that has a benefit to customers faster. We still did and do Sprints, but for a longer period atm. We still do sprint planning to some extend but more focused and not in every detail. We have two short meetings per week instead of dailies because it worked well for us to keep the momentum. We got rid of demos as nobody really listened anyhow and was doing something else in these meetings.

And now this works very well since over 4 years. The only things that is missing right now is a deeper involvement from the business areas who like to work in chaos and have all their own priorities instead of working together and prioritize in terms of what is the best for the company. But we are working on this.

Agile reached the management level

When we started out with that agile way of working in the service desk team we were smiled at by other teams and management. The young manager has strange ideas. That was basically what was coming up all the time because I did things differently. Not only for the agile part but also other areas of leadership (probably something for another article).

After some time and with the switch to ServiceNow agile made its way more and more into other teams and therefore it became a topic in management as well. All bigger companies were working agile, so we needed to do so as well. Agile was now a management term and no longer a way of working within software development.

Now, we are at a level where management is pushing all teams to work “more agile” but a lot of the managers I talked to have no idea what this really means. After some discussions I learned that agile for management means doing scrum and use xyz tool for having nice kanban boards and follow the rituals. This was agile for management but at the end the biggest part was missed. Working for the needs of customers (our business) to ship quality software, process improvements, etc. in a faster way without overplanning so you can steer quickly if the market or other requirements are changing.

We now have scrum masters, agile coaches, different tools, sprints in projects, sprints in teams, and the list goes on. But what we have achieved was mainly having more meetings and less output, similar to what I mentioned already in my own experience. The issues is this is not yet recognized by everyone in management. We still are in discussion about tools and similar methods for each team, even though each team is different, has different requirements and a different maturity level of agile.

For me we are having currently a hard fight about agile and what it really is all about. On one hand management wants to have more autonomous teams, on the other hand they want to push everyone on the same tools and frameworks. We will see where we will go from here, I’m happy atm that it is not a hard order to use the tools and all stuff from scrum so we can use what is helpful and skip the rest in my team.

How are your experiences with agile? How is your management dealing with it?