There is no Success or Fail, only Learn

I have been in discussions both in-person and on twitter with colleagues on whether we should use the word “fail” or “learn”.  This was in context to projects (aka, releases, increments).  Did they failed or did we instead learn.  I also realized that the term “fail” is somewhat subjective (e.g., did the whole project fail or just parts of it?).  The overwhelming agreement was that “what did we learn” was a better way to discuss the findings or results. This lends itself to a shift in mindset, to a continuous learning environment that recognizes that there is value even in the negative feedback.   We can learn from that feedback and adapt for better results in the future. 

Then it occurred to me, the term “success” was also a bit subjective.  I recall reading a Standish Group Study where those projects that were “deemed” successful, 45% of the features were never used.  Another 19% was rarely used.  This meant that projects deemed successful built 64% never or rarely used features.  That seems to be a very loose definition of what “success” looks like.  In addition, how many projects are deemed successful because it met the scheduled deliver date yet few customers upgraded to it or bought it?  Is there a benefit to use the term “learn” in place of success?

While it may sound feel like the terms success or fail are the way to traditionally judge a project, release, product, or service, we lose sight of the most important result of the work, the feedback and what we learned from that feedback.   This learning helps us adapt to achieve better results.  If you are working in an Agile context where there are short increments of work, there is the benefit of continuous learning where you can continuously adapt for better business results.

I would suggest in the modern lexicon of work, when a project, release, or increment of work is done, it is much more important to ask what was learned instead of classifying it as a success or failure.  This strengthens the mindset within the organization that there is a value in feedback and the most important thing is what did we learn.  It also emphasizes a discovery mindset where what we think a customer wants is really a hypothesis that must be explored.  It is in the learning that can help us lead to better business results in the future.  So next time people talk about a project as a success or failure, instead turn the discussion around and ask “What did we learn”?  

Are Google’s OKRs compatible with Agile?

A collaboration by JP Beaudry and Mario Moreira

Recently, someone asked us if we thought that the Objectives and Key Results (OKRs) used at Google and applied at Intel in the 1970s is compatible with the Agile mindset. In order to refresh our understanding of OKRs, we reviewed the Rick Klau presentation on How Google sets goals: OKRs. After examining the characteristics of OKRs, and with a few open questions, we are of the opinion that for the most part, they can be used in support of the Agile mindset. 

To provide a basic understanding, OKRs is a technique for setting and communicating goals. The first part, the objective, is the outcome that is sought. While the second part, the key results, is comprised of 3 to 5 specific and measurable pieces of evidence of progress against the objective. OKRs can be cascaded and refined at various levels in an organization. In order to allow people to be bold and think big, the guidance is that only about two thirds of OKRs be completed within a given period of time. To promote transparency, everyone’s OKRs are publicly accessible and graded.

Now back to the key question – Are OKRs compatible with Agile?  Based on our examination of OKRs, here are some reflections:

Ambitious - By design, OKRs should only be met or succeed about two thirds of the time. This lines up well with the general desire for organizations to be more innovative. There is a broad agreement that innovation is inherently uncertainty/high beta, and that a certain amount of failure/learning is inevitable. A goal of imperfection makes it safe for people to take chances

Measurable - Measurable outcomes are critical in determining whether one is getting closer to the stated objective. This is well aligned with Eric Ries’ concept of Validated Learning. It also plays well with Mario Moreira’s framework of a Lagging-to-Leading metric path. 

Public - I’m sure the public display of OKRs does wonders for creating alignment on priorities. This is because it makes it so much easier for all stakeholders to notice, and more importantly correct, misalignments. So much the better if the full cascade from strategy to team-level user stories is visible in one place. 

Graded - Grading OKRs forces participants to confront reality. Without an explicit process step where results are confronted, it’s too easy to skip the learning step. Without the result-driven feedback, roadmaps cannot be updated.

Because we haven’t worked with OKRs on a sustained fashion at scale to date, we have a few open questions on how they would fit in an Agile environment:    

Individual or Team

At what point does the individual accountability get in the way of teamwork? Most Agile organizations spend a tremendous amount of energy creating high performing teams. It seems that individual OKRs could undermine teams

Local or Global Optimization

A corollary is how to prevent local optimization that could make top-level objectives more difficult to attain. Would OKRs promote a narrow view?

