Many of you will already be familiar with the Galactic Empire (spoiler alert: we’re the ones ruling the galaxy through fear and intimidation). It’s really great to have this opportunity to share some of my experiences in the challenging but rewarding field of galactic domination and demonstrations of hitherto inconceivable power and destruction.
Approaching Agile Like a Master
Our releases are pretty mammoth. Like 120km mammoth in the case of our Death Star, and it’s the Death Star I’d like to discuss with you in this article. Not a lot of people know this, but the DS-1 almost never got completed and in fact could have been DESTROYED had we not discovered–and repaired–a small but nonetheless major flaw in our design. More on that later.
You may think that building a Death Star is as simple as welding together a few million panels of metal, wiring up some electrics, adding a few light fixtures and firing up the wireless router. Let’s put that myth to bed right now: Death Stars are a logistical nightmare. They are absolutely no fun to build, at any stage. They are pretty much financial suicide and include countless concerns and protocols, not to mention the amount of hardware and software development required.
Most of these needs have to be outsourced to contractors across the galaxy, adding even more complexity to the logistics of the project. Several times I almost lost my mind trying to keep track of everything. Folks, I’m not exaggerating.
It’s also worth noting (and I’ve mentioned this before) even a technological terror of this magnitude is insignificant next to the power of the Force. Don’t ever be too proud. Be prepared.
An omnipresent threatening force is a useful methodology, but myself and my master, Emperor Palpatine, soon came to the realization that a more pragmatic, controlled and proactive approach to our project management was needed to pull off such a monumental and complex venture in a timely manner.
Of course, we adopted an Agile approach. But agile is not in and of itself the solution to complicated projects – it needs to be implemented well.
Thank the Force we discovered Axosoft to implement our agile workflow! Here are just a few ways in which certain Axosoft features helped us see some exciting (and some less so) aspects of Death Star planning through to completion:
Planning Releases
We needed to have the ability to plan our releases, both as a way of planning projects within the overall scope of the Galactic Empire’s continuing dominance of the galaxy, but also within each project.
We were able to plan with a forward-thinking methodology (we might, implausible as it may seem, decide to build another Death Star, for example) and also split up our Death Star progress into sprints to ensure milestones were clearly defined and completed on time.
Many subsequent tasks were dependent on completion of our defense systems, and so our shield and defensive firepower planning and construction formed our first sprint, with subsequent sprints being populated with items contingent on that security being in place (offensive weaponry and phase 2 of actual construction are two obvious examples).
Other items could run concurrently across multiple sprints, such as Human Resources policies, onboarding processes for certain staff members (but not others), etc.
Viewing Backlogs
The overview of our backlogs was essential for us to be able to glance at outstanding and completed items, see what priorities needed addressing, and filter down into a narrower selection of items. Using workspace tabs, we were able to filter items by designation, by sprint, and all sorts of other ways, and then save these views in convenient tabs at the top of the screen.
Within the DS-1 version (essentially our project), we added sprints to understand where in the overall project certain milestones would occur and what needed to be completed to meet them on time. For example, we were able to work out precisely at which stage in development the Death Star’s weapons and shields could be fully operational, even before overall completion.
Using Axosoft’s Release Planner, we were able to quickly drag and drop items to assign them to team members, and set up our releases.
Burndowns and Dashboard
Work progressed and we amassed more data as workers entered in work logs. This allowed us to compare projected work hours with actual hours and identify where we were underestimating the time that items would take. We could then, at a glance, see how many hours each team member had available and could see whether members were overstretched or underutilized.
For example, as the development of our laser was completed ahead of schedule, we were able to reassign several scientists and engineers to the more menial task of uniform design and stitching, which was behind schedule. We were able to see at a glance that our workforce in this area would have been way overstretched, and so we made a polite request that others become team players.
After all, showing off the destructive power of a planetary deathray hardly looks impressive when conducted in the standard issue Empire polo shirts and khakis.
We used the snazzy burndown chart and dashboard to analyze this data and predict our completion dates. From there, we could make adjustments as necessary to get back on schedule.
(As an aside, this has become far easier to enforce now that the Death Star can destroy your home planet if you underperform. Nothing like the obliteration of your entire world as motivation to try just a little harder, is there?)
Standup Mode
This was a big one, especially for the higher-ranked members of the team. Previous face-to-face standups had the unfortunate tendency to create situations where emotions ran high. Colleagues would always overrun or deviate from the discussion at hand, and this would lead to raised voices, sarcasm, and eventually force chokeholds from yours truly. In standup mode, we were kept to task, and things were, well, less disturbing.
Wiki
Axosoft’s wiki feature allowed us to collaborate in a sensical manner on certain items–mainly documents. We were able to set up items, and then link them (see the above screenshot) to their corresponding wiki for collaborative review. So, in the above example, we worked on a wiki to agree on content, logo usage etc.:
And ended up with a robust and efficiently-edited performance review form (go ahead, download it):
Plans Change
Literally. Using Axosoft helped us to better share updates, understand and anticipate the progress of every team, and adjust quickly to accommodate any unexpected changes.
Our burndowns let us see where scope had changed. We were able to see a timeline of comments and progress, and re-assign tasks as necessary to have a clear picture of who was responsible for what at every stage of an item’s progress. This was especially important re: a small issue that turned out to be pivotal in our balance of power in the galaxy.
A small vulnerability in our exhaust port seemed minor at first, but just the right shot could have DESTROYED the Death Star! (can you imagine the egg on our faces?) Axosoft allowed us to track our defense items much more robustly, and we were able to discuss issues and ensure no rash decisions were made (or ignored) without the review of other team members. We were able to act swiftly and with a clear chain of command to implement fixes.
Long story short – the flexibility that Axosoft afforded the Galactic Empire during the Death Star’s construction meant that the old plans stolen by the Rebel Alliance were not quite – ahem – accurate anymore.
We had completed ahead of schedule but had also managed to squash a fair few bugs and design flaws that might otherwise have slipped through the cracks. Flash forward to the Battle of Yavin, the Rebel Alliance thinks we’re vulnerable – SURPRISE! – we’re not! We win the battle, crush the Rebellion and the Death Star shines on as a symbol of fear and tyranny throughout the galaxy. Pretty certain that’s how it went down.
Good times! Anyways, if you’re ready to cross over to the agile side, give Axosoft a try! xoxoxo -DV