|
|
The day to day ramblings of Jim Scardelis, Release Manager turned Program Manager in Microsoft.com.
-
-
Once in awhile, I get to work on something really cool that makes a difference for a bunch of folks. Most of the time, though, the effect is only really seen inside the company by the people that use our tools or processes. Today is one of those days when something I’ve worked on is visible to the outside world. Today, we’re making a change to the code behind the www.microsoft.com home page that should make a difference to anyone coming to it with a recognized mobile browser (via the http://www.microsoft.com/ URL) – instead of serving up the full site to them that most mobile browsers can’t deal with, if the user agent is from a known mobile browser, the user will go to a mobile-optimized version instead. This is one of a number of steps we’ve got planned over the coming year or so to improve customer experiences with Microsoft Web sites.
|
-
Since I last posted about going to the Seattle Art Museum, I did decide to become more involved in the Microsoft Art Collection as an “Art Ambassador”. By doing so, I will play a liaison role between the Collection’s art department and the Microsoft community. I’ll get to learn more about the art in my building, and art in general, and share that with other folks in the building. A side benefit is special education opportunities – like the lecture on the piece of the Berlin Wall we have at Microsoft in a couple of weeks that’s just for Docents & Art Ambassadors.
|
-
One of the great things about living in a 'hip' metropolitan area is the plethora of art of all kinds that can be found just by looking around. For example, the city of Redmond has art installed in many interesting places -- even along some of the major paved bike trails like the one I took a 12 mile bike ride on a week or so ago.
Another great place for art lovers is on the Microsoft campus, where amongst the Microsoft Art Collection you'll find works of all kinds -- even a chunk of the Berlin Wall can be found in a building at Microsoft.
On top of that, Seattle's museums are top-notch. Awhile back, we got to see parts of the Dead Sea Scrolls at the Pacific Science Center, and today we went to the Seattle Art Museum to see the Roman Art from the Louvre exhibit. Wow. I had no idea statues made 2000 years ago were so detailed -- or so big. We saw the Gates of Paradise too, which was another once in a lifetime type of thing, since it's closing after April 6th, to return to Florence, never again to leave -- but for me, it was the Roman work that made my day.
I'm really starting to 'appreciate' art and want to learn more about it. Maybe I'll try to get more involved with the Microsoft Art Collection.
|
-
Like many folks these days, my wife & I have a computer in the kitchen. Occasionally, there are files, like lists of stuff we have, that we need to access from various computers, whether from work, or just from our primary computers in our studies. To enable this, we use a piece of software called Windows Live FolderShare, which is free and enables you to not only keep files in sync across computers, but also share them with friends. I like it a lot -- https://www.foldershare.com/welcome.aspx
|
-
It’s been a long time since I last blogged, mostly because late last Spring, I transitioned out of the Release Management role in Microsoft.com (now part of the Microsoft.com Operations Team) into a Program Management role in one of the software development groups that I used to work with as the RM on their projects. This was an interesting transition to make – on the one hand, my title in the address book didn’t really change, since Microsoft generally views Release Management as a specialized type of program management anyway. The key difference, I think, lies in the scope of the things that I do now – by being part of the actual product development team, I’m better able to take an active role in application design (i.e., let my inner techie out more often). My commitments look a lot more like the kind of goals that I had when I started at Microsoft last century (oh yeah, I celebrated 10 years here last November) – which was really a lot about doing the right thing for customers & partners than could be expressed in a more narrowly defined role like the RM role was. So, I’m having fun. I still get to work with and define processes to some extent, and I’ve been working with stakeholders and partner teams a lot more than before. I even shipped a feature last December that is gradually getting adopted on www.microsoft.com. I plan on blogging a bit more often as I get more into my new projects, so stay tuned.
|
-
This morning, I was looking through one of the stack of trade magazines that seems to find its way to my mailbox and read a very interesting article on software documentation that I wanted to share with you. In the article, (“Documentation Strategies” by Scott W. Ambler, in the March 2007 issue of Doctor Dobb’s Journal), the author reiterates that “ documentation is an important part of every system, regardless of the paradigm followed to develop that system.” Figuring out where to strike a balance between having sufficient documentation vs. not spending too much effort on documentation (vs. coding) is one of the things that most development teams, whether agile or traditional, struggle with – and is one of the key areas that the RM teams struggle with as we try to define a consistent set of deliverables (release criteria) to be used by teams developing software for our operational environments.
Ambler suggests that system documentation should be treated like any other requested feature – “What you do is suggest to your stakeholders the need for such documentation, justify why it’s important, estimate the Total Cost of Ownership (TCO) of creating and maintaining it, and then let them decide whether they wish to invest in the documentation.” This approach is markedly different than the one taken by traditional software processes – which, as we have all experienced, often lead to “overly bureaucratic and documentation-heavy processes” that are often justified by regulatory requirements. When this is the case, Ambler points out, one of the key steps is “to ensure that your resulting process is as streamlined as possible yet still in compliance.” Sounds familiar to me… J
He also suggests that documentation should be created when it’s needed, and only if it’s actually needed – noting that sometimes, there are alternatives to documents. For example, many times it’s possible to use a suite of user acceptance tests in lieu of a specification.
The article also gives a number of pointers to further information about agile documentation, which has become really important to me lately as some of the project teams I'm on have begun to use Scrum... but more on that in another blog post later.
|
-
>After my post the other day referencing my article in TechNet Magazine, a few folks, such as Blake Handler inquired about my old pseudonym that I used to write books & magazine articles in during the late 1990's. (Boy, typing that sure does make me feel old!) Well, way back then, when the Microsoft MVP program was something so small & new that you could fit all of the recipient's names on a postcard, I worked on a few computer books, at first contributing chapters, then co-authoring and later, being the primary named author along "with" my wife. At the same time, I was a Contributing Editor to a magazine called "MCP Magazine", which was focused on Microsoft certifications. My column was called "Exam Spotlight" and had reviews & information about the various MCP exams as they came out. Anyway, my pen name was "Jim Blakely" (a long story, having mostly to do with being towards the top of things sorted by Author last name and folks' ability to remember it). Here's some pix of the covers of the books I worked on -- last I looked, you could order copies of the last one, Windows 95 Exam Guide from sellers on Amazon.com for prices ranging between $0.49 (Used-Good condition) to the full price of $99.99 (Collectible!). Wow, I knew that it was the first book in its genre, but I had no idea it was "collectible" :)    
MCP Magazine changed its focus a few years ago from Microsoft Certification to all things Microsoft - they're called "Redmond Magazine" nowadays, although there still is a Web presence for them at www.mcpmag.com
|
-
I wrote an article for TechNet Magazine about Release Management at Microsoft.com. You might find it interesting. One curious factlet: Although I've written books and was a contributing editor for a magazine last century, I used a pen name back then, so this is the first thing I've had published with my "real" name.
|
-
One of the projects I'm working on now is the family of systems that will become the new publishing & rendering system for at least the Microsoft.com Home Page. It's a really cool project that's pulled together a lot of the best people at Microsoft.com and has the potential to really improve a lot of things by really streamlining the content production process, while also introducing some really cool new look & feel elements.
Last week, we released a visual design preview of what the new home page might look like to the MSCOM Preview Site and started soliciting feedback from customers who are randomly chosen through a similar mechanism as the one used for our customer satisfaction surveys. Those who are chosen receive the link to the site, along with an opportunity to provide feedback on the look & feel and overall usability of the new design. The preview site was designed to work only with Internet Explorer 6 and Internet Explorer 7, so if you're using a different browser, the preview site won't work for you - you'll be redirected to the regular www.microsoft.com Home Page.
It's important to note that the visual design preview site is just that -- a preview of the look & feel of what the Microsoft.com site could look & feel like at some point in the future. It's just a mock-up -- it's not running on the systems & software that will actually be used if and when this new design goes into production. They're not even built yet - in fact, some parts of it are still in the Design phase, with specs being written & reviewed.
As the Release Manager for the Microsoft.com Home Page, and the new publishing & rendering systems projects, I am responsible for ensuring that all of our internal release criteria are met whenever we release projects into production. When the new systems are released into production, the new Home Page will meet the same criteria that the Microsoft.com Home Page currently does -- including the same matrix of supported browsers. After all, it's the Microsoft.com team's job to make sure that customers -- no matter what browser they choose to use -- can get to the content on Microsoft.com in order to find out about our products.
|
-
I've been kind of slow posting since a number of things have been in flux back at the office. Over the last few weeks:
- We had a re-org in the Microsoft.com space. Some of the chips haven't finished falling yet, I think, but essentially my team moved out from the development group it had been in for several years into a new group led by Todd Weeks. This new group, which has three pillars -- Portals, which is a relatively large development organization, will be working on software for the next version of microsoft.com, whatever that is. The second pillar is the old Microsoft.com Operations Group, and the third is a sort of Central Services group under the Business Manager, which contains service management, release management, the lab team and some other stuff. Our responsibilities remain the same (although the scope is expanding), only now we're centrally placed where we hopefully can be even more effective.
- Microsoft IT has redefined and expanded our internal software development process (SDLC) in some interesting ways which affect the release checklists etc. that I've mentioned in previous entries. In addition, it's become part of a larger overall process that focuses not only on delivering value, but also on whether or not we should be solving a need with software -- or whether changing a process would take care of it. This has a lot of interesting and exciting implications, most immediately, the fact that our checklists etc. need to be updated.
- Related to the above is the fact that I've become the Microsoft.com "SME" (subject matter expert) for SDLC. This means that part of my commitments will be to work with the right people to make the necessary changes in our processes, policies and documentation, (such as those checklists) to align them with the "new" SDLC. I also get to be trained on it, and then provide training to the people on Microsoft.com teams that need it. Oh, and especially pick up the work where we're figuring out how (and if) we can get SCRUM aligned with the required SDLC elements.
- In my Deployment Automation project, the Development team took the lead on figuring out which tools were going to be our standard for creating .msi files and deploying them. We've settled on using the tools built-in to Visual Studio 2005 to build the .msi files and an internal tool for deploying them to the various environments.
All in all, it's been a pretty busy few weeks, although there was a bit of fun in it, as I got to go to San Francisco for a couple of days to attend a Leadership Conference for one of the organizations that I'm a member of. These are usually pretty cool, since I meet all kinds of interesting people, learn some good stuff, and, on the side, have an opportunity to talk to folks who are Microsoft customers. I also got to pop over to Ellensburg for one day last week for a Board of Directors meeting for one of the charities that I serve as a Board Member for. This charity operates two clinics that provide free speech therapy to kids that need it, and funds several non-clinic programs in other places in the State. I'm on the Board of the Seattle Clinic as well -- well, actually, I guess I'm an officer of both the State and local programs now, since I was elected Secretary at last week's meeting.
|
-
There are a couple of variations on agile development methodologies in use in the groups that develop applications for Microsoft.com. Most groups utilize the old traditional Waterfall approach, which can be summarized as:
- Initiate the project -- Sell the basic idea of what the project will be about to management & other stakeholders. Get funding and set a very high level projection on project timeline.
- Plan -- Gather requirements, produce a vision/scope document (also known as business requirements document) that lays out the goals and objectives of the project. Key components of the planning phase are a description of the business value being returned by the project and associated metrics.
- Design -- A functional specification is created, which covers, in detail, the functionality that the application will have. A separate technical design specification is also created, which describes how Development plans on implementing that functionality.
- Build -- The Development team turns the technical design spec into actual code.
- Stabilize -- The Test team verifies that the code built matches the specification.
- Deployment -- The Release Management and Operations teams put the app into production.
- Production -- The Operations team maintains the application and customers use it.
Another common approach is essentially what is included in MSF for Agile Development. It's an iterative process in which several mini build/stabilize cycles ("iterations") take place inside of the Build phase. The functional spec starts out as a kind of skeleton and is fleshed out and updated at the conclusion of each iteration, with the PM often working on adding the work from iteration 3 into the spec at the same time Dev & Test are working on iteration 4. At the end of each iteration, a review meeting takes place with stakeholders at which the progress is reviewed, and any changes / updates in requirements addressed before the next iteration.
Both Waterfall and Agile work well for applications on microsoft.com because they have a high degree of predictability. Since many of our applications run in shared environments (www.microsoft.com, for example, has literally hundreds of applications on, or associated with it), operational, security, and architectural reviews are critical. If these are not planned for in the development methodology, then they can only be done at the end -- which may be too late to avoid having to introduce design changes that may require additional iterations before the application is ready for deployment to the operational environment. To track progress, and help monitor compliance and accountability, the Release Management and Operations teams collaborated on release checklists -- one is created for each project, and the RM tracks the progress and agreements in the appropriate checklist. We also developed Microsoft Project templates that include the checklist items and other basic high level work breakdown structures to assist the Program Managers in planning and tracking the effort and schedules for their projects.
There is another agile development methodology that some teams in microsoft.com have started to use, called SCRUM. SCRUM is very different from either Waterfall or other agile methods, since it is very dependent on dedicated and co-located resources. I'll go into more detail on how we do SCRUM in a future post, but the main points are:
- No functional spec -- instead, a queue of "User Stories" are worked through
- Instead of iterations, there are planned 30 day long "sprints".
- At the end of each sprint, a full-day sprint review meeting is held, at which the results of the sprint are analyzed, and a high-level plan for the next sprint, including which user stories will be worked, is done.
- Every morning, the team comes togther for a face-to-face meeting, in which the plan for the day is set.
SCRUM only works for projects where the entire development team is located in the same place -- in fact, industry SCRUM resources suggest a "bullpen" approach, where all are literally in one big room.
The other interesting thing about SCRUM is that you do not know in advance where the project is going to end up -- which can make architectural reviews, capacity planning, and other tasks very difficult for applications that will be deployed to operational environments (as opposed to, say, information worker applications on desktops). To work around this, we did create a checklist that ensures that operational and security needs are included in SCRUM projects. It's included in the download mentioned earlier.
|
-
The MSCOM Ops team just put a good description of Operations interacts with our software development life cycle (SDLC) process up on their blog. It's a good read. Included therein are a couple of versions of the documents that my team uses to track the project teams' progress through the SDLC as apps get developed. You might want to take a look, as I'll be expounding further on them later.
|
-
The use of Agile software development methodologies, such as MSF for Agile Development holds a lot of promise. However, 1st generation agile methodologies can be problematic when developing software for deployment in online systems, as they do not always address the architectural needs that operations requires.
Randy Miller, in the MSF for Agile Development blog, talks about how second generation agile methodologies are addressing the architecture question, and other issues like testing with testers.
|
-
One of the side projects that I'm working on in Microsoft.com is called our "Deployment Automation 1.0" project. The goal is to codify some policies, processes, and standards around how we deploy projects into the operational environment. This is a big project, with people involved from several development teams, operations and management, many of whom have found different ways of doing this -- ranging from hand-written scripts to .msi files developed using a number of tools.
Wish us luck.
Oh, and if you have a favorite setup / deployment tool, I'd love to hear about it in a comment ....
|
|
|
|
