J.D. Meier's Blog : Agile

Agile Architecture Method Revisited

J.D. Meier — Mon, 02 Mar 2009 18:49:23 GMT

I posted an update to the Agile Architecture method on Shaping Software. When I originally posted about the Agile Architecture method, I took some things for granted. I thought the mapping to agile practices was more obvious than it turned out to be. After taking more customers through the approach, I realized some things are worth more elaboration. Here's some of the key things that stood out among the conversations:

Whiteboard technique. You can use the Agile Architecture method as a simple technique to quickly sketch out your solutions on a whiteboard. It's a guided process for rapid prototyping. The value is that it helps you identify hot spots for technical risks more quickly than ad-hoc or random approaches.
Hot Spots. Thinking of the cross-cutting concerns and quality attributes as hot spots seems to stick. The intersection of the hot spots and stories is a key way to drive architectural concerns.
Prioritized scenarios. The user, business, and system stories are a way to help focus and prioritize which hot spots matter most.
Mapping to agile practices. You can use the Agile Architecture method to shape your candidate architecture, as well as prioritize technical risks and guide your architectural spikes for iteration 0. For iterations 1 - N, you can use the Agile Architecture method to guide your design, implementation, and deployment inspections as well as identify hot spots in your design. You can also use it to help you periodically refactor your design to meet your objectives for your various quality attributes, such as performance, security ... etc. Most importantly, you can use the Agile Architecture method as a structured approach for addressing cross-cutting concerns and baking quality throughout the life cycle.
Just in Time Architecture. One of the most important points about the Agile Architecture method is that it's just enough architecture and just in time architecture. When you're creating your baseline or candidate solutions, it's a structured approach to help you prioritize technical risk and find the key hot spots. During iterations, it's a way to provide just in time architecture by mapping relevant hot spots against your prioritized stories.

Writing Books on Time and on Budget

J.D. Meier — Fri, 06 Feb 2009 22:47:57 GMT

One of the questions I get asked is how did we execute our patterns & practices Application Architecture Guide 2.0 project, on time and on budget? It was a six month project, during which we ....

Created a language and model for application architecture. (See Grady Booch on the Microsoft Application Architecture Guide 2.0)
Wrote a 300+ page book, the patterns & practices Application Architecture Guide 2.0 (affectionately referred to as the Microsoft Playbook for Application Architecture)
Created an Application Architecture Knowledge Base (KB), with step-by-step How Tos, videos, checklists, slides, and reusable figures.
Created a series of Pocket Guides for Application Architecture.
Created a map of the Microsoft application platform.
Created technology matrixes to organize and navigate technology decisions. (See the Presentation Technology Matrix, Data Access Technology Matrix, Workflow Technology Matrix, and Integration Technology Matrix)
Created a systematic approach for the architecture and design of applications.
Created a patterns catalog for the patterns documented by the patterns & practices team.
Formed, stormed, normed, and created a performing team. (See Wikipedia on Forming, Storming, Norming and Performing.)
Coordinated among more than 70 internal and external reviewers, across key product groups and with our field, support, and experts. (See the contributors and reviewers list.)

2 Keys to Success
We used two keys to success:

Fix time, Flex scope
Agile Guidance Engineering

Fix Time, Flex Scope
One of the most successful patterns I've used for years now is to fix time, and flex scope. The idea is to deliver incremental value and find a way to flow value along the way rather than wait for one big bang at the end. This allows you to deliver the most timely and relevant value with a healthy worklife balance. It helps reduce project risk along the way. More importantly, it helps get your stakeholders on board, by showing them results versus just trust you to the end. Scope is the best to flex because there's the least amount of precision or accuracy up front, and it enables you to respond to the market or stakeholder concerns more effectively.

Agile Guidance Engineering
This is the secret sauce. I call it Agile Guidance Engineering:

In a nutshell, Agile Guidance Engineering is about building guidance using nuggets of specific types (how tos, guidelines, checklists ... etc.) and composing them into books. The books themselves are actually an information model. The information model is designed to both structure the content as well as structure the problem domain. We vet the nuggets as we go for feedback, and we prioritize, tune, and improve them along the way.

I've used Agile Guidance Engineering successfully to build the following Microsoft patterns & practices Blue Books:

My Related Posts

Microsoft patterns & practices Agile Workspace Tour

J.D. Meier — Mon, 19 Jan 2009 19:14:26 GMT

