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

Agile Coaches Myth or Reality?

This article is really interesting since the subject to write about this was born during one of the Lean Coffee Portugal sessions when someone raised the subject/question “What is a difference between a Scrum Master and an Agile Coach?”.

Meanwhile, seeing as this can potentially be a long and interesting debated subject after chatting with my colleague Cornelius Engelbrecht  I decided talk with him if he would like to accept the challenge. That he did 😉

So, we would like to start with a quick question where you ask  yourself:

“What is an Agile Coach? Are they a myth or reality?”


The reason why we are asking this is because we can say that Agile Coach is a recent role and when we say this we are talking a few years and not like Developer or Project Manager that are with us for a long period of time.

Also, we think that we have people that are confused regarding the role definition and what are the best characteristics for a good Agile Coach.

To start we want to give you some context behind our opinions. We are not sure if you realised that nowadays everyone have on their LinkedIn, CV or role Agile Coach. But do they know what is the real Agile Coach role?

Well… We can say that we became curious, so we started to dig and get more information around the label Agile Coach. Our first approach was discuss this topic with a lot of people around the world and by coincidence or not, we had the need to also hire Agile Coach’s for my team.

What we discovered was kind of funny. Well… Not funny but curious.

  • People that updated their role after reading Agile books.
  • People that use the label on their current role even what they do is not related.
  • People that use the table Agile Coach since they don’t like the name Scrum Master.
  • People using the table Agile Coach since in Kanban there is no Scrum Master.
  • Role updated just to apply to a job without any experience.
  • People who collect certifications to prove they are a Coach.
  • The main reason we see is people that updated their role because everyone is doing it (Buzz word from the moment).

So, we would like to return to the question made during the Lean Coffee Portugal session by providing the definition of what is a Scrum Master and as you can see we don’t need to invent the well since is already well defined as we can see by the Scrum Guide definition (image below).

SM Scrum Guide


Now let’s have a look at the Agile Coach role from our perspective:

An Agile Coach helps individuals/teams/departments/organisations so they can become better and be proud of what they do.  One does this through being a guide & change agent who applies Lean/Agile/Continuous Improvement practices which are relevant to people’s journey.

Attributes of an Agile Coach:

  • Great listener
  • Patient
  • Impartial
  • Humble & always learning
  • Respectful
  • Not so much directing, more guiding (i.e. helping people find ways/answers not giving answers)
  • Non-judgemental
  • Fearless (i.e. able to communicate  with confidence at all levels in the organisation be it CEO, management and team members)
  • Flexible (“being able to think outside the box”)

Quick re-cap:

Scrum Master is mainly focused on guiding one/two teams (including Product Owner)  in using Scrum.  Agile Coach is a very different role whereby he/she has a wider organisational view when coaching individuals/teams/organisations on improving (becoming better at what they are doing) whilst using Lean/Agile/Continuous Improvement practices.

Why did we want to become an Agile Coach?

Funny enough we did not know we wanted to become coaches, what we wanted  is to improve our ability to help people in achieving more.  We started to look into why people understand, react, how they learn, absorb and believe in what they do and how to embrace change  – this is where it began for us…