Aces Studio Organization:Yesterday and Today

Now that I am starting a new series of posts, let’s talk about where the Studio is from an organizational perspective.

To understand the present, you first need to understand the past. The Studio has had a lot of changes and growth in my 18 months.

First we shipped FSX in October 2006, 3 months after I joined. I did get some time in on FSX but for the most part I stayed out of the way.

Then the changes and growth started. For changes, we have had 2 new products approved:

1)Trains2, approved in Late 2006

2)ESP, approved in Mid 2007.

And that has led to growth, where the Studio was 50-60 people when I started it is now 100+ so we have almost doubled in size and are still growing. There are at least 10 openings on the MS career site ( hint, hint ) as well.

Along with growth comes organizational change. The organization we had when I started was a single, flat organization as the “Flight” team.

Adding Trains to the mix required we have 2 product teams, which is easy to see.

The “not so clear” part was what to do about “shared resources” like the Graphics and Terrain team ( really 2 teams joined together at the hip ), the Platform team, and the Internal Tools ( PIT ) team.

SCRUM and Agile in general are very interesting and useful additions to the project management toolbox and is probably worthy of a blog post on its own. I have quite a bit of experience with SCRUM and thought it might help here and did to some degree but the circumstances in Aces were different than those in DevDiv; where my team won a division wide Engineering Innovation award. We ended up using SCRUM to various degrees on both product teams and let the shared teams organize how they wanted. Graphics and Terrain and PIT were SCRUMing ( with some modifications ), while Platform did its own thing.

 

It soon became apparent that the shared resource teams were both somewhat of a bottleneck ( thru no fault of their own ) and getting worn out due to multiple incoming requests from multiple product teams. No one can easily serve multiple masters. Buffering those requests and making decisions was a challenge. We organized a “Scrum of Scrums” based on experiences in the literature on scaling up SCRUM ( like this ) to address decisions that were larger than a single team, and that definitely helped for a while but the problem was still too few people trying to do too much. We all lived with that thru SP2 and Acceleration, but knew organizational and scope changes were needed.

Another factor was space. The space in the old building ( Millenium F for those who eat up MS trivia ) was small for us. We had people doubled and even tripled up in offices as there is a global MS space problem that the company is working to build its way out of. These “less than satisfactory” working conditions contribute a “grumpiness” factor to any other issue that has to be accounted for. Thankfully MS as a company is moving in the right direction now.

 

And somewhere in there ESP was approved, made their v1.0 plan, and started executing on it. Which meant more people, more work, and more challenge.

 

So it was really crowded in the old building, and we really needed to change to react to the new conditions.

So what did we do?

 

We moved and had a re-org. Except this was a really good re-org. Really J.

Last September the Studio moved to a new space that not only has room to alleviate the immediate overcrowding problem, but also has room for us to grow. Huzzah, three cheers for the Studio leadership on that on!. The Studio is now at the Willows building, and even though the drive is a bit more for me personally, the space is great.

As we moved into the new space, the leadership team updated the Studio with a re-org plan to form 4 teams:

1)Core

2)Flight

3)Trains

4)ESP

The Core team owns the platform and the technology and delivers it to the product teams. We work with the product teams to define new features and figure out who is best to work on them. And in general drive the technical direction.

The product teams have to define their own vision for their next product iteration, but cannot do so without Core team input as a vision that is unimplementable is in some respects worse than no vision at all.

One other thing the leadership team did is recognize we were trying to do too much as an organization. So we are now scoping back in some areas and trying to do fewer things, but each thing at a higher quality. We hope this approach will make our customers happier over time as well as improving work-life balance for the teams in the Studio.

Given this is less than 6 months old, and we still had product in flight under the old organizational structure – we are still working out a lot of the details but so far there has been a noticeable improvement in team and individual dynamics.

