J.D. Meier's Blog

Software Engineering, Project Management, and Effectiveness

  • J.D. Meier's Blog

    Put Your Thinking Hat On

    • 1 Comments

    I'm a fan of using different techniques for improving thinking. Here's a write-up on Six Thinking Hats.  This book presents a simple and effective thinking framework.  What I like about the approach is that it's both effective for individuals as well as a team.  What I also like about the approach is that rather than focus on trying to change personalities, it creates a way for different personalities to play well together.  Imagine the time you'll save in meetings!

    Because Six Thinking Hats uses the hats as a metaphor, nobody gets a label.  Instead, the entire team can put on the relevant hat for the task at hand: white, red, black, yellow, green, or blue.  Imagine the surprises you get when the dominantly data-driven put on their green hats and get creative.  Better yet, imagine what happens when the overly optimistic put on their black hats and play the "devil's advocate"?

    What's interesting is this type of mode switching already happens.  For example, in security we use white hats and black hats.  On my team, I often ask, "what's your gut say" to tap into intuition and emotions.  If I see the team too optimisitic, I ask "why won't this work?".

    I think having a simple set of metaphorical hats and rules for the game will really help improve thinking and collaboration, and avoid the stale-mates that can often happen in meetings.  As the author puts it, you "think your way forward versus judge your way forward."

  • J.D. Meier's Blog

    Feed Readers

    • 4 Comments

    Darren asks Which Feed Reader is Best?  I was going to just add a comment, but it quickly turned into a post.

    I've used Bloglines, Google.com, Google Reader, Live.com, Newzie, OMEA Reader, and RSS Bandit.  I know I've used more that I'm forgetting.  They all have their strengths and weaknesses, so finding the right match for my scenarios is the key.  They all seem to continue to improve, so I find I also have to go back and re-evaluate from time to time.

    For the rich desktop experience, I ended up using NewzieRob pointed me to it and I know he does a lot of feed reading and he too had tried a lot of readers.  What's interesting about Newzie is its use of color-coding to flag by time.  I also like the fact that it has multiple views, including a tree view, list view, news ticker view, and a today view.

    For my "webtop" experience, I end up mostly using Live.com so I could get to my feeds from any desktop.  I created pages for different topics.  This lets me chunk up my reading experience and never get overwhelmed.  The nice thing about a page view is it's easy to scan across. 

    When I help somebody get started reading feeds, if they have a Windows Live account, then I show them how to add pages and add feeds to Live.com, since I don't think it's obvious.  If they don't have a Windows Live account, then I have them download Newzie and help them add a few posts of their favorite topic, and then show them how to swtich views.

    My Related Posts

  • J.D. Meier's Blog

    The Better Adapted You Are, the Less Adaptable You Tend To Be

    • 10 Comments

    I was skimming The Secrets of Consulting and I came across this nugget: 

    “...Many years ago, Sir Ronald Fisher noted that every biological system had to face the problem of present versus future, and that the future was always less certain than the present. To survive, a species had to do well today, but not so well that it didn’t allow for possible change tomorrow. His Fundamental Theorem of Natural Selection said that the more adapted an organism was to present conditions, the less adaptable it tended to be to unknown future conditions. We can apply the theorem to individuals, small groups of people, large organizations, organizations of people and machines, and even complex systems of machinery, and can generalize it as follows: The better adapted you are, the less adaptable you tend to be...”
    Source: Gerald M. Weinberg, The Secrets of Consulting (New York, Dorset House Publishing, 1985) pp 29-30

    Along the same lines, I was scanning Lean Software Engineering and came across this nugget:

    "... When it comes to large-scale, creative engineering, the right processes for all the various teams in an organization depends on both people and situation — both of which are constantly changing. You can’t just adopt a particular process and be done with it.  So really the only “bad process” is one that doesn’t provide framework to reflect and permission to adapt..."
    Source: Avoid Dogma When Herding Cats

    This reminded me of a quote from Hereclitus - "Nothing endures but change."

    I'm a fan of adaptability and continuous improvement.  I think adaptability is a key ingredient for effectiveness.  I always reflect on and test how adaptable is my mindset? ... my approach? ... my tools? ... my teams? ... my organization? ... my company? ... etc.

  • J.D. Meier's Blog

    ARCast.net - Defending the Application

    • 1 Comments

    Ron talks security with Alik in ARCast.net - Defending the Application.  If you want to hear some practical advice on security, listen to Alik.  He's in the field doing security every day with customers.  It doesn't get anymore real-world than that.

    The key take-away for me is the focus on proven practices.  I have a belief that focusing on a set of core practices is more effective than chasing all the variations of bad symptoms.  For example, if you adopt a practice of constraining, rejecting and sanitizing input, and you verify input for length, range, format and type, you tackle injection issues (cross-site scripting, SQL injection, SQL truncation ... etc.) at the source.

    At one point in the interview, Ron mentions that attackers share information all the time.  Unfortunately, security is a game of what you don't know can hurt you.  That's why I think community efforts and knowledge bases are a must.  I'm glad to see more information sharing in blogs.  I'm also glad to see efforts like the Open Web Application Security Project (OWASP).  It's also why I try to share as much as possible through patterns & practices security guidance, Guidance Explorer, and SecurityGuidanceShare.com.

     

  • J.D. Meier's Blog

    Per's Blogging

    • 1 Comments

    Per Vonge Nielsen is blogging! He's been my manager for several years at patterns and practices.  He's also been a mentor for myself and many others, so it's great to see him share his learnings more broadly.   Per has a way of distilling information down into the essential insights, which is a treat in today's information overloaded world.

    Enjoy Per's first post - Divide and Conquer – one step at a time.

  • J.D. Meier's Blog

    Security Guidance Share Experiment

    • 3 Comments

    SecurityGuidanceShare.com is an experiment.  I'm testing different ways to maintain and share a large body of guidance.  I'm also exploring ways to factor and maintain a comprehensive set of more stable principles and practices, while dealing with more volatile, technology-specific information.

    I'd like your feedback on

    1. Overall organization of the information (it's a massive body)
    2. Usability of the chunks (can you grab just what you need? are the chunks right-sized?)
    3. Ability to find your way around

    My two favorite features:

    1. All Pages - this let's me quickly see the knowledge base at a glance.
    2. Inspection Questions - these are factored so you can chunk up your inspections.

    Comment here or send mail to SecNet.

  • J.D. Meier's Blog

    Jason Taylor is Blogging

    • 1 Comments

    Are you experiencing anxiousness, self-doubt or guilt?  It might not be your fault.  A parasite might be controlling your mind.  Jason explains how in Mind Control and the Friendly Mouse.

    I've worked with Jason for a few years from building software to writing guidance.  He's fast and effective.  We regularly swap techniques for getting results.  He's got a gift for distilling insights into action.  He shares that gift in his blog.

    Check out Jason Taylor's blog - The Good Life, to learn:

    • How to be an effective manager
    • How to be an effective leader
    • How to prioritize tough decisions

    You can also use his blog to learn how to recover from repetitive stress injuries.

    Jason's currently working with me and Prashant on the patterns & practices Visual Studio Team System Guidance project.

  • J.D. Meier's Blog

    Incremental Environments for Performance Excellence

    • 2 Comments

    Mark Tomlinson shared an emerging industry practice with me.  Customers are setting up incremental environments.  The environments are incremental steps from a developer environment to production.
     
    Incremental Environments

    1. Component-level performance testing. (close to dev)  The lab is setup with debuggers and profilers - anything a developer would need to investigate issues.
    2. Application performance testing.  A single "slice" of architecture, good for scale-up and optimization/tuning); usually dedicated for optimization or tuning of a single application/system; still have debuggers and profilers setup.
    3. Performance integration.  This is still the basic "slice" of architecture, but now bring into play other applications or systems; usually has multiple applications and supporting technologys that mutually get loaded (e.g. IIS and AD); network diagnostic tools and debuggers may be used here sometimes.
    4. System performance and stress.  Larger performance testing with scale-out scenarios, load balancing, failover; larger sized systems get more load - so you see more stressing of entire system resources, esp. network; often just for 1 application, but also for multiple integration testing.
    5. Large-scale integration and performance.  Multiple applications, with everything needed to prove business needs will be met; usually without some security and perhaps some 3rd-party integrations; usually not a stress testing environment - e.g. virtual users are set to generate real-world pacing and load.
    6. Pre-production simulation.  This is just like the real thing - full sized system, with full security and network topology (only not production); used both for internally built applications, and 3rd-party solutions which must be integrated; production repro's, patches, fixes, etc can be tested here safely.

    There's no strict rule for how many of each type of environment, and the most sohpisticated setup has multiple physical environments/labs which could be used for any of each purpose.  The beauty of this approach is that instead of having a great big wall to throw your application over, it's a series of incremental hurdles.  Each hurdle represents increasing requirements and constraints. 
     
    This approach is also great for Centers of Excellence.  A Center of Excellence team can build the environment to reflect and codify their practices.   The Center of Excellence team can also harvest and share the lessons learned to help teams over each incremental step.

  • J.D. Meier's Blog

    Baking Performance Into the Life Cycle

    • 2 Comments

    To engineer for performance, you need to embed a performance culture in your development life cycle, and you need a methodology. When you use a methodology, you know where to start, how to proceed, and when you are finished.

    Keys to Performance Engineering
    These are fundamental concepts to performance engineering:

    • Set objectives and measure.
    • Performance modeling helps you design performance for your scenarios.
    • Measuring continues throughout the life cycle and helps you determine whether you are moving towards your objectives.

    High ROI Techniques
    These are some of the most effective techniques we use to directly impact performance results:

    • Performance Objectives
    • Performance Design Guidelines
    • Performance Modeling
    • Performance Design Inspections
    • Performance Code Inspections
    • Performance Testing
    • Performance Tuning
    • Performance Deployment Inspections

    Key Notes

    • Think about performance up front versus after the fact.  If performance isn't a part of your scenarios, you're ignoring your user's experience, or you're ignoring your businesses.  Don't expect users to ask for performance.  They just expect it.
    • Use objectives and constraints to set boundaries.  Objectives tell you how much to invest in performance and what good looks like (for users, for the system, and for the business).
    • Use Objective-driven inspections over code reviews.  Don't tune your code for tuning's sake.  Know what good looks like.  Model and measure to know where to spend your time.  (Make sure your ladder is up against the right wall!)
    • Use design guidelines to make performance actionable.  Build a repository for your performance knowledge.  Wikis are great for this.  Capture your insights as principles, patterns, guidelines, ... etc.  Don't think of this as a blanket set of rules to follow.  Think of it as a knowledge base that you and your teams can draw from when desiging solutions, doing inspections, tuning performance ... etc. 

    More Information
    You can find more about the concepts above at:

  • J.D. Meier's Blog

    Lean Software Engineering

    • 1 Comments

    I'm jazzed to see Corey and Bernie on the blog scene.  They're partners in crime on a Lean Software Engineering blog.  They have real advice for real people doing software.

    Why listen to what Corey and Bernie have to say?  They know what they're talking about from experience.  They have the knowledge that can turn your software engineering around, if you need it.  A lot of what they know, is not well known (or at least not applied), so their blog is something of a gateway to a world of better software engineering.

    Whether you shape software, build it, or manage it, you'll find insights you can use.  Here's some of the things you'll learn:

    • How do you determine the minimum deployable feature set?
    • What essential principle allows Lean development to be something more than Agile?
    • How to take an evolutionary approach to software process change?
    • Why is quality NOT the fourth variable in the project triangle?
    • How do you aggregate decentralized knowledge?
    • What happens when single-piece flow meets the V model?
  • J.D. Meier's Blog

    patterns & practices Security Engineering Explained

    • 4 Comments

    I don't think our patterns & practices Security Engineering Explained guide is very findable, so I'm blogging it.  This could very well be the short guide that forever changes how you do security engineering.  The techniques in the guide are timeless and time-tested.

    TOC

    • Chapter 1: Security Engineering Approach
    • Chapter 2: Security Objectives
    • Chapter 3: Security Design Guidelines
    • Chapter 4: Threat Modeling
    • Chapter 5: Security Architecture and Design Review
    • Chapter 6: Security Code Review
    • Chapter 7: Security Deployment Review

    It's not a complicated methodology.  Instead, it's a set of techniques that have proven to  be the most valuable. How do we know?  Customer case after customer case.

    Incremental Adoption
    The beauty of this approach is that you don't have to adopt them all at once.  You can pick and choose the technique you see fits your software life style.  Here's some examples:

    • If I was a developer, I might start with the Security Code Inspections.
    • If I was an independent security consultant, I might first master Threat Modeling or perhaps build services around Security Design Inspections or Security Code Inspections.
    • If I was an architect, I might first master Threat Modeling and Security Design Inspections, as well as how to identify security objectives.
    • If I was a dev manager, I might find an iterative and incremental way to integrate  Threat Modeling, Security Design Inspections, Security Code Inspections, and Security Deployment Inspections into my software development life cycle.
    • If I was in charge of system administration, I would adopt Security Deployment Inspections.  I would also build threat models of the network and servers that the application teams can reuse for their application or product-line threat models.

    (Sorry - we don't have a set of patterns & practices guidance on performing specific security testing techniques at this time, though I think it's important and I have done some R&D projects in this area.)

    It's worth pointing out that the security techniques baked into Visual Studio Team System use our security engineering approach.  For example, you'll find our threat modeling templates in the MSF Agile and MSF for CMMI process guidance.

    How to Get the Guidance

    Team
    Here's members of the original team that have blogs:

  • J.D. Meier's Blog

    Guidance on Managing Source Control Dependencies in Team System Now Available

    • 2 Comments

    Our Explained: Managing Source Control Dependencies in Visual Studio Team System is now available.   I've seen several questions around handling source control dependencies so hopefully this guidance will help you spiral down on solutions that work for you. This guidance  covers dealing with the following dependencies:

    • Source code and binary references
    • Web service references
    • Database references

    You can read it online or download the PDF.

  • J.D. Meier's Blog

    How To Reference Web Services and Databases During Development

    • 2 Comments

    One technique for pointing your Web services and database references to alternate locations during development is to use a user.config file.  Although you could change your app.config references directly, using a level of indirection keeps your production settings intact while carving out just the references to your Web services and database connections.

    To use this approach, you point your app.config file to a user.config file.  You then store your user.config file with production settings in source control.  Each user changes their user.config file to point to the dev or test locations, but they don't check this in.

    In .NET 1.1, you can use the approach outlined in "Managing Dependencies" from Team Development with Visual Studio .NET and Visual SourceSafe.

    In .NET 2.0, you can use configSource to redirect from your app.config to user.config.

    Referencing Web Services from WinForms
    In a WinForms application, you would do the following:
    1.  Add a Web service reference to your WinForm.  This will add an app.config file with settings for the Web service:
            <WindowsApplication1.Properties.Settings>
                <setting name="WindowsApplication1_localhost_Service" serializeAs="String">
                    <value>http://localhost:8085/WebServiceTest/Service.asmx</value>
                </setting>
            </WindowsApplication1.Properties.Settings>
    2.  Add an application configuration file and name it user.config
    3.  Delete all the text in user.config
    4.  Copy the relevent settings from your app.config to your user.config
            <WindowsApplication1.Properties.Settings>
                <setting name="WindowsApplication1_localhost_Service" serializeAs="String">
                    <value>http://localhost:8085/WebServiceTest/Service.asmx</value>
                </setting>
            </WindowsApplication1.Properties.Settings>
    Important  - Your user.config file should only the settings above.
    5.  In app.config, use configSource to redirect from app.config to user.config
            <WindowsApplication1.Properties.Settings configSource="user.config">
      <!--
                <setting name="WindowsApplication1_localhost_Service" serializeAs="String">
                    <value>http://localhost:8085/WebServiceTest/Service.asmx</value>
                </setting>
      -->
            </WindowsApplication1.Properties.Settings
    IImportant - comment out the settings, since you will now be using the settings in user.config
    6.  change the "Copy to Output Directory" property of the user.config file from "Do not copy" to "Copy if newer"

    Referencing Web Services from WebForms
    In an ASP.NET application, you would do the following:
    1.  add a Web services reference.  This would create settings in Web.config
     <appSettings>
     <add key="localhost.Service" value="http://localhost:8085/WebServiceTest/Service.asmx"/>
     </appSettings>
    2.  Add a new web.config file and rename it to user.config
    3.  Delete all the text in the user.config file.
    4.  copy appSettings from web.config to user.config
     <appSettings>
     <add key="localhost.Service" value="http://localhost:8085/WebServiceTest/Service.asmx"/>
     </appSettings>
    Important  - Your user.config file should strictly have only the settings above.
    5.  In web.config, use configSource to redirect from app.config to user.config
     <appSettings configSource="user.config">
      <!--
      <add key="localhost.Service" value="http://localhost:8085/WebServiceTest/Service.asmx"/>
      -->
     </appSettings>
    Important - comment out the settings, since you will now be using the settings in user.config

    Referencing Database Connections from WinForms
    To reference a database from a Winform application, you would do the following:
    1.  Add an application configuration file and name it app.config
    2.  Add a reference to the configuration dll (System.Configuration)
    3.  Add an application configuration and rename it to user.config file
    4.  Add your connection string in app.config
     <?xml version="1.0" encoding="utf-8" ?>
     <configuration>
      <connectionStrings>
      <add name="test" connectionString="Server=MyServer;Database=MyDatabase;Trusted_Connection=Yes" providerName="System.Data.SqlClient" />
      </connectionStrings>
     </configuration>
    5.  Test your connection string
               string connectionString = ConfigurationManager.ConnectionStrings["test"].ConnectionString;
               using (SqlConnection connection = new SqlConnection(connectionString))
                {
                    connection.Open();
               }
    6.  Copy your connectionStrings from app.config to user.config
      <connectionStrings>
      <add name="test" connectionString="Server=MyServer;Database=MyDatabase;Trusted_Connection=Yes" providerName="System.Data.SqlClient" />
      </connectionStrings>
    Important - this should be the only text in your user.config
    7.  In app.config, redirect to user.config using configSource
     <connectionStrings configSource="user.config">
      <!--
      <add name="test" connectionString="Server=MyServer;Database=MyDatabase;Trusted_Connection=Yes" providerName="System.Data.SqlClient" />
       -->
      </connectionStrings>
    Important - comment out the settings, since you will now be using the settings in user.config 
    8.  On your user.config file, change the "Copy to Output Directory" property from "Do not copy" to "Copy if newer"

    For more information, take a look at Explained: Managing Source Control Dependencies in Visual Studio Team.

  • J.D. Meier's Blog

    Team Foundation Source Control Guidelines Now Available

    • 4 Comments

    Our Team Foundation Source Control Guidelines are now available.  You can read the Team Foundation Source Control Guidelines online in HTML or you can download the Team Foundation Source Control Guidelines in PDF.  The guidelines are part of our patterns & practices Visual Studio Team System Guidance Project.  We use the guidelines to encapsulate strategies and convey recommendations.  You can quickly skim the guidelines to checkpoint your understanding of some of the proven and emerging practices for Team Foundation Source Control.  We write each guideline using a "what to do", "why" and "how" approach to help make them easy to consume. 

    Team Foundation Source Control Guidelines is complimentary to our Team Foundation Source Control Practices at a Glance and our Team Foundation Source Control Questions and Answers.

  • J.D. Meier's Blog

    Downloads Now Available for Visual Studio Team System Guidance

    • 1 Comments

    We have a Downloads Index for Visual Studio Team System Guidance in our patterns & practices Visual Studio Team System Guidance Project.  You can now download various types of guidance including our Explained, Guidelines, How Tos, Practices at a Glance, and Questions and Answers guidance modules.  While we optimized our guidance for online availability in HTML, we know many readers prefer reading PDFs.

  • J.D. Meier's Blog

    7 Habits of Highly Effective Program Managers

    • 6 Comments

    What does it take to be an effective Program Manager at Microsoft?  I'm responding to some requests for my take on what it takes to be an effective PM.  I figured I could use a familiar 7 habits approach to help frame out a start. 

    To pick a set of habits, I started with a set of reference examples.  I used the most effective and ineffective PMs that I've seen over time.  I considered their track record, their ability to influence, and their leadership skills.  Most importantly I looked at their ability to ship and make the right impact for customers.  Next, I looked for the underlying patterns (I'm a principles, practices and patterns guy).  I used the ineffective PMs to think of the anti-patterns and the practices of what not to do.  This contrast helped me clarify the distinctions between effective and ineffective.

    Here's what I found to be the 7 habits of highly effective program managers:

    • Habit 1, Frame problems and solutions.
    • Habit 2, Sell visions.
    • Habit 3, Deliver incremental value.  
    • Habit 4, Manage communication.
    • Habit 5, Connect with customers.
    • Habit 6, Execute. 
    • Habit 7, Leverage the system.

    Habit 1, Frame problems and solutions.  Frames are the things mental models, metaphors, and conceptual frameworks are made of.  Simply put, they're frames of reference.  Effective PMs create useful ways of looking at the problems and solutions.  They create shared frames of reference that help narrow and focus, while keeping perspective.  Frames help chunk up the problem or the solution.  Frames also help share information quickly as well as avoid information overflow.  The secret here is that frames provide contextual reference.  Without context, it's hard to evaluate problems or solutions.    

    Habit 2, Sell visions.  The most effective PMs dream up great ideas and they sell them.  They sell them in the hall, they sell them to co-workers, they sell them up the chain.  They have an elevator pitch that resonates.  They can paint a vivid picture of how the world will be different.  Sometimes a PM has an idea that people aren't ready for.  Sometimes a PM has an idea they just aren't selling right.  Sometimes a PM has an idea that ... well ... just isn't ready for market or planet Earth.  Selling visions involves both thought leadership and people leadership.  I think the secret here is effective PMs sell visions by answering "what's in it for you" for stakeholders and customers.

    Habit 3, Deliver incremental value.   How do effective PMs go from zero to Rome?   While the big bang can make a lot of impact, the problem is the longer they delay, the more project risk adds up over time -- visions change, people change, markets change, stakeholders change, perceptions change … etc.   Anything that isn't built in a day needs a serious chunking strategy.  The sooner they can start delivering value, the sooner they can get feedback and adapt and change.  Also, they have better chances of hitting key windows of opportunity. 

    The most effective PMs can chunk their solutions.  This is non-trivial, particularly in software.  It means knowing what the minimum shippable chunk is.  It means right-sizing their chunks so that each one delivers value for the right customers.  It means unbundling dependencies to remove unnecessary project risks.

    I think the secret of effective PMs here is thinking in terms of value rather than quantity, as well as knowing dependencies.  What can they cut and truly gain time and resources without risking quality?  Here's a true test ... if their 12 month project were cut into 6 ... or their 6 month project cut into 3 ... what would they cut and what would they deliver?  If the success of their project depends entirely on shipping everything in their plan for the full project cycle, that's a recipe for failure. 

    Habit 4, Manage communication.  This is a crucial skill since this means managing perceptions, managing expectations,  brokering knowledge, and making sure the right people are involved.   This is why some PMs fail where others succeed.  The most effective PMs make sure the right people are involved on the right problems.  They also setup forums and channels for communication.  I think there are a few secrets here.  The first secret is, they tailor the language for their audiences.  For example, for stakeholders, they know their relevant currency (time? budget? resources? business value?).  For engineers, maybe it's how does it work or why.  For customers it might be features, scenarios or value.  The second secret is, they use a variety of communication tools.  Effective PMs make use of a range of SharePoint portals, Wikis, Mind Maps, whiteboards, blogs, forums, etc.  The third secret is, they use the right mediums for the message.  Effective PMs consider whether their message is best delivered in slides, mail, meeting, phone, etc.  For example, slideware is often more effective than a long email. 

    Habit 5, Connect with customers.   This is where the rubber meets the road.   The most effective PMs have strong customer connections.  Not only do they work with customer directly, but they have a useful representation across relevant segments.  The mistakes I usually see here include the following: no customers, pretend customers, one customer size fits all, or assuming their internal scenario can be generalized to typical customer scenarios.  The secret here is that it is not the number of customers, rather it is scenario representation and trusted sounding boards with key customers.

    Habit 6, Execute.  Execution makes life easier at Microsoft.  The most effective PMs have great work breakdown structures and the right resources working on the right jobs.  I know this sounds overly simple, but there's a secret here.   I've seen work breakdown structures that are focused on activities versus outcomes.  If a PM does not have a good work breakdown structure, then that means they don't know the work to be done.  If they don't know the work to be done, then their estimates are off.  If they don't have a good work breakdown structure, then it's also easy to have the wrong people doing the wrong jobs.

    Habit 7, Leverage the system.  Effective PMs know the system they are operating in.  For example, they know their product cycle, software development life cycle, key milestones, and key events.  They also know who or what influences who.  Basically, they know how the system works.  While they could paddle down the river without a map, this map helps them anticipate the obstacles and opportunities.  The secret here is that experience alone doesn't create this map.  Anybody can start making their own map by asking questions about the system they're working in.

    While this list of habits above is not a comprehensive list, I thought it would be a good start.  I'd actually like to hear from you what you think are the habits of the most effective PMs.

  • J.D. Meier's Blog

    What's Their Story?

    • 2 Comments

    "What's their story?" ... With one cutting question, my manager exposed the fact a colleague had only one side of the story -- their own.

    We make up stories every day either to explain our own actions or the actions of others.  What happens when our stories limit us or hurt our relationships?  For example, have you ever jumped to the wrong conclusion about somebody's actions and later regreted it?  I know I have.

    What the experts do is they swap stories.  The trick is seperating fact from fiction.  First, they share the facts they know.  The more objective or verifiable the facts are, the better.  The facts help build common ground.  Next, they share their interpretation of those facts.  This is their story.  Then they ask the other person for their version of the story.

    It's a simple technique, but I'm finding swapping stories is very revealing.  Sometimes I'm surprised by my own interpretation of the facts.  Other times, I'm surprised by another person's interpretation of the facts.  Either way, I consistently find that a thoughtful response is better than an emotional reaction.

    The next time you find you just don't get somebody's behavior, before jumping to negative conclusions, ask "what's their story?"   

  • J.D. Meier's Blog

    More Effective Feed Reading

    • 6 Comments
    I want more from the information that's out there today. I want to spend less time hunting and gathering it, and more time acting on it. I want to find the information that gives me an edge. Most importantly, I want to avoid the "free shopping spree" pattern, where if I grab it all as I go, I may not get the most value for my time.

    As I talk to more feed readers, I find there's patterns that work and patterns that don't. I'm a fan of starting with examples of "what's working" and "what's not" before building a new solution. The most common anti-pattern I found was "too many feeds, not enough time." The most effective pattern I found was a set of tuned and pruned feeds.

    To fix my feeds, I used the following approach:

    1. Started with a clean slate.
    2. Figured out my objectives (what do I want to know? what would I do with the information?)
    3. Figured out my constraints (how much time and how many feeds?)
    4. Hunted and gathered for the most effective feeds.

    To wipe my slate clean, I archived what I had. I had several hundreds of feed sources. I figured I could compare later, but I wanted to start fresh and lose potential baggage.

    To figure out my objectives, I asked a simple question -- "what do I want to accomplish?" I figured listing the questions I need to answer with my feeds would be the most effective:

  • What are new ideas, insights or techniques I can use in my day to day?
  • What's going on in my immediate circle? (my stuff, friends, family, teams … etc.)
  • What are the influencers up to? (Business, tech, ... etc.)
  • What's the blogosphere and social software up to? (Technorati, Delicious, ... etc.)
  • What's going on in software engineering?
  • What new insights will change the world?
  • What's Google, Microsoft, Yahoo, IBM, and Apple doing?

    This created my map of what feeds I needed to add. I ended up surprised by how different my deliberate map was than my typical feed reading habbits. I didn't realize this until I had the map above to check against.

    Next, I figured out practical time and quantity constraints. I set a bar of 30 feeds and a max of 20 minutes reading time max for reading time. Talk about a true exercise in prioritization, considering I'm used to hundreds of feeds! I decided I want to trade lightweight and effective over exhaustive and a burden. Put it another way, I want to spend more time with the cream of the crop, and less time filtering the wheat from the chaff.

    As I hunted and gathered for feeds, I distinguish sources of news from sources of insight. I want both but I prioritize insight. I also looked for bloggers that take the time to distill information for some key areas, so that I don't have to. In some areas, I do my own distillations, in others, I want to leverage the network effect. As I hunted for feeds, I also kept the following guiding questions in mind:

  • How to minimize my time, while maximizing results?
  • How to cast a wide enough radar to see beyond what's right in front of me?
  • How to use checks/balances for the information I see?
  • How to keep a stream of information to build anticipation and foster innovation?

    This gave me a good baseline of feeds. It also put me in great shape to bring over some of my favorite feeds I had archived. It was easier to bring over just a handful of the best vs. sort and filter through everything I had.

    While this wasn't my first do-over, it was probably my most useful. I feel closer to the sources of information that I'm actually going to use, and less burdened by the noise. I'm going to test more tools and techniques for feed reading, so if you have any tips or techniques to share, I'd like to hear them.

  • J.D. Meier's Blog

    My Tag Cleanup

    • 1 Comments

    I made some changes to my tag cloud and learned some lessons along the way:

    • A few useful tags are more effective than a laundry list.
    • If I have to choose between tags too often, consolidate and eliminate.
    • If I'm not using my own tags, they aren't working.
    • If my tag cloud doesn't visually reflect some hot spots, it's broken.
    • Use search for the long tails.  Tag and browse for the big buckets.

    I removed the following tags:

    • Enterprise 2.0 (consolidated under Social Software)
    • General
    • Information Management (consolidated under Guidance Engineering)
    • Product Design (consolidated under Design)
    • Requirements (consolidated under Design)
    • User Experience
    • Work Tips (consolidated under Effectiveness and Project Management)

    I changed the following:

    • Project -> My Projects
    • Visual Studio Team System -> Team System

    I'm not satisfied with my tag set yet, but I did find some  of my old favorite posts.  There's still a few sets of posts that aren't easy enough to get to, but I'll have to think more about how to surface them.

  • J.D. Meier's Blog

    New Video: How To - Personalize Team System Guidance with Guidance Explorer

    • 10 Comments

    If you are a hunter and gatherer of guidance, you'll want Guidance Explorer.  Watch Video: How To - Personalize Team System Guidance with Guidance Explorer to see how you can use Guidance Explorer to build a custom collection of guidance from our Visual Studio Team System Guidance project.  If you haven't used Guidance Explorer before, or it's been a while, you're in for a surprise.  Seriously.

    Guidance Explorer is a free tool to help you browse, find, organize, or even create your own guidance. When you launch Guidance Explorer, it synchronizes with our online store.  For example, today's additions include a number of brand new Team System guidance items:

    My favorite Guidance Explorer features include:

    • Create collections of your favorite guidance (custom views)
    • Browse by checklists, code examples, how tos, guidelines (view by type)
    • Filter for just security, performance or Team System (Filter by technology, topic or category)
    • Share guidance among your teams (UNC share scenario)
    • Build a customized guide or whitepaper on the fly with exactly the parts you want (Save to Word, HTML or XML)
    • Create new guidance libraries and write your own personal guidance or checklists.

    Keep in mind that Guidance Explorer is actually a diamond in the rough.  It has its flaws, but it also has unique powers.  For example, I could use Guidance Explorer to inform you of brand new, emerging security practices.  I could also flag the top performance issues using the priority field.  Imagine the alternative of hunting through a whitepaper or article, instead of organized collections and lists of actionable, guidance nuggets.

    I know consultants that literally save themselves many hours per week by using Guidance Explorer as a personal knowledge base and for tailoring guidance for customers.  I also know of customers using Guidance Explorer as a light-weight and effective way to share guidance among their development teams.  It's actually the type of tool where customers surprise me what they use it for.

    While Guidance Explorer has nearly 1100 guidance nuggets at last count (across security, performance and .NET 1.1. and 2.0), you can quickly shrink the haystacks to find the needle that you need (Ed and I call this our Shrinking Haystack pattern).  You can also discover relationships among the guidance, because related items are linked.  Don't take my word for it though, test drive it for yourself.  Did I mention it's free?  Oh yeah, I should also mention it comes with source, so shape it to your heart's content.

    Go ahead and watch Video: How To - Personalize Team System Guidance with Guidance Explorer and then download Guidance Explorer.  If you do use Guidance Explorer and you have a story you'd like to share, please leave a comment in this post. 

  • J.D. Meier's Blog

    New Video: What Is - Branching

    • 1 Comments

    We just added Video: What Is - Branching to our Visual Studio Team System Guidance Project.  Watch this video to see how branching may impact your strategy when using Team Foundation Server source control.

  • J.D. Meier's Blog

    New Video: What Is - New in Team Foundation Server Source Control

    • 2 Comments

    We added Video: What Is - New in Team Foundation Server Source Control to our Visual Studio Team System Guidance Project.  Watch this video if you want a brief highlight of some of the differences between Visual Source Safe and Team Foundation Server:  It's one of our first "What Is" type videos as part of our Video-Based Guidance Experiment.

  • J.D. Meier's Blog

    New Prescriptive Guidance for Visual Studio Team System

    • 20 Comments

    Our patterns and practices team has just released new prescriptive guidance for Visual Studio Team System!

    Since my previous post we've made significant updates with the addition of the following content:

    This puts us on course to deliver on these main outcomes we have in mind for our Visual Studio Team System Guidance Project

    • The single best repository of Visual Studio Team System guidance
    • Practical and insightful scenario-based guidance for roles (PMs, developers, architects, testers ... etc.)
    • Thoroughly engineered and tested set of recommendations
    • Great entry point through videos, roadmaps, and task-based How Tos
    • Breadth and depth coverage

    Project Overview
    While Visual Studio Team System provides powerful new tools, customers are asking "where's the guidance?" ... "where do I start?" ... "how do I make the most of the tools?"  In response, our team is building a definitive Body of Guidance (BOG) for Team System. This includes How Tos, Guidelines, Practices, Q&A, video-based guidance, and more.

    We’re helping customers walk before they run, so we’re starting with the foundation.  On the code side (for developers) – this includes source control, building your dev and test environments and setting up a build process.  On the project side (for PMs) – this includes work items and reporting.  Once we have the foundation in place, we can move up the stack to making the most out of Team System for the various roles (tester, architect, developer … etc.)
     
    We're framing out the tough problems using Scenario Frames (for an example see Source Control Scenario Frame).  We then identify where we need guidance and perform solution engineering.  This involves building out reproducible customer scenarios, vetting potential solutions, and sharing the ones we can generalize enough to be broadly useful, yet still specific enough to be actionable.
     
    We're partnering with customers, product teams, support, field, MVPs, and subject matter experts.  We’re working closely with Jeff Beehler to synchronize efforts with the VSTS Rangers, such as the Branching Guidance.

    Related Posts

  • J.D. Meier's Blog

    Video-Based Guidance for Visual Studio Team System Now Available

    • 5 Comments

    As part of our Video-Based Guidance Experiment, we've released an initial set of  VSTS Guidance Videos.

    Source Control Videos

    Test drive our videos and help shape our experiment by either leaving your comments here or sending your feedback to vsguide@microsoft.com

    Enjoy!

  • J.D. Meier's Blog

    Video-Based Guidance Experiment

    • 3 Comments

    We're piloting some video-based guidance.  Here's what I want to accomplish for the videos:

    • Factor "What Is" from "How To" type videos (i.e. reference vs. action)
    • Do more, smaller videos vs. a few larger videos (modular vs. monolithic)
    • Show me how vs. just tell me how
    • Outcome-based videos (walk away with actionable insights)
    • Share strategies and approaches that sometimes don't across in just text

    For the user experience:

    • Ability to quickly browse an index of the videos
    • Ability to preview the videos inline
    • Ability to download and watch the videos at your convenience

    I'd like the videos to complement our text-based guidance modules (how tos, guidelines, checklists.)   While doing video is nothing new, I think the tough part for my team is figuring out:

    • How to balance prose-based guidance with video-based guidance
    • How to figure out the most useful videos to avoid signal to noise ratios
    • How to figure out the most effective channels and mediums

    I think a lot of our guidance can be more consumable in video form.  At the same time, I think some things aren't as useful in video.  I see video as a supplement to augment baking knowledge into plaintext (where we can efficiently search it, share it, tag it … etc.).

  • Page 37 of 43 (1,060 items) «3536373839»