Share via

How We Adhered to the Agile Manifesto on the Microsoft patterns & practices Team

  • Article

A colleague asked if I could elaborate on how we adhered to the Agile Manifesto on the Microsoft patterns & practices team.    If you don’t know the Agile Manifesto, it’s a short set of sweet values, focused on building better software, flowing value to customers, while responding to change.

Here is my reply …

The heart of the Agile Manifesto is the values:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

You can think of these as operating principles that embrace a set of core values that have proven themselves over time, and add “the people part” back into software, as well as embrace change as a first-class citizen.

Here is how we embraced the Agile Manifesto on the Microsoft patterns & practices team:

Individuals and interactions over processes and tools
A quick conversation could easily save somebody getting lost in the weeds or mired in the muck.

We used face time, even "virtual" face time, instead of a bunch of email.  We established a simple cadence of meetings to stay in sync.  For example, iteration planning meetings on Mondays, and a daily stand up, helped everybody stay on top of and participate in the plan.

Rather than shove everybody into a process or into documents, it was about building effective working relationships, and spending more time in conversations.  This was especially helpful for complex topics and issues, that could easily turn into long, emotional emails.

Working software over comprehensive documentation
Rather than get bogged down documenting, it was more action-oriented.  The goal was to produce working solutions, incrementally, and test the path as we go.  To do this, we would focus on capturing user stories, prototyping the solution, then getting feedback on the solution with the customer.

That does not mean the documentation was not valuable.  It does mean that we put a priority on building and testing the solution, so that the documentation has a firm foundation to build on.  What it also means is that rather than depend heavily on attempting to capture and share requirements as text, we spent more energy on internalizing and embracing the requirements, with empathy, by working with customers, and feeling the pain.

Something gets lost in the text, and if I had to put my finger on it, it's empathy, and that comes from shared experience.

Customer collaboration over contract negotiation
At the end of the day, this is about rapport.  If you pair with the customer and co-create the solution with them, and bring them along on the journey, they are with you.

If, instead, you try to bind them to a contract, and tell them how every time they want to make a change, they can't because of what they agreed to earlier, you are simply creating a bigger divde for the customer, and your team.

The reality is, it's often less about requirements "changing" and often more about gaining clarity on the true requirements.  Pushing the pain of this reality back on the customer is convenient, but ineffective, for all involved.

Responding to change over following a plan
This really builds on the previous, but the big ideas is that rather than fearing or fighting change, you embrace it.

What keeps you grounded is having a plan to begin with.  Another thing that keeps you grounded is having operating principles, and clarity of the end in mind.  The most important thing though is having trust in your process.  You have the trust the process you use to flow value along the way, and value adds up.

If you are not flowing value, you have a problem.  It will not matter how good or great you thought your plan was.  That's why it's called a plan, not reality.  When the rubber meets the road, the unexpected happens.

How did we respond to change?  We stayed open to the idea that we were wrong.  Sure we tried to get the risk out early and often, but risk happens.  We stayed connected to the customer so that we could understand what's actually valued.  We used our iteration meetings to do a reset as necessary, and we would use project reviews and checkpoints as a way to readjust the bigger plan.   The way we reduced the risk here overall is by having a timebox and resource constraints.

The upside was that we could continuously adapt and adjust as we got more clarity on what's truly valued.