The software lifecycle is the same wherever you go.

It s one of these things that you are taught in school that really is the way it s described. The steps are basi cally to figure out what you need to do (requirements), how it will work (design ), do it (implementation), and verify you ve done it right (testing). Then you ve go t to get the finished product to the people you promised to get it to (deploymen t). When you lay it out sequentially it feels very much like a waterfall develop ment model, but of course all the same steps happen in agile as well. There s been a big move towards agile over the past ten years and big companies are no excep tion. You do encounter a lot of faux agile as well (fauxgile?) a team I was once a part of had one hour scrum meetings with 15 or 20 managers with laptops sitting d own in a room. I digress. At a big operation, each stage is documented according to organizational or team standards. This is a good idea, and it s vital if you want to be able to share in stitutional knowledge among past and future team members, seed the localization and user documentation teams with good information, and form the genesis of pate nt applications. Accountability for different stages in the software life cycle is divided among the team. Teams are large enough to permit specialization. At Microsoft (and oth er places besides), the three primary job descriptions are program manager , develop er , and tester (or QA). Program managers are accountable for requirements, develope rs for implementation, and QA for testing. All three disciplines are involved in all stages, but each discipline takes its turn in the spotlight as concepts mov e from vague notions to concrete implementation. Different outfits divide these responsibilities in different ways. The concept of a program manager (as opposed t o project manager) was essentially invented at Microsoft and is not universal. S ome teams combine dev and QA responsibilities. Other teams include operations (a ccountable for deployment) in the core engineering team. This separation of powers feels like the division that exists between legislativ e (PM), executive (dev), and judicial (QA) in government. As in government, tens ion sometimes exists between the three branches. Some amount of this is natural and healthy because after all, software engineering is an activity that is under taken with limited resources under changing conditions. Tradeoffs are necessary, and figuring out how and when to make these changes naturally leads to differen ce of opinion. One difference between engineering teams and governments is that in an engineering team there is a fourth party sitting above all the others: man agement. Management, if it is to be useful, should step in when necessary to rem ind all three disciplines of their common mission and purpose, and to make the j udgment calls that are necessary to keep them on track. They re in a good position to do that when the mission is clearly defined, they can articulate it, and whe n they can relate it to the day-to-day work that their team is being asked to do . (Knuth: the psychological profiling of a programmer is mostly the ability to sh ift levels of abstraction, from low level to high level. To see something in the small and to see something in the large. ) I don t know about you, but I d rather be a president than a legislator or a judge. I always liked being a dev. It s common for the devs to feel like they are special I remember a conversation early on in my Microsoft career where a more senior d ev told me that devs were special because they were the only ones that could per form the other two job functions. I have found that it is not really true a grea t PM could be a dev or a tester, and a great tester could be a PM or a dev. Thi s makes sense because in order to do your job well, you need to understand how t he work you do fits into the larger story. It is common for Microsoft employees to change from one discipline to another in the course of their careers. A triad of PM, dev, and tester form a basic unit that can take a portion of a prod uct (a feature) from start to finish. It s become more common in certain divisions at Microsoft to make this partnership more formal by calling this triad a featur

e crew . They meet regularly from the inception of the project to the very end, re viewing each other s work and tracking its progress together. Opinions vary on whe ther formal feature crews are a good idea or simply bureaucracy, but I liked the m. Camaraderie develops between the triad, which is enjoyable and effective.