Compartilhar via

Agile Methodology in Microsoft patterns & practices

  • Artigo

Note: This article is updated at Agile Methodology in Microsoft patterns & practices.

“I put my heart and my soul into my work, and have lost my mind in the process.” -- Vincent Van Gogh

I find myself mentoring on Agile practices and Agile methodology on a regular basis.  More and more teams are needing to stay connected with customers, respond to change, and flow value along the way.   I find that if you know what Agile methodology looks like, it’s easier to get started.   In this post, I’ll share what an implementation of Agile methodology looks like.

When I was on the Microsoft patterns & practices team, we used a combination of XP/Scrum for executing projects.  We called our agile methodology, "Customer-Connected Engineering"or CCE.  The following table is an overlay of customer-connected activities on top of the agile methodology:

Phase Core Activities Customer-Connected Engineering Activities
Exploration
  • Go / No Go
  • Business Case
  • Product Backlog
  • Release Planning
  • Team Role Assignments
  • Vision Scope
  • Broad Customer Surveys
  • Customer Advisory Board Setup
  • Stories / Scenarios
  • Prioritization
Iteration 0
  • Clarification of process, responsibilities, and roles
  • Infrastructure setup
Iteration N
  • Iteration Planning
  • Daily Stand-Up
  • Mid-Iteration CheckpointReview
  • Retrospective
  • Internal Release (Optional)
  • Customer Release (Optional)
  • Stories / Scenarios
  • Prioritization
  • Demos
  • Product Drops
  • Feedback
Stabilization
  • Remaining Work Completed
  • Outstanding Bugs Resolved
Release
  • Documentation Updates
  • Incomplete Stories Removed
  • Final Test
  • Remaining Bugs Resolved
  • Release Bar Met

The activities on the left-side of the table are core activities in patterns & practices projects.  If you’re familiar with XP/Scrum, you’ll be familiar with the activities.  On the right-hand side are customer-connected activities.

