J.D. Meier's Blog

Software Engineering, Project Management, and Effectiveness

October, 2010

  • J.D. Meier's Blog

    Getting Results the Agile Way is Now Available in Print



    You can now buy the printed version of Getting Results the Agile Way on Amazon.   The PDF and Kindle versions should be available within the next few weeks.  You can read the book free in HTML at http://GettingResults.com   I know many people have been waiting for the printed version so I figured I should announce that the paperback is now available.

    Who’s it for? … So far, it seems like anybody who wants more from life.  I’ve had requests from restaurant owners to people in the financial industry, to doctors, lawyers, marketers, teachers … you name it.  I know some consulting firms that have been waiting for the book.   If you happen to be a software developer or a project manager, this book will find a special place in your heart.

    It’s a timeless system for the changing times.  Getting Results the Agile Way is a personal results system for work and life.   The best way I can put it is, it helps you be the author of your life and write your story forward.   It’s a simple system for meaningful results that helps you get faster, simpler, and better results.  You achieve this by working on the right things, at the right time, the right way, with the right energy to get your best results.  Basically, it’s a system that can support you in everything you do.  It’s based on principles and patterns so you can tailor it for yourself or for any situation.

    Contents at a Glance

    • Foreword
    • A Word from the Author
    • Introduction
    • Chapter 1 - Why Agile Results
    • Chapter 2 - Agile Results Overview
    • Chapter 3 - Values, Principles, and Practices
    • Chapter 4 - Hot Spots
    • Chapter 5 - Monday Vision, Daily Outcomes, and Friday Reflection
    • Chapter 6 - Design Your Day
    • Chapter 7 - Design Your Week
    • Chapter 8 - Design Your Month
    • Chapter 9 - Design Your Year
    • Chapter 10 - Results Frame, Personas, and Pitfalls
    • Chapter 11 - 25 Keys to Results
    • Chapter 12 - 25 Strategies for Results
    • Chapter 13 – Motivation
    • Chapter 14 - Mindsets and Metaphors

    I got the proofs of the book earlier this week and I was surprised how good the book feels.  It feels like a little handbook or a playbook.  It’s a thin guide -- about 1/2 an inch.   It’s 6x9 inches so it’s about the size of some of John Maxwell’s handbooks.  The cover is a brilliant blue with puzzle pieces coming together.   I wanted to have at least ten folks hold the book and take it for a test drive before announcing the book is available.  Last night, when the hostess at a local restaurant instantly fell in love with the book, it was the final test.  She said the blue made her feel calm, the print was easy to read, and as she flipped through, she said each page made her think and inspired her.  I felt bad I couldn’t let her keep the copy, but I promised her a copy next week.

    Contributors / Reviewers
    The book has quite a list of acknowledgements:

    Adam Grocholski, Alik Levin, Andrew Kazyrevich, Andy Eunson, Andrea Fox, Anutthara Bharadwaj, Brian Maslowski, Chaitanya Bijwe, Chenelle Bremont, Daniel Rubiolo Mendoza, David K. Stewart, David Wright, David Zinger, Dennis Groves, Don Willits, Donald Latumahina, Dr. Rick Kirschner, Eduardo Jezierski, Eileen Meier, Erin M. Karp, Ethan Zaghmut, Gloria Campbell, Gordon Meier, Janine de Nysschen, Jason Taylor, Jeremy Bostron, Jill Heron, Jimmy May, John Allen, John deVadoss, Julian Gonzalez, Juliet du Preez, Kevin Lam, Larry Brader, Loren Kohnfelder, Mark Curphey, Michael Kropp, Michael Stiefel, Mike de Libero, Mike Torres, Mohammad Al-Sabt, Molly Clark, Olivier Fontana, Patrick Lanfear, Paul Enfield, Per Vonge Nielsen, Peter Larsson, Phil Huang, Prashant Bansode, Praveen Rangarajan, Richard Diver, Rob Boucher Jr., Rohit Sharma, Rudolph Araujo, Samantha Sieverling, Sameer Tarey, Scott Hanselman, Scott Stabbert, Scott Young, Sean Platt, Srinath Vasireddy, Tom Draper, Vidya Vrat Agarwal, Wade Mascia

    … and of course, many thanks to my loyal readers of my blog, Sources of Insight (http://sourcesofinsight.com/), for their helpful feedback.

    If you want to get a good sense for what drove the book, I encourage you to read A Word from the Author.  It’s the story in a nutshell.

    Some folks inside and outside Microsoft have been telling me the system gives them the advantage they’ve been looking for, and helps them make meaning and find purpose and motivation in the things they do.  That’s what I like to hear!

  • J.D. Meier's Blog

    Developer Guidance IA at a Glance


    The Information Architecture (“IA”) for Microsoft Developer Guidance is a work in progress.  You can see a living instance of the IA at Microsoft Developer Guidance Maps

    The purpose of the IA is to simplify and improve the effectiveness of content for Microsoft developer guidance.  Rather than create more prescriptive guidance, our management team wants me to scale by baking what I’ve learned from building Microsoft Blue Books and platform playbooks into an Information Architecture that improves our overall content effectiveness for our developer platform.  This means having me work at the “meta” level to frame out the information architecture for our content and our platform technologies.

    The IA work that I’m primarily focused on is about figuring out the most effective content types, schemas, and the relationships among the content types.  It’s also about figuring out technology “information models”, domain models, feature sets/capability maps, and  key relationships among the technologies.  As you can imagine, mapping out the content story, the Microsoft application platform story, customer scenarios, and finding a way to blend and integrate these multiple dimensions is a bit of a challenge.  The payoffs can be big though.  On the producer side, the potential upside is we improve our portfolio of content, while improving our processes for content, as well as improving the efficiency and effectiveness of our content.  On the user side, the potential upside is that it gets easier to find and browse the information you need, in a simplified, contextual, and consumable  way.

    A Simple View of the IA …
    Here is a simple view of how I think of an IA for Developer Guidance at a top level …


    It consists of three key parts:

    1. App / Solution Hubs.  One way to up-level information for technologies is to group the information by scenarios or solutions.  For example, when you can look at the Microsoft application platform, you can think of it in terms of platform, tools, and process (i.e. the .NET Framework, Visual Studio, and ALM for example.)  You can imagine creating a “solution” hub for each area.  You can also imagine grouping information by application types or deployment targets.  This is a loose categorization but you can think of it in terms of developers building applications for the cloud, desktop, phone, server, etc. … or you can think of it in terms of customers building Web apps, phone apps, services, etc.  This is an abstraction that sits above the technology.  Depending on what you want to build, you can choose the most relevant or appropriate platforms and technologies.
    2. Tech Hubs.   These are simply “one-stop shops” for key content, documentation, and guidance for a particular product or technology.  For these to be effective, it means finding and organizing the most useful content for that particular technology.  In other words, rather than a stream of content, it’s an organized body of content.
    3. Simple IA.    The simplest way I’ve found to make content useful for a given technology is to make it easy to browse by topics, by features, and by content types (Code Samples, How Tos, Videos, etc.)

    Why “Hubs”? … This is simply a “Hub and Spoke” pattern, where the “Hub” is a place to bring the various spokes together.

    A More Complete View of the IA …
    Here is a more complete view of the IA in progress …


    To explain the model, I’ll use a simple example.  If you wanted to build applications for the cloud, the two main paths are building a Web application or a Web service.  On the Microsoft platform, that translates to ASP.NET and WCF.  Imagine that you can browse common application patterns and design patterns from the Cloud hub.  Imagine that you can then explore specific Code Samples, How Tos, Videos, or Training for a specific technology, such as Windows Azure, or ASP.NET, or WCF, or that you can quickly jump into the more relevant node in the MSDN Library and explore the product documentation with ease.  Further imagine that the Code Samples, How Tos, Videos, or Training are organized by topics that reflect common scenarios.  Imagine that for any of the key technologies, you can easily browse the topics or the features, and find relevant content.

    The easiest way to see this model in action is to browse the Microsoft Developer Guidance Maps site, where I model, prototype, and test the IA with customers.   Before rolling out any IA changes, this is a way to experiment and rapidly change the model.

    Key IA Components at a Glance
    Here is a summary of the key Information Architecture components at a glance:

    Item Notes
    App / Solution Hubs

    App Hubs are simply information hubs centered around solutions or app types.  They are an abstraction from the specific technology or product.  An example set of App Hubs could be:

    • Cloud
    • Data
    • Desktop
    • Games
    • Phone
    • Service
    • Server
    • Web

    A good App Hub makes it easy to get started, build your first app, find the key technologies, and solve the most common and important problems, as well as provides arch/design guidance, patterns, and best practices.  Here is an example of an App Hub:

    Tech Hubs

    Tech Hubs are simply information hubs centered around products or technologies.  They showcase the best information and sources of information for a given technology.  An example set of Tech Hubs could be:

    • ADO.NET
    • ASP.NET
    • Silverlight
    • WCF
    • Windows Azure
    • Windows Phone

    A good Tech Hub makes it easy to figure out the technology, get started, find the documentation, and browse by topics, features, and content types, including Code Samples, How Tos, Videos, and Training.  Here is an example of a Tech Hub:

    Feature Maps

    Feature Maps are simply lists of the features for a given technology.  These are relatively straightforward because they are identified by product teams.  The feature names are especially helpful when it comes to creating product usage guidance.

    Here are example Feature Maps:

    Topic Maps Topic Maps are simply lists of topics that represent areas or categories of scenarios.   While topic maps are great for organizing scenarios, they can also organize concepts, questions, or tasks.

    Here are example Topic Maps:

    Collections by Content Type

    Collections by Content Type are simply collections of content such as Code Samples, How Tos, Videos, and Training.  When you organize content by content types, this helps you evaluate the ROI against the cost of a given type.   It also makes it easier to innovate on experiences.  For example, you can show a carousel of videos.  It also makes it easier to set and meet expectations.  When a user browses a How To, they come to expect a set of actionable steps to perform a task. 

    Here are examples of browsing by content type for ASP.NET:

    Scenario Maps

    Scenario Maps are simply lists of user scenarios worded as “How to”, such as “How to show records from the database.”    The Scenario Maps are generated by consulting with product teams, customers, field, industry experts, support, etc.   Scenario Maps help to drive content by identifying demand.  The categories of scenarios help identify the key topics for Topic Maps.

    Here are some example Scenario Maps:

    Learning Roadmaps

    Learning Roadmaps are simply lists of learning objectives worded as “Learn how to” or “How to” … etc.  Learning Roadmaps lay out a learning path through sets of concepts and tasks for a given domain.  They help identify what training assets need to be created against demand, as well as identify effective paths through concepts and tasks to quickly gain proficiency within a domain.

    Here is an example Learning Roadmap:

    Content Types

    Content Types are simply types of content.  Identifying content types helps you make deliberate choices against what kinds of content you will invest in.  For example, are books or patterns as a content type, effective for users?  Here are some of the common content types used for Developer Guidance:

    • Code Samples
    • How Tos
    • Videos
    • Training
    Content Schemas

    Content Schemas are simply structures for content in the form of templates.  Each template identifies the content pattern.  For example, How Tos include a summary, a list of objectives, a list of steps, and then each step details how to perform a sub-task in the process.  Here are examples of content schemas:

    Table of Contents (TOC) Model A Table of Contents model is simply a canonical example of organizing top level nodes for a given product or technology within the tree of the MSDN Library.  

    The Windows Phone TOC in the MSDN Library is a good example and includes the following key components:
    • What's New
    • Code Samples
    • Getting Started
    • Tools
    • Concepts
    • Common Tasks
    • Features
    • Class Library Reference
    Controlled Vocabularies

    Controlled vocabularies are simply a shared set of agreed terms.  They help content producers use consistent labels for ideas and concepts and to organize information.  You can also use them to help map alternative terms and words back to the main term.

    Here are some Controlled Vocabularies I’ve found helpful:

    • Content Types (what are the various types we use and what do we call them?)
    • Categories / Topics (what are the key categories or topics for a given domain?)
    • Features (what are the key features for a given product or technology?)

    You can see these parts working together in action at Microsoft Developer Guidance Maps.

  • J.D. Meier's Blog

    Getting Started, Solve-a-Problem, and Arch-and-Design


    This post is about creating an effective body of knowledge for helping developers succeed with your product.  When I try to size up a space in terms of technical documentation, best practices, and prescriptive guidance for a given domain, product, or technology, I use the following mental model:


    I think of it in terms of three basic buckets:

    1. Getting Started.   This is a relatively finite space.  If you address the basic scenarios, how to install, how to get started, how to do a simple “hello world” and then provide a roadmap for learning and a roadmap for knowing the timelines and paths for the technology, you have a pretty good baseline for users to get up and running.  My two favorite developer guidance tools here are a map of the technology in terms of the key components, features, and APIs (like a “PDC Poster”) and a walk through the flow of a request (like a UML sequence diagram.)
    2. Solve-a-Problem.  This is the space in the middle and it’s infinite.  You can think of it in two big parts though: common and niche.  There is a set of common challenges that a broad set of users will face, and then there is a set of long-tail, corner-case, and niche set of challenges.  The better you solve the common problems out of the gate for the broader set of users, the more successful you can make your product.  You can find these common challenges by using people and SEO (Search Engine Optimization).  On the people-side, you can use experts and mentors in that space, to map out the common challenges.  On the SEO side, you can simply map out the demand using keyword analysis.
    3. Arch and Design.   This is another finite space.   While it might seem infinite because it’s complex, it is actually pretty finite.  You can map out this space pretty quickly for a given technology by mapping out the common deployment patterns, the application types (the canonical app archetypes), the key design patterns for common scenarios, and how to address quality attributes such as security, performance, and reliability.

    While the path to mastery might be a long one, there is no reason why the path to effectiveness can’t be a short one – especially in a world of addressed “Just-in-Time Learning.” 

  • J.D. Meier's Blog

    Why Agile Results Works for Getting Results


    “Agile Results” is the name of the “personal results system” inside Getting Results the Agile Way.   People that have tried every personal productivity system under the sun tend to ask me, what’s so different about this system or why does it work?  Here are the key things I usually say:

    1. It’s a mindful approach.  It’s not about doing more, and it’s not about doing less.  It’s about doing the right things, at the right time, the right way, with the right energy.
    2. It’s shifting from what you didn’t do, or what you didn’t get done, to figuring out the best things you can do with the time, energy, and opportunity you now have.
    3. It helps you ask better questions.  For example, “What are the 3 best results you want for today?”  “What’s your next best thing to do?”  “If this week was over, what are three things you want under your belt?” … “When are your best power hours?” … “When are your best creative hours?” … “What are three things going well that I can carry forward from this week?” … etc.
    4. It’s story-driven.   You get to be the author of your life and write your story forward, a day at a time, a story at a time.
    5. It’s pinned against time.   It’s a time-based system.  This keeps it simple.  You can focus on three results for today, three results for the week, three results for the month, and three results for the year.  This lets you zoom in and out while keeping things simple.  It also gives you a fresh start each day.  The main pattern in the book is the Monday Vision, Daily Outcomes, Friday Reflection pattern.  This makes the pattern easy to adopt, easy to remember, and you get to practice each day and each week.
    6. It’s integrated.  It combines mind, body, and emotions, and it’s a system you can use for work and life.
    7. It’s principle-based.  Because it’s a set of guiding principles, you can incrementally adopt the system, and you can use it on top of your existing systems.  It can easily blend with your approach or you can use it to re-shape your existing approaches.  It’s flexible by design, and meant to be tailored to help you unleash your best and improve your personal effectiveness in all areas of your life.

    While it might seem new, and some concepts are, it’s really a system that I’ve been evolving over more than 10 years.  I’ve used it to help people at Microsoft get faster, simpler, better results, and it’s how I’ve quickly ramped up folks on my project teams (you can read some of the testimonials and case studies.)  I do recommend reading A Word from the Author -- It’s short, but it gives you some of the back-story on how the system evolved. 

Page 2 of 2 (29 items) 12