In summary, it seems to me that the Objectives and Key Results (OKRs) technique has several characteristics that make them compatible with Agile environments, and few obvious downsides. The fact that OKRs are also used at LinkedIn and Twitter seems to provide further evidence of their usefulness in innovative environments. 

If you have experience with how OKRs can be used in an organization that values Agile and the discovery mindset, please consider sharing.  Bonus points if you can shed some light on the open questions in the article.  

------------------

To read more of JP Beaudry's articles, visit: http://www.thepragmaticleader.com/   

To read more of Mario Moreira's articles, visit: http://cmforagile.blogspot.com/

Startupbucks (aka Starbucks) the OaaS Innovation Incubator

As I was momentarily pausing from working on a presentation, I leaned back and noticed that there was quite a bit of “business” occurring in my local Starbucks.  There were a lot of enthusiastic conversations with a collection of open laptops, notebooks, tablets, and more being used to share, illustrate, and note ideas.  This wasn't the first time I’d seen this same level of engagement in a Starbucks. 

Then something occurred to me.  I was witnessing an incubator of business, non-profit, and personal ideas being generated and matured.  Of course some people are there for just a coffee and a chair to relax.  Others are there for a quick pick-me-up for the day or remainder of the day.  Alternatively, it was clear that Starbucks was this place where business was happening, where new ideas were being generated, where collaboration was happening, and where progress was being made.  It was an incubator of innovation! 

That’s where it occurred to me, Starbucks was part coffee shop and part office-as-a-service (OaaS) incubator.  I therefore have redubbed Starbucks to Startupbucks!  The first part of the name (Startup) is a place where new ideas come to life and blossom surrounded by the aroma of coffee beans.  The second part of the name (bucks) is coincidentally where hopes for financial reward is part of the innovation dream.   I wonder how much business has been conducted in Startupbucks and much money this translates into?   Next time you are in Starbucks, take a look around.  Are you seeing the same thing that I am?  Finally, thank you Starbucks and the many coffee shops like you for providing us this OaaS that makes a great incubator of ideas and haven for progress!    

How can Portugal be a Technology and Business Leader on IT thru Agile practices?

The following is an article written based on an interview with Mario Moreira:   

Portuguese Companies have to combat risk aversion and rediscover their Vision of Discovery

This perspective is by Mario Moreira who specializes in Agile.  He was the keynote speaker during the first ScrumDay held in Portugal.  The initiative focuses on Agile and Lean approaches, where it promotes a philosophy of continuous adaptation to accelerate the ability of organizations to respond to change, as did the Portugues in the time of discoveries.  

Author of the book Being Agile: Your Roadmap to Successful Adoption of Agile, a blog on Agile Adoption, broad experience in this area, and a Vice President of Client Engagement at Emergn, he argues that Portuguese companies have to change their risk averse culture and improve adaptation strategies toward constant changes of the market, in order to maximize the opportunities for success in a global competitive landscape. And this is Agile, a concept which includes a set of adaptive concepts and software development methodologies that Mario Moreira came to Lisbon to help publicize and demonstrate at this event where in the morning featured presentations and afternoon joined the participants in a think tank.  

"At one point in history the Portuguese were the greatest explorers in the world and this was because we had the right mindset. We did not just go to India like everyone else," he stresses. "We decided to take some risks, to try something new with the awareness that we could bring great benefits. We need to recover that mindset," adds Mario Moreira."

To get there, we need to circumvent the risk averse culture constraining the Portuguese, because "the market is increasingly competitive and customers are demanding changes every day," said this expert, "considering that companies - in Portugal and the world - must increasingly be prepared to face these changes, trying to adapt to them, and this is where Agile can help."

The method gives flexibility to organizations to adapt to new inputs in the course of projects and promote the involvement of various actors, such as the client. Scrum fits this universe, as a framework for organizing and managing complex processes.  It is an alternative to traditional models, which are guided by a budget, a deadline and a chain of rigid decisions, together with a set of initial assumptions that are maintained throughout the project.

Mario Moreira argues that a market dominated by small and medium enterprises, as the Portuguese, the Agile philosophy makes even more sense because they are smaller companies who feel more pressure to respond on time to market requirements and its customers. They have less room to fail in terms of resources and too much competition.   

The original Portuguese version can be found at http://tek.sapo.pt/noticias/computadores/artigo/empresas_portuguesas_tem_de_combater_aversao_ao_risco_e_reencontrar_visao_dos_de-44423qlz.html