J.D. Meier's Blog

Software Engineering, Project Management, and Effectiveness

November, 2009

  • J.D. Meier's Blog

    Now Available: Final PDF of the Microsoft Application Architecture Guide, Second Edition


    A final PDF is now available for our patterns & practices Application Architecture Guide, second edition.  This is our platform playbook for the Microsoft application platform.

    Here are the relevant links:

    Here are some of my related posts:

  • J.D. Meier's Blog

    Patterns and Practices for Distributed Teams


    This post is a summary of my lessons learned from leading distributed teams.  I've managed distributed project teams since 2001, spanning the UK, Argentina, India, and other parts of the world.  While I preferred having everybody together on site around a whiteboard to simplify and improve communication,  flexibility with distributed teams gave me access to the right talent, wherever it may be.

    Key Challenges
    These are some of the most common challenges I faced:

    • Trust
    • Time zone differences
    • Sharing state
    • Changes in direction that have a ripple effect
    • Communication overhead
    • Keeping everybody on the same page
    • Sharing knowledge across the team
    • Partitioning work for enough autonomy but to keep checks and balances
    • Lack of a whiteboard

    Distance didn’t matter as much as differences in time zones.  If the time zone differences were too much, it meant  a lot more information, knowledge and state had to be packaged up and handed over.  However, when you leverage time zone differences, the experience can feel like you carry the baton forward, or, it’s like “The Elves and the Shoemaker,” where you make progress around the clock.

    Success Patterns for Distributed Teams
    The following success patterns helped improve distributed team effectiveness:

    • Forming, storming, norming and performing.   The forming, storming, norming and performing lens helps remind everybody to expect that things smooth out over time.  It’s a simple maturity model for explaining how a team gels.
    • Proxy / On Point.  One of the most helpful patterns for cross-site communication is to have somebody act as the proxy or person on point to funnel key communication.  This is especially important when their are major time zone differences.  The additional patterns, such as the show and tell, and the Monday iterations and daily stand-ups, keep this from being a single point of failure.  Instead, it’s a focal point with some accountability when key information needs to be shared across time zones.
    • Rhythm of results.  Daily, Weekly, and Monthly Results.   While the team might ship every two weeks, thinking in terms of daily, weekly, and monthly results helps set the right mindset.  It creates a bias for action, and it helps get the kinks out of execution.
    • Monday Vision, Daily Outcomes, and Friday Reflection.   This is a simple, high-level pattern to drive results each week.   The approach is to identify 3 key outcomes for the week, as well as 3 key outcomes each day, and to use Friday for learning and reflecting. 
    • Stories.  By focusing on stories, it makes it easy for everybody on the team to think in terms of end-to-end stories over, features or discipline-focused activities.  It’s a great way to balance the customer, technical and business perspectives, as well as help the team converge around common goals.
    • Monday Iteration plans.  Doing iteration plans on Mondays helps set the goals for the week, as well as include everybody’s input.  We keep these to 30 minutes or less.  The outcome is the prioritized set of stories for the week.
    • Daily stand-ups.    Everybody calls in and we go around the team asking 3 questions: 1) what did you get done? 2) what are you getting done today? and 3) where do you need help?  We keep these to 10 minutes or less.  It sets the pace and prevents getting side-tracked.
    • Invoke a teammate.  One goal up front is to make it easy for everybody on the team to reach whoever they need in an ad-hoc way.  Everybody identifies their preferred email, phone number, Skype account, and instant message information, as well as their main working hours.
    • Show and Tell.  I use weekly show and tells as a forcing function.  It gives people on the team a chance to show off their work.  More importantly it’s a simple way to dog food results as well as use the team as a sounding board.  It’s one thing to build something, it’s another to show it to other people and get honest feedback.
    • Wiki Knowledge Bases (KBs.)   Using Wikis helps simplify sharing information.  It keeps people from over-engineering and it’s easy to keep updated.
    • Experience Step-Throughs.   These are simply short slide decks that mock up the experience.  Each deck walks through one story or scenario visually.  We test the experience with customers, and then we walk through as a team, from a technical perspective.  We do this for high-risk stories.   See Experience-Driven Development and Experience Step-Throughs.
    • Distributed pairing.   I’ve found the fastest way to hand over information is to pair people up.  Pairing can also help people get unblocked or keep pace.  It’s not always obvious who pairs up well, so we test different combinations to find what works best for people.  Sometimes it helps to compliment skills.  For example, one person might be great technically, while another might be great with customer experience.
    • Mentoring and buddies.   Helping new people on the team ramp up is a priority.  I’ve found the most effective way is to have people pair on things together.  For metaphors, we call it either “co-pilot” or a “student-driver” model.
    • Email Triage.  As simple as it sounds, it’s been helpful to include “triage” in the title of some emails.  This tells the team that this email thread may be a drill-down or discussion on a topic.  It’s also a quick way for anybody on the team to ask for help, since they may not know who on the team has the answer.
    • One mail.   This is a simple burn down list.  Whenever we’re pushing for a key milestone, it’s helpful to summarize the open work that everybody can see and comment on in a shared way.  To do so, we simply send out an email that lists the current open work to the team and everybody chimes in.  It helps everybody see a tangible finish line.
    • Team project site.   It’s important that the team has one place to look for all the shared information.  The most important information here is the schedule, the deliverables, status, and any key information related to either the deliverables or the project.
    • Lessons Learned.   I’m a fan of sharing lessons learned on the team.  To bootstrap these, we usually just start an email thread and dump our lessons learned.  We then port the lessons into the Wiki for easy reference.  We list the lessons as one-liners in the form of “do’s” and “don’ts".”  It’s a tickler list that provides a backdrop for richer conversations, dialogues, and discussions.
    • Checklists.  Checklists for common tasks have been the best and simplest way to share information across the team.   They help reduce mistakes and carry lessons forward.
    • Best Practices Repository.   We store our best practices for each project in a project-level repository.  At the end of the project, we port the best practices to a shared repository across projects.  This way each project is focused on “best practices,” and these are very specific and detailed.  The all up best practices are more generalized to be useful across projects, and as a starting point for new projects.
    • Reduce friction in the process.   This is a shared goal on the team to get the kinks out of any sticking points in any of the processes.  We try to innovate in the process to save cost or time or improve effectiveness.  This helps us avoid death by a 1000 paper cuts.
    • Video nuggets.   We’ve found that sharing short-videos can help share knowledge on the team very quickly.  These are throw-away videos, but they help capture a snapshot whenever somebody does research in a particular area.

    No single pattern is a silver bullet.  Instead, it’s the composition of these patterns and practices that help improve distributed team communication and overall effectiveness.

    Tools of the Trade
    The following are some common tools of the trade:

    • Email.  This is helpful for sharing technical details, state, and general asynchronous communication.
    • Conference calls.  This is important for Monday iterations, daily stand-ups, Show and Tells, and any other team meetings.
    • Microsoft Shared view.  This is helpful for distributed pairing as well as Show and Tells, so that everybody can see a shared desktop.
    • Slides.  Slideware is a great way to share visuals and consolidate key information or to demo ideas and concepts.
    • Mind Maps.   Mind maps are a great way to pair and map out what the team knows about a given topic.  We’ve also found them useful for creating Work Breakdown Structures, as a team.  This way everybody gets to see the big picture  as a simple map.
    • Instant Messenger.  This is especially helpful for simply knowing when people on the team are around and for ad-hoc synch ups.
    • Skype.   This has gradually replaced setting up conference calls.  In fact, we’ve started having better luck with Skype than conference calls in terms of clarity in some cases.
    • Groove.  This has been our simplest way to share files instead of email.  There are some tricks to learn, but we’ve successfully shared projects of with thousands of files and hundreds of MBs.

    What about you?  … What have been your best lessons learned when it comes to distributed teamwork?

  • J.D. Meier's Blog

    Now Available: patterns & practices Application Architecture Book


    AAG2FrontCover-Small The Microsoft Application Architecture Guide, 2nd edition, is now available on Amazon and should be available on the shelf at your local bookstores soon.  The PDF was downloaded ~180,000 times.  This is the Microsoft platform playbook for application architecture.  You can think of it as a set of blueprints, and as your personal mentor for building common types of applications on the Microsoft platform:  mobile, RIA, services, and Web applications.

    The backbone of the guide is an information model for the application architecture space.  It’s a durable and evolvable map to give you a firm foundation of principles, patterns, and practices that you can overlay the latest technologies.  It’s your “tome of know-how.”  While it’s not a step-by-step for building specific applications, it is a pragmatic guide for designing your architecture, with quality attributes, key software principles, common patterns, and architectural styles in mind.  It’s holistic and focused on the key engineering decisions where you face your highest risks and most important choices.

    Key Features of the Book
    The book has several compelling features for slicing and dicing the application architecture body of knowledge:    

    • Canonical Frame.  This describes at a meta-level, the tiers and layers that an architect should consider. Each tier/layer will be described in terms of its focus, function, capabilities, common design patterns and technologies.
    • Application Types.  These are canonical application archetypes to illustrate common application types: Mobile, Rich Client, RIA, Services, and Web applications.  Each archetype is described in terms of the target scenarios, technologies, patterns and infrastructure it contains. Each archetype is mapped to the canonical app frame. They are illustrative of common application types and not comprehensive or definitive.
    • Quality attributes.  This is a set of qualities and capabilities that shape your application architecture: performance, security, scalability, manageability, deployment, communication, etc.
    • Cross-cutting concerns.  This is a common set of categories for hot spots for key engineering decisions: Authentication, Authorization, Caching, Communication, Configuration Management, Exception Management, Logging and Instrumentation, State Management, and Validation.
    • Step-by-Step Design Approach.
    • Principles, patterns, and practices.   Using the application types, canonical frame, and cross-cutting concerns as backdrops, the guide provides an overlay of relevant principles, patterns, and practices.
    • Technologies and capabilities.  The guide provides an overview and description of the Microsoft custom application development platform and the main technologies and capabilities within it.

    Contents at a Glance
    The full Microsoft Application Architecture Guide is available for free on MSDN in HTML.  This is the contents of the guide at a glance:



    The Team
    Here is the team that brought you the guide:

    • Core Dev Team: J.D. Meier, Alex Homer, David Hill, Jason Taylor, Prashant Bansode, Lonnie Wall, Rob Boucher Jr, Akshay Bogawat
    • Test Team - Rohit Sharma, Praveen Rangarajan, Kashinath TR, Vijaya Jankiraman
    • Edit Team - Dennis Rea
    • External Contributors/Reviewers - Adwait Ullal; Andy Eunson; Brian Sletten; Christian Weyer; David Guimbellot; David Ing; David Weller; Derek Greer; Eduardo Jezierski; Evan Hoff; Gajapathi Kannan; Jeremy D. Miller; John Kordyback; Keith Pleas; Kent Corley; Mark Baker; Paul Ballard; Peter Oehlert; Norman Headlam; Ryan Plant; Sam Gentile; Sidney G Pinney; Ted Neward; Udi Dahan
    • Microsoft Contributors / Reviewers - Ade Miller; Amit Chopra; Anna Liu; Anoop Gupta; Bob Brumfield; Brad Abrams; Brian Cawelti; Bhushan Nene; Burley Kawasaki; Carl Perry; Chris Keyser; Chris Tavares; Clint Edmonson; Dan Reagan; David Hill; Denny Dayton; Diego Dagum; Dmitri Martynov; Dmitri Ossipov; Don Smith; Dragos Manolescu; Elisa Flasko; Eric Fleck; Erwin van der Valk; Faisal Mohamood; Francis Cheung; Gary Lewis; Glenn Block; Gregory Leake; Ian Ellison-Taylor; Ilia Fortunov; J.R. Arredondo; John deVadoss; Joseph Hofstader; Koby Avital; Loke Uei Tan; Luke Nyswonger; Manish Prabhu; Meghan Perez; Mehran Nikoo; Michael Puleio; Mike Francis; Mike Walker; Mubarak Elamin; Nick Malik; Nobuyuki Akama; Ofer Ashkenazi; Pablo Castro; Pat Helland; Phil Haack; Rabi Satter; Reed Robison; Rob Tiffany; Ryno Rijnsburger; Scott Hanselman; Seema Ramchandani; Serena Yeoh; Simon Calvert; Srinath Vasireddy; Tom Hollander; Wojtek Kozaczynski

    Application Architecture Knowledge Base
    The guide was developed in conjunction with our Application Architecture Guide v2.0 Knowledge Base Project. The knowledge base project was used to inform and steer the guide during its development. The Application Architecture Knowledge Base includes a large amount of material that expands on specific topics in the main guide. It also includes draft material from the main guide that is targeted and packaged for more specific audiences, such as the Pocket Guide series.

    Key Links at a Glance
    Here are the key links at a glance:

Page 1 of 1 (3 items)