I posted a visual walkthrough of our Microsoft patterns & practices Agile workspace on Shaping Software. I basically did a lap around the halls and pointed out key things along the way. Our patterns & practices team workspace is optimized for agile development practices. The workspace features writeable walls, configurable workspace, speaker phones, projectors, focus rooms, and a customer room. The walkthrough is extensive. It's basically more than 40 pictures. Enjoy!

Agile Architecture Method Pocket Guide

J.D. Meier — Tue, 25 Nov 2008 02:54:12 GMT

We posted our Agile Architecture Method Pocket Guide to our Application Architecture Guidance KB. This is in response to customers who expressed interest in more modular guides as a supplement to our Application Architecture Guide 2.0.

Chapters At a Glance
Here’s the chapters at a glance:

Ch 01 - Agile Architecture Method
Ch 02 - Step 1 - Identify Objectives
Ch 03 - Step 2 - Identify Key Scenarios
Ch 04 - Step 3 - Application Overview
Ch 05 - Step 4 - Key Hot Spots
Ch 06 - Step 5 - Candidate Solutions
Ch 07 - Reviewing Your Architecture
Ch 08 - Communicating Your Architecture

Download

Download the Agile Architecture Method Pocket Guide.

My Related Posts

Agile Architecture Method

J.D. Meier — Thu, 06 Nov 2008 07:31:03 GMT

I presented our new patterns & practices Agile Architecture Method for the first time at the patterns & practices Summit. Our Agile Architecture Method is an iterative and incremental approach for designing architectures.

To summarize, it’s a technique that:

Scopes and focuses your architecture exercise.
Uses scenarios to drive the design and evaluate potential solutions.
Helps you think through your choice of application type, deployment, architectural style and technologies.
Helps you quickly iterate through potential solutions.
Helps you map potential patterns.

I’ve summarized the approach below, and we’ve posted a step-step how to on CodePlex:

How To Design Using Agile Architecture

Input
Here’s the key input into the process:

Use cases and usage scenarios
Functional requirements
Non-functional requirements (quality attributes such as performance, security, and reliability)
Technological requirements
Target deployment environment
Constraints

Output
Here’s the key output of the process:

Architecturally significant use cases
Architecture hot spots
Candidate architectures
Architectural spikes

Summary of Steps

Step 1. Identify Architecture Objectives.
Step 2. Identify Key Scenarios.
Step 3. Create an Application Overview.
Step 4. Analyze Key Hot Spots.
Step 5. Create Candidate Solutions.

Step 1. Identify Architecture Objectives
This is a scoping exercise. The purpose of this step is to figure out how much time and energy to spend on subsequent steps as well as guide your overall effort. You should know what you want in terms of outcomes. Here’s an example of potential goals:

Build a prototype
Identify key technical risks
Test potential paths
Share models and understanding

Step 2. Identify Key Scenarios
Identify relevant scenarios to focus your design on what matters most, and to evaluate your candidate solutions. In this case, you want to identify architecturally significant use cases. Architecturally significant use cases are those that meet the following criteria:

They are important for the success and acceptance of the deployed application.
They exercise enough of the design to be useful in evaluating the architecture.

You can draw key scenarios from your user stories, business stories and system stories.

Step 3. Create an Application Overview
Create an application overview. The application overview serves to make your architecture more real, connecting it to real-world constraints and decisions.

An application overview consists of the following steps:

Determine your application type. First, determine what type of application you are building. Is it a mobile application, a rich client, a rich internet application, a service, a Web application, or some combination?
Understand your deployment constraints. Next, understand your targeted deployment environment and determine what impact this will have on your architecture.
Identify important architectural styles. Determine which architectural styles you will be using in your design. Will you build a service oriented architecture, client/server, layered, a message bus, or some combination?
Determine relevant technologies. Finally, identify the relevant technology choices based on your application type, architectural styles and deployment constraints.

A good test of an application overview is whether you can whiteboard it.

Step 4. Analyze Key Hot Spots
Identify key hotspots based on quality attributes and the architecture frame. These are the areas where mistakes are most often made when designing an application.

Quality Attributes Frame
Understand the quality attributes that are important for your application and scenarios. For instance, most applications need to address security and performance and will be traded against usability, flexibility and other attributes that may be more or less important to you depending on your scenarios and requirements. You can use the following frame to identify key quality attributes to consider:

