Do it faster, better, make an impact … or fail fast, and move on!

In April we shared the Managing Agile OSS Projects with Microsoft VSO eBook sharing how we manage solution requirements and ship solutions in an agile environment. An environment we discussed in Radio TFS and the GREAT curve ball question about (ex-nightmare) shorter delivery cycles, which is continuously changing and, as you have probably already guessed, triggered this post.

Special thanks to Anisha Pindoria and Rui Melo, who engaged in in-depth discussions on our continuous evolution and helped me review this content.

WHY are we revisiting our fire-and-forget projects?

A few months ago we introduced rolling triages and fire-and-forget projects enable us to increase responsiveness and diversity and dog-fooded the concept with the teams that delivered the Visual Studio Team Services Extensions from the Rangers. In hindsight the “forget” was a poor choice of word.

What worked well?

  • Most teams were autonomous and self-organised, churning out amazing ideas and innovation.
  • Most teams were able to make phenomenal progress, leaning on the Program Managers to focus on impediments.
  • We started with 13 extension teams and all delivered!

What did not work so well?

  • Some teams “forgot” about the milestones and ended up in an unfortunate last-minute fire-storm.
  • Some of the teams struggled with the “freedom” and required the Program Managers to coordinate.
  • Most importantly the importance of scope and the definition of done (DoD) became very clear as the teams started showcasing their solutions. As shown below, if (1) the product owner fires the request “I need a smart transportation solution” and then forgets the team, the (2) delta deliverables varies.
  • In some cases (3) the solution === the PO’s expectation, or (4) the solution appears flat, and (5) the solution == the PO’s expectation.
    It is probably only obvious to the JavaScript and TypeScript developers, who appreciate the difference between == and ===, that most of the solutions did not match what the product owner was envisioning, without making any compromise.

WHY are we revisiting our project process?

The core concepts of Scrum, as shown in the diagram below, will remain to be our solid foundation. 


Based on observations and looking at the recent success stories, the move to Kanban is the right decision for most of our teams. I would state “all” teams if we had not introduced the notion of self-organisation, autonomy and fire-and-forget … which should really be called start-and-observe, but we can debate that at some other time.

WHAT are we proposing?

We are proposing three fundamental changes to our process and would appreciate your candid feedback, thoughts, and experience to help us fine-tune and perfect the process.

  1. We do less.
  2. We do it better.
  3. We fail fast if needed.

Looking at the diagram below, this is what we are thinking:

  1. We always start with an idea, the more the better. The only idea that is bad is the one that was never shared!
  2. The ALM Ranger Program Managers triage the idea. If it is not aligned with our mission, we need to reject it (fail fast) and move on.
  3. We need a committed and passionate product owner, who clearly defines the scope (what, why) and expectations.
  4. We need subject matter experts who are also passionate about the idea, potential solution, and agree with the expectations.
    If the product owner or subject matter experts are missing, we do not have a team and need to shelve it until the conditions are right (fail fast).
  5. The team needs to investigate, prototype and plan the release(s) in one or more sprints. It is not a sprint 0! Martin Hinshelwood you can take a deep breath and relax!
  6. If the investigation is not positive, we need to ground the flight (fail fast) and move on. If we have a feasible and well crafted plan (backlog), a definition of done and acceptance criteria that matches the product owner expectations, we are ready for “take off”. We will only show “in flight” projects in our sprint summary emails and the public status boards. The teams can peruse our backlog to track projects that are in research / investigation mode. This enables us to fail fast and silently, before we raise expectations … or would you expect to see suggested flights on the departure board at an airport as well?
  7. After the idea phase (research/investigation), we restrict each release to 2-3 sprints max (do less), which requires solid sprint planning and prioritisation.
  8. After every sprint we need to review a minimally viable product, to validate that we are on course, or in a position to re-align.
  9. After 2-3 sprints we return to the pool of ideas, which could be unrelated to the solution we just shipped, or a vNext.
  10. If conditions are not ideal, we correct the flight or fail as fast as possible. Dragging an imperfect team, or a meaningless solution across the finish line is just not worth it.


To summarize, we need an idea, a committed and passionate product owner, an experienced and passionate team, and a proposed solution that will make an impact (do it better) before we commit to a project … else we fail fast and move to the next idea.

WHAT about transparency and community contributions?

11. We plan to share ideas and planning on our team blog in future.

  • It will create noise, but will give you an insight into what we are thinking about and why.
  • More importantly you have an opportunity to give feedback and influence the team.

12. We plan to share more of our solutions on GitHub as Open Source projects.

  • It will give you an insight into how we are building the solution.
  • It will give you an opportunity to contribute to the solution.
  • If and when a solution appears on GitHub “depends” on a number of factors, but the earlier the better.

In a nutshell, we want to turn our transparency dial even further and start accepting contributions from the community.

OK, now it’s your turn!

What do you think?

Please share your thoughts as a comment below or ping us here.

Comments (0)

Skip to main content