Project Portfolio Office’s DevOps team has made an almost natural progression towards Agile throughout the years. When the PPO tool was introduced in 2004, the waterfall model was the order of the day. PPO had ample scope to grow as a product and the projects we undertook were mostly large feature sets that took weeks, if not months, to develop. We stuck to about four customer-facing releases a year, with technical or non-customer-facing releases in-between.

Fast forward to today, and we undergo one week sprints consisting of daily deployments to production. Any of our team members could – on a given day – be troubleshooting an alarm, building a new feature, introduce a new cloud service, or fielding a third-line support call.

The benefit of working on the same product over a long period is that it is easier to spot what works and what doesn’t. We have not always done things by the book but preferred rather to stick to the principles that worked for us.

Caveat, this post is a bit technical. For the non-TLDR (Too long, Didn’t read) version, please jump to the conclusion.

Our Agile principles

The following Agile principles were vital to our progression down this path and in most cases, came as a result of trial-and-error and continuous improvement:

Incremental changes – Break work items up into smaller chunks. Do something small and get it out there. This shortened the feedback loop to our customers and allowed us to react quickly when we had gone down the wrong path.

Fixed deadlines, with a flexible scope – This ensured that we always delivered something, perhaps not with all the bells-and-whistles. It also helped manage customer expectations to some degree.

Estimation – We have always estimated work required, despite this being a notoriously difficult task. Some would perhaps cringe at the idea, but we work on a simple hourly estimation (one, two, four or eight hours). You’ll be surprised how good you get at it after a few years. One hour for one-liners, up to eight hours for a full day’s work. Anything more needs refinement.

Planning – I don’t recall us putting together many projects plans, but we have always had a list of work-in-progress or to-do items bundled together in releases or sprints. Maintaining these items or the “backlog” became an important daily task. PPO was the preferred tool here and interestingly today, we have a complete record of changes as old as our product.

Track changes – Tying the backlog items to our code repository change sets has saved us many hours. Understanding the context of a change clears up a lot of uncertainty about why a particular change was made. Code commenting has been a big no-no for us.

Review code – This has been part of our daily routine for a long time. It ensures the quality and security of our code and is also a way of transferring or improving knowledge within the team.

Automation – We have regularly spent extra time automating repetitive tasks and, in the long-run, this has probably saved us years.

Continuous integration – Automation of our build, test and deployment processes is important, especially when you deploy multiple times daily.

Feature switches – Frequent deployments made the development of larger features difficult without branching our source. Feature toggles or switches enabled us to expose pieces of functionality as we see fit until such time it is ready for release – no branching required.

Cloud – We were lucky to be early cloud adopters and it enabled us to move much faster. Ten years ago, it took us a couple of days to get a co-location server going. Today it is just another automated task that takes a couple of minutes. Implementing messaging, queuing, storage and other typical application components, is a configuration job through managed cloud services.

Monitoring – Knowing that our system operates within its limits is essential to ensure high availability. A number of dashboards show us visually how things operate and thresholds with alarms alert us when we aren’t looking.

Fail only once, or at least try – Each failure, minor or catastrophic, should be evaluated for its risk, then addressed or at least documented. Remember though that some things are just not worth fixing.

Jacks of all trades – We have always had a small team and felt uneasy to entrust specific knowledge to a single person. In our team, everyone does everything. It removes dependencies on people and of course makes allocation of work a matter of availability. It does however require a longer on-boarding and learning curve for new developers.

Toolset – PPO is our backbone. We use it to keep track of projects, backlogs, sprints, work items, documents, outages, incidents, metrics, sprints and tickets.

These Agile principles are all about reducing our overheads, stopping wastage, adapting to change, focusing on useful changes and delivering value to your customer as fast as possible. Many are encompassed in well-known approaches and methodologies like DevOps, extreme programming, Scrum, continuous delivery and more.

A typical sprint

As stated before, we have weekly sprints which somewhat resembles Scrum.

A typical sprint starts off on a Monday morning with a look back at the week before – a quick retrospective – and also to tie up loose ends.  This is followed by a look ahead at the coming week to ensure the team is on the same page.

For the remainder of the week, our days start off with a stand-up meeting, reviewing the Kanban board to quickly assess progress so we can plan reviews, quality assurance and deployments for the day.

The actual work involves progressing work items from To-Do (Committed) – to Doing (In Development, Ready for Code Review, Ready for QA, Failed QA, Passed QA) – to Done (Deployed, Closed). With every change in state, we update the work item, including the estimated time to complete. An item is considered done once it has reached production.

By Thursday, we have made enough progress on the current sprint, as well as planning against the next, to meet with the Release Management team. Here, we coordinate to ensure blog content, product documentation and the likes coincide with the deployment of new features. We review the longer-term product development pipeline, which is a marriage between business and customer requirements, and long-term team objectives.

Backlog grooming is a continuous process and entails preparing work items (based on their priority) for sprint readiness. They start off as an epic or huge unknown, then gets chiselled down to size until a clearer picture emerges. By the time an item is ready, we have a clear description of the requirement or problem, a proposed solution, and an estimated duration of less than eight hours. Throughout the week, sprint-ready work items can be taken from the product backlog and committed to the next sprint depending on the team’s capacity.

Conclusion

Agile has been a natural fit for our team for a number of reasons.

• We have a mature product, which evolves all the time.
• We control the scope, but we listen to our customers.
• Our team is small and works as a unit.
• We’ve spent years reducing overheads though process improvement and automation.
• We do DevOps and cloud.
• We have a great tool to back us up.

The key is to be flexible and to embrace change. None of the Agile principles or approaches mentioned are new, and are probably best practice for most teams; the trick is to find the ones that work for your setup.