J.D. Meier's Blog

Software Engineering, Project Management, and Effectiveness

  • J.D. Meier's Blog

    Actions, Insights and Notes

    • 1 Comments

    I find chunking my notes from lectures and training helps me turn insights into action.  I chunk my notes into three categories:

    • Actions - this is a tickler list of things I'm going to go do.
    • Insights - this is a tickler list of distinctions and "ah-ha"'s from the sessions.
    • Notes - this is my raw tickler list and details of key notes throughout the session.

    Why It's Effective
    It's simple, but effective.  It's effective because rather than just a list of notes, it's distilled actions and reference points.

    Putting It Into Action
    Here's what I do 

    1. During the session, I can capture a lot of notes fairly quickly.  I typically use a pad of post-its and jot down key things.  These are my raw notes.  For example, during the lecture or training, I'll take a bunch of notes in a pretty linear fashion.  It represents a stream of real-time notes. 
    2. I transfer the notes to an electronic store (usually notepad).  This is a fast, focused step.  Sometimes I use Dragon NaturallySpeaking software and just read my notes rappidly.  I title this section Notes.
    3. I scan my notes and cherry pick the insights.  I put these under an Insights section that I create above my Notes section.
    4. I scan my notes and cherry pick the actions.  I put these under an Actions section that I create above my Insights section.

    The result is a crisp set of actions, a crisp set of insights, and then a full reference list of notes.  Taking  a few quick passes through my notes, reminds me of key things and helps the information sink in deeper.   Deliberately turning notes into insights and actions also helps retention.  Think of it as challenging yourself to use what you learn.

  • J.D. Meier's Blog

    How To: Create a “Hello World” WCF Service Using Visual Studio

    • 6 Comments

    Here's a quick step through of using WCF in Visual Studio 2005.  In this case I used a local machine, running Windows 2003, for the service and the client. 

    There's lot of possible paths, and this is just one path through.  I focused on "Hello World" to run through the basic mechanics, but chose a path to touch enough things that might be interesting to explore another day.

    Scenario
    Use Visual Studio 2005 to do a dry run of creating a WCF service hosted in IIS and calling it from a console application on your local development workstation.  (Note that you don't need to host WCF in IIS; for example, you could use a surrogate console application.)

    Preparation
    In my case, I needed the .NET 3.0 components and the WCF extensions for Visual Studio:
    1. .NET 3.0 Runtime Components
    2. WCF and WPF extensions for Visual studio

    Summary of Steps

    • Step 1.  Create the test service
    • Step 2. Add a Hello World Method
    • Step 3.  Test your WCF service
    • Step 4.  Enable meta-data for your WCF Service.
    • Step 5.  Create the test client.
    • Step 6.  Add a Web Services reference to your WCF Service.
    • Step 7.  Add the namespace to your
    • Step 8. Call your WCF service

    Step 1.  Create the test service
    In this step, we'll create a WCF service that uses HTTP bindings, for backward compatibility (non-.NET 3.0 clients)

    1. In Visual Studio, click File -> New Web Site
    2. Select WCF Service
    3. Browse to a directory to store your project: (e.g. D:\Dev\WCF\Test1\Serve )
    4. Enable wsHttpBinding.  To do so, right-click Web.config and click Edit WCF Configuration ... Expand Services > expand MyService -> expand Endpoints.  Click (Empty Name).  Change wsHttpBinding to basicHttpBinding
    5. Create the virtual directory.  In your File Manager, right-click your Server folder (i.e. D:\Dev\WCF\Test3\Server) and click Properties, then Web Sharing, and click Share this folder, then click OK.

    Step 2. Add a Hello World Method
    In Service.cs, you'll add your Hello World method:

    1. Add the HelloWorld operation contract below public interface: [ServiceContract()]
      public interface IMyService
      {
          [OperationContract]
          string MyOperation1(string myValue1);
          [OperationContract]
          string MyOperation2(DataContract1 dataContractValue);
          [OperationContract]
          string HelloWorld();
      }
    2. Add your HelloWorld method below public class MyService : public class MyService : IMyService
      {
          public string MyOperation1(string myValue1)
          {
              return "Hello: " + myValue1;
          }
          public string MyOperation2(DataContract1 dataContractValue)
          {
              return "Hello: " + dataContractValue.FirstName;
          }
          public string HelloWorld()
          {
              return "Hello World";
          }
      }

    Compile and debug any errors.
    Step 3.  Test your WCF service

    1. In IIS Manager, under Default Web Site, right-click expand Server (the virtual directory you just created)
    2. Right-click Service.svc and click Browse

    There's two issues you might hit here:

    1. You don't have ASP.NET installed/enabled.  To fix this, first run aspnet_regiis /i from your .NET installation directory (C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727)  Then, allow ASP.NET in your IIS Manager.  To do so, in IIS Manager, expand Web Service Extensions, select ASP.NET v.2.0.50727 and click Allow.
    2. You might see "Security settings for this service require 'Anonymous' Authentication but it is not enabled for the IIS application that hosts this service."  To fix this, first enable anonymous access.  In IIS Manager, right click your v-dir (Server), click Properties, click Directory Security, click Edit under Authentication and Access control, click Enable Anonymous Access, then OK your way out of the dialogues.  Next, recycle IIS.  In a command prompt, type IISreset.  If successful, when you browse your Service.svc file from IIS Manager (e.g. http://localhost/service/service.svc). you'll get a message that starts with the following:
      This is a Windows© Communication Foundation service. 
      Metadata publishing for this service is currently disabled.

    Step 4.  Enable meta-data for your WCF Service.

    1. In VSTS, right-click Web.config and click Edit WCF Configuration.  In WCF Configuration, expand Advanced, then expand Service Behaviors, then
      right-click returnFaults and click Add Service Behavior Element Extension.  Select serviceMetadata and click Add
    2. In WCF configuration, select serviceMetadata and change HttpGetEnabled to True.  Close the dialogue and save changes.
    3. Test your service again.  Browse to http://localhost/Server/Service.svc and this time you should see your service (e.g. MyService Service).  You
      will see a message that starts with the following:
      "You have created a service."

    Step 5.  Create the test client.
    In this step, we'll create a quick console app to call the WCF service:

    1. In Visual Studio, click File -> New -> Project
    2. Select Console Application.
    3. Browse to a directory to store your test client:  (e.g. D:\Dev\WCF\Test1\WCFClient)

    Step 6.  Add a Web Services reference to your WCF Service.
    In this step, we'll add a Web Services reference. 

    1. Right-click References      
    2. Click Add Web Reference ...
    3. In the Add Web Reference dialogue, add the path to your WCF Service (http://localhost/Server/Service.svc)
    4. Click Add Reference to close the dialogue.  You should then see your Web Service reference show up under Web References.

    Step 7.  Add the namespace to your   

    1. Browse to your Reference.cs file.  You'll find the file below Reference.map under your Web service reference.  You might need to click the Show All Files button on the Solution Explorer so you can see the files under your Web service reference. 
    2. Find the namespace.  You'll see a line similar to the following:
              namespace ConsoleApplication1.localhost
    3. Add the using statement to your Program.cs file.
                      using ConsoleApplication1.localhost;

    Step 8. Call your WCF service
    In your test client, call your WCF service:
            static void Main(string[] args)
            {
                MyService service = new MyService();
                string foo;
                foo = service.HelloWorld();
                Console.WriteLine(foo);
            }
    When you compile and run your console application, you should see the following:
    Hello World
    Press any key to continue . . .

    Additional Resources

    Hopefully this step through helps you quickly see some of the bits and pieces you can play with.

  • J.D. Meier's Blog

    Scenarios in Practice

    • 2 Comments

    Scenarios are a practical way to organize and focus your product design, development and release.   (We use scenario-driven engineering in patterns & practices) 

    Key Benefits

    • Business value.  You can  use scenarios to evaluate business value.   What pain does that scenario address? ... What opportunity does it create? ... etc.
    • Chunking and prioritizing.  You can use scenarios to chunk up and prioritize your product.  You can think of versioning in terms of releasing incremental value or scenarios.
    • Effective design.  Walking through a set of customers scenarios and "what ifs" will help you figure out your product's most effective design.  It's not a silver-bullet, but it does help make requirements more concrete, or at least put them in perspective.  It also opens the door to more precise questions about user experience or engineering challenges..
    • Focal point for perspectives.  You can use scenarios as a focal point for user experience, business and tech perspectives.
    • Requirements in context.  You can use scenarios to put requirements in context.  A requirement makes a lot more sense when you see it in action.
    • Architectural trade-offs.  You can use scenarios to evaluate and make architectural trade-offs.  You can't evaluate an architecture in a vacuum; you can evaluate against concrete scenarios.  There's several flavors of scenario-based evaluations you can leverage.
    • Customer value.  Your customers can appreciate how well you did (or didn't) address their scenario.
    • Tests for success.  You can use scenarios as tests for success.  By measuring customer effectiveness against specific scenarios, you have a way to focus your improvements.

    Chunking Up a Project Using Scenarios
    If you think of your product as helping a user accomplish a goal, it helps cut through the fog. You can think of your product in terms of a list of user goals, business goals and technical goals.  What's the minimum set of tasks your user needs to perform with your product?  That's your baseline release.  What's the incremental value from there?  That's how you start to shape your versions and releases.

    User Experience, Business and Technical Perspectives
    Using scenarios is a good forcing function to bring together the user experience, business, and technical perspectives.  For the sake of example, let's say your scenario is "User views the product catalog."  From the user experience perspective, you're thinking in terms of "show me a relevant list" and "don't make me wait,"  From a business perspective, you're thinking in terms of "support a given number of orders per hour" and "lower the total cost of ownership."  From a technical standpoint, you're thinking in terms of "requests per second," "minimize resource utilization," ... etc.  Well, no wonder getting software right is tough!  Luckily, scenarios help you bring together and rationalize the perspectives against a common frame of reference.

    Constraints Make More Sense In Context
    Constraints are boundaries to operate within, or what the solution must or must not do.  In software, I see a lot of generic constraints passed down as policies.  When policy meets scenario, you now have a way to evaluate the effectiveness of that constraint.  You can also measure whether that scenario is actually meeting the constraint.  You can perform scenario-based testing against a set of scenarios with specific constraints.

    Walking the Scenarios
    Have you ever been sold on a great set of features, only to fall flat when you try to actually do something useful?  Obviously, that's the extreme case, but it happens to me.  It happens less now because whenever I go to buy something, I walk my usage scenarios.  Doing a dry run against a scenario is very revealing.   This approach works great on the engineering side too.  It's one thing to have generic technical requirements for security or performance.  It's another to evaluate a scenario and make appropriate and relevant trade-offs from a user, business and technical perspective.  Suddenly, generic technical requirements no longer seem as helpful, do they?  They still have their place, but when you're engineering your job is to make the right trade-offs.

    Scenarios and Solutions
    Given part of my job is to improve customer effectiveness on our platform, I regularly use scenarios as a backdrop for evaluation.  As I've gotten more effective, I noticed shifting from features and components to scenarios and solutions is the key.

    More Information

    My Related Posts

  • J.D. Meier's Blog

    Guidance Explorer: A Top Download on CodePlex

    • 2 Comments

    It was a nice surprise to see that our Guidance Explorer is among the top downloads on CodePlex.

    GEMostDownloadsOnCodePlex

  • J.D. Meier's Blog

    Growth Mind-set Over Fixed Mind-set

    • 6 Comments

    Do you have to be great at everything?  If this stops you from doing things you want to try, then it's a limiting belief.  Scott Berkun spells this out in Why You Should Be Bad at Something.

    Keys to Growing Your Skills
    Here's a set of practices and mind-sets that I've found to be effective for getting in the game, or getting back in the game, or learning a new game versus just watching from the side-lines. 

    • Swap out a fixed mind-set with a growth mind-set. (innate ability vs. learning) See The Effort Effect.
    • Call it an "experiment."  This sounds like a trivial frame game, but I see it work for myself and others.
    • Treat perfection as a path, not a destination.  If you're a "perfectionist," (like I "was", er "am, er ... still fighting it), you know what I mean.
    • Use little improvements over time.  Focus on little improvements and distinctions over time, versus instant success.  It's consistent action over time that produces the greatest results.  You're probably a master of your craft, whatever it is you do each day, every day.  John Wooden focused his team on continuous, individual improvement and created the winningest team in history.
    • Remind yourself you're growing or dying.  You're either climbing or sliding, there's no in-between (and the slide down is faster than the climb up!)
    • Try agin.  If at first you don't succeeed, don't just give up.  Remember folks like Thomas Edison, who "failed" many, many times before finding "success" (it's a part of innovation)
    • Focus on lessons over failures.  Remind yourself there are no failures; only lessons (one more way how "not" to do something)
    • Fail fast.  The faster you "fail", the faster you learn.
    • Don't take yourself or life too seriously.  If you take yourself too seriously, you'll never get out alive!
    • Learn to bounce back.  It's not that you don't get knocked down, it's that you get back up.  (Just like the song, "I get knocked down, but I get up again")
    • Give yourself time.  A lot of times the difference between results is time.  If you only chase instant successes, you miss out on opportunities. Walk, crawl, run.  Or, if you're like me, sprint and sprint again ;) 
    • Start with something small.  Build momentum.  Jumping an incremental set of hurdles is easier than scaling a giant wall.   
    • Build on what you know.  Now matter where you are or what you do, you take yourself with you.  Bring your game wherever you go. 
    • Learn to like what growth feels like.   I used to hate the pain of my workouts.  Now, I know that's what growth feels like.  The better I got at some things, the more I hated how awkward I was at some new things.  Now I like awkward and new things.  It's growth.
    • Find a mentor and coach.  It doesn't have to be official.  Find somebody who's great at what you want to learn.  Most people like sharing how they got good at what they do.  It's their pride and joy.  I used to wonder where the "mentors" are. Then I realized, they're all around me every day.
    • Have a learning approach.  For me, I use 30 Day Improvement Sprints.  Timeboxes, little improvements at a time, and focus go a long way for results.  I use 30 Day Improvement Sprints.

    There's a lot more I could say, but I think this is bite-sized working set to chew on for now.

    More Information

    • The Effort Effect - This article exposes the truth behind "you can't teach an old dog new tricks" and whether all-stars are born or made (nature vs. nurture.)  If you have kids, this article is particularly important.  Adopting a growth mind-set over a fixed mind-set can have enormous impact.

    My Related Posts

  • J.D. Meier's Blog

    Links: patterns and practices links

    • 4 Comments

    I did a quick round-up of some key patterns & practices team links and figured I'd share:

    MSDN

    Team Blogs

    CodePlex Projects

    Community Contribution

    Surveys / Feedback

    Resources

  • J.D. Meier's Blog

    Patterns and Practices for New Hires

    • 9 Comments

    Whether you're a new hire or taking on a new job, here's some principles, patterns and practices to be more effective.  They're lessons learned from the school of hard knocks and they represent some of the proven practices that have worked for others and have stood the test of time.   This is a limited, but prioritized list (I gave myself a 20 minute window.)  I'll drill into areas in upcoming weeks, depending on where there's interest.

    Personal Productivity

    • Timebox your day.  Carve your day into time budgets.  Figure out how much time you should spend on administration, work time, meeting time, and think time.  Start with a day.   For example, some of the most effective people spend 1 hour on admin, 1 hour on think time, 4 hours on work time, and 2 hours on meetings.  You need to find the pattern that works for you.  The trap is to not know when the day ends and over-spend time in areas you should allocate to others.   See Timebox Your Day.
    • Manage your meetings.  You'll likely spend a lot of time in meetings.  Value your time.  Find out the meeting you must go to versus should or could.  Use meetings to build your network.  The most effective meetings have agendas and the right people.  Some meeting are more about connection versus results, so if you know that up front, you can reset your expectations.  Nothing's worse than trying to get results in a connection meeting.  One thing to remember is that connection precedes results.  You get more done with rapport (think "rose colored glasses")       
    • Manage your mail.  Doing a day of email doesn't mean you did a great day of work.  Timeboxes help.  See Clearing Your Inbox.
    • Manage your action.  Think in terms of daily results working towards larger outcomes.  See Execution Checklists and Using Scannable Outcomes with My Results Approach.
    • Manage your plate.  Underpromise and over-deliver.  It's better to nail a few things well, than take on a bunch and never finish.  Think of it like a buffet -- rather than over-flow your plate and get bogged down, take smaller plates and more trips.  The fast eat the slow.
    • Master information management.  The most important concept is to factor reference information from action.  Always use the RAT test on information you get (relevant? accurate? timeley?)  Use trusted sources and trusted people for finding the best, most distilled information.
    • Manage your energy.  You can throw a lot of time at a problem, but it's your energy that will give you the power hours.  See Manage Energy, Not Time.

    Results

    • Know what's important.  Your manager and peers will tell you if you ask.  Sanity check when you hear one thing, but see another.  Usually folks are doing what's on their commitments, so walk the commitments stack up the chain to see how and where you fit in.
    • Manage your results.  Microsoft rewards "smart and gets results."  Focus on outcomes over activities.  Think in terms of value delivered over activity performed.  You can do lots of activities but that doesn't necessarily translate into meaningful results.
    • Walk an instance end-to-end.  Know what you're getting yourself into.  Whatever your team delivers, walk an instance from start to end.  Knowing the bigger picture will quickly help you orient where you are in the bigger picture.  This will help you anticipate.  You'll also know how to pace yourself for the race (walk, jog or run.)
    • Avoid analysis paralysis.  It's really easy to fall into the trap of mistaking great throughts for great actions.  Take action and improve.  Analyze enough to start taking action, getting results and improving.  Figure out your higher risks earlier versus later.  Fail fast.
    • Learn project management.  Knowing how to do a work breakdown structure, timeline, work estimates and how to allocate resources gives you an advantage in getting results.  You can apply these skills to a micro-level (personal productivity) or to a macro-level (getting large projects done.)
    • Play to your strengths.  You have your strengths.  Use them.  Find a way.  If you find yourself doing a job and you know you really could be more effective, figure out whether it's your approach.
    • Use reference examples.  Find the best reference examples and work backwards from there.  Whatever you need to do, chances are, somebody's paved a path or there's an example you can find.  You can leapfrog results if you don't always start from scratch.
    • Know the tests for success.  Nothing's worse than to finish a major project only to find you missed the mark.  Figure out the tests for success earlier versus later.  They're might not be a lot of clarity in the beginning, but continuously refine figuring out what good looks like.
    • Deliver incremental results.  If you can chunk it down, you have a better chance for success.  Show progress along the way.  Always have a great end in mind, but be able to chunk it up and make progress on the bigger picture.
    • Think in terms of value delivered.  You can think in terms of time (daily, weekly, monthly).  You can think in terms of value (how important is this).  Just the act of thinking in terms of value delivered will help you prioritize your personal queue. 

    Communication

    • Create the driver's guide for your manager.  Your manager has a high-correlation to your job satisfaction and your success in Microsoft.  What's their communication style?  Do they like email, voice or dialogue?  How frequently should you meet with them to stay on the same page?  How do they want status?
    • What's their story?  Be careful when you jump to conclusions.  When somebody doesn't do something as you expect, it's good to checkpoint assumptions.  See What's Their Story? 
    • Speak in the right currency.  Know what matters to your audience and the terms they use.  Use their terms where you can to bridge the communication gap.
    • Use metaphors and mental models.  The better you can simplify complex information into a mental model or visual, the more effective you'll be.
    • Use stories.  Use short stories to convey a point.  By short, something you can say in a few sentences.  It should be relevant and have an emotional aspect.  If just stating a point, doesn't make the point hit home, sometimes telling the right story can.
    • Use a whiteboard.  The power of the whiteboard is that people tend to put down what's important versus get lost in the details.  You can also drill in or step back as needed.
    • Speak in slides.  A slide is a great forcing function to make you consolidate your point.  At Microsoft, it's easy to pass slides around.  I use One-Sliders.

    Intellectual Horsepower

    • Ask better questions.  Thinking in just asking and answering questions.  If you want better answers, ask better questions.  You can ask question in terms of time, meaning, assumptions, truth, causes, effects and actions.  One thing I like to do is think in terms of what do I know, don't know and need to know next.  See Cutting Questions.
    • Test it versus debate it.  There's a lot of opinions on a lot of things.  You'd be surprised how quickly a simple repro test can cut through debate.  Find empirical evidence where you can.
    • Learn thinking techniques.  There's lots of thinking patterns and techniques.  You can study Disney's imagineers such as Michael Michalko, or practices such as Neuro Linguistic Programming (NLP.)

    Learning / Improvement

    • Change your approach.  Stay adaptable.  If you're not getting results, change your approach.  The best way to get unstuck is to change your approach.  You learn the most from trying something different.  Sometimes this is uncomfotable, but that's what growth feels like.
    • Model the best.  Find the people that get results.  Have at least a few examples of people that have both continuous improvement and balance.  For balance, that means both work and home, and at work it means, balance between connection and results. 
    • Take key training.  Obviously, you'll want relevant technical training, but you'll want training to make you more effective in your day to day success at Microsoft.  While I've had great tech training, some of my most useful training has been in effective meetings, personal productivity, interpersonal communication, negotiation skills, influence, leadership, and thinking techniques.
    • Use everybody as a mentor.  Everybody can teach you something.  Everybody.  Find something each person does well and find out how they do it.  Success leaves clues.
    • Use a personal sounding board.  Find some folks you trust to give you the tough feedback.  Sanity check your ideas with your personal sounding board.
    • Improve strengths, but limit liabilities.  If you spend all your time working on your weaknesses, you won't get the benefit of your strengths.  Continously improve your strength, while you master you craft.  Every day at work is a chance to practice.  Reduce your liabilities, but don't ignore improving your strengths. 

    Networking

    • If you don't know, ask.  If you ask a precise enough question, you can stretch your network over time and space.
    • Build your network.  Your network naturally waxes and wanes.  Your results are a combination of what you know and who you know.  Building your network will help you get more done over time.  It's a long-term investment that builds on itself.
    • Play tradesees.  It's easier to network when you bring something to the table.  You can trade what you know or your expertise in an area with somebody elses.  This is how a lot of effective people get results.  They build a network of complimentary skills and experience. 
    • Use WIIFY.  What's In It For You (WIIFY) is a simple, but effective way to communicate.  If you always ask yourself, what's in it for the person you're brokering in, you're off to a better start.  Point out to them what's in it for them if it's not obvious.  If there's nothing it it for them, then that's a flag.  Challenge yourself to find a way for their to be something in it for them and you'll get further.

    My Related Posts

  • J.D. Meier's Blog

    My Cockpit

    • 4 Comments

    A few readers asked me to show some screens of my approach in Outlook.   (I haven't used images in my blog before, so this is a good post to give it a shot.)

    My Outlook Folders
    Here's what I see when in my Outlook folders.

    OutlookFolders4

    Notice how I cluster my scannable action folders (Outcomes, To Dos and Daily Status) and my reference folders (Notes, Quick Stuff and Thoughts.)  The reference folders are my Collection Pools.  The folders are physically stored in my local Outlook.PST folder I named "Admin." I then dragged the folders up to "Favorite Folders" since I use them daily.

     

     

     

     

     

    Scannable Outcomes
    I use Posts in Outlook for my Scannable Outcomes.  This is what I see when I click my Outcomes folder:

    ScannableOutcomes2

    Each post represents a key project.  In each post, I list the outcomes and actions (like a mini queue.)  I can scan each post very quickly using the Outlook preview pane. 

    My To Dos
    I use Posts in Outlook.  Here's a shot of leveraging the pre-view pane for my To Dos.   This is what I see when I click my To Dos folder.

    ToDos

    Keys to Results

    • Factoring action from reference helps get results.
    • Consolidating reference information to a few collection pools helps simplify storing information.
    • Using scannable indexes for action is a low-overhead way to figure out next actions.
    • Using scannable outcomes shows me everything on my radar at a glance.  It's ultimately my portfolio of results and a quick view of where I spend my time and energy.  It continuously reminds me that I need to balance areas in my life.  When my portfolio is not compelling, I know it's time for a change.
  • J.D. Meier's Blog

    Collection Pools

    • 6 Comments

    How do you store your notes and reference information in a way that’s low overhead and easy to find?  The key is to created a limited set of places to look that you trust.   I use a small set of what I call Collection Pools.  I think of them as pools because they’re effectively pools of reference information I draw from.

    Collection Pools
    I currently use the following pools:

    • Notes
    • Quick Stuff
    • Thoughts

    I create a folder in Outlook for each pool and I create posts in the folders.  It’s flat by design.  I could just as easily use a folder  on my hard drive with text files, but I like the preview pane in Outlook and sometimes the rich text helps.

    Using the Pools
    Here's how I use the pools:

    • Notes is where I store the majority of my reference information which is anything from a meeting recap to notes from a Web page.  It’s one long flat list of posts, ordered by time.  I can quickly sort by title or search for a keyword.  I used to use a local Wiki, but I find a flat lists of posts to be really lightweight and effective.  Scrolling through my notes is great with the preview pane in Outlook.
    • Quick Stuff is where I keep a lot of common lookup information and indexes, such as favorite links, lab machine names, distribution lists … etc.
    • Thoughts is where dump my ideas and distinctions I make throughout the day.  It’s my pool of insights.  It’s a very light-weight way to journal my ideas and distinguish my insights from the rest of my reference notes.

    Results
    I actually started with my Notes and Quick Stuff folder a few years back.  I thought it would be a temporary solution while I explored options.  It turned out to be the most efficient approach of all the various ways I tried.  I always knew where to put things and I always knew where to look and it was always open.  I added the Thoughts folder in February this year.  It too turned out to be the most efficient approach I have for a scannable set of ideas and insights and I like the ability to scroll through time.

    While there’s a lot of fancier things I could do, simple text notes chunked up in a few folders is a pretty efficient system.  I think the lesson here is that for a practice to stick over time, it has to be simple enough and effective enough.  Otherwise, it fails the test of time. 

    My Related Posts

  • J.D. Meier's Blog

    Vision Scope Template

    • 2 Comments

    How do you convince a team of venture capitalists to bet on you?  There's a lot of ninja techniques but here I'll share the fundamentals. 

    Vision and Scope
    We use Vision Scope milestones in patterns and practices to sell management on how we'll change the world.  Knowing the vision and scope for a project is actually pretty key.  The vision will motivate you and your team in the darkest of times.  It gets you back on your horse when you get knocked off.  The scope is important because it's where you'll usually have to manage the most expectations of what you will and won't do.

    Thinking in Terms of Venture Capitalists
    When I do a vision scope, I think of the management team as the venture capitalists (a tip from a friend.)  This helps me get in the right mindset.  I have to convince them that I have the right problem, the right solution, the right customers, the right impact, the right team, the right cost and the right time-frame.  Hmmmm ... I guess there's a lot to get right.  A template helps.  The right slide template helps because it forces you to answer some important questions.

    Template for Vision Scope
    Here's the template I used from my last vision scope meeting:

    • Agenda
    • Problem
    • Vision
    • Approach
    • Prioritized Tests for Success
    • Scope
    • Key Activities
    • Deliverables
    • Execution
    • Team
    • Budget
    • Schedule
    • Asks
    • Go/No Go

    It's implicitly organized by problem, solution, deliverables and execution.  While the slides are important, I found that the real success in vision scope isn't the particular slides.  It's buy in to the vision, rapport in the meeting, and trust in the team to do the job. 

    What works for you?

  • J.D. Meier's Blog

    It's the Fast That Eat the Slow

    • 2 Comments

    Using speed as a competitive advantage is less about finding ways to do things quicker.  It's more about eliminating speedbumps.  In It's Not the Big That Eat the Small...It's the Fast That Eat the Slow: How to Use Speed as a Competitive Tool in Business, Jason Jennings and Laurence Haughton write:

    "Instead of looking for magical answers as to what companies do to be fast, we began asking, "What do fast companies do to eliminate speed bumps that slow everyone else down?" ... truly fast companies that have demonstrated the ability to maintain momentum aren't naturally faster than their slower-moving rivals.  But they are smarter.  Smart enough to recognize that the speed bumps that slow everyone else down must be ruthlessly eliminated... Each has made speed -- fast thinking, fast decisions, fast to market, and sustaining momentum -- one of their unique competitive advantages."

    Friction is death by a 1000 paper cuts.  I'm a fan of reducing friction, while building speed and momentum.  I'm always asking, what speedbumps can I eliminate in my day? ... my job? ... my org? ... my company? ... my industry? ... my life?   These simple questions shape a lot of what I do.  If I'm not part of the solution, I'm part of the problem. 

  • J.D. Meier's Blog

    Testing Your Organizational Clarity

    • 1 Comments

    How do you figure out what your organization is really about?  It's one thing to know it intutitively.  It's another to be able to share it or have meaningful dialogue.  Here's the tests I use lately to know what a team or org is really about:

    Tests for Organizational Clarity

    • Vision / Mission: What's the one-liner vision and mission?
    • CustomersWho's the customer?
    • Problems: What domains or problems does it focus on?
    • Business Case; What's the internal and external business case?
    • Measures of Success; What's the measures of success?
    • Catalog / Product Line: What's the product line / deliverables / results?
    • Rhythm of Results: What's the product cycle or rhythm of results?

    If you know these, it tells you a lot. 

    Why This Cuts to the Chase
    Here's a quick rundown on how you can use this:

    • Mission is who you are and vision is where you want to go. An important attribute in the mission, is some unique value or differentiator. If everybody knows the vision and mission, they can run to the same finish line.   For me, I like one-liner visions and missions that you can spit out in the hall without a cue card.
    • In a large shop like Microsoft, knowing your customers makes a big difference.  For me, while I server a lot of customers, my main focus is developers.  While it's partly a chicken and egg deal, knowing your customers helps you clarify which domains or problems you tackle.  When in doubt, ask your customers!
    • Owning important problems is key.  I think you can measure the value of an org, by measuring the value of the problems it solves.
    • Business cases are powerful because they justify existence and investment.  I think looking through two lenses helps -- what do your customers see as the business case? (why you versus some other group or service or product) ... and what does your company see as the business case? (what's the unique value to keep this group around and invest in it)  One important piece of a business case is knowing how big is the pie and what's your slice.
    • Measuring success is important.  Everybody wants to do a good job and know what it is.  Knowing what gets measured tells you what's valued.
    • Knowing the deliverables in the form of a catalog or product line tells a lot about an org or team.  I like to think in terms of portfolios of results.  When I talk to teams about what they do, finding out what they deliver really cuts to the chase.
    • The rhythm of results is important.  This tells you a lot about the cadence, work styles, value of time, ... etc.

    There's obviously a lot more you can know about an org or team, but I'm finding these are keys to cut to the chase.

  • J.D. Meier's Blog

    How To Be a Leader in Your Field

    • 2 Comments

    How to be a leader in your field?  Dragos shared a link to How to Be a Leader, which I found interesting.  In the article,  Philip E. Agre presents a six step recipe for becoming a leader in your field:

    1. Pick an issue.
    2. Having chosen your issue, start a project to study it.
    3. Find relevant people and talk to them.
    4. Pull together what you've heard.
    5. Circulate the result.
    6. Build on your work.

    I think the takeaway was that to be a leader in the field, you help move the ball forward.  In step 1, Philip gives an A-Z list of how to pick which ball to move forward. 

    Another part of the article caught my attention.  Philip writes:

    "To succeed in your career, you need more than the skills that you got in school -- you need to be the world expert in something. Knowledge is global, it's growing exponentially, and nobody can pack all of the necessary knowledge into their head. So everyone's going to specialize."

    I think there's a lot to be said for focus and specialization.  The trick is picking what to specialize in.  Personally, I like to specialize in skills that compound over time versus flavor of the day.

  • J.D. Meier's Blog

    How Might That Be True?

    • 3 Comments

    It's obvious in retrospect, but I found a distinction between low-friction communication and high-friction communication.  By low-friction, I mean *person A* doesn't have to work that hard for *person B* to get a point.

    I find low friction scenarios are often cases where *person B* starts with the mind-set "how might that be true" and they help *person A* tease out, or make their point.  The starting point is collaboration -- two people working to understand the message.  I find high-friction scenarios are often cases where *person B* starts with the mind-set "let me tell you how you're wrong." 

    It's really easy among a bunch of engineers to rip ideas apart.  The trick I found is to first ask, "how might that be true?"  This gets over the potential hump that maybe while the delivery was off, there was merit in the message (or a concept needs help to be teased out) and it certainly builds more rapport than starting off as a devil's advocate.

  • J.D. Meier's Blog

    How To Use the Six Thinking Hats

    • 4 Comments

    How do you get past deadlocks in a meeting?  You can apply the Six Thinking Hats.  I've blogged about the Six Thinking Hats before, but to summarize, it's a way to get everybody thinking about the problem in a collaborative way. 

    The Keys to The Six Thinking Hats
    The real key here is that rather than circular or deadlock debates, you focus the group on a particular viewpoint at a time.  This is a similar to writing, then editing vs. editing while your write, or brainstorming, then critiquing vs. critiquing while you brainstorm.  The big difference is that rather than just brainstorming and critiquing, you're looking at the issue from multiple, specific angles.  On the people side of this technique, you're letting people wear a different "hat", in a safe, constructive way.

    Applying the Six Thinking Hats 
    The approach below is lightweight and low-overhead, but gets you 80% there without requiring everybody to know the details of the Six Thinking Hats.

    Summary of Steps

    • Step 1.  List the questions that represent the hats
    • Step 2.  Walkthrough each question as a team
    • Step 3.  Modify the approach

    Step 1.  List the questions that represent the hats
    List a set of questions on the whiteboard to represent the hats.  You can do this either at the start of the meeting or when you hit a sticking spot.
    Here's the Six Thinking Hats:

    • White Hat - the facts and figures
    • Red Hat - the emotional view
    • Black Hat - the "devil's advocate"
    • Yellow Hat - the positive side
    • Green Hat - the creative side
    • Blue Hat - the organizing view

    Here's an example set of questions you can use to represent the hats:

    • What are the facts and figures?
    • What's your gut reaction?  How do you feel about this?
    • Why can't we do this?  What prevents us?  What's the downside?
    • How can we do this?
    • What are additional opportunities?
    • How should we think about this? (what are the metaphors or mental models)

    The sequence of the questions can matter.  For example, it wouldn't make sense to start thinking up solutions before you've focused on the problem.

    Step 2.  Walkthrough each question as a team
    Walkthrough each question as a team.  This is the key.  Rather than debating each other, you're now collaborating.  You'll be surprised when suddenly your team's "Devil's Advocate" is now showing off their ability to dream up wild solutions that just might work!

    Step 3.  Modify the approach.
    If it's not working, change the approach.  For example, you might find that you started with the wrong "hat" or question.  See if switching to another question or hat makes a difference.  The key is to keep this lightweight but effective.

    This isn't a heavy handed approach.  Instead, it's a subtle shift in stratey from free-for all debate to focusing and coordinating your team's thinking power in a deliberate way.  This lets everybody get heard as well as really bang on a problem from multiple angles in a teamwork soft of way.

    More Information

  • J.D. Meier's Blog

    Mark Curphey Joins Microsoft

    • 1 Comments

    Well, it's official ... Software security is in for a ride! -- Mark Curphey joins Microsoft.   Mark already brings a ton to the table in terms of ideas, network, and results.  At Micrsoft, he'll crank it up.  Congrats Mark and I look forward to our future adventures!

  • J.D. Meier's Blog

    Scenario Frames for Team Foundation Server

    • 1 Comments

    Our Scenario Frames for Team Foundation Server are available on CodePlex.  We have Scenario Frames for the following:

    We use scenario frames for several things:

    1. Mapping out the problem space
    2. Performing scenario evaluations to evaluate platform, tools, and guidance
    3. Designing products
    4. Scoping work

    The real power of a scenario frame is that's it's a shared frame of reference.  Personally, because I've seen so much benefit from scenario frames time and again, I couldn't imagine doing guidance or building a product without using scenario frames.

    My Related Posts

  • J.D. Meier's Blog

    New Release: patterns & practices Performance Testing Guidance for Web Applications

    • 14 Comments

    We released the final version of our patterns & practices Performance Testing Guidance for Web Applications.  This guide provides an end-to-end approach for implementing performance testing. Whether you're new to performance testing or looking for ways to improve your current performance-testing approach, you will gain insights that you can tailor to your specific scenarios.  The main purpose of the guide is to be a relatively stable backdrop to capture, consolidate and share a methodology for performance testing.  Even though the topics addressed apply to other types of applications, we focused on explaining from a Web application perspective to maintain consistency and to be relevant to the majority of our anticipated readers.

    Key Changes Since Beta 1

    • Added forewords by Alberto Savoia and Rico Mariani.
    • Integrated more feedback and insights from customer reviews (particularly chapters 1-4, 9, 14, 18)
    • Integrated learnings from our Engineering Excellence team.
    • Refactored and revamped the performance testing types.
    • Revamped and improved the test execution chapter.
    • Revamped and improved the reporting chapter.
    • Revamped the stress testing chapter.
    • Released the guide in HTML pages on our CodePlex Wiki.

    Highlights

    • Learn the core activities of performance testing.
    • Learn the values and benefits associated with each type of performance testing.
    • Learn how to map performance testing to agile
    • Learn how to map performance testing to CMMI
    • Learn how to identify and capture performance requirements and testing objectives based on the perspectives of system users, business owners of the system, and the project team, in addition to compliance expectations and technological considerations.
    • Learn how to apply principles of effective reporting to performance test data.
    • Learn how to construct realistic workload models for Web applications based on expectations, documentation, observation, log files, and other data available prior to the release of the application to production.

    Why We Wrote the Guide

    • To consolidate real-world lessons learned around performance testing.
    • To present a roadmap for end-to-end performance testing.
    • To narrow the gap between state of the art and state of the practice.

    Scope

    • Managing and conducting performance testing in both dynamic (e.g., Agile) and structured (e.g., CMMI) environments.
    • Performance testing, including load testing, stress testing, and other types of performance related testing.
    • Core activities of performance testing: identifying objectives, designing tests, executing tests, analyzing results, and reporting.

    Features of the Guide

    • Approach for performance testing.  The guide provides an approach that organizes performance testing into logical units to help you incrementally adopt performance testing throughout your application life cycle.
    • Principles and practices.  These serve as the foundation for the guide and provide a stable basis for recommendations. They also reflect successful approaches used in the field.
    • Processes and methodologies.  These provide steps for managing and conducting performance testing. For simplification and tangible results, they are broken down into activities with inputs, outputs, and steps. You can use the steps as a baseline or to help you evolve your own process.
    • Life cycle approach.  The guide provides end-to-end guidance on managing performance testing throughout your application life cycle, to reduce risk and lower total cost of ownership (TCO).
    • Modular.  Each chapter within the guide is designed to be read independently. You do not need to read the guide from beginning to end to benefit from it. Use the parts you need.
    • Holistic.  The guide is designed with the end in mind. If you do read the guide from beginning to end, it is organized to fit together in a comprehensive way. The guide, in its entirety, is better than the sum of its parts.
    • Subject matter expertise.  The guide exposes insight from various experts throughout Microsoft and from customers in the field.

    Parts

    • Part 1, Introduction to Performance Testing
    • Part II, Exemplar Performance Testing Approaches
    • Part III, Identify the Test Environment
    • Part IV, Identify Performance Acceptance Criteria
    • Part V, Plan and Design Tests
    • Part VI, Execute Tests
    • Part VII, Analyze Results and Report
    • Part VIII, Performance-Testing Techniques

    Chapters

    • Chapter 1 – Fundamentals of Web Application Performance Testing
    • Chapter 2 – Types of Performance Testing
    • Chapter 3 – Risks Addressed Through Performance Testing
    • Chapter 4 – Web Application Performance Testing Core Activities
    • Chapter 5 – Coordinating Performance Testing with an Iteration-Based Process
    • Chapter 6 – Managing an Agile Performance Test Cycle
    • Chapter 7 – Managing the Performance Test Cycle in a Regulated (CMMI) Environment
    • Chapter 8 – Evaluating Systems to Increase Performance-Testing Effectiveness
    • Chapter 9 – Determining Performance Testing Objectives
    • Chapter 10 – Quantifying End-User Response Time Goals
    • Chapter 11 – Consolidating Various Types of Performance Acceptance Criteria
    • Chapter 12 – Modeling Application Usage
    • Chapter 13 – Determining Individual User Data and Variances
    • Chapter 14 – Test Execution
    • Chapter 15 – Key Mathematic Principles for Performance Testers
    • Chapter 16 – Performance Test Reporting Fundamentals
    • Chapter 17 – Load-Testing Web Applications
    • Chapter 18 – Stress-Testing Web Applications

    Our Team

    Contributors and Reviewers

    • External Contributors and Reviewers: Alberto Savoia; Ben Simo; Cem Kaner; Chris Loosley; Corey Goldberg; Dawn Haynes; Derek Mead; Karen N. Johnson; Mike Bonar; Pradeep Soundararajan; Richard Leeke; Roland Stens; Ross Collard; Steven Woody
    • Microsoft Contributors / Reviewers: Alan Ridlehoover; Clint Huffman; Edmund Wong; Ken Perilman; Larry Brader; Mark Tomlinson; Paul Williams; Pete Coupland; Rico Mariani

    My Related Posts

  • J.D. Meier's Blog

    Performance Threats

    • 4 Comments

    Rico and I have long talked about performance threats.  I finally created a view that shows how you can think of performance issues in terms of vulnerabilities, threats and countermeasures.  See Performance Frame v2

    In this case, the vulnerabilities, threats and countermeasures are purely from a technical design standpoint.  To rationalize performance against other quality attributes and against goals and constraints, you can use performance modeling and threat modeling.  To put it another way, evaluate your design trade-offs against the acceptance criteria for your usage scenarios, considering your user, system, and business goals and constraints.

  • J.D. Meier's Blog

    Blog Improvements

    • 2 Comments

    I did a few things to try and improve browsing and findability:

    I was surprised by how many of my posts related to productivity.  Then again, I focus heavily on productivity with my mentees.  I think personal productivity is an important tool for turning their great ideas, hopes, and dreams into results.  If it's not already their strength, I want to make sure it's a least not a liability. 

    On my Book Share blog, I changed themes, reorganized key features, and created a best of list.  While it may sound simple here, I actually went through quite a bit of trial and error.  I tested many, many user experience patterns and relied heavily on feedback from a trusted set of reviewers.  Although I used a satisficing strategy, I did try to make browsing the content as efficient and effective as possible.  I was surprised by how many subtle patterns and practices there are for blog layouts.  Maybe more surprising was how many anti-patterns there are.

  • J.D. Meier's Blog

    Cutting Questions

    • 5 Comments

    How do you cut to the chase?  How do you clear the air of ambiguity and get to facts?  Ask cutting questions.

    My manager, Per , doesn't ask a lot of questions.  He asks the right ones.  Here's some examples:

    • Who's on board?  Who are five customers that stand behind you?
    • Next steps?
    • What does your gut say?
    • Is it working?  Is it effective?
    • What would "x" say? (for example, what would your peers say?)
    • What's their story?
    • Where's your prioritized list of scenarios?

    As simple as it sounds, having five separate customers stand behind you is a start.  I'm in the habbit of litmus checking my path early on to see who's on board or to find the resistance.  As customers get on board, my confidence goes up.  I've also seen this cutting question work well with startups. I've asked a few startups about their five customers.  Some had great ideas, but no customers on board.  The ones that had at least five are still around. 

    At the end of any meeting, Per never fails to ask "next steps?", and the meeting quickly shifts from talk to action.

    "Is it working?" is a pretty cutting question.  It's great because it forces you to step back and reflect on your results and consider a change in approach.

  • J.D. Meier's Blog

    Vision, Mission, Values

    • 2 Comments

    There's a lot to be said for well-crafted vision and mission statements.   I've been researching and leaving a trail at The Bookshare.

    In a Nutshell

    • Mission - who are you? what do you do?
    • Vision - where do you want to go?
    • Values - what do you value? what's important? (your corporate culture)

    How Do You Craft Them

    1. You start by figuring out the values.  You figure out the values by observing how your organization prioritizes and how they spend their time.  There can be a gap between what folks say they value and what they actually do.  Actions speak louder than words.
    2. Once you know your culture and values, you can figure out your mission -- who you are and what you do.  What is your organization's unique value you bring to the table?  What is your unique strength?  In a world of survival of the fittest, this is important to know and to leverage.
    3. Now that you know who you are, you can figure out where you want to go.

    A good vision statement is a one-liner statement you can repeat in the halls.  Nobody has to memorize it.  It's easy to say and it's easy to groc.  The same goes for a mission statement.  You might need to add another line or two to your mission statement to disambiguate, but if folks don't quickly get what you do from your mission statement -- it's not working.

    How Do You Use Them

    • Use a mission statement to quickly tell others what you do.
    • Use a vision statement to inspire and rally the team.  It should be on the horizon, but achievable and believable.
    • Use a mission statement as a gauge for success. 
    • Set goals and objectives that tell you whether you're accomplishing your mission and moving toward or away from your vision.
    • Use your mission to remind you what you do (and what you don't) and to help you prioritize.
    • Craft a personal mission and vision statement to help you get clarity on what you want to accomplish.
    • Use your personal vision and mission statements to help you stay on your horse, or get back on, when you get knocked down, or lose your way.

    Examples
    I'm a fan of using reference examples (lots of them) to get a sense of what works and what doesn't.  The Man on a Mission blog is dedicated to mission statements and has plenty of real-life examples to walk through. 

  • J.D. Meier's Blog

    Daily Syncs

    • 2 Comments

    On my teams we do a daily sync meeting.  It's 10 minutes max.  We go around the team with three questions:

    1. What did you get done?
    2. What are you getting done next?
    3. Where do you need help?

    We stay out of details (that's for offline and follow-up).  It's a status meeting more on accomplishments and progress over reporting activities (lots of folks are doing lots of things, so it's crisper to focus on accomplishments.)  The more distributed the team, the more important the meeting.

    Keys to Results

    • 10 minute Timebox.  The 10 minute bar is apparently a big factor in how folks view the meeting, based on feedback from folks that have been in longer meetings (1/2 hr or more).  The 10 minute max is key because it keeps a fast pace and energy high (vs. another meeting of blah, blah, blah.)  We can always finish earlier (in fact, one of my teams was regularly finishing the meeting in under 2 minutes for a 5 person team).
    • Daily.  Daily is important.  Having them daily, means everybody can structure their day consistently.  Daily means it's also easy to build a routine and reduce friction points.  It also means that team members have a reliable forum for getting help if needed.

    The best pattern that has worked over time is ...

    • Mondays - we define the most important outcomes for the week (the few big things that matter, no laundry lists).  This is actually closer to a 1/2 hour (max) meeting.
    • Daily - we do a daily checkpoint meetings. (this is about execution, bottlenecks and awareness)
    • Fridays - we reflect on lessons learned and make any improvements to project practices.

    Another way of thinking about this is ... "if this were the end of the week, what would you feel good about having completed?"  "Each day, are we getting closer or further, or do we need to readjust priorities or expectations?" ...  "What did we learn and what can we improve?"

    My Related Posts

  • J.D. Meier's Blog

    Execution Checklists

    • 5 Comments

    Execution checklists are a simple, but effective technique for improving results.  Rather than a to do list, it's a focused checklist of steps in sequence to execute a specific task.  I use notepad to start.  I write the steps.  On each execution of the steps, by myself or a teammate, we improve the steps as we learn.  We share our execution checklists in Groove or in a Wiki.

    Key Scenarios
    There's two main scenarios:

    1. You are planning the work to execute.  In this case, you're thinking through what you have to get done.  This is great when you feel over-burdened or if you have a mind-numbing, routine task that you need to get done.  This can help you avoid task saturation and it can also help you avoid silly mistakes while you're in execution mode.
    2. You are paving a path through the execution.  In this case, you're leaving a trail of what worked.  This works great for tasks that you'll have to perform more than once or you have to share best practices across the team.   

    I encourage my teams to create execution checklists for any friction points or sticking spots we hit.  For example, if there's a tough process with lots of movable parts, we capture the steps and tune them over time as we gain proficiency.  As simple as this sounds it's very effective whether it's for a personal task, a team task, or any execution steps you want to improve. 

    One of my most valuable execution checklists is steps for rebuilding my box.  While I could rebuild my box without it, I would fumble around a bit and probably forget some key things, and potentially get reminded the hard way.

    The most recent execution checklist I made was for building the PDF for our Team Development with Visual Studio Team Foundation Server guide.  There were a lot of manual steps and there was plenty of room for error.  Each time I made a build, I baked the lessons learned into the execution checklist.  By the time I got to the successful build, there was much less room for error simply by following the checklist.

  • J.D. Meier's Blog

    New Release: patterns & practices Team Development with Team Foundation Server Guide

    • 11 Comments

    Today we release the final version of our patterns & practices: Team Development with Visual Studio Team Foundation Server.  It's our Microsoft playbook for Team Foundation Server.  It shows you how to make the most of the Team Foundation Server.  It's a compendium of proven practices, product team recommendations, and insights from the field.

    Key Changes Since Beta 1

    • We added guidelines for build, project management and reporting.
    • We added practices at a glance for build, project management, and reporting.
    • We added a chapter to summarize key Visual Studio 2008 changes.
    • We revamped our Internet access strategies.
    • We did a full sweep of the guide.
    • We completed more thorough product team reviews for key chapters.

    Contents at a Glance

    • Part I, Fundamentals
    • Part II, Source Control
    • Part III, Builds
    • Part IV, Large Project Considerations
    • Part V, Project Management
    • Part VI, Process Templates
    • Part VII, Reporting
    • Part VIII, Setting Up and Maintaining the Team Environment
    • Part IX, Visual Studio 2008 Team Foundation Server


    Chapters

    • Ch 01 – Introducing the Team Environment
    • Ch 02 – Team Foundation Server Architecture
    • Ch 03 – Structuring Projects and Solutions in Source Control
    • Ch 04 – Structuring Projects and Solutions in Team Foundation Source Control
    • Ch 05 – Defining Your Branching and Merging Strategy
    • Ch 06 – Managing Source Control Dependencies in Visual Studio Team System
    • Ch 07 – Team Build Explained
    • Ch 08 – Setting Up Continuous Integration with Team Build
    • Ch 09 – Setting Up Scheduled Builds with Team Build
    • Ch 10 – Large Project Considerations
    • Ch 11 – Project Management Explained
    • Ch 12 – Work Items Explained
    • Ch 13 – Process Templates Explained
    • Ch 14 – MSF for Agile Software Development Projects
    • Ch 15 – Reporting Explained
    • Ch 16 – Installation and Deployment
    • Ch 17 – Providing Internet Access to Team Foundation Server
    • Ch 18 – What’s New in Visual Studio 2008 Team Foundation Server

    Our Team

    Contributors and Reviewers

    • External Contributors / Reviewers: David P. Romig, Sr; Dennis Rea; Eugene Zakhareyev; Leon Langleyben; Martin Woodward; Michael Rummier; Miguel Mendoza; Mike Fourie; Quang Tran; Sarit Tamir; Tushar More; Vaughn Hughes
    • Microsoft Contributors / Reviewers:  Aaron Hallberg; Ahmed Salijee; Ajay Sudan; Ajoy Krishnamoorthy; Alan Ridlehoover; Alik Levin; Ameya Bhatawdekar; Bijan Javidi; Bill Essary; Brett Keown; Brian Harry; Brian Keller; Brian Moore; Buck Hodges; Burt Harris; Conor Morrison; David Caufield; David Lemphers; Doug Neumann; Edward Jezierski; Eric Blanchet; Eric Charran; Graham Barry; Gregg Boer; Grigori Melnik; Janet Williams Hepler; Jeff Beehler; Jose Parra; Julie MacAller; Ken Perilman; Lenny Fenster; Marc Kuperstein; Mario Rodriguez; Matthew Mitrik; Michael Puleio; Nobuyuki Akama; Paul Goring; Pete Coupland; Peter Provost; Granville (Randy) Miller; Rob Caron; Robert Horvick; Rohit Sharma; Ryley Taketa; Sajee Mathew; Siddharth Bhatia; Tom Hollander; Tom Marsh; Venky Veeraraghavan

    My Related Posts

Page 36 of 44 (1,077 items) «3435363738»