Is Agile really Dead? Myths and beliefs on what Agile means today

I would like to share with you our thoughts, here at Beyond Lean Agile, about a much-discussed topic in the community.

More and more people keep stating that Agile is Dead and we want to shed some light on this phenomenon.

Photo by Jonathan Bowers on Unsplash.

A few days ago while having my coffee break, a moment of the day I really enjoy, I was catching up on some of the articles I’ve been meaning to read, to keep up with news from the community and industry.

I was reading “So If Agile Is Dead, What’s Next… Flow? by Fin Goulding”.

Immediately after finishing the article I’ve challenged my great friend and colleague Mike Sousa, to write our own piece on why we think Agile is Not Dead and share our arguments on the topic.

Before getting started we would like to make a disclaimer:

  • What you are reading here is not a criticism to the article written by Fin Goulding, rather it was inspired by the topic he approached and the claiming that ‘’Agile is Dead’’ as so many others that currently are available. We strongly believe that having different ideas and opinions is what helps us to keep learning and improving. Through the article, we will present our thoughts and bring some balance and support to the true meaning of the Agile Mindset definition.

Up for a challenge?

Before we dive into the topic,  we challenge you to do a quick Google search about “Agile is Dead”. For sure you will see that nowadays there are a huge number of articles and talks on this topic.

Screenshot taken from Google Search about “Agile is Dead”.

As we see it, all the headlines in the news about “Agile is Dead” are creating a lot of confusion and some people are really believing that this death of Agile is because it doesn’t work. Many times Agile is implemented with lightness and incomplete, or with the belief that it will be the “Silver Bullet” to solve all the problems. This thought leads to drastic and hasty conclusions about the efficiency of the mindset/methodology while disregarding essential factors such as culture, environment and customization.

What are Agile ‘’CAPITAL SINS’’?

While browsing through the numerous google results from our ‘’Agile is Dead’’ search, we found many ‘’points of accusation’’ sustaining the concept.

Since the purpose of our article is to defend the status of ‘’not guilty’’ it is only fair to have a look at the aspects people find of faulty with Agile:

  • Using non-tech staff to manage projects reduces the quality of code and refactoring;
  • It has a range of inapplicability for more non-technical functions;
  • Attempts to scale Agile to reach strategy fell short;
  • As opposed to Lean or Six Sigma, Agile is meant to increase volume;
  • Instead of a framework, Agile is more a marketing tool;
  • Low visibility of the software utility and performance makes it impossible to calculate ROI before the development starts;
  • Systematic study and observation can teach organization and be able to differentiate between self-inflicted problems and those problems you can’t control;
  • Last but not least, the initial guiding principles lacked one essential element – having the Agile Mindset.

When going Agile, there are several challenges, from setting up individual teams to clearly communicating the benefits. However, the biggest challenge remains to get the interfaces working properly and make teams and the organization itself, leave the old ways of working and assist them in adapting what is new.

Let’s start with the basics…

Before we start drilling down into the subject of this paper, we would like to give some context and make sure everyone is on the same page.

If we do a quick search on “What is the definition of Agile” we find that Agile is the ability to move quickly and easily. This means that Agile helps us to achieve performance, innovation while delivering fast and obtaining customer satisfaction.

Agile doesn’t mean ‘’do/say” what I want nor does it commit faster without factoring in all the risks, dependencies while lowering the delivered quality.

We believe the issue with the statement ‘’Agile is Dead’’ starts with understanding what Agile really means.

There is another great definition saying “Agile enables organizations to master continuous change. It permits firms to flourish in a world that is increasingly volatile, uncertain, complex and ambiguous” from the Forbes article “What Is Agile? by Steve Denning”.

By coincidence, or not, Mike Sousa and I, attended the Agile Portugal 2018 Conference on the 25th of May 2018 and during the talk “Devops: The continuing evolution of operations” we heard Gareth Rushgrove share this Agile reminder:

Picture taken at the Agile Portugal 2018 Conference from the talk “Devops: The continuing evolution of operations” by Gareth Rushgrove.

So, why do people keep saying that “Agile is Dead”? Let’s think about what is Agile to us? What is our definition of Agile?

Agile is the founding mindset stone, based on which all the frameworks, systems and operating models are defined.

Photo by Martin Sanchez on Unsplash.

