Skip to content
loading...
Discussion
markdown guide
 

TL;DR: Patience and Persistence. Start with the smallest possible thing.

First: Good luck on what will be a long, and rewarding journey!

In the case of both DevOps and agile, you're talking about significant cultural changes in your organisation. The first expectation you should set for yourself is that it will be a slow, arduous and very incremental road. Don't expect to be DevOps super heroes over a weekend, unrealistic expectation will make you sad :(.

I come from a position of significant bias on this (the organisation I work for is very well known for facilitating exactly the change you're looking for), but it can be very helpful to engage experienced, external parties to help your organisation make the right moves on what is a very long and foggy journey. Not a sales pitch, I promise ;).

In general, you're going to want to start with the smallest thing. In the case of agile, it's very common for organisations and teams to just start with holding regular retrospectives. Once a fortnight or so, to look at what's helping and hurting them. From these retrospectives you may discover things like "we don't know who's working on what at any given time", "it takes us too long to decide on what to build", "it takes too long for us to release new features once devs are finished with them". These are all actionable issues that can be remedied with a variety of practices.

I guess the key here is: Don't just do what a book/podcast/resource says to do. Do the things that you demonstrably need to do based on data you collect from within your organisation. That's what it's all about. See an issue or a change, and respond to it. Implementing solutions for problems that don't exist yet is a fools game.

 

When I was incharge of a change program at the top management level, I was pushing the program with the benefit for the organization. Then my CDO (chief delivery officer) advised me think deeply about what they would get of the change program. That changed the momentum of the program.

  • identify few champions at each level (CXO, top management, developers, your peers and so on)
  • identify what is in it for them. The incentive is different at different level. Ex: For CXOs it could be stability and confidence; for developers it could be saving in time and so on.
  • start small and go for low-hanging fruits to build momentum. Depending on the competency of the team, you could start anywhere from version control to automated deployment. Show benefits for them. Build on that momentum.
  • Truman said, "you can get anything done, if you don't care who gets the credit". Give these champions lot of credit. Shine the light on them. Nobody should see you. Find ways to show these champions as success. Let their peers envy them. Then these champions will take it upon themselves to take the program forward. Their peers will embrace. After certain point, you don't have to do anything. Everybody would want to be part of the game.

Watch this 3 min video of how to start a movement: ted.com/talks/derek_sivers_how_to_...

Classic DEV Post from Jul 30 '19

PublishTo.Dev: Scheduling article publishing on dev.to

Scott Howell III profile image
When I'm not trying to find constraints to fix in the value process I can be found digging through books looking for history of Native American Beadwork