I invented a new word today: “Stratagical” – a synthesis of “Strategically tactical, practical and agile.” This sounds terribly pointy-haired boss-like, but whatever, I don’t care, because I’m excited that I’m able to hoist myself to a place where I am able to help make tactical decisions but keep a focus on the strategic goals of a project. In many ways, in my previous software developer role, I could become consumed with the architecture of a solution and its enormous volume of details to the exclusion of practicality and making tactical choices when necessary. One transformative step on the road to Stratagical decision making was the day I realized I needed to do a huge batch process completely in memory for speed. This decision eventually paid off quite well. I am learning that many tactical decisions can be strategically advantageous if done correctly.
I consider this type of decision making process to be a key to agile management of an agile software development and technical operations group, and it must be founded in practicality. The strategic part comes in by ensuring that the software and systems we are designing meet the long-term needs of the institution, that we not shut the door to future needs, that we ensure good data to start with. The practical part comes when you understand that a new system will not be immediately used by the entire population of the institution, and can be phased in over time. The agile part comes in by focusing on improving the baseline of the system at each customer integration opportunity.
Step 1: Design the system to be flexible in the future
Step 2: Get good enough data into the system to start with one or two customers
Step 3: Validate the data with those customers
Step 4: Fix discovered data issues
Step 5: Repeat steps 2-4 with a new customer or customers
If you do this right, things seem to start nearly magically falling into place, and you start knocking out large chunks of alignment and execution, like scoring 5 lines at a time in “Tetris.”
Nick,
Can we start the entire process with a Use Case diagram, and let that expose the business challenges required by incremental software development?
Hah, you are right, Jerome… I have the same feeling about unit tests for some of the things we do in the identity space. For example, how do you design unit tests to test the outcome of a business rule with 30 inputs, many of them with hundreds of different possible values. That’s where agile can kind of fall down. But we can make a tactical decision to evaluate those types of situations using a different kind of testing – for example, data comparison between pre- and post-revision output run on an entire population. We should be able to determine the impact of a known change to a rule within a population ahead of time and make sure the rule behaves as expected before putting it into production.