This means that before it all, what we really need is to understand the mindset properly and then develop the methods to adopt/do Agile in the right way.

After all, Agile is based on inspect and adapt (continuous improvement), culture, trust, collaboration and delivering value. This for us is the most basic Agile definition. All next steps can be adapted.

Why we say this?

It’s simple… Should we stick to a standard framework, system or operating model? Or should we be Agile and first of all understand what is the problem we are trying to solve and customize what operating model works for our business reality?

Let’s take a look at Spotify. Did they follow/adopted an existing operating model or did they go an extra mile to really understand what the problem was they wanted to solve? They went the extra mile and customized their operating model (Spotify Tribes Model) to respond to their real needs. Also, did they stop or did they continuously improved their operating model to constantly respond to their needs?

Like Spotify and Amazon, we have more companies that keep improving their ways of working every day so they can constantly exceed their goals.

So, returning to the Agile ‘’CAPITAL SINS’’. This is why we believe that the sins are not real:

  • Using non-tech staff to manage projects reduces the quality of code and refactoring;

Using non-tech staff to manage projects does not reduce the code quality since they shouldn’t be the ones writing or reviewing the code. There is a reason why there are different, well-defined roles when using any Agile methodology, so we can use the strength from each role and create dynamics. Diversity is what makes a team, project and business to succeed.

  • It has a range of inapplicability for more non-technical functions;

As we shared above, for us Agile is a mindset, the founding mindset stone. This means that any framework, system or operating model can be applied to any area and/or business.

For more details and examples please check our previous article “Can Agile be adopted by non-software development areas?

Most of the attempts to adopt or scale Agile fail because we are missing the most important point that is understanding what it really means. Understanding that Agile is about seeking to get better by continuously scanning the environment/process while empowering people to do so is the key element into extending the concept to a strategic level. It is people’s by in adopting the mindset that will allow large-scale success and focus on what is actually important for the business. The Agile Mindset helps tailor successful custom solutions and copy-pasting something designed for an organisation with different goals and challenges.

  • As opposed to Lean or Six Sigma, Agile is meant to increase volume;

Agile is the founding mindset stone also for Lean and Six Sigma since it provides the ability to move quickly and easily. It empowers organisations to respond to the constant changes and increase “customer satisfaction”. While a highly efficient and autonomous team will produce more in a shorter time, the end goals are to optimize resources, reduce waste and increase customer satisfaction.

  • Instead of a mindset, Agile is more a marketing tool;

Unfortunately, in many cases this is true. Nowadays people are selling Agile as a silver bullet solution since companies are being forced to “become Agile” due to the high trend in the industry. Being Agile is the magical word or the catchphrase that seem to be attracting more investments or increase sales and success rate.

Quoting Todd Little from the Forbes article “What’s Missing In The Agile Manifesto: Mindset” by Steve Denning.

“The first line of the Agile Manifesto is about valuing individuals and interactions ahead of tools and processes. Yet what do we see being sold in the marketplace, but processes and tools? Agile has become way too much about processes and tools, partly as a result of the way the economic engine works. People are looking for, and buying, processes and tools, when it should be about the Agile mindset.

That’s the challenge we face in keeping Agile truly Agile.”

We also have some common experiences were companies hired consultants to bring or define the  “magic solution”. However, after implementation, these companies declare themselves as being Agile, while in reality, they operate more or less the same while having invested in a concept that will not work if people don’t incorporate the mindset.

  • Low visibility of the software utility and performance makes it impossible to calculate ROI before the development starts;

We can forecast ROI but this will remain an estimation calculated for possible scenarios. While we are aware that ROI is in most cases a financial measurement of success, we are also focusing on the less tangible gaining’s. What could be a higher ROI than small and fast iterative deliveries with the capability to constantly have customer satisfaction? With these small chunks of continuous deliveries, companies have almost immediate ROI and the possibility of increasing product/service value by adding constant and real feedback.

  • Systematic study and observation can teach organization and be able to differentiate between self-inflicted problems and those problems you can’t control;

Systematics studies and assessments are important for gathering data and preparing us to respond to problems especially to the ones we can control. This data gives the ability to constantly inspect and adapt to the real work is – this being actually the Agile Mindset in action. We need to keep in mind that there is not always to problems exactly the same that the same solution will work. The world is constantly changing and problems evolving into different ones due to the higher and hard competition. As we can see what worked 10, 20 or more years ago is not working nowadays anymore.

  • Last but not least, the initial guiding principles lacked one essential element – having the Agile Mindset.