10 Highlights of the Agile Methodology and Customer-Connected Engineering
Here are some of the most important points and distinctions:

  1. 40 Hour Work Week.    In my experience, a 40 hour work week is a benchmark of the most effective teams.  They have work-life balance.  They have buffer to respond to opportunity and to deal with crunches.  They have processes in place, they invest in their learning and growth, and they move up the stack instead of always solving the basics.  Instead of perpetual fire-fighting, they are more deliberate about planning and strategy and they anticipate their customers and the market (through empathy and staying connected to customers.)  They learn and respond and can turn on a dime.  They have a dashboard, they know the score, and they can change their approach.   See 40 Hour Work Week at Microsoft.
  2. Exploration and Execution.   One of the best moves we did was introduce the idea of an “Exploration” phase.    This is where we would explore and test customer value, while also exploring technical risk.  By doing architectural spikes we could very quickly identify potential technical risks that would impact the project, long before we even started the project.  In general, our exploration phase was anywhere from 4 – 8 weeks.  It was also a practical way to drive innovation and explore new opportunities.  We reduced risk by setting a limit on time and budget.  This gave creative freedom within the box, but constrained risk and cost for the business, while exploring high potential opportunities.
  3. Demos.   Demos are the key to product success, if you do them early enough.  Demos actually serve two functions.  First, they force you to put together that you’ve got into a presentable form.  What looks good on paper, or sounds good in your mind, might not be that good when you actually present it.   So, the demo is a great forcing function for you to identify what’s actually valuable and how to package and showcase that value in a presentable way.    Second, the value of the demo is the actual feedback.  As a rule, I like to Demos on Thursdays each week, as a way to bring work together into a package.  It helps people show off their stuff and feel acknowledge and appreciated.  If it’s an internal demo, then it helps people on the team get real feedback from their peers before going more broadly.  If it’s a public demo, then it’s a great chance to get real feedback from actual users.  I’m a fan of failing fast and failing often.   You get better through failure than you do from success because you learn *why* and *how* to improve.   As Tony Robbins puts it, when you succeed you party and when you fail you ponder.  My guiding principle is to carry the good forward and to turn failure into feedback.
  4. Iterations.   Iterations are a wonderful thing.  They help you set a cadence for shipping stuff, doing demos, and executing your work.   In patterns & practices, the most common pattern was two-week iterations.  I originally used three-week iterations, and then moved to two-week iterations, and eventually moved to one-week iterations, for a variety of reasons.  The one-week iterations reduced my iteration planning time from one or two hours down to 30 minutes max.  It also helped people on the team feel more connected to their results and to drive a great week.   It also meant people had to spend less time estimating their work, and it meant that estimates were more accurate.  In simple terms, it meant that the team could plan a great week, and on Friday reflect on their results without bleeding things into the net week … bite off a weeks’ worth of work, and finish a week’s worth of work.   This radically improved our agility and our ability to execute in a more predictable and streamlined way.   This also set the stage for more lean practices, and on my projects, I was a fan of using a Kanban to visualize the work, reduce open work, and to improve our flow.  I also liked that Kanban is a very customer-connected approach to development in that it is “pull” vs. “push.”  It’s the ultimate in “demand-driven” development.
  5. Product Backlogs and Sprint Backlogs.   Your “Product” backlog is everything that needs to get built.  The “Sprint” backlog is simply the chunk you are biting off for this particular iteration.   This distinction is an important one.   It’s great to have one place to look for everything that makes up the possibilities, the pains, and the needs of your potential product.   It’s also great to be able to grab a meaningful chunk for execution.   The real trick with biting off a meaningful chunk is knowing the dependencies and being able to sequence in a way that flows value while reducing risk.  This is also another reason why user stories are helpful.  They are a collection of customer value at your finger tips.
  6. Prioritization.   To prioritize our user stories and backlog items, we’ve used surveys extensively.   A proven practice is to play a game of “spend a $100.” (See Enterprise Library 5.0 Product Backlog Prioritization Survey.)   An important point is that the prioritization surveys are input into your prioritization planning.  They help you balance perspective and identify actual demand.  In a best case example, they help you find the surprises or disconnects.  Customers usually know what they want, but they don’t always know what they need, and there is often an awareness issue.   If you’re familiar with marketing, this is specifically about finding, surfacing, and addressing latent needs.   Customers may want the “cheaper” bridge, but as the engineer, you need to make sure they know the trade-offs, and that a “safer” bridge might be a better bet.  What’s important is that you create an opportunity for customers to voice their priorities and that you keep an open mind to being surprised.
  7. Project cycles and product cycles.  Having a distinction between the project and product cycle help you optimize and use the right tool for the job.  For a simple example, Scrum is more of a project process, while XP is more of a product development process.  The project cycle is important at the business level.  It’s the cadence of the projects.  It’s where the vital few milestones are established in terms of start, key checks, ship, and post-mortem.  Product cycles on the other hand, are geared towards the product development.   The real key here is that if you have multiple teams, you can standardize on the project cycle, while you let each team choose it’s most effective product cycle or development methodology.  The product cycle would simply feed into the agreed milestones at the project cycle level to support the rhythm at the business level.
  8. Release Planning.    Release planning is a significant body of work.   One of the most important features of release planning in patterns & practices was determining the Minimum Credible Release (MCR.)  This was the minimum product we could ship that would actually be worth it.   To illustrate this to management, we simply drew a cut-line in terms of scenarios.
  9. Scenarios and Stories.   In many ways, scenarios and user stories are the backbone of the product.   They are one of the best ways to set scope.   Scenarios and stories are also a great way to capture and share requirements in a more contextual way.   You get customers to tell you their specific goals and tasks.   If you want to build a better product, then focus on building a great set of scenarios and stories.   These are the backbone of your product.   They set the tests for success.   They are your tool for prioritizing.   To stay customer connected, your customers directly contribute the stories and scenarios, and they help prioritize the stories and scenarios with you.   This is how you build empathy for the customer’s pains and needs.   For examples, see WCF Security Scenarios in Azure and WCF Scenarios Map.
  10. User, Business, and Technical Perspective.   Maintaining and balancing perspectives and points of view is key to successful product development.   You’ll find that a lot of conflict and arguments happen because everybody is “right”, but they are “right” only from their perspective, and you need to know which perspective they are arguing.  The perspectives that you will most often bump up against in product development are user, business, and technical.   If you keep those in mind, then whenever there is an argument or a conflict, then you can do a quick sanity check to figure out what perspective are they arguing from.   When you know this, it is a lot easier to build bridges too or speak the right language.   When speaking to the business, talk about value and cost, budget, and quality.  Or talk about cycle time and efficiency or effectiveness.   Or focus on the “What” or the “Why.”  When speaking to the technical, it’s fine to elaborate on trade-offs, the “How”, and implementation details.  Tech is a great perspective to elaborate on system concerns or quality attributes like security, performance, or reliability.  When talking tech, it’s a great perspective to speak about features and specifics.   When speaking to the customer perspective, here is where you want to talk about persona, roles, and goals.  Or it’s a great place to talk about pains and needs.   A great rule of thumb that has served me well is to speak in terms of “persona-based goals with scenarios.”  See Perspectives Frame and User Experience, Tech Feasibility, and Business Value.

There is a lot more I could say, and a lot more I could share, and I will.   For example, I learned a lot from doing Retrospectives for various product teams around Microsoft.    I also learned a lot on building more effective business cases.   I’ve also learned a lot about doing effective daily standups with distributed teams around the world.  The most important thing though that I learned, at least in terms of helping teams get up and running with Agile, is how to show and share end-to-end life-cycles.   For example, I have a simple model now of the Project Cycle + Product Cycle and the workstreams below each, now in my head.  In a future post, I’ll share what that looks like, if there is interest.

My Related Posts