About a month ago we started the Self-Service Approach topic with an article covering it from the perspective of application integration: What the latest self-service integration features for developers are, and what, in this light, companies should pay attention to when choosing an integration tool.
This week I would like to revisit this topic, but as promised, from a different angle. This time we are going to outline the application of the self-service approach in agile software development, or in other words, in agile organizations.
If you remember, I mentioned that this scenario needed a bit more investigation, and so we searched for companies who either apply self-service approach themselves, or help other companies do that. Below you’ll find an extensive interview with a CEO of an Agile Services company. In addition to that, two companies will share why they love the self-service approach in the context of agile software development.
Why Agile?
First and foremost, let’s review why the concept of agile software development has gained such popularity.
If you are or were in IT at a large organization, you are probably very well familiar with the usual IT project cycle. First you spend a couple of months designing a new update or a new software feature, then you need another couple of months to build it. Testing it would take yet another couple of months, and finally you are ready to go live. In the best case scenario, you have at least about half a year lying between the original idea and the final outcome.
This means that your business has to analyse and decide way upfront what new products or new features your business users, or your current or potential customers will need. What could possibly go wrong in this scenario? And the answer is: Practically everything. With such a rapid technology development as we observe today, in half a year’s time the market can change completely; your company might develop a new strategy for better user engagement or recognize new opportunities; new technology or new products can (and will) appear.
If you do agile software development, you don’t know this dilemma. If your IT organization is agile, you typically would have several teams working on the same project in short-cycle sprints. Every sprint means you deliver a ready-to-use piece of product, be it a bug fix or a new feature. It might still be ‘raw’, but at least you already have it.
This means, first, that you do only what is really important now, and not what MIGHT BE important in half a year. This way you can react to your business users’ and customers’ requests organically, adding a module or a functionality that is particularly desired and needed. In the end, the role of IT is to keep your business going, which means delivering products and solutions that make the life of your business users and your customers easier and happier.
Then you can also react to any market shifts, new demands or appearance of new technology timely, and correct the course on the go if needed. And let us not forget the fact that any mistakes can be detected and resolved this way considerably faster, so that you don’t have to roll everything in six months back, just because someone oversaw an error halfway.
With so many obvious benefits at hand, it is easy to see why the principles of agile software development is preferred to the waterfall way of working.
Agile software development requires a new mindset
At the same time, sometimes, companies fail to adopt the Agile. They might be following all the right ‘rules’, but they don’t really see this working. And the reason might be lying in the old mindset. In the desire to still control everything, sticking to legacy systems and known technology, prescribing what tools must be used, developing manuals of do’s and don’ts and making developers stick to those.
The problem is, this just kills Agile. The new way of developing software also requires the new way of thinking. And self-service approach goes together with this new mindset. However, self-service doesn’t mean (at least not necessarily) that your teams use whatever tools and technology they whatever they can get their hands on. It requires a far more planned approach.
Self-Service should be built upon automated repetitive tasks
Zubin Irani is founder and CEO of cPrime, a US-based $50mm company that helps Adobe, GAP and Pinterest (among others) leverage the intersection of DevOps, Agile and ALM. From his own experience, he knows that in order to achieve success in short-cycled sprints, it is important to have certain processes like building your code or creating a new prototype environment fully automated.
Normally, “some of these things require help from external teams, it could be an environment provisioning team, or Load Test QA team, or a DevOps team. If these things are made as a self-service, it could be achieved much faster,” he told us in the interview. He made it especially clear that he meant not some items that are done only once in a lifetime of a project, but that actually keep repeating all the time. “It is better to convert these implementations or executions into a self-service tool, it saves a lot of time in collecting requirements, implementing them, and making changes for future engagements.”
This might sound as if plucked out of the air, but in fact, I heard a CPO of a big telecommunication company, where they relatively recently adopted the principles of agile software development, telling that they automated their deployments, allowing developers to deploy their code to the environment with just one click. Zubin Irani has a concrete example of his own: “Recently, we designed and built a self-service pipeline for a high-tech client, which allowed developers to self-select the pipeline that best suited their needs.”
Implementation of the self-service approach requires some investment, but it’s worth it
At the same time, it’s not like you’d say “OK, we go with self-service”, and in a minute – to put it in exaggerated terms – you do. According to Zubin Irani, this requires investing some time and, naturally, money. “To implement a self-service approach someone should have spent time in the organization to understand what are the common requests and how long they take to be implemented.”
Some other factors, he said, play also a major role. For one, it should be clearly identified:
- Are these things the ones that are repeating over and over again?
- How can we group tasks, or how can we classify them into a single group?
- Which users are asking for the same tasks?
So, in order to successfully implement the self-service approach, one needs to do a substantial amount of categorization and classification work. The next step would be putting them together and starting analyzing which things should be made self-service first. Zubin Irani mentioned that it requires a ticketing tool or a workflow automation tool like Jenkins to implement the self-service model.
This whole process of identification, classification and analyses BEFORE you can allow your teams to work on self-service basis might seem overwhelming and scaring off. However, Zubin Irani was (and by the way, still is:-) ) convinced that it’s worth it. He said that, sure, it’s all about money and time. But “self-service model is like spending some money upfront to save a lot in the future,” and I guess this is what is most important to understand. The immediate results won’t be visible in the short term, but they will be utmost beneficial in the long run.
Those who use self-service, love it. And for a good reason.
It is obvious, therefore, that implementing the self-service approach for agile software development is not that easy. It requires some careful planning and considerations, and it certainly requires a certain level of control. For example, Zubin Irani suggested in this context “to add roles and permissions to restrict some self-service tasks to a restricted group of people, for example deploying to production.”
But this approach works. “I have seen a lot of people liking this model, as it gives them the freedom to execute things on their own at their own pace,” said Zubin Irani. “Little to zero dependency on others is a big factor in going to this model.”
And he is not alone in his opinion. Mark Tuchscherer, Co-Founder at Geeks Chicago, and Michael Kovacs, Head of Business Development at OpenChannel, both see the self-service approach implemented in their respective companies. And both are highly satisfied with the results.
“We have several tools that we use for projects across all of our teams,” told me Mark in the interview last week. “Systems like JIRA and Confluence are the main ones, but outside of these, we allow people to try out and use anything they feel would help them day-to-day.”
“This policy has worked out extremely well, and it has helped us discover some excellent new tools which we have implemented into our process. One of our teams discovered Bugsnag and Browserstack, both of which we now use on all projects. I think allowing your teams the freedom to test out different systems will help out the company in the long run; our teams love this policy.”
Michael Kovacs shared the same attitude towards self-service. His company has implemented the self-service approach by using tools that are highly extensible. According to Michael, this means that even if the company as a whole has decided on an internal system, technical users can extend the product to meet their needs. “Outside of some experiments and lost time, we haven’t had any major hurdles and would rate our choice to keep extensibility as a top priority very high. We certainly believe it is crucial, and believe that letting people structure their tools is how they will be most effective.”
Of course, some might argue that that the examples named above – allowing developers test other tools and systems – can work only in smaller organizations, but not in large ones. And I actually asked this question Dwight Kingdon, he is principal consultant and Agile coach at Mindtree, and a thought leader in Agile methods and best practices. He admitted that in his opinion, larger organizations will have more challenges as they usually have standard tools and tool suites that have been vetted and scrutinized for development and support over many years. But at the same time, he added that “Agile is all about continuous improvement, so if the case is strong enough for a different platform, stick with it and campaign for your cause. It always makes sense to evaluate tools and technologies from time to time – just like we do Retrospectives after each sprint to evaluate what works and doesn’t work.”
Let Developers ‘Screw Up’, Because They Need To Learn
Self-service approach to agile software development is crucial to giving agile teams more freedom. And they need this freedom, even if it means that mistakes will be made along the way. As Sander Ettema from Rabobank put it in his presentation “Moving from Traditional IT Infrastructure Services Towards a DevOps” [Video] , “It is OK to give developers more responsibility and ownership, and let them screw up something. They need to make mistakes, otherwise they won’t learn.”
