Towards better software

You Can't Learn Agile by Reading a Book

  • April 3, 2016

Agile is a journey that requires learning and discovery. You can't learn agile just by reading a book. There are a lot of good books on Agile, Scrum and so on, and you should read some of them. In fact, my point in this post is to start the journey somewhere, because it's the journey that you will learn the most from.

Software Development is continually evolving as a profession. Effective development teams are always looking for ways to be more productive through new techniques and better ways of interacting with project stakeholders. Agile is a big change, but you still have to start somewhere. As a consultant I work with many clients that are not Agile. Incorporating Agile practices into essentially Waterfall projects have made my projects more productive, transparent and effective.

There is a wide array of practices associated with Agile and DevOps and many of them are very useful on their own. As a leader of application development, I recommend starting with a few key practices. Practices such as daily stand-up meetings, sprints and periodic demos of working software all hold value on their own and deliver some of the benefits of Agile.

You can also start with discussions, attending presentations or having book discussions. With this approach, facilitate discussions on your teams time to release to production, feedback loops to the business, ability to deliver value when needed and so on. There are likely to be widely varying opinions on how these issues are affecting your organization, your organizations ability to improve the situation and different levels of realization that agile might help.

My recommendation is to do both - try some practices and encourage discussions. Your at the start of a long jouney that will be well worth it. Both Agile and DevOps are as much about culture and interaction as they are about implementing new practices. There is not likely a cookie-cutter approach that will be the best for your organization. You will need people that believe that there is a problem and that want to make things better - those will be the people that guide agile to success in your organization.

I tried to write this blog post two months ago.  Every time I read my work it looked like a full fledged recommendation for Wagile. A couple of things happened since then that solidified my argument that you can't can't go from 0 to Agile in one step. In recommending that teams pick a few things to start with I suppose I am recommending Wagile - but only as a starting point on your journey.  Here's what helped me feel good about this post.

First, I attended a local Agile meetup on tools available for Agile and DevOps. The presenter worked for a company that makes tools for Agile teams. He was fair in his presentation and kept it from being a commercial. He also said something that surprised me - he said that he still thinks there is value in having teams write their own tools - at least at first. It prevents the tool itself from dictating how Agile should work for them - that is something they need to decide. From his perspective, it was important for teams to understand that before shopping for commercial tools.

Second, I read The Pheonix Project. The book is about DevOps, and I think this blog applies equally to DevOps. In the book a company is in trouble and need to find a way to implement the Phoenix project, which is over budget and way behind schedule. There are several other issues as well - things blowing up in production and a host of strong attitudes that you might find in large organizations. The main character, Bill, is a brand new VP and needs to find a way to improve the situation. Eventually he is introduced to Eric, who he thinks is a madman at first. Eric understands the DevOps journey that Bill and his team need to go on in order to save the company. However, Eric does not spill the beans all at once. What's relavant here is that Eric gives Bill only enough information for Bill to figure out the next steps, and at each step Bill and his team have to learn how the information applies to their ogranization. Eric understands that the Journey and Discovery are the most important part of DevOps.

Agile and DevOps were born out of an attitude of continual improvement. People were looking for better ways to work productively. Achieving an attitude of continual analysis and improvement on your teams is just as important as getting them to adopt new practices. You need teams that want to find better ways of working in order to find the best approach for your organization. The best way to encourage this behavior is to introduce things slowly and try to get them to take the next steps themselves. If you can get people looking for the next step towards working better with others, measuring progress, automating and so on, then you are well on your way.