On the Core team we are moving to use Feature Crews, you can read about them here. Having used Traditional and Agile methodologies on multiple projects, I think I can make just about any methodology work but the planning disciple that Agile and Feature Crews drive can help with success if done correctly. Doesn’t guarantee it, but can really help if you do the right sort of planning and not just “planning for planning sakes”. I think that topic is deep enough to justify a posting on its own.

Now a bit more about my changing roles in the Studio.

I joined in July 2006 as the Graphics and Terrain Program Manager. For those who don’t know what a PM at MS is, PMs at Microsoft are responsible for planning, design, and execution so I get to do a wide range of activities; Program Management at MS is almost like a product planner, a product manager, and a project manager all rolled into 1.

With the move and the reorg in September, I was promoted to Lead PM ( some people in the community picked up on this ) and gained more responsibility and a couple of direct reports (people who work for me). That responsibility includes helping plan and drive the entire Core team. So I moved up from PM-ing a single team (or two) to Lead PM for 7 or so teams (Graphics, Terrain, Platform, PIT, International, Geo-Tools, Geo-Data) as well as a lot of cross-group activities and it is a huge amount of work. Huge. Having 2 people working for me ( and a 3^rd opening on the MS career site, look at my jobs blog post ) helps somewhat but that adds people management time as well so it’s just a lot of work.

We just went through a Core planning exercise for the next 4 month milestone that started with the New Year and doing that for 50 or so people instead of 10 reinfored there is much more work than it looked like from the outside to do this job right. I have to say that while I thought I was ready in the past, I probably wasn’t. Humbler, smarter, or both? This time around, though, I am really working hard to understand people and not just problems and projects.

In future posts I will expand on the PM and Lead PM role here at MS, talk about how Planning can be a CSF ( critical success factor ) or not for a project, and other “project” related discussions as we wait for the next round of products to get to the point where I can talk about them and the tech involved.

Comments

• Anonymous
  January 16, 2008
  The comment has been removed

• Anonymous
  January 16, 2008
  Phil - an insightful and informative article - thanks for posting it. I do think developing a core platform, as Aces are doing is certainly the way to go. This approach should hopefully result in more creative product teams. There is tremendous scope in the core engine as demonstrated by FSX (though some people will no doubt disagree ;) ) As you say planning will be critical, especially for the core team. In addition to internal changes I hope that Aces continue with their declared objective of working with the FS developer community on multiple levels and continuing in developing two way communication with 3P devs. I look forward to some great products from Aces in the future... in addition to those listed above. cheers Rob

• Anonymous
  January 17, 2008
  Thank you very much Phil for posting this. Love very much to hear ACES's progress and inside workings. Sounds like the teem learned alot from the past/ FSX. Wish the team all the luck for the future!  

• Anonymous
  January 17, 2008
  Great post, Phil. Very informative and gives a different perspective than what we usually see. I guess the days of bespectacled longhairs pulling all nighters while drinking Coke and eating pizza are gone forever. Good luck, Vic

• Anonymous
  January 17, 2008
  Rob: yes, working with 3PDs will continue to be a major part of the plan; I just didn't see a way to work that into this post :-).

• Anonymous
  January 24, 2008
  Thank you for this informative post. Reading a little between the lines and in light of some of your earlier posts about dropping backwards-compatibility, could this be a real opportunity to "streamline" the next version of flight sim? The engine in FSX already delivers great graphics. It also seems to have plenty of headroom to handle whatever 3PDs can handle for the next few years. What's really needed now is not a better looking sim*, or one with more bells & whistles**, but one that is better at handling what's already being thrown at it. Whatever happens, PLEASE preserve us from the bloat & "change for change's sake" of the 2007 Office products. Rgds Tim

---

• = Though I wouldn't discourage you from adding a 2nd byte to describe the sky gradient (or whatever it takes), for darker blues at higher altitudes ... ** ... and how about a way to measure precipitation density, so that 3PDs can develop weather radar properly? [... drones on indefinitely in same vein ...]