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

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

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