The Agile tools vision - Azure DevOps
In 2009, a change was happening within the Team Foundation Server team I was working with. They had acquired a small startup called TeamPlain, who had created a web interface to TFS. It was shipped quickly as a power tool for TFS in 2007, but not much more had come of it.

Brian Harry and Lori Lamkin had commissioned my research colleague Miki Konno to run ethnographic research to understand how Agile software development was being used in the wild. TFS had long supported Agile SCRUM through a process template, but there had been a wave of startups beginning to produce tools to run Agile ceremonies that had been physical to that point - task boards, retrospectives, standups, and planning.
I was fortunate to join Miki on a number of these site visits - we talked to many, many teams in companies ranging from startups to multi-national corporations. It was honestly a shock - these teams were moving FAST and doing so sustainably. Meanwhile at Microsoft, the whole company was still largely following the 3-year milestone-based, boxed product software model of the 1990's.
These Agile companies were shipping product to their customers every 3-4 weeks.
When Miki delivered her report and findings back to Brian and team, it convinced them too - we had to do something.
Hatching the plan
At a team building off-site in North Carolina, I was in a breakout session to discuss Agile. While we were discussing Agile tools and what we might want to build into TFS' next release, conversations converged. All credit to Brian, Jamie, and Lori for seeing this before I did:
Flying home from that offsite I knew a lot of things were about to change. A short time later, Brian announced that the organization was going to bet the farm on Agile, and that to be successful meant the organization had to become Agile itself, immediately.
I was fortunate to have an incredible set of colleagues to work with on this problem - Hakan Eskici, Aaron Bjork, and of course Miki!
We set off to answer the question - what should Microsoft do to get back in the lead of the ALM product space?
Market and User Research
Several factors all landed in 2009 to show Agile was about to go from early-adopter to mainstream.
Agile adoption had quadrupled from 2006-2008, and there was a swell of new startups building new tooling that all had one thing in common - they were all web-based and hosted products.
But ALM suites are HUGE - with dozens of complex products from source code management to build and test pipelines. We knew we weren't going to be able to build everything at once - so where do we focus first?
All of our research pointed to Agile project management, and also told us that we had to do more than just a hosted product. People were picking their tools for low barrier to entry, and not relying on enterprise IT provisioning and approvals.
So the gauntlet was thrown down - we needed a best-in-class Agile project management experience and it needed to be a full SaaS offering. All of the competitors at the time had hosted offerings - but none were multi-tenant. You had to get dedicated servers and manage provisioning, upgrades, and maintenance for every single customer.
"Agile planning" for the Agile project management experience.
Normal planning and envisioning up to that point in Microsoft was a pretty consistent process - leadership commissions market and user research, 3 months later everyone reads the reports and creates a feature backlog, PMs go explore and ideate and build their plans, and then mash it all back together into a release plan and then you have a multi-day strategic design review with stakeholders, partners, and large customers to share the plan and get feedback. Make some small tweaks based on the feedback and then get started! This only takes a year and a hundred people.
Well, we didn't have a year. The writing was on the wall - if Microsoft didn't have a viable product in market by the end of 2010, we were going to miss the wave entirely.
The market and competitive research work had already taken months - we were constantly trying to balance working on this vision with the realities of shipping TFS2010. Something had to give. So, we locked ourselves in a room and just got started. In typical fashion, we started by writing user stories -

And after a day we had a massive list of features. Aaron and Hakan were happy - they could start building a backlog and developing a system architecture. I was frustrated - none of the user stories gave us any idea of how a person would use the product, or how these individual capabilities would flow together. Even prioritizing the stories got contentious quickly - we all had our own perspectives, and they were often in conflict.

We had created a backlog without even knowing it, and we were struggling.
I suggested we step back and try to write an actual narrative story - how would a person use this product if we built the best possible solution? Hakan and Aaron were both skeptical - you can't architect or prioritize an actual narrative story, right? Fortunately, I'd built up some trust over time with these guys, so they bought in and gave it a shot.
Start with a story
So we wrote a story outline - it wasn't a novel, but it got us moving:
- Getting Started - Define Context, Define Team
- Capture & Enter
- Enter user stories, task, etc. quickly and easily
- Split scenarios/stories
- Breaking down work items
- Estimation - Estimate user stories/tasks/...
- Scheduling - Capacity, Release, Iteration Planning
- Team Collaboration - Visibility of status, communicating progress, risks
- Tracking - Release, Iteration, Velocity Tracking
- Answering questions
- What's going on?
- Who's working on what?
- Are we on track?
- What are the risks?
- Answering questions
- Retrospectives - Iteration retrospective, Release retrospective
- Answering questions
- What worked well? What didn't?
- How can we improve our process?
- Answering questions
This rough outline gave us common ground. We all agreed with the logical order of operation, and it helped us feel a sense of flow. It wouldn't make sense for instance to work on tracking and collaboration features before users could effectively data in the product in the first place.
Actors, scenes, and plot
Seeing the success of the outline, we adapted my narrative writing process to flesh out a quick and dirty story. We used OneNote and the outline served as the mechanism to group story scenes and flows. We quickly found gaps between user stories when they had to fit into an overall narrative - so we had to improvise and fill in what we thought a real team would plausibly do.
We knew we had a couple of different types of users to account for, but we didn't have any personas to lean on, nor the 6+ months of time it would take to formally develop personas for us. We looked at what others were doing and found some references on the agile alliance site:
This didn't remove the need for vetted and well researched personas, but it kept us moving forward. We created two actors - David and Patricia - and focused solely on their jobs over their demographics - not knowing at the time that we were following the Jobs-to-be-done framework.
It was at this point that all three of us became pot committed. When we were able to sit together for a few hours, we would make more progress than weeks of offline work and weekly sync-up meetings.
Continuous feedback
This was the point we realized we needed feedback. We had a story, users, features, and a workflow that all sounded great... to us. But we were 5 months away from the next customer summit - and even UXR recruiting would take weeks to put together a focus group.
More importantly, we needed more than just one round of feedback. We had a rough story and not much else - no mockups, no architecture, just a narrative. So we went looking for whoever we could.
I quickly dumped our narrative out of OneNote and into PowerPoint - one slide per task. We started by enlisting our stakeholders and colleagues. Weekly progress reviews went from logistics conversations to storytelling - we'd tell the story and get their reactions and feedback during and after.

Within a couple of weeks of starting this process, it became our process - one day of feedback from whoever we could sit with, followed by a day of iteration - rinse and repeat. We called on Microsoft partners, participants from the ethnographic research the year before, colleagues in other parts of the company - whoever we could find that was a practicing Agilist and would be willing to give us their time on short notice.
Iterate, Iterate, Iterate
Over the next several weeks I iterated the deck every other day. 2,000+ slides, 50+ iterations. Slides went from all text to keyframe blurbs, and then slowly to bits of mockup UI concepts.
What surprised me the most was how fluid the UX concept development was - we changed the navigation structure, content layouts, and everything else constantly - based on what made the story work for our audiences. We often got conflicting feedback from users, partners, and stakeholders - but over time we adapted the story itself (product definition) as well as the way we told it (marketing) to remove fears and being clarity to the product being proposed.
The UX structure
The mockups to this point were purely functional - provide just enough detail to answer questions and keep the story moving along.
Many of the concepts in these mockups would take years to see the light of day in the actual product. Some, like the scrum-of-scrums multi-team boards, and portfolio management would never make it in for many reasons (competing with MS Project and SharePoint being chief among them).