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 http://agilemanifesto.org/

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.
      • “Social Contract – key success factor for a great Agile team by Subhabrata Pal”
      • “Social Contracts for Agile Teams by Ethann Castell”
  • 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