How I Used Agile to Create Super Successful Software

“The way a team plays as a whole determines its success.” — Babe Ruth

I created software (and other solutions) at Microsoft for several years.

It’s nice now and then to take a look back, and really figure out the core of what worked (and what didn’t).

I reviewed my model for how I shipped super successful software back in patterns & practices.

I learned a lot each time and tested different ways, but there was a core pattern that worked very well.

In a nutshell, the main approach was to create a cadence for shipping stuff.

I built a habit of getting the trains leaving the station, and if you miss the train, don’t hold the train back…catch the next train.

I focused on weekly iterations so that the team could feel good about the week’s results.

Plus, it shortened the iteration planning by just worrying about the week (and it better focused people on right here, right now).

An Example of a Weekly Cadence

So my week looked like this:

• Monday Vision / Iteration Planning – 30 minutes
  • Identify 3 wins for the week for the team (the vision for the week expressed in terms of outcomes or wins)
• Daily Stand Ups – 10 minutes – around the horn – 1) what did you get done, 2) what are you getting done, and 3) where do you need help
  • I enforced the 10 minute box – even with 14 people around the world – I would hang up at the 10 minute mark
  • People got crisper and it kept eh energy strong knowing that our 10 minute meeting wasn’t a disguise for a 20 or 30 minute or longer session
  • It got people used to parking lot stuff or having a separate drill-down on hot topics – and this meeting was really a quick session for clarity and changing priorities
• Wednesday Ship Day
  • I shipped on Wednesdays
  • This stopped ruining Fridays
  • This gave folks time to fix stuff before the weekend so they could have a weekend
  • It was fun for users to get something mid-week while the energy was still strong, before fading to the weekend / end of week
• Thursday Demos
  • This gave folks on the team a chance to show and share their great work – and get appreciation by the team
  • This gave folks a chance to give each other better feedback (and learn empathy)
  • When somebody demoed it changed their perspective – suddenly they wish they put that button here or called that option something else
  • I periodically included customers based on how baked things were or the comfort level with the team
• Friday Reflection
  • Post mortem personal results / team results – feed learnings into next week
  • No fire drills, no hustles – decompress from a high value week
  • Tell the story of 3 Wins for the team

You might say it’s effectively a vision-led and value-driven approach.

Supporting Habits and Practices for Successful Software

I did fancy stuff like axiomatic design based on concepts I hacked with Corey Ladas and others.

But the most basic thing I did that really helped is that I organized an information model for the software.

I created user stories using the simple approach of:

“As a user, I want to X so that I can Y”

I used the user stories to chunk down value so we could flow value (and communicate and prioritize value).

I organized user stories in a simple frame of getting started, core, and advanced/niche.

I organize the MVP in a very simple way – with very simple demos and to really reflect a good, friction-free “first-time experience”

I taught the development team to be clear about the distinction between the user stories and the developer stories (for the tasks).

I focused on “experience-driven” development – to really teach the team empathy through doing demos and “feeling” the user experience.

When I did design reviews, I would actually do them around the user stories (and system stories, too).  For example, when showing a screen that pages through records, go into the security and the performance and the usability concerns.

I also focused on creating system stories for quality attributes (security, performance, reliability, etc.).  I think Agile practitioners that did not explicitly focus on system stories, missed out on entire classes of quality attribute challenges.

Mind Map the Balcony View of the Program/Project

One interesting exercise I did with the team early on to create a balcony view of the challenge before us was to co-create an all up map of the Product + Project work to be done.

I did this by creating a Mind Map and just going around the room as each of us talked about the high level activities and outcomes for each area.  It helped the team build appreciation for all involved parties – by looking above, below and sideways – and to see how different activities impacted other parts.

Bring Out Everybody’s Best…

My real goal was to get more out of the team by helping everybody give their best where they have their best to give, by creating clarity, generating energy, and empowering everyone to make things happen. (And sometimes the best thing I could do was to just get out of the way).

As a Program Manager, the non-obvious and most painful thing I did was to be “the oil and the glue” for the team… to grease things where they were stuck, and to hold things together in a common frame with shared vision, mission, and goals.

Kanban, Long-Range Planning, and Frequent Experimentation

I shared my core process with a friend, Eric Brechner, and he pointed out a few very good additional tweaks and optimizations:

• Kanban.  Shifting from Scrum to Kanban provides more flexibility, shorter standups, and continuous deployment.  Standups can focus on where people need help, since the Kanban board shows the rest.
• Long-rang planning.   Eric says a real key here is planning around dependencies, and he likes the approach “Manual, social intensive” he writes about in Chapter 7 of his book, Agile Project Management with Kanban.   He says another key here is using the McGrath and MacMillan Options Portfolio for a balcony view, which he also describes in his book in the same section, and in his post, It’s Business Time.
• Frequent experimentation.  Here Eric recommends frequent experimentation with A/B tests with prototypes to let customers and data inform and shape the best design.

I’m with Eric when it comes to testing ideas and designs with customers early and often.

I’ll share more on my approach in a future article.

You Might Also Like

Agile Results for Teams and Leaders
Experience-Driven Development
How Agile and Lean Help Business
How To Lead High Performance Teams the Agile Way
How User Stories Help Leaders Learn Agility
Kanban for High Performance Teams
What I Learned About the Triad of User Experience, Tech Feasibility and Business Value