As explained above, we can say that we embrace Agile, that we follow the values and principles but if we don’t have the mindset record in our mind we have a breach to Agile adoption fail with time. This is something that we believe that we need to understand, believe and breed.

Does this mean that Agile is Dead?

Off course not! 🙂

Agile is not a framework, system or operating model, is much more than that!

We understand that the word is imprecise and many people really don’t understand or misuses it. Still, this is why we emphasize the fact that understanding and truly adapting the mindset sits at the bottom of a successful implementation. Moreover, we want to help people understand what Agile really means and testify that it can be the solutions for a smooth and sustainable continuous improvement process.

It would be great to hear your thoughts on this topic.

Last but not least, we’d like to give a special “thank you” to Anett Stoica for the article revision and all her feedback. Thank you!

#agile #agilemanifesto #agilemindset #agileadoption #agileisdead #forbes

Agile Online our new online community

Hi Portuguese and all Agilists!

Yesterday I had the pleasure to attend a live webinar (Descomplicando Agilidade) hosted by our Agile colleagues from Brazil.

One of the discussed topics was about the communities around the world, in particular, how they work and their challenges.

This discussion made me realize that we do not have an online community/channel where we can bring everyone together to share experiences and ideas, so we can all learn and grow together.

Having said that, I would like to share that I’ve created a Slack Channel called “Agile Online” as an action inspired by the discussion mentioned above.

Thanks to the Brazilian colleagues for the great tip!

Do you want to join this new community? Use the following link (Agile Online Community) to join and don’t forget to share the link with all Agilists.

Disclaimer: Please don´t use this channel to sell training or consultancy.

#agile #agilecommunity #agileonline #agilists

Can Agile be adopted by non-Software Development areas?

Agile is around for quite a while now and became a de-facto standard. Still, in this time span, it has always been regarded as part of the software development process.

But why? Why is that every time I talk to anyone outside software development (Person/Teams/Business) they reply: “Oh, but we are not a software development team!”.

Since the first time that I got this feedback, I have been trying to understand why people have this reaction. I have been reviewing my past experiences to understand what could be the trigger that makes people react this way.

Eventually, I had discovered that I was not the only one doing the same analysis and trying to understand why this was happening and, most importantly, how could it be fixed and how could I help other areas to embrace an Agile Mindset.

This was the moment that I challenged my great friend and college Mike Sousa, so we could work together and write this article where we share our findings, past experiences and our case studies.

“Our faces (Eduardo Ribeiro and Mike Sousa) after agreeing in writing about this topic and share our finding and experiences.”

I’d like to give a special “thank you” to Alexia Sousa for the background poster 😉

Before we start drilling down into the subject of that paper, we would like to give some context and ensure that everyone is on the same page.

The Agile Manifesto was created in early 2001. The main reason was to improve/solve problems related with the way software projects were being delivered and managed. The main issue, at that time, was that most projects were managed in a strict approach, based on micromanagement, that didn’t make people happy. Their minds were not open to the idea of “fail fast learn faster”. Moreover, the delivery was, most of the times, late and with no added value to the business.

And in the Manifesto for Agile, as you can see, the expressions “Software Development” and “Working Software” go together.

Screenshot taken from the

Agile adoption has become the ‘trend’ and nowadays most of the companies (mainly related to software development) have, in some way, joined this trend.

But can the original intent of Agilists towards software development cross over to other areas?

Our experience says “Yes, it can!”.

We believe that if you change the word ‘software’ from the Manifesto by another ‘value’ you want, it (still) works perfectly and makes full sense.

Just as an example…

Manifesto for Agile HR

We are uncovering better ways of recruiting

By doing it and helping others to do it.

Through this work we have come to the value:

Individuals and interactions over process and tools

Working Recruiting over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan


As we adapt the message of the Manifesto to their reality, people became more open and willing to accept our help and support. A simple re-wording was our missing trigger that changed their attitude, from blocking us to at least listen to what we have to say. We could then work together and find new ways to improve the way they work and how the Agile Transformation could be included in their processes increasing the value they are adding to the business and their customers.

If before, the feedback was not so positive, and they had a lot of pain points; after this short initial phase of transformation, the mindset was already changing considerably. People started to see that visible improvements were taking place, which naturally changed the feedback into a more positive one.

