Radio TFS and the GREAT curve ball question about (ex-nightmare) shorter delivery cycles
In the // the podcast about microsoft visual studio team foundation server, visual studio online and visual studio application lifecycle management, episode 82 … WOW, that many episodes already … I had the privilege to chat with two ALM MVP colleagues, and an ex-MVP, now MSFT colleague. The chat we had, their usual comprehensive news summary, event description presents a great summary and links to the important information. What got me thinking is the curve ball question about how I really feel about the shorter delivery cycles, which as attempted in the show, I still have to answer wearing two (user and Ranger) hats.
important historical context
UPDATE: 2014-10-22 – Changed average from worst case 0.125h/day to average 0.25h/day estimate. It must be emphasised, that many Rangers invest *far* more!
Winding the clock back to 2009 the VSTS Rangers were working with solution cycles ranging from atypical 1 month to typical 12-24 month solution cycles. In those days these cycles were in harmony with the need to deliver practical guidance for upcoming technologies and plug holes of current technologies. The ALM Rangers working geographically distributed, part-time and with volunteers who had a “real life” were able to embrace a solution that delivered huge value in one cycle. For example, assuming a Rangers commits an average of 0.25 hours/day, we were able to inject an equivalent of 325 full-time man-hours (calculation #1) into a typical solution with a team of 10. A substantial amount of resource bandwidth!
Fast-forwarding to 2012 our first process change was to align to a shorter solution roadmap and pairing up Rangers in dev/test pairs to raise the quality bar and enable us to complete the testing and raise of quality bars in parallel to development. As a result we had an equivalent of a two-thirds man week of resource bandwidth for a 1-month solution (calculation #2) and roughly 3 man-weeks of bandwidth for a five month solution (calculation #3). Already most Program Managers have probably left the building at this time and the remaining have a look of concern. While it is feasible to create a whitepaper of a prototype under these conditions, tackling a project such as the Version Control (ex Branching and Merging) Guide v3, TFS Planning, Disaster Avoidance and Recovery, and TFS on Azure Iaas Guide v1.4.1 and Config as Code for DevOps and ALM practitioners v1.
More recently we aligned our sprints cadence with the rest of the division as outlined in aligning our planets with a common cadence and synchronization. We now have 3-weeks and roadmaps ranging from 1 to 5 sprints. This means we have a maximum of 1.17 man-weeks of bandwidth for a 5 sprint project, such as the “Extracting Effective Permissions from TFS v1” solution. Any Program Managers left in the room? Anisha, Keith and Martin, I know you are and would appreciate you adding your thoughts as a comment below.
Rough calculations ( I dream that someone will find an obvious glitch and surprise us with extra bandwidth )
- Calculation #1 –> 650h = 260 working days per year * 0.25h per ranger * 10 rangers = ~16.25 man-weeks
- Calculation #2 –> 54h = 21.67 working days per month * 0.25h per ranger * 5 ranger pairs = ~1.35 man-week
- Calculation #3 –> 270h = 21.67 working days per month * 0.25h per ranger * 5 ranger pairs * 5 sprint road map = ~6.75 man-weeks
- Calculation #4 –> 184h = 260 working days per year * 0.25h per ranger * 5 ranger pairs * 3 week sprints / 52 weeks per year * 5 sprint road map = ~4.6 man-weeks
A typical ALM Rangers project therefore has a recipe of 184 hours bandwidth (or less), tons of experience, commitment and passion, a pinch of unreported excess hours committed by every Ranger and PMs that have to engage like chameleons.
In the talk we joked about a whitepaper that is taking months, instead of days. Let’s do another calculation assuming that both Martin Hinshelwood and I were able to commit 0.125h/day, which is questionable as Martin has been travelling a lot and focusing on family>job>rangers.
- Calculation #5 –> 21.67 working days * 0.25h per ranger per day * 2 ranger = 10.835h/month
That said, we did complete the whitepaper and are waiting for the technical content editors and reviewers to dot the i’s and cross the t’s. One variable is fixed … the Rangers always deliver!
my “feeling” as a user
Let’s get back to the question of how I feel as a user of technology with the shorter delivery cycles.
Initially I felt out-dated, doomed and stressed. Instead of trying to apply every update, experiment with every release and dog-food the latest and greatest, I had to start making difficult choices and began to select and focus on what I really need to be productive. For example, I am still running Windows 7, Windows 8 and Windows 8.1 on my three working devices, with Windows 10 Preview running on my desktop at the office, which also acts as the Ranger scrapyard for interim file shares and experimentation, and interim VMs with the latest and greatest Visual Studio CTPs in Azure. From afar if seems I am still as energetic as before, however, I have started relying on automated installations, updates happening behind my back and using a fraction of the solution palette that ships with Azure, Office, Windows and Visual Studio.
Today, I feel at ease with the knowledge that I will never know everything, but that I have the opportunity to learn and work with something new every day.
“It is change, continuing change, inevitable change, that is the dominant factor in society today. No sensible decision can be made any longer without taking into account not only the world as it is, but the world as it will be... This, in turn, means that our statesmen, our businessmen, our everyman must take on a science fictional way of thinking.” ― Isaac Asimov
my “feeling” as a ranger
As a Ranger I initially felt pressured, wondering whether we were turning ourselves into the robots in an assembly line, and seriously doubting that we could continue to ship the block-buster solutions we have to date. The sprint alignment with the rest of the division felt-awkward at first, but the reduction in confusion and ability to align and focus on what was important quickly took over. I, as many others, probably have to peek at our overall roadmap to remember which sprint we are in, but a healthy side-effect ensures we check the overall roadmap, imminent milestones and objectives at the same time. As a Ranger I have to come to grips with the fact that we cannot ship a perfect solution, with all the bells and whistles anymore, that a roof with holes is better than no roof, and that we piece-meal and evolve our solutions over time.
Today, as a Ranger, I feel excited about the rapid and continuous change, and excited about what we can achieve as a community.
As a Ranger PM, however, I am still frazzled. Continuously working on (1) unblocking the teams, (2) refining our engineering process to be more productive and “fun” for the Rangers, and (3) convincing the leadership and the community that a 3-week sprint is not really a 3-week sprints and that miracles take time, takes its toll and tends to instigate panic. When we started to shorten the delivery cycle and align the cadence I was concerned about the churn and impact, the inability to make an impact and Rangers running away. BUT, I am seeing the light, opportunity and truly believe that we can make an even bigger impact than before.
I hope this answer the question a bit better and that I can sleep tonight. Thank you Martin, Paul and Greg for a great chat and for getting my brain rebooting itself in the middle of the night to ponder over the question