Introduction
This is my attempt at writing a book to explore the new digital book writing and self publishing platform http://www.gitbook.com. I decided to just chronicle my teams transformation into an agile software product delivery team. Let's see how it goes. This is taken from my perspective as a team member and not a manager. I am currently the Lead Automation Engineer on the team and my views are taken from my perspective in this position.
Going Agile
From the time I joined the team our software delivery pipeline has included:
Discovery
Planning
Developing
Building
Deploying
Testing
Releasing
Monitoring
How we actually did each of these has changed during our going agile journey. Throughout this book I will strive to explain how our process has evolved. Going agile is not easy because software development isn't easy.
For me going agile has meant embracing some core concepts:
Since I am throwing around buzz words, it can't hurt to mention that my love affair with continuous delivery and DevOps has greatly influenced my personal experience in our going agile story. My love affair was sparked by a wonderful novel by Gene Kim titled the Phoenix Project.
Going Agile Recommendation
My ultimate advice for teams looking to go agile, just jump into it. I can hear the certified agile experts cursing my name for saying that, but agile is much simpler than someone trying to make money off of it will admit it. "Responding to change instead of following a plan," this is the last value in the agile manifesto. Don't spend months trying to plan it or understand it. There is no "one way fit all" approach to going agile. You can't buy a book and follow it word for word or higher a consultant to wave a magic agile wand. Its best if individual teams discover how to go agile within the context of their product.
If your team is finally "Going Agile," I applaud you. There has been a lot of backlash against going agile because so many people are trying to profit off of agile. There are so many agile methodologies, certifications, books, classes and tools that agile has been complicated. Many teams are listening to experts and failing to achieve the success they hear about in seminars and give up. You shouldn't just blindly copy someones agile process or buy your way into agile. Expensive consultants shouldn't be employed to bend your teams into the agile way. I am not saying that you shouldn't listen to experts or go to seminars, just do it with the understanding that agile is contextual. Your teams should define what agile is for them, your executives and managers have to allow teams to go agile on their terms, and your organization as a whole needs to buy in to an agile culture.
You should understand that there will be successes and failures. You can reduce stress during agile adoption by realizing failure is encouraged and expected as you go agile. The fact is you will most likely get it wrong. Learning from failures is how you improve. If you are going agile the right way, you will never stop failing and your "Going Agile" story will be never ending.
Even if you don't have total buy in from your company you should still "agilize" what you have control of. There seems to be a big push for enterprise agile or agile at scale, but even if your company hasn't establish a roadmap to fostering an agile culture, your team can still take the plunge.
In my eyes, it's somewhat foolish if a team doesn't commit on some level to continuous improvement and subscribing to some of the agile principles. There is enough data and experience in the industry to prove that agile works for software development teams of all sizes and situations. Getting started could be as simple getting an overview of the agile manifesto, the twelve agile principles, and establishing an improvement kata. So, just get started, take small steps, and learn from each failure so you can improve in the next iteration. Never stop learning and "stick and move."
Lastly, as an individual in software development consider writing your own book on gitbook.com or blogging about your experience. Join the Twittervers or a LinkedIn group. Get out to a MeetUp or conference. Contribute on GitHub or an open source project. One benefit of the major benefits of the agile movement is the community of sharing and the industry attempting to get better as a whole.
Have fun "Going Agile!"
Last updated