A few of the areas that we have already experimented with are HR, Finance, DevOps, Networks, Support Teams, etc.

From the list above, let us show you some details from two of them, in this case, HR and DevOps, as examples:

  • HR
    • What were the issues that they wanted to solve?
      • There was a lot of feedback, both from the team and their stakeholders, related with the lack of organisation building pressure on the team. The lack of a clear view of what was in-progress and were new requests raised challenges to expectations’ management: no delivery of incremental value was perceived, and customer engagement was low. These were creating a false sense of delivery since many times, due to the lack of detailed requirements, the final delivery was taking longer than expected.
    • How was the adoption?
      • This was an extremely smooth adoption. We used the above approach, what created a receptive mood, turning HR personal open to adopting change. The most impressive change in behavior was the engagement and ownership. In a short period of time, their ways-of-work (WoW) started to improve; feedback from the team and stakeholders was very positive. We decided to use a hybrid approach (Scrumban) that helped HR to improve the way they were planning and managing their work while keeping the flexibility to accept short notice requests which were regarded as high-priority to business.
    • Any challenges?
      • The initiation phase was challenging since HR had to spend a significative amount of time in reviewing their WoW and how they would like to start working in a near future. Moreover, there was the need to gather information on their workstreams, so that they could have a clear view of what was already on their plate that they could start using immediately.
    • How do HR and their stakeholders perceive the team now?
      • Everyone involved in the process has a clear view of what is happening and on what each other is working on, with stakeholders feeling more comfortable and trustful towards the team’s delivery.
    • Also, how does everyone feel after the adoption?
      • Their enthusiasm and engagement is high, what is creating the will to keep on improving by analysis of what they can and want to improve next.
      • Interestingly, after a couple of months of this HR Agile transformation, the Harvard Business Review published an article addressing this topic. For further details, please refer to the full-body of the article “HR Goes Agile by Peter Cappelli and Anna Tavis”.
  • DevOps
    • What were the issues that they wanted to solve?
      • They were struggling with two big distributed teams, not relating and collaborating that well; both due to distance and culture.
      • The ways of working were not known by all, and different team member, even from the same office were following diverse ways to deliver value.
      • They were not following priorities properly, and mixing support, project and research.
    • How was the adoption?
      • Not easy at first… but the turning point was when we did an off-site with everyone in one single room. We created an entire day just dedicated to the Agile transformation, with Games, discovery sessions, sharing sessions, collaborative sessions, etc. These allowed us to bring awareness that:
        • Some work was being done in different ways which were creating some communication issues.
        • Following different processes also created different expectations for delivery and definition of Done.
        • Sharing knowledge helps to go further in the delivery and team motivation.
      • In that session, we started by creating and explaining what a Social Contract is and how it can help the team to come together.
    • Any challenges?
      • The teams were not keen on using Agile, mainly due to a misconception about what that would mean. Once we removed those wrong ideas about agile, the defense barrier went down and they could embrace all the advantages that we were trying to provide them with an Agile mindset.
    • How do DevOps and their stakeholders perceive the team now?
      • We are still in a very initial phase which does not yet provide a lot of insights (only two months), but the feedback got so far is that they see the team working better, communicating in a more positive way. They also said that ‘they see the team more open to innovative ideas and to experiment new ways to improve their work’.
    • Also, how does everyone feel after the adoption?
      • Everyone, or almost everyone, identified as positive the Agile mindset adoption. And they are also identifying new things they want to try.

Our conclusion is that it is evident for us that the Agile methodologies can be successfully adopted in other areas than originally intended, meaning beyond software development. For this, it is also important to have certifications and training existing beyond software development; allowing everyone that wants to use it, to have a way to understand the concepts behind it and how to best make use of it. Doing a training/certification that is all turned into Software Development will only create doubt and confusion in the minds of those trying to follow a new way that is not software related.

Also, once more thing that we need to consider is that Agile Culture is very important to the millennial generation and that in the next 10 years, the workforce will be significantly comprised of millennials, a generation that loves speedy, short and direct communication. For further details, please refer to the full-body of the article “Why Agile Work Cultures Are So Important To Millennials by Larry Alton” published in the Forbes.

