J.D. Meier's Blog

Software Engineering, Project Management, and Effectiveness

  • J.D. Meier's Blog

    Three keys of a business case


    If you have to compete for resources or budget or sell an idea, one of the keys is a business case.  One way to think of a business case is "how big is the pie" and "what's your slice."  You use the business case either to argue for your project or in argument against other projects competing for the same resources and budget.

    The Three Keys of a Business Case
    Because the business case is such a critical piece of the project puzzle, I asked one of my mentors for their take on an effective business case.   Here's the keys:

    1. Problem has to be apparent .  It's apprehensible.  As a stakeholder, I can attach to it.   It's real.  I relate to the examples.  I can see it, smell it, and can relate to instances of it.
    2. Compelling benefit.  It has to be meaningful to the stakeholders (spell out what's in it for them.)
    3. Clear path to return.  How do I realize the path?  When do I start getting paid? Cut my staff by 1/2 when?  What actions happen that are specific to the stakeholders ?

    The Fourth Key
    My mentor was on a roll and added an additional key: 

    4.  Risk / reward "options."  The key is to be able to chunk down the value or the risk into an acceptable size (right-size the risk.)  For example "I like your idea, but it's too big a chunk to bite off."

    My Related Posts

  • J.D. Meier's Blog

    The Five P's


    How do you design an org?  While there's lots of approaches, one of my mentors shared the 5 Ps approach with me.  To think about the org, you need to enumerate the 5 Ps to define the organization, the type of talent you need, overall organizational competencies, culture, etc.  If you don't know what you're trying to do, you don't know who to hire.

    The Five P's
    The 5 P's are:

    1. Purpose: What problem are you trying to solve and for who? This has to be more than a mission statement.
    2. Principles: This should touch on both the culture you want to develop as well as your guiding light in how you think about the problem you're solving and tradeoffs you will need to make. This should effectively establish your decision making framework on what tradeoffs you are and are not willing to make.
    3. Priorities: Enumerate all the things that are important to you, now stack rank them to focus the organization.
    4. People: Enumerate the types of people, competencies, experiences, and roles you need to support your Purpose. Quantify how many of each type you need.
    5. Process: This defines the rhythm of your business. Do you do monthly, semi-monthly, or quarterly progress reviews? With what frequency does your "leadership team" meet to discuss issues? How frequently is your management going to check in on the organization. Note you should stay away from detailed processes like scrum vs. waterfall and other day-to-day implementation details.
  • J.D. Meier's Blog

    Framing Results


    It's one thing to get results.  It's another to articulate them.   Having a way to frame results can help both for personal learning, as well as review time when you have to reflect on accomplishments.

    Commitment, Results, How, Evidence, Analysis

    I've found framing results by listing the commitment, the results, the how, the evidence and the analysis to be pretty effective over the years.  I'm a fan of concrete examples, so here's an example:

    Architecture Reviews Results
    • MSF Agile changed their original threat modeling approach to align with our updated approach.
    • 10 DCRs submitted to product teams.
    • Security scenarios were used by STBU to focus developer security efforts.
    • Cross-product/technology guidance that addresses key customer customers.
    • Accelerated Analysis Design (AAD) Session. Held an AAD session with partners, customers and extended team to analyze and prioritize problems within the application security space, while evaluating .NET Framework 2.0.
    • Scenario Evaluations. Evaluated .NET Framework 2.0 platform, tools, and guidance in the context of application security.
    • Whiteboard Walkthroughs. Held whiteboard walkthroughs with the CLR team, ASP.NET team, MSF Agile, STBU marketing
    • Randy Miller, PM, MSF Agile. “ … we are building links into MSF to Patterns and Practice online material. Thus the activities in MSF and the patterns and practices enjoy a very complimentary relationship. The patterns and practices group continues to be very helpful and our relationship is one of very open communication. “
    • ASP.NET Team. “Your guidance cuts across a number of products and shows how to integrate them - as opposed to product group specific documents that are much more narrowly focused.” Improved confidence in Customers Ability to implement secure application improved from 4 to 7 with patterns & practices security guidance.
    • Building mental and conceptual models to frame communication was the key to effective collaboration with product teams.
  • J.D. Meier's Blog

    Iterate More, Plan Less

    I'm always on the prowl for useful insights.  Alik sent me a link to Dustin Andrew's post, Learn to Get Traction in Your Team.  I like the collection of tips, and I found myself using the phrase, iterate more, plan less a few times.  When I joined Microsoft, one of my rules was "avoid analysis paralysis."  I avoid analysis paralysis by taking action, producing results, and changing the approach as I learn.  I've learned to improve by versioning perfection over time.  I find it's easier to settle for "good enough' for now, if there's a chance to improve downstream (i.e. perfection as a journey vs. destination)
  • J.D. Meier's Blog

    How To Use Guidance Explorer to do a Security Code Inspection


    One of the key experiences you get with Guidance Explorer (GE) is support for manual security inspections.   We call them inspections versus reviews because we inspect against specific criteria.   We supply you with a starter set of inspection questions, but you can tailor them or add your own. 

    Security Code Inspection
    We use three distinct types of inspections:  design, code and deployment.  For this example, we'll use Guidance Explorer to do a security code inspection of an ASP.NET application. 

    Summary of Steps

    • Step 1. Create a new View.
    • Step 2. Add inspection questions to your view.
    • Step 3. Save your View to Word.

    Step 1. Create a new View. 
    In this step, you add a new view to My Views.  To do so, in GE, right-click, My Views, and add a new View.  You can name your View whatever you like, but for this example, I'll name mine "Security Code Inspection."

    Step 2. Add inspection questions to your view.
    In this step, you add relevant security inspection questions.    To do so, in GE, click the patterns & practices Library, next click Security, next click Security Engineering, next click Code Inspections.  Expand the ASP.NET 2.0 set of security inspection questions.

    For this example, drag and drop the questions from the following categories: Input and Data Validation, Forms Authentication, and SQL Injection.  This will give you a nice focused set of questions to drive your inspection.

    Step 3. Save your View to Word.
    In this step, you save your View as a Word doc.  To do so, right-click your view (e.g. "Security Code Inspection") and click Save Vew as ....  Name your doc (e.g. "My Security Code Inspection.doc") and click Save.

    You just built your own security code inspection set!

    Extending and Exploring
    There's a lot of exploring you can do and ways you can extend:

    • Design and Deployment Inspection: For example, you can try building a security design inspection set or a security deployment inspection set. 
    • Code Examples.  You can add code examples and link them to your inspection questions.
    • Agile Security Engineering.  If you're doing Agile development, you can scope your security inspection to a finite set of categories for a specific set of stories within the current iteration. 
    • Patterns. If you're a fan of patterns you can add pattern examples to your design inspection.  At the end of the day, do what makes sense for you and your team to more effectively build software and meet your security objectives.

    Share Your Stories
    I'm sure you're bound to have stories.   If you haven't done security code inspections before, you're in for a treat.  Security Code Inspections are a proven practice.   While the criteria and context may vary, the technique pretty much remains the same.  Share your stories either in this post or send email to getool@microsoft.com.

    My Related Posts

  • J.D. Meier's Blog

    New Release: Guidance Explorer is Now on MSDN


    This is a significant release for Guidance Explorer (GE).  Our online "guidance store" is now hosted on MSDN.  To take advantage of this, you need to download the new version of Guidance Explorer (release 20071206)

    What Is the Guidance Store
    Our guidance store is a catalog of reusable guidance nuggets for helping you build applications.  The catalog is organized by the following:

    • Types (e.g. principles, patterns, practices, guidelines, checklists, how tos, Q&A, app scenarios, code examples ... etc.)
    • Topics (e.g. security, performance., project management, reporting, build, ... etc.)
    • Technologies (e.g. .NET Framework, ADO.NET, ASP.NET, XML, SQL Server, Visual Studio Team System, Web Services ... etc.)
    • Techniques (e.g. security inspection, performance inspection, threat modeling, performance testing ... etc.)

    At a high-level, you can think of the catalog as a collection of application scenarios, "building codes" and engineering practices.

    What is Guidance Explorer
    Guidance Explorer is a smart client application that talks to the Guidance Store over a Web service.  You can use GE to create, organize and share your favorite guidance nuggets.

    Key Usage Scenarios
    The key usage scenarios are:

    • Find relevant patterns & practices guidance.
    • Build customized checklists for your development scenarios.
    • Build customized guidelines for your development scenarios.
    • You can build custom sets of guidance and share with your team as recommended practice.

    To put it another way, you can use GE to slice and dice the patterns & practices catalog, tailor the guidance, or build your own guidance. 

    What's New in the Latest Release
    What you can expect in Guidance Explorer version 20071206:

    • MSDN now hosts the guidance store (the guidance catalog is now hosted in MSDN labs)
    • Improved catalog of guidance (it's more than 3,000 nuggets)
    • Improved general usability, reliability, performance, and security
    • Improved view structures in My Views and the patterns & practices Library
    • Improved authoring/editing experience (tweaked the UI to feel better, improved reliability, fixed copy+paste from Word and added image support)
    • Improved pushing down guidance types (if we do a new guidance type, you’ll get it now)
    • Improved pushing down new views (if we change our views, you’ll get them)
    • Improved deploying guidance stores (if you are a hosting your own guidance store, you can deploy it more reliably)

    How's that for guidance as a service?  (Personally, I think the next step is relevant guidance feeds for guidance mash up scenarios.)

    Getting Started

    1. Download Guidance Explorer.
    2. Unzip to a directory.
    3. Run the .EXE file from the \bin file.

    When you run GE the first time, let it synch for about 10 minutes.  It's downloading more than 3,000 items from our catalog.

    Test Driving Guidance Explorer
    Here's a few of the first things to try

    1. Build your own playlist of guidance (create a new view under My Views and then drag your favorite guidance nuggets into it.)
    2. Build your own guide on the fly (create a view of your favorite nuggets and save the view to a Word doc.)
    3. Tailor an existing guidance nugget (double-click an item, click Edit, make your modifications then save to My Library.)
    4. Write your own guidance (right-click My Library and add a new Item.)
    5. Create a new focused library (right-click Libraries, click New Library, name your library then add some new items.)

    Key Links

  • J.D. Meier's Blog

    Outlook Reminder for Leadership Practices


    I created a recurring appointment in Outlook for Fridays.  It's a checklist of key leadership practices from The Leadership Challenge.  Each Friday, I scan this checklist and reflect on how well I've demonstrated the practices and where I need to tune for the upcoming week. 

    Leadership Checklist 


    • Sets a personal example of what to expect?
    • Makes certain that people adhere to agreed-on standards?
    • Follows through on promises and commitments?
    • Asks for feedback on how actions affect people's performance?
    • Builds consensus around organization's values?
    • Is clear about philosophy of leadership?


    • Talks about future trends influencing work?
    • Describes a compelling image of the future?
    • Appeals to others to share a dream of the future?
    • Shows others how their interests can be realized?
    • Paints "big picture" of group aspirations?
    • Shows conviction about meaning of work?


    • Seeks challenging opportunities to test skills?
    • Challenges people to try new approaches?
    • Searches outside organization for innovative ways to improve?
    • Asks "What can we learn?"
    • Makes certain that goals, plans, and milestones are set?
    • Experiments and takes risks?


    • Develops cooperative relationships?
    • Actively listens to diverse points of view?
    • Treats people with dignity and respect?
    • Supports decisions other people make?
    • Gives people choice about how to do their work?
    • Ensures that people grow in their jobs?


    • Praises people for a job well done?
    • Expresses confidence in people's abilities?.
    • Creatively rewards people for their contributions?
    • Recognizes people for commitment to shared values?
    • Finds ways to celebrate accomplishments?
    •  Gives team members appreciation and support?



  • J.D. Meier's Blog

    Now on Amazon: Performance Testing Guidance for Web Applications


    Our patterns & practices Performance Testing Guidance for Web Applications book is now available on Amazon.

  • J.D. Meier's Blog

    Now on Amazon: Team Development with Visual Studio Team Foundation Server


    Our patterns & practices Team Development with Visual Studio Team Foundation Server book is now available on Amazon.

  • J.D. Meier's Blog

    Videos: Security, Performance Testing, and Visual Studio Team System


    We posted our ASP.NET 2.0 security videos, performance testing videos, and Visual Studio Team System videos to the MSDN library.

    Video Index

    ASP.NET 2.0 Security Videos
    Keith Brown explains the mechanics behind some common input and data validation security issues and how to address them.

    Performance Testing Videos
    Scott Barber explains the big picture for how to approach performance testing as well as how to do workload modeling and performance reporting.

    Visual Studio Team System Videos
    Our team takes you through key source control concepts in Team Foundation Server.

    I hope we produce more videos in the coming months.  I particularly like factoring "explained" videos from the "how to" videos and keeping the videos short and focused.  I think we have more work to do here, but I think we've learned key lessons each time we've done a batch of videos.

  • J.D. Meier's Blog

    TFS Guide: A Top Download on CodePlex


    It was a nice surprise to see that yesterday our patterns & practices Visual Studio Team Foundation Server Guide was among the top downloads on CodePlex.


    The HMTL version of the guide is available on MSDN at http://msdn2.microsoft.com/en-us/library/bb668991.aspx.

     My Related Posts

  • J.D. Meier's Blog

    Pattern-based Leadership vs. Fact-Based Management


    I found an interesting article about contextual decision making.  "A Leader's Framework for Decision Making," an article in Harvard Business Review, is about tailoring your decision making approach based on the context.  You can use the Cynefin Framework to figure out which context you're operating in, so you can choose the most effective response.  The key is whether to categorize, analyze, probe or act.

    Context's Characteristics
    The Cynefin Framework includes five context types:

    • Simple - Repeating patterns and consistent events; Clear cause-and-effect relationships evident to everyone; right answer exists; Known knowns
    • Complicated - Expert diagnosis required; Cause-and-effect relationship discoverable but not immediately apparent to everyone; more than one right answer possible; Known unknowns
    • Complex  - Flux and unpredictability; No right answers; emergent instructive patterns; Unknown unknowns; Many competing ideas; A need for creative and innovative approaches
    • Chaotic - High turbulence; No clear cause-and-effect relationships, so no point in looking for right answers; Unknowables; Many decisions to make and no time to think; High tensions
    • Disorder - This context is particularly difficult to recognize because of multiple, competing perspectives.  The recommendation is to break it down into its constituent parts and assign it to one of the other four realms.

    Fact-based Management
    Simple and complicated are part of the ordered world.  How to respond as a leader in simple and complicated scenarios:

    • Simple - (The Domain of Best Practices) - Sense, categorize, respond; Ensure proper processes are in place; Delegate; Use best practices; Communicate in clear, direct ways; Understand that extensive interactive communication may not be necessary.
    • Complicated - (The Domain of Experts)  - Sense, analyze, respond; Create panels of experts; Listen to conflicting advice.

    Pattern-based Leadership
    Complex and chaotic are part of the unordered world.  How to respond as a leader in complex and chaotic scenarios:

    • Complex - (The Domain of Emergence) - Probe, sense, respond;  Create environments and experiments that allow patterns to emerge.  Increase levels of interaction and communication.  Use methods that can help generate ideas; Open up discussion: set barriers; stimulate attractors; encourage dissent and diversity; and manage starting conditions and monitor for emergence.
    • Chaotic - (The Domain of Rapid Response) - Act, sense, respond;  Look for what works instead of seeking right answers; Take immediate action to reestablish order (command and control); Provide clear, direct communication.
  • J.D. Meier's Blog

    Harvard Business Review and The Economist


    I'm always on the prowl for sources of profound insight.  At my leadership workshop last week, I noticed the instructor had a wealth of practical insights and distinctions that aren't common knowledge.  I asked him his favorite sources of information and he listed two:

    I was surprised because I had never read either before (the titles weren't appealing to me.)  I picked them up this week and it looks like they're packed with lessons learned and news I can use.  I think of The Economist as sharing business and organizational practices.  I think of Harvard Business Review as personal development applied to the workplace.  Here's a sample of some of the titles from this month's Harvard Business Review:

    • "A Leader's Framework for Decision Making"
    • "Solve the Succession Crisis by Growing Inside-Outside Leaders"
    • "Eight Ways to Build Collaborative Teams"
    • "Mapping Your competitive Position"
    • "Cognitive Fitness"
    • "Simple Rules for Making Alliances Work"
    • "Are Your Engineers Talking to One Another When They Should?"
  • J.D. Meier's Blog

    Patterns vs. Tooling


    I'm a fan of patterns.  I think of patterns simply as problem and solution pairs.  I wandered by The Hogg Blog and noticed Jason's post on The Great Debate: Patterns vs Tooling.  Since patterns and tooling both have their place, I think there's less of a debate and more of a gap between state of the art and state of the practice.

    Why Patterns
    I think patterns are an efficient way to share insights.  Consolidating 100's of words down into a few is pretty powerful.  A pattern language is a great way to map out the terrain of a domain.  I think of the pattern language as a constellation of meaningful nuggets.  I think the most insighful nuggets are the ones that help you with the toughest forks in the road.

    Patterns in Practice
    While working on our security and performance guidance, our team was able to rapidly solve and share end-to-end solutions for incredibly complex application scenarios.  As we worked through customer scenarios, we would pattern match against our deployment patterns and application infrastructure patterns.  To put this in perspective, I remember a customer that had been prototyping a solution for six months, that we solved in ~3 hours because we had a collection of patterns to draw from.  We got to a vantage point where we could solve some of the toughest architetural issues for customers in a few minutes.  Looking back, I wish we had a more agile way for sharing our learnings with more customers, and I think patterns and pattern languages could have been part of the answer.

    Key Usage Scenarios
    There's lots of uses for patterns, but here's some examples:

    • Building vocabulary.  A lot of light bulbs went off for me when Ward pointed out that patterns help build a shared vocabulary.  It's a way to talk about our craft and to hand knowledge down from one generation to the next.
    • Sharing solutions.  This is what patterns do best.
    • Encapsulating principles.   It's one thing to talk about a bunch of underlying principles.  It's another to have a nicely named pattern.

    Key Issues with Patterns
    Here's some of the issues I've run into with some patterns and repositories over the years:

    • Problems solved.  I don't tend to see enough patterns around the more interesting, engineering problems where patterns are worth the effort.  I think quality attributes are great candidates for patterns (security patterns, performance patterns, reliability patterns, flexibility patterns ... etc.)
    • Locked in print or teasers to more.  A lot of the most insightful patterns are locked in print.  It makes it tough to share, particularly when we don't all have the same bookshelf.
    • Bad organization.  I've seen only a handful of pattern libraries that impress me.  I'm not saying they don't exist, but that I haven't seen a lot I like.
    • Relevancy.  I think one of the biggest issues is just finding relevant patterns for your problem at hand.  No matter how well a library of patterns is organized, it still helps to have a shepherd.  Web 2.0 can help here.
    • Bad templates.  Sometimes the structure of information is as important as the information.
    • Bloat.  Blah, blah, blah.  I'm not a fan of verbosity when I need to get my job done.  I've seen some patterns that were more complicated than the solution they were describing. 
    • Vocabulary.  While patterns can help build a shared vocabulary, it can be tough in the beginning, like learning yet another vocabulary.  Convergence takes time.
    • Silos and pockets of insight.  I don't think patterns are as prevalent as they could or should be.  I find a lot of the best nuggets are spread a great deal over time and space.
    • From concept to code can be a big jump.  Sometimes you can't get there from here, or it'a a painful process.  I think this is very much a tooling opportunity.
    • Silly or make-believe patterns.  I've come across a lot of patterns that seem to be patterns for the sake of patterns.  Ward always told me that the best patterns tell you something you didn't expect or that surprised you.
    • Lack of anti-patterns.  I actually think there's not enough anti-patterns.  While there's more than one way to solve a problem, sometimes there's a few places you really shouldn't go, and that's where anti-patterns fit in.   Some of the best security insights are documented as anti-patterns.

    Key Opportunities for Patterns
    I think there's more opportunity than ever for building better pattern libraries and leveraging social software scnearios and tooling opportunities.  Here's some examples:

    • Guidance Explorer.   Guidance Exploer lets you easily cross-link patterns or link them to other items.  For example, imagine a pattern that links to a code example or a how to or a set of guidelines and checklists.  We've also played with the idea of showing patterns as mind maps so you can see the related patterns.  Guidance Explorer can also help solve the relevancy issue, by providing more fine-grained organization, as well as make it easy to build a collection of the ones you want.  All we have to do is fill up our pattern node with a critical mass of more useful patterns.
    • Web 2.0.  I think Yahoo Design Patterns is a good example.
    • Tooling support.  I'd like to see more drag+droppable patterns and pattern-based modeling going forward.

    My Favorite Pattern Guides
    Here's a few of the pattern guides I've found to be useful:

  • J.D. Meier's Blog

    Human Shepherds and the Law of Relevancy


    Yesterday, Ed helped me word a "law" that I use for important decisions and that I see show up quite a bit in a number of places.  It's the law of human relevancy.

    The Law of Relevancy
    No matter how relevant the information is, it's more relevant with the help of the right people.

    The Human Shepherd
    All this law really means is that no matter how well you organize and display information, at some point, there's a glass ceiling on how much easier you can make it for somebody to find what they need.  There's always a place for the human shepherd.

    Usage / Examples

    • The obvious example is the Web 2.0 movement -- where people are the shepherds of the read/write Web.  There's lots of needles in the world wide haystack and I'm glad there's people, voices, blogs there to help.
    • I like the pattern on the Web where sites have a live chat to use a human to help you match their info to your needs, in real time.
    • I like how Second Life provides the ability to "invoke a human" over just self-help and forums. (I proposed some models for "human help" in Visual Studio and as a general platform some time back I need to revisit)
    • There's lots of implications for an Enterprise 2.0 world, but I'll save that for another day.

    A Story
    In an early version of Practices Checker (a tool meant to verify your solutions against patterns & practices recommendations), we tried to figure out relevant guidance based on the type of project (Web, winForm ...), what technologies (ADO.NET, ASMX ...) you were using, ... etc.  We did this automatically and generated what I considered more harm than help (it missed things that were important and created a lot of noise.)  I applied the law of relevancy and argued that we'd be better off figuring out how to leverage the user's own relevancy engine and pattern-matching ability over auto-magic guesswork.  We then created a tool to help smart people, rather than a "smart" tool that gets in the way.

  • J.D. Meier's Blog

    How To Build Your Own Guide with Guidance Explorer


    You can build your own guide using Guidance Explorer.  Guidance Explorer is a front-end browser optimized for our patterns & practices guidance store.  Here's some of the usage scenarios:

    • Build a guide of your favorite patterns & practices items.
    • Build a custom set of guidelines for your team.
    • Build a custom checklist for a security or performance inspection.
    • Build a customized guide for your customer.

    Summary of Steps

    • Step 1.  Create a new view.
    • Step 2.  Add items to your view.
    • Step 3.  Save your view as a Word doc.

    Step 1.  Create a new view.
    To create a new view, right-click My Views and click New View.   Name your view.

    Step 2.  Add items to your view.
    For this example, select some items from the patterns & practices library node and drag and drop them into your view.  Note that you can edit the items.  Just double-click to bring up the item, then click Edit.  Once you are happy with your changes then you can save to your read write libraries (such as My Library.)  You can also create new items.  For example, right-click My Library and click New Item.  You can then add your new item to your View by dragging and dropping.

    Step 3.  Save your view as a Word doc.
    Once you are happy with items in your view, right-click the view and save it as a Word doc.  Note that you can also choose to save it as HTML.

    Voila!  You now have your very own, custom guide.

    My Related Posts

  • J.D. Meier's Blog

    Now on MSDN: patterns & practices Performance Testing Guidance for Web Applications


    You can now find our patterns & practices Performance Testing Guidance for Web Applications on MSDN in HTML.  It's the same guidance we hosted on CodePlex.  CodePlex was our channel for agile release of the guidance.  Once we baked the guidance, we ported it to MSDN.

    Contents at a Glance
    Here's the


    You can download the patterns & practices Performance Testing Guidance for Web Applications from CodePlex.

    Guidance Explorer Scenario
    If you want to tailor the guidance for your scenario, you can download Guidance Explorer from CodePlex.  Using Guidance Explorer, you can create custom views by dragging and dropping the relevant guidance and then tailoring it as you see fit.  You can then save your view or an item to Word or HTML

  • J.D. Meier's Blog

    Performance Testing Videos Posted to CodePlex


    Today we posted our Performance Testing Videos to CodePlex.  They're a companion set for our patterns & practices Performance Testing Guidance for Web Applications.

    Video Index
    Here's a list of the videos: 

    Additional Resources

  • J.D. Meier's Blog

    Now on MSDN: patterns & practices Team Development with Visual Studio Team Foundation Server Guide


    You can now find our patterns & practices Team Development with Visual Studio Team Foundation Server guide on MSDN in HTML.  It's the same guidance we hosted on CodePlex.  CodePlex was our channel for agile release.  Once we baked the guidance, we ported to MSDN.  For some customers, MSDN is a trusted source, so being on MSDN is important.  Additionally, MSDN provides some additional hooks and channels.

    Contents At a Glance
    Here's the guide at a glance



    Practices at a Glance

    Questions and Answers

    How Tos

    You can download the Team Development with Visual Studio Team Foundation Server Guide from CodePlex.

    Guidance Explorer Scenario
    If you want to tailor the guidance for your scenario, you can download Guidance Explorer from CodePlex.  Using Guidance Explorer, you can create custom views by dragging and dropping the relevant guidance and then tailoring it as you see fit.  You can then save your view or an item to Word or HTML. 

  • J.D. Meier's Blog

    TGIF (10/26/07)


    I happened to glance at the MSFT stock.  I took a snapshot because I thought it was make believe.  Either way, it made me smile.


  • J.D. Meier's Blog

    Results-Focused Teams Over Role-Focused Teams


    In my experience, talent and passion are the keys to effective teams.  It's not better defined roles.  In PM Tip#14: Great teams have members that defy roles, Brad Abrams writes that the best teams defy traditional roles and responsibilities, and I agree.

    When role issues show up, it's usually a sign there's other problems.  Here's common problems:

    • You're missing a critical role.  In sports it's more obvious.  You wouldn't start a baseball game without a pitcher.  On a project team, where the work isn't well understood, it might not be obvious you're missing an important role, but symptoms show up over time.
    • The open work isn't obvious.  If the team isn't sure what to do next or who's doing what, it leads to problems.
    • There's too much stepping on toes.  There's probably just not enough teaming or communication.
    • The work is unevenly distributed
    • Somebody is out of their comfort zone.
    • There's a mismatch in talent for the task.
    • There's a mismatch in passion for the task. 
    • There's a lack of clarity around what good looks like.  You might think you did your job, but somebody else thinks you only did half of it.
    • There's a mismatch in values.  If you want to knock the ball out of the park, while somebody else wants to just punch the clock, you'll have role issues.

    Carving out roles to help orient the team is one thing (who's on first, who's on second ... etc.)  Carving out roles to act as contracts is another.  I'd rather work on teams where the focus is on collaboration and results over contract negotiation. 

    Here's a few keys that help with a results focus:

    • Build a shared vision of the end in mind.  If the team can't see the finish line, there's no way they can race there.  
    • Know the work to be done.  Granted this is a continuously unfolding process.  At the same time, you don't want to go off to Antartica without the right skills on board.  If you know the work to be done, you can get the right people on the team.  If you know the work to be done, people are generally more willing to sign up.    
    • Match talent to the task.
    • Match passion to the task.  Passion is the key to productivity.
    • Stay adaptable.  Adaptable teams survive and thrive, where rigid teams fail.
    • Pair up in complimentary ways.  For example, pair a dev with a tester to swap perspectives.  Pair a strong thinker with a strong doer.  Pairing up is a great way to keep momemtum and share learnings.  It's also a way to help avoid stepping on toes   

    At the end of the day, I push for results-focused teams over role-focused teams, but it's probably because I'm a fan of getting results.

  • J.D. Meier's Blog

    How To Use Time Boxing for Getting Results


    Time boxing is a way to chunk up time and get results.  If you continously miss windows of opportunity or spend all of your time in one area of your life at the expense of others, time boxing can be one of your best tools.   A time box is simply a limited set of time to accomplish a result.  Think of it as how much work can you get done in a given block of time.  I use it to organize my day, drive project results, make incremental progress on problems and spend time on the right buckets in my life.

    Why Use Time Boxing
    Using time as a constraint and forcing function for results is extremely effective:

    • Avoid missing windows of opportunity.  Time's a limited resource.  If you don't treat it this way, you end up blowing project schedules, missing windows of opportunity, or doing too little, too late.
    • Spread your results across key areas.   If you spend all of your time in one area of your life at the expense of another, you can use time boxes to allocate time for important areas (such as career, mind, body, social, spiritual ... etc.)
    • Prioritize more effectively.  If you know you only have three months for that project, you can be smarter about what you bite off that you can actually finish.
    • Chunk up a problem.  Use time boxes to slice a problem down to size.  This works well if you have a daunting problem that seems too big to take on.  Timeboxes are also a more realistic way to deal with problems that spread over time.  If you can't solve a problem in a single session, then figure out the right-size time chunks to throw at the problem.  How do you eat an Elephant?  One timebox at at time ;)
    • Deliver incremental results.   You can use a time box to show progressive results.  For example, rather than all-or-nothing thinking, use time boxing to make incremental progress on a problem. 
    • Increase focus.  Giving yourself dedicated time boxes to focus on a problem help you avoid task switching, and help you stay engaged on the problem.  If you find yourself wandering too much, then chunk your timebox down even further. See
    • Increase motivation.  Make a game of it.  For example, how many sit ups can you do in 60 seconds?  Between splitting problems down to size, staying engaged on the problem and making a game of it, time boxing is a sure-fire way to build momentum and results.
    • Improve your effectiveness and efficiency.  use time boxing to tune your results.  Using a time box can help you identify areas to improve as well as refine your approach.  If you're not getting enough done within your timebox, experiment with different approaches, while you tune your effectiveness and efficiency.
    • Version your results.  It can be very liberating if you think in terms of revisiting a problem over a period of time, versus trying to get it all right up front.
    • Defeat analysis paralysis.  Analysis paralysis can be the worst enemy of results.  Use a time box to switch gears from think mode to execution.

    Summary of Steps
    Here's some prescriptive guidance for creating and using time boxes effectively:

    • Step 1.  Identify candidate areas for time boxing.
    • Step 2.  Identify your objectives.
    • Step 3.  Identify the appropriate time box. 
    • Step 4.  Execute results within your time box.
    • Step 5.  Evaluate and adapt. 

    Step 1. Identify candidate areas for time boxing.
    Identify candidates for time boxing.  This could be anything from work projects to personal projects.  Personally, I've found it the most effective to start with something small, such as starting a new exercise program.  I've also found it effective to use it to tackle my worst time bandits (any area where I lose a bunch of time, with either little ROI or at the expense of another area.)

    Step 2.  Identify your objectives.
    In this step, ask yourself what you need to accomplish with time boxing.  Examples include:

    • Meet a deadline.
    • Show incremental results.
    • Make incremental progress on a tough problem.
    • Build momentum.

    Step 3.  Identify the appropriate time box.
    In this step, figure out what a right-sized time box would be.  For example, you might have a project due in three weeks.  Within that three week time box, you might decide that if you allocate 2 hours a day, you'll produce effective results.

    The right-sized time box largely depends on what you determined in Step 1.  You might need to grow or shrink your time box depending on whether you're trying to build momentum, show results or just make progress on a problem.
    Step 4.  Execute results within your time box.
    Execute within your timebox and stop when you run out of time.  This can be tough at first because you might be on a roll.  This can be really tough if you are used to doing things until they are done.  What you're learning at this step is how to stay completely focused, how to treat time as a limited resource, and how to tune your results.  You're also learning how to make time boxes effective for you. 

    Start with your time box as a baseline so you can evaluate your results.  The worst mistake is to give yourself an hour for results, spend two hours, and then say what a great job you did in your one hour timebox.  Instead, do the hour, then figure out whether you need longer time boxes or if your approach needs to change.
    Step 5.  Evaluate and adapt.
    If it's not working, change your approach.   Using time boxing is one of the most effective ways to experiment with different techniques to find the most efficient.

    Examples of Effective Timeboxing
    Here's some examples of putting timeboxes into practice:

    • Software development.  Because our teams within patterns & practices do iterative and incremental development, we make heavy use of time boxing.  For example, within a two-week iteration, how much value can we deliver?
    • Feed reading.  Give yourself a 10 minute window and see how many useful feeds you can read.  See how you tune your feed reading skills, including choice of reader, how you prioritize, and how you choose posts to read, as well as what links to follow.  You might choose to factor your exploratory, pleasure feed reading from your personal and professional development feed reading.
    • Email.  Use time to help you outsmart your inbox.  For example, if you allocate 30 minutes for your email, but you're falling behind, instead of throwing more time at the problem, experiment with different approaches.
    • Time bandits.  Set limits on how much time you'll throw at your worst time sinks.  For example, do you spend too much time in meetings?  Do you spend too much time stuck in analysis paralysis and not enough time in execution?  Tackle your time-bandits with some hard limits.    

    Additional Resources

    My Related Posts

  • J.D. Meier's Blog

    Actions, Insights and Notes


    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


    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.

    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.)

    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
          string MyOperation1(string myValue1);
          string MyOperation2(DataContract1 dataContractValue);
          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();
    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


    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

Page 35 of 43 (1,074 items) «3334353637»