Category	Considerations
Availability	How to design for failover support How to design a redundant site How to plan for backup and recovery How to design for runtime upgrades
Conceptual Integrity	How to isolate from external dependencies How to create a migration path from legacy technologies How evolve the system without breaking clients
Flexibility	How to handle dynamic business rules How to handle dynamic UI How to handle changes in data and logic processing How to handle changes in business requirements
Interoperability	How to allow applications to interoperate while still evolving separately How to isolate systems through the use of service interfaces How to isolate systems through the use of mapping layers
Maintainability	How to reduce dependencies between layers and components How to implement a pluggable architecture How to choose an appropriate communication model
Manageability	How to understand the key types of failure How to monitor system operation and health How to modify system behavior based on load
Performance	How to determine a caching strategy How to design high performance communication between layers How to design high performance data access How to manage resources effectively
Reliability	How to handle unreliable external systems How to audit requests and jobs How to redirect load How to handle failed communication How to handle failed transactions How to handle exceptions
Reusability	How to reduce duplication between components and layers How to share functionality across systems How to share functionality across components and layers
Scalability	How to design layers and tiers for scalability How to scale-up or scale-out How to handle spikes in traffic and load
Security	How to address authentication and authorization. How to protect against malicious input. How to protect sensitive data
Supportability	How to design auditing and logging How to design usable error messages
Testability	How to design for testability How to design unit tests How to design for UI automation
Usability	How to design for user empowerment How to improve responsiveness How to avoid common user experience pitfalls

Architecture Frame
The architecture frame represents cross cutting concerns that will impact your design across layers and tiers. These are also the areas in which high impact design mistakes are most often made. Use the architecture frame to identify hot spots in your design that require additional attention to get right. You can use the following architecture frame to identify cross cutting concerns in your design:

Category	Considerations
Authentication and Authorization	How to choose an authentication strategy. How to choose an authorization strategy. How to flow identity across layers and tiers. How to store user identities when not using Active Directory.
Caching and State	How to choose an appropriate caching technology. How to determine what data to cache. How to determine where to cache the data. How to determine the expiration policy.
Communication	How to choose appropriate protocols for communication across layers and tiers. How to design loose coupling across layers. How to perform asynchronous communication. How to pass sensitive data.
Composition	How to choose a composition pattern for the user interface (UI). How to avoid dependencies between modules in the UI. How to handle communication between modules in the UI.
Concurrency and Transactions	How to handle concurrency between threads. How to choose between optimistic and pessimistic concurrency. How to handle distributed transactions. How to handle long running transactions.
Configuration Management	How to determine what information needs to be configurable. How to determine where and how to store configuration information. How to protect sensitive configuration information. How to handle configuration information in a farm/cluster.
Coupling and Cohesion	How to choose an appropriate layering strategy for separation of concerns. How to design highly cohesive components and group them within layers. How to determine when loose coupling is appropriate between components within a layer.
Data Access	How to manage database connections. How to handle exceptions. How to improve performance. How to handle binary large objects (blobs).
Exception Management	How to handle exceptions. How to log exceptions. How to provide notification when required.
Logging and Instrumentation	How to determine which information to log. How to make the logging configurable. How to determine what level of instrumentation is required.
User Experience	How to improve task efficiency and effectiveness. How to improve responsiveness. How to improve user empowerment. How to improve look and feel. </>
Validation	How to determine where and how to perform validation. How to validate for length, range, format, and type. How to constrain and reject input. How to sanitize output.
Workflow	How to choose the appropriate workflow technology. How to handle concurrency issues within a workflow. How to handle task failure within a workflow. How to orchestrate processes within a workflow.

Step 5. Create Candidate Solutions
Create a candidate architecture and along with architectural spikes and evaluate it against your key scenarios, hot spots, and deployment constraints. The outcomes of this step are:

Baseline / Candidate Architectures
Architectural Spikes

Iterative and Incremental Design
You can iteratively flesh out your architecture as you work through your design and discover more details that impact your architecture. You don’t have to design your architecture in a single iteration. Do not get lost in the details; focus on the big steps and build a framework on which you can base your architecture and design.

My Related Posts

New Release: patterns & practices App Arch Guide 2.0 Beta 1

patterns & practices App Arch Guide 2.0 Project

App Arch Guide 2.0 Overview Slides

Abstract for Application Architecture Guide 2.0

Layers and Components

Key Software Trends

Cheat Sheet: patterns & practices Catalog at a Glance Posted to CodePlex

Cheat Sheet: patterns & practices Pattern Catalog Posted to CodePlex

New Release: Distributed Agile Development at Microsoft patterns & practices

