This book is specifically aimed at my team members and customers to know how we implement projects in order that they are successful. However, it’s now also available to other teams to adopt in addition for client buy-in (whether internal or external) as ensuring understanding from the client on the process is essential for the success of this methodology – so share this with them!
The T-Minus-15 methodology gives specific implementation details for development teams that want to apply the principles of Agile (specifically Scrum) and DevOps. Whilst you can read about DevOps and Agile frameworks (at the time of writing, 589 and over 8,000 results respectively for books on these topics on Amazon), what an IT manager and his team really want to hit the ground running with is actual specifics that can be applied. This includes knowledge such as metadata for your work items, how to create estimates, what meetings to schedule, who you need in the team, who is responsible for what, and other secrets from an elite DevOps team.
The T-Minus-15 is for the team, and fits into a larger framework called SAFeR which is a way for large enterprise to still capitalize on teams working in an agile methodology.
It comes from iterative improvements to a process over the last 20 years of being involved in the software development industry, mostly as a contractor at the likes of Suffolk Constabulary, Scottish Widows, Publicis, IBM, The United Nations, Nissan, BearingPoint, CBRE, Ntegra, Thames Tideway, Grant Thornton, Cielo Costa, KnowAll and New Signature to name but a few.
Where does the name “T-Minus-15” name come from? The analogy made in this process is the launching of rockets. Not a big-bang launch, but continual launches made at the end of each sprint. Apparently in the rocket world, days before a launch are referred to as “L-Minus”, but I figure most people are not aware of this, so we’ll go with “T-Minus”. With regards to “15”, this is the proposed cadence of 15 working days per sprint. So, there we have it: T-Minus-15.
This isn’t just theoretical; we practice what we preach and use this methodology internally on development projects. Having a defined process allows us to share this knowledge with newcomers and existing team members alike. It also allows us to share our process with our customers, so they are aware of their responsibilities within this process – after all they are an important member of the team as you will find out.
In a similar vain to the iterative nature of the software delivery process outlined in this book, the book itself will therefore have subsequent versions – currently v1.950.