Our challenge to you is this: did you lead, participated or witnessed an Agile transformation in a non-software development team? Why not share your experience on how you have dealt with it, what were the challenges, and how did it work? It would be great to hear your learnings.

#agile #agility #agilemanifesto #hr #finance #devops #nonsoftwaredevelopment #softwaredevelopment

Food for thoughts… This time from the Harvard Business Review Magazine!

Is Agile an officially CEO’s responsibility?

Find it out in this month Harvard Business Review Magazine about “Agile at Scale”, by renown authors: Darrel K, Rigby, Jeff Sutherland and Andy Noble.

So do you agree? It would be great to hear your thoughts on this responsibility matter.

#agile #agility #scale #hbr #harvardbusinessreview

Food for thoughts…

What an amazing Paper “2017 State of DevOps“!

One of the highlights that caught my attention was their focus in the culture of continuous improvement and continuous learning that helps the company to keep it self-innovative in the long run and help you stay ahead of the competition.

Moreover, they clearly show the difference between high and low performant organizations.

e.g. High performers deploy 46x more frequent code deployments and 440x faster lead time from committing to deploy.

Quoting them “The more we deploy the more we can have faster feedback from the costumers”.

Another great topic is the Lean Product Management Practices that is been adopted by several organizations. These practices drive higher organizational performance because they create the will to try out new ideas and update specifications during the development process.

#lean #agile #continuousimprovement #devops #highperformaceteams #change


What is the best way to influence, based on my experience

Today I would like to share with you a few thoughts about the best way to influence others, based on my experience.

To give you more context, yesterday I came across an article with a very interesting quote from Albert Einstein saying:

“Leading by example isn’t a way to influence, it’s THE way to influence.”

This quote got me thinking, so I carried out a quick retrospective of all the leaders, managers and peers I came across during my career. The aim was to identify which was the most important characteristic that made them great influencers.

As you know, we live in a world of constant change and it’s vital that we keep inspecting and adapting to succeed from a business, professional and personal perspective. So, why is it that, with all our current resources (e.g. Training about Coaching, Influencing, Mindfulness, etc.) influencing others can still sometimes be so difficult? After all, we are already spending most of the time actively listening and communicating with people to influence them (The Art of Influence: Lesson 2 – Listening & Communication Skills).

What is missing to become a great influencer?

My personal belief is that the best influencers I have worked with (following Albert Einstein’s criteria above) were always the ones that led by example. The ones that didn’t ask or try to influence without doing it themselves. Can you ask a single person or a group of people to change or do something if you don’t do it yourself? Is it realistic to expect any behavioral change if you are not the first one demonstrating and giving the first step? How do you think they would see you, what would they think or how would they react in the long run?

For me, the best way to influence and create a huge impact on my day to day work is to show the strength of my convictions by doing myself what I would like others to do; e.g. Changes/Attitudes I would like to see in others.

One great example of influencing by doing is when working with non-development teams and convincing them to adopt Agile. Why I am saying this? Because non-technical teams’ common reaction will be “We are not developers and this doesn’t work for us!” At that moment, what I do is just showcase how my own team works (since we are not a development team) and help them see how adopting Agile could make their day to day work easier. After a few moments, they are the ones saying “Wow! Can we do the same? Can you help us?”. In the long run, the results are stunning and their feedback is great with the will to improve more.

Another example is how my team works, and our overall level of trust and commitment. It’s normal for a leader to provide feedback and challenge the team as well as team members. In our case, they know they can do the same with me. It took some time to build this level of relationship, but nowadays if we need to put in place any action or deploy any workstream, we challenge each other, and even if the solution is not the one initially proposed by me, I will be the first one doing it. This creates a sense of high engagement because they see me as an example.

So what made you be a successful leader? Why not share your experience on how you made it and why you think it worked? It would be great to hear your thoughts even if you don’t agree with this approach.

#Agile #Lean #Leadership #Influence #Change #ContinuousImprovement

Today’s Thought on Leading Change

While watching a training about Leading Change by Britt Andreatta where she shared an amazing thought that I totally agree with her. This is something that we need to keep always in our mind and that besides applying to driving change teams also applies to any team.

“If you deliver what you promised you build more trust to future change initiatives. If you don’t you have a more challenging run. So, listening to feedback is really important.”

Don’t forget that the real impact is very important to your team reputation.

#Agile #Lean #Change #ContinuousImprovement