J.D. Meier — Thu, 30 Oct 2008 23:31:00 GMT

Distributed Agile Development at Microsoft patterns & practices (PDF) is now available.

Abstract
Distributed development is a fact of life for many teams. Unfortunately most agile methodologies or approaches assume that the team is located in a single team room. Until recently there has been little guidance about how to apply these approaches with a geographically dispersed team. Microsoft’s patterns & practices group has been following an agile, distributed development approach for the past five years. During this time teams within the group have experimented extensively with different approaches to best address the challenges of distributed agile development. This paper outlines the challenges faced by geographically distributed agile teams and details some proven practices to address these issues and build successful distributed teams.

Contents at a Glance

Introduction
Why Colocate?
The Reality of Distributed Teams
Distributed Teams at patterns & practices
Challenges
Proven Practices
Focus on Communication
Plan to Travel
Team Distribution
Focus on Coaching the Team
Distribution of Work
Build the Team Over Time
Provide the Right Tools
Conclusions
Acknowledgements
About the Author

Key Links

Distributed Agile Development at Microsoft patterns & practices

Software Methodologies at a Glance

J.D. Meier — Mon, 18 Aug 2008 09:14:01 GMT

I like to draw from a variety of sources for software engineering principles, patterns, and practices. To be able to do this, I usually need to create information models that let me quickly scan bodies of knowledge. Once I can frame out a space, it's a lot easier to drill into areas looking for gold. I can also step back and see across approaches and this helps me see underlying principles or key distinctions between approaches.

XP, MSF Agile, RUP, and Microsoft Solution Framework
To compare process methodologies, here are some skeletal information models I've used:

While the frames aren't entirely consistent, I can still quickly scan the methodologies and get a good sense of what the key ideas, activities, artifacts, and practices are.

My Related Posts

MSF Agile Frame (Workstreams and Activities)

Agile Guidance

J.D. Meier — Tue, 22 Jul 2008 19:58:11 GMT

When I ramp new folks on the team, I find it helpful to whiteboard how I build prescriptive guidance. Here's a rough picture of the process:

Examples
I've used the same process for Performance Testing Guidance, Team Development with Visual Studio Team Foundation Server, and WCF Security.

Here's a brief explanation of what happens along the way:

Design
The dominant focus here is identifying candidate problems, candidate solutions, and figuring out key risks, as well as testing paths to explore. The best outcome is a set of scenarios we can execute against.

Research - finding the right people, the right problems, and the right solutions.
Prototypes - experiment and test areas of high risk to prove the path. This can include innovating on how we build prescriptive guidance. We also use these to test with customers and get feedback on the approach.
Question Lists - building organized lists of one-liner user questions.
Task Lists - building organized lists of one-liner user tasks.
Scenario Frames - organizing scenarios into meaningful buckets. See Scenario Frame Example.
Information Models - framing out the problem space and creating useful ways to organize, share, and act on the information. See Web Services Security Frame.
Guidance Types - testing which guidance types to use (how tos, checklists, guidelines, patterns, ... etc.)

Execution
The dominant focus here is product results. It's scenario-driven. Each week we pick scenarios to execute against.

Development - building prescriptive guidance, including coding, testing, and writing.
Backlog - our backlog is a prioritized set of scenarios and guidance modules.
Iterations - picking sets of scenarios to focus development on and test against.
Refactoring - tuning and pruning the guidance to improve effectiveness. This includes breaking the content up and rewriting it. For example, a common refactoring is factoring reference information from action. We try to keep reference information in our Explained modules and action information in our How Tos.
Testing - step through the guidance against the scenario. The first pass is about making sure it works. It should be executable by a human. Next, it's about reducing friction and making sure the guidance really hits the what, why and how. We test the guidance against objectives and scenarios with acceptance criteria so we know when we're done.
Problem Repros - creating step by step examples that reproduce a given problem.
Solution Repros - creating step by step examples that reproduce a given solution.

Release
We produce a Knowledge Base (KB) of guidance modules and a guide. The guidance modules are modular and can be reused. The guide includes chapters in addition to the guidance modules. Here's examples from our WCF Security Guide:

Agile Publishing
We release our guidance modules along the way to test reactions, get feedback and reshape the approach as needed.

CodePlex - we publish our guidance modules to CodePlex so we can share early versions of the guidance and get customer feedback, as well as to test the structure of the guidance, and experiment with user experience.
Guidance Explorer - we publish guidance modules to Guidance Explorer so users can do their own guidance mash ups and build their own personalized guides. Our field also uses this to build customized sets of guidance for customers.

