We reach our goal with DevOps
erikschumann 270002VJ46 Visits (7050)
Our agile program and release planning tool Sellegi ACT has been developed for several years. It was a monolithic, eclipse-based, thick client with file based data storage.
We knew that the features in our product are one of a kind; supporting enterprise agility in an extremely efficient way. But the UI on the thick client makes it less intuitive to understand and use. In June we decided to migrate the complete tool to a web-based, client / server application. A complete shift of architecture, platform, storage model, and what not. In addition, the new version should be useable on touch-based devices like IPad and Android tablets.
The goal was to have a first working demo with key capabilities ready mid-September, launch a fully fledged demo at the Rational User Conference in mid-October, and have a release ready end of November. And it should support the Scaled Agile Framework out of the box. Nobody except ourselves believed that we could make it.
Now it is mid November. Are we going to make it?
Going for DevOps – all in!
With this extremely challenging schedule and in addition a complex product, it is clear that we would need both to change our way of working as well as improve tool support for fast feedback cycles and deployment. We believe that agile development is not enough. We need to be agile across the line and think about flow. So we decided that the project should be planned and run mostly according to the Scaled Agile Framework (SAFe). In addition we set up a combined DevOps / ART (Agile Release Train) team, responsible for the complete chain. All roles are involved constantly and meet at least once a week.
The DevOps team
Here is our current team setup. We have put together a virtual team with roles from all involved functions from budgeting, management, and sales to development and release. This team has complete authority over all decisions regarding the development and launch of the new product.
The development is SAFe inspired and scrumish, with two weeks sprint length. The biggest difference there is that we have a weekly 30-minute DevOps meeting on Friday afternoon. a 15-minute demo, and a 15-minute feedback and information from latest activities, feedback from customers, conferences, colleagues and so on.
The DevOps infrastructure
Below is the rough timeline of this project. Most points were fixed in the beginning, but content is variable according to decisions in the DevOps team, all according to the Develop on cadence, release on demand paradigm of SAFe. The first code check-in was in the beginning of August.
By the end of August, we could produce screenshots for a first mail-out that got us customer meetings.
At the beginning of September we had our first meetings and could show a live demo.
At the middle of September, the architecture was stable enough to implement continuous integration and on-demand deployment to the test and demo server. This means that as soon as the developers check in their code into our SCM system (RTC / Jazz based), it is compiled, automatically checked, and built and deployed to the application server.
One week later, IT had set up the external cloud environment of virtual demo-servers, so that we could provide demos directly to interested customers and colleagues for feedback. Usually once every second week the latest stable snapshot is automatically deployed to the demo environments. That task takes about five minutes of work.
Since the beginning of October, we use the latest development build of Sellegi ACT for our own program planning and follow up. We call it internally for ACT for ACT. This gives us real-time feedback on quality, missing features, and usability that is so much richer than relying on pre-defined test cases only.
To the right, you see a filtered screenshot from our ACT for ACT sprint status board. As you can see, we have work items that span across DevOps to make this project happen. It is not enough to have development become faster and better and plan its work in sprints. All parts of the enterprise have to join in and participate on the same turf – using or interconnecting the same tools for planning, reporting, and thus communicating across the teams and functions.
We took a risky decision, but we believed that we could make it. In hindsight, we could have done many things better, but we are sure that without the use of a DevOps mindset and setup supported by tools, we would not have been able to get where we are today. Using our own tool has sharpened its focus and increased its quality. We have seen how well Sellegi ACT works in the agile DevOps context and how much it supports this way of working. This project has had a steep learning curve and lots of surprises for all of us and we are proud of what we have accomplished.
So, if you want to know more about our way of working, how we did it, our tool setup, and, of course, about our agile planning support with Sellegi ACT, Get in touch! We are happy for all feedback and welcome discussions where we can learn and improve or are able to help you.
Oh, and as a side note: The traditional guesstimates before the start of the project said it would take a year or more to get this to work.