Stable Reference
Once we've tested and vetted the guidance and have made it through a few rounds of customer feedback, we push the guidance to MSDN.

MSDN - this is the trusted site that users expect to see our prescriptive guidance in final form.
Visual Studio/ Visual Studio Team System - once we're a part of the MSDN distribution, we can automatically take advantage of the VS/VSTS documentation integration.

My Related Posts

MSF Agile Frame (Workstreams and Key Activities)

J.D. Meier — Sun, 01 Jul 2007 02:33:00 GMT

When I review an approach, I find it helpful to distill it to a simple frame so I can get a bird's-eye view. For MSF Agile, I found the most useful frame to be the workstreams and key activities. According to MSF, workstreams are simply groups of activities that flow logically together and are usually associated with a particular role. I couldn't find this view in MSF Agile, so I created one:

Workstream	Role	Key Activities
Capture Project Vision	Business Analyst	Write Vision Statement; Define Personas; Refine Personas
Create a Quality of Service Requirement	Business Analyst	Brainstorm quality of Service Requirements; Develop Lifestyle Snapshot; Prioritize Quality of Service Requirements List; Write Quality of Service Requirements; Identify Security Objectives
Create a Scenario	Business Analyst	Brainstorm Scenarios; Develop Lifestyle Snapshot; Prioritize Scenario List; Write Scenario Description; Storyboard a Scenario
Guide Project	Project Manager	Review Objectives; Assess Progress; Evaluate Test Metric Thresholds; Triage Bugs; Identify Risk
Plan an Iteration	Project Manager	Determine Iteration Length; Estimate Scenario; Estimate Quality of Service Requirements; Schedule Scenario; Schedule Quality of Service Requirement; Schedule bug Fixing Allotment; Divide Scenarios into Tasks; Divide Quality of Service Requirements into Tasks
Guide Iteration	Project Manager	Monitor Iteration; Mitigate a Risk; Conduct Retrospectives
Create a Solution Architecture	Architect	Partition the System; Determine Interfaces; Develop Threat Model; Develop Performance Model; Create Architectural Prototype; Create Infrastructure Architecture
Build a Product	Developer	Start a Build; Verify a Build; Fix a Build; Accept Build
Fix a Bug	Developer	Reproduce the Bug; Locate the Cause of a Bug; Reassign a Bug; Decide on a Bug Fix Strategy; Code the Fix for a Bug; Create or Update a Unit Test; Perform a Unit Test; Refactor Code; Review Code
Implement a Development Task	Developer	Cost a Development Task; Create or Update a Unit Test; Write Code for a Development Task; Perform Code Analysis; Perform a Unit Test; Refactor Code; Review Code; Integrate Code Changes
Close a Bug	Tester	Verify a Fix; Close the Bug
Test a Quality of Service Requirement	Tester	Define Test Approach; Write Performance Tests; Write Security Tests; Write Stress Tests; Write Load Tests; Select and Run a Test Case; Open a Bug; Conduct Exploratory Testing
Test a Scenario	Tester	Define Test Approach; Write Validation Tests; Select and Run a Test Case; Open a Bug; Conduct Exploratory Testing
Release a Product	Release Manager	Execute a Release Plan; Validate a Release; Create Release Notes; Deploy the Product

MSF Agile Persona Template

J.D. Meier — Mon, 05 Feb 2007 01:01:00 GMT

I was looking for examples of persona templates, and I came across Personas: Moving Beyond Role-Based Requirements Engineering by Randy Miller and Laurie Williams. I found it to be insightful and practical. I also like the fact they included a snapshot of a persona template example from MSF Agile ...

MSF Agile Persona Template

Name - Enter a respectful, fictitious name for the persona.
Status and Trust Level - Favored or disfavored and level of credentials.
Role - Place the user group in which the persona belongs.
Demographics - Age and personal details optional Goals, motives and concerns.
Knowledge, skills and abilities - Group real but generalized information about the capabilities of the persona.
Goals, motives, and concerns - Describe the real needs of the users in the user group represented by the persona. If multiple groupings exist, write a persona for each grouping.
Usage Patterns - Write the frequency and usage patterns of the system by the persona. Develop a detailed understanding of what functions would be most used. Look for any challenges that the system must help the persona overcome. Note the learning and interaction style if the system is new. Does the persona explore the system to find new functionality or need guidance? Keep this area brief but accurate.