It was an absolute pleasure working on this article with Pedro Duarte. Stronger Together 😉
With some good years of experience on board, we both agreed that companies often miss when chasing their view instead of focusing on what delights their consumers. Click below to read how and why putting customer satisfaction needs to drive product development to change.
I was reading the article “Digital Transformation Success Depends on Agile Approach to Change” by Peter Bendor-Samuel, where the author says that companies are rushing to apply digital transformation to gain competitive advantage. Furthermore, driving the digital transformation often requires changing the company’s operating model through multiple iterative steps known as journeys. Peter Bendor-Samuel explains the benefits of using an agile approach and how this can support companies to move forward with the digital transformation. The author also states that corporate culture is the key element missing that make an organisation struggle to support the agile environment while driving their digital transformation. These ideas were so interesting that made me think deeply about the importance and strength of the relationship between digital transformation, agile and culture.
Due to its content, I decided to share it together with my thoughts on the topic. Surprisingly, as soon as I started to write my input, I realised I started writing this article. I hope you enjoy reading it the same way I enjoyed writing it. As always, it would be great to hear your thoughts on this subject.
Nowadays, companies already realised that in order to achieve a successful agile transformation, they should not limit this change to engineering departments but all business departments, including HR, finance, sales, marketing, customer support, among all others. More and more, we observe that digital transformation is becoming the new trend, leaving many people talking about this topic alongside agile transformations while companies try to achieve both. Clint Boulton states in his article “What is digital transformation? A necessary disruption” published in CIO.com that digital transformation is a basal change for how organisations deliver value to their customers. In other words, we can say that digital transformation is a revolutionary rethinking of how organisations use technology, reorganise people and processes to challenge and improve their current status quo.
Taking into consideration Peter Bendor-Samuel and Clint Boulton thoughts, we realise that agile and digital transformation are not the same. Agile focuses on how organisations deliver value iteratively to the customer while digital transformation focuses on how organisations use technology to support how value is delivered. Still, one supports the other to achieve the same goal that is delivering value. However, both authors agree that culture is so crucial that its core to achieve a successful transformation. The reason I say this is because, in traditional organisations, executives and managers are given targets that they are held accountable for, and which they cannot fail. I genuinely believe that to succeed with any transformation following the agile approach experimentation must be allowed so we can absorb the learnings from the failures and keep going forward.
During my career, agile transformation and digital transformation initiatives were driven separately, or their touchpoint was high-level. However, people started to realise that the relation between these two transformations is more substantial than initially thought — one cannot work correctly without the other. In his article Peter Bendor-Samuel Bendor-Samuel, states that companies use an agile approach to minimise risks and validate if their efforts meet the desired outcome as they move forward in their journey. Furthermore, the authors say that the key element for any digital transformation supported by an agile approach is the corporate culture. Many times, at the heart of the cultural change, we have the long-established practise of penalising failure. We should understand that there is no perfect or one solution fits all, meaning that experimentation is an essential element to understand what works or not and what can we do differently to make things work and keep improving. Therefore, companies need to celebrate their failures, that they do things to learn and test, rather than penalise failure.
All this make us think and realise that any transformation can be at risk if we take into consideration how failure is managed within the organisation by the leadership.
On a similar note, Tabrizi, Behnam et al. article “Digital Transformation Is Not About Technology” published in HBR says that digital transformation does not come in a box — or a cloud. The authors share the five key lessons that help them lead their organisation through a successful digital transformation:
What is interesting to note is that culture is again mentioned as a key factor in these five lessons.
After having read them, these are my thoughts on each of those lessons:
Brainstorming in front of a whiteboard helped me to have a better understanding of the relationship between agile transformation, digital transformation, leadership and culture.
After a while, an image started to become clear—the image of Business Transformation Trinity, as shown below.
Business Transformation Trinity by Eduardo Ribeiro, July 2020
As we can see:
The triangle edges are independent, and the edges are connected by the vertices (relationships), which support each other to achieve any transformation. Furthermore, culture is the key to make transformation a success. We know that change creates discomfort since people are getting out of their comfort zone and without a proper culture in place, we will face resistance and setbacks where the worst scenario could be giving up our transformation and returning to the old ways.
In conclusion, when we are driving an agile and/or digital transformation, we need to keep in mind that all triangle edges need to be worked on iteratively. We need to do this so we can measure the impact of our implemented change, and understand if it was a success or if we need to do it differently. Last but not least, we need constant collaboration with leadership so we can learn from these small failures and not return to the long-established practise of penalizing failure.
Once more, culture is key; it needs to be in our centre of attention and addressed appropriately since even a minor change can be the trigger for the change not being accepted and ultimately not working. Following Peter Bendor-Samuel suggestion in his article, maybe what we need to do is rename the term “failure” to something else that does not create a negative impact like “learnings”. Otherwise, people can misunderstand that the transformation journey failed when actually, we have learned.
In the end, I would like to send a special “thank you” to Anett Stoica for helping me to unblock during my brainstorming moment. For the received feedback about the article, Margarida Carvalho, Mike Sousa and once again Anett Stoica thank you!
#agile #agilty #digitaltransformation #leadership #culture
Sometimes we see Agile Coaches and Agile Consultants trying to use the same coaching techniques with different types of people. They believe if they have successfully applied a coaching technique, the same will work with most of the people.
During my career, I realised that it is not the case. There is no universal recipe for an Agile Transformation/Change. Moreover, besides first understanding what is the problem we want to solve, it is key to keep in mind that we have to address a multitude of people and roles with different needs and level of resistance to change. While we can get some people on board from the early stages, depending on role, seniority or personal traits, we might need to adapt our coaching style to communicate our message better. After all, change means stepping out of our comfort zone.
Flowing my thoughts, today I’ve come across Eric´s article “Dealing with psychopaths during Agile change” in which he explains how to deal with Psychopathic or Narcissistic people during Agile change.
Thanks Erich R. Bühler, for sharing your thoughts on the matter.
#lean #agile #agility #continuousimprovement #highperformaceteams #change
When dealing with the methodologies of working, we hear a lot of interpretation and opinions.
Much of this feedback is constantly shared by members of our community, talking about the success or failure rates when adopting an agile methodology in their companies.
One of the much-discussed topics amongst us professionals is the reason why some companies are able to achieve success in transformation and others can’t. More importantly, what causes the initial enthusiasm and desire for improvement to quiet down and revert to the initial disbelief in the effectiveness of the methodology.
Having said that, a while ago I decided to write an article on this topic. I gathered all my thoughts and inputs collected both from businesses as well as from individuals with the desire to adopt an Agile Mindset and keep improving their way of working.
The moment has come to shed some light on what I think about this phenomenon.
I don’t remember who started this saying, but we all hear this quite often, “Agile is not the Silver Bullet”.
Photo by Velizar Ivanov on Unsplash.
The bullet concept reminded me of Lev Tolstoy´s famous novel, War and Peace. While we are not building here a literary commentary of the Russian masterpiece, we cannot overlook some similarities between Tolstoy’s characters and our modern-day corporate employees. Although situated in different centuries, both categories characters struggle with problems unique to their era, their history, and their culture in the process of adapting to the new times and changes.
What I’ve been observing is that two moments that can define weather adapting agile will be a success or a failure. In my experience, I call these moments the Time of War and time of Peace.
Photo by Vitor Pinto on Unsplash.
Time of peace is what I consider to be the moment of engagement, specially buy-in from all stakeholders. Teams are split between being reluctant or enthusiastic about the change. At this point, the focus is on the benefits: predictability, transparency, empowerments, delivery at a faster pace. Potential challenges are acknowledged as being part of the journey until the moment of full transformation occurs. Even so, everybody is doing their best to take up the principles and values of Agile. The collective energy level is high, and this improvement process creates a new opportunity for people to build something together and become better at what there are doing while becoming a united and more autonomous team.
Photo by Eddie Kopp on Unsplash.
Teams are committed to making this work. Often times they repeat the mantra “Others did it, so why couldn´t we?”.
What amazes me is that they truly believe in the concept and are in fact doing all the work. Obstacle after obstacles, they are adapting and making it work!
Until…
Photo by Specna Arms on Unsplash.
As so often specific for human behaviour, when the going gets tough. Everything is going well until this moment, the moment doubts or non-existing doubts appear.
What could happen to create this momentum?
Like most things having to do with human behaviour, this question does not have a single and ultimate truth as an answer. Environment, faulty processes and human nature all factor in.
From what I observed so far, it all gets down to pressure, the catalyst for a time of War.
Corporate environment can often times be a major influence. Pressure from upper management to see quick outcomes or ROI (return on investment), constant nudges from stakeholders powered by the fear of failure push the teams in untested waters too fast.
Broken processes leading to lack of transparency and communication on what, why and how to do will create further confusion and isolation.
Ultimately, the natural resistance to change, pushing too hard will lead to team burnout. And as always, not people but the concept will be to blame. An exhausted group of people will prefer to go back to what they know instead of spending more energy on fixing or adapting the “unknown evil” – this being in our case, the use of the agile methodology.
So, what is there to do?
I consider the breaking point of an adapting process to be when I hear the words “This doesn’t work for me”. Beyond this, there is no point of return. This is the moment that can make the difference between making this work or not.
I am a true believer of step by step, incremental changes. A Big bang approach puts far too much pressure on people and allows no real time for the mind to perceive and adapt to the new requirements. With small steps and iterative improvements “Time of War” moments can be dismantled, like a ticking bomb.
Across our adapting, we will have many “Times of War and Peace” but we need to keep our eye on the ball and remember that each “Time of War” it’s just one more obstacle we need to pass before getting over the finish line and make these principles and values part of our DNA.
With every obstacle passed, it gets easier.
Don’t stop here. This is just the beginning of the continuous improvement path.
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 help with the article revision and all her feedback. Thank you!
A few months ago I was challenged by my good friend Eddie Kenny and Vasco Duarte to participate in the Scrum Master Toolbox Podcast – A daily podcast for Scrum Masters and Agile Coaches.
I have accepted the challenge to be part of a podcast production while never having done anything similar before. It was not a simple as I have imagined, but with preparations and the guy´s support, I was very happy with the final result.
To make it easier for you to follow, I’ve combined all 5 days content in one post below. To access the podcasts click the links bellow.
Hope that you enjoy listening as much as I enjoyed making them.
As always, feel free to share your feedback.
There’s a lot of #scrumbut out there (not really scrum). However, applying #Scrum by the book may be as bad as any #scrumbut pattern. a @scrumpodcast interview with @edu_f_ribeiro
#agile #lean #adoption #transformation @duarte_vasco
— Scrum Master Toolbox (@scrumpodcast) April 1, 2019
On this @scrumpodcast, @edu_f_ribeiro asks a critical question that every #scrummaster should ask every now and then: is the Scrum team really that good, or just not willing to improve?
#scrum #agile #learning #growth #improvement @duarte_vasco
— Scrum Master Toolbox (@scrumpodcast) April 2, 2019
How to create a guiding coalition for change, the Scrum Master’s guide by @edu_f_ribeiro on the @scrumpodcast
#lcm #change #changemanagement #scrum #scrummaster #agile @duarte_vasco
— Scrum Master Toolbox (@scrumpodcast) April 3, 2019
Make your team metrics, also your metrics! A #ScrumMaster tip to achieve an impact by @edu_f_ribeiro on the @scrumpodcast
#scrum #agile #lean #metric #improvement @duarte_vasco
— Scrum Master Toolbox (@scrumpodcast) April 4, 2019
How to deal with conservative cultures in Scrum teams, a #CultureFriday episode and @edu_f_ribeiro
#Scrum #agile #lean #culture #team @duarte_Vasco
— Scrum Master Toolbox (@scrumpodcast) April 5, 2019
Some years ago, to be more precise in 2015, I had the opportunity to develop and implement an Agile Maturity Self-Assessment Survey.
The idea for developing this tool was driven by my strong belief in constant feedback, and it´s role in challenging the status quo that leads towards an improved and adaptive way of working.
Photo by rawpixel on Unsplash.
Another reason for designing the self-assessment survey was driven by one of the organizations I was working with. Their strategic objective was to focus on continuous improvement by growing our ways of working. The framework for this approach was based on constant feedback collection, agreement of improvement actions, and measurement of the achieved impact.
Thus, a self-assessment tool was needed, to provide realistic data that would lead our focus efforts. Most importantly, the source of data needed to come from those doing the day to day work.
After finishing the model, this was also published Scrum Alliance community as well as on the Beyond Lean Agile blog space.
Since its date of publishing, the survey has received a lot of feedback, adding my own experience while using it with various teams and organisations. The main points of improvements suggested were around making the survey generic so that it can also apply to non-development functions, less focus on Scrum, and customization of questions for specific areas.
In other words, be able to use to assess and understand the agile maturity level across the entire organization.
All the accumulated information drove me to sit down and review what I have created a couple of years ago. For a comprehensive result, I have done more research in the industry and asked people from several different areas do the assessment and share their opinion. All this input and research helped me take this survey to the next level – “Enterprise Business Agility Maturity Assessment”.
The goal of this iteration is to perfect a tool that helps understand the agile maturity level without limiting this type of assessment only to development or tech areas. Our main purpose as “agilists” is to improve ways of working by understanding pain points, to agree and prioritise what is critical, and keep our focus on constant improvement. The best way of doing this is to assess how known and widespread is the agile mindset across the organization.
While this new version has successfully been tested on a small sample, it would be deployed on a larger scale next year (FY19). Once tested, I will be happy to share the lessons learned and any improvement identified.
Having all said that, you can find bellow\here the “Enterprise Business Agility Maturity Assessment”:
———- Survey starts here ———-
Thirst of knowledge, willingness to fail fast and learn faster and keep improving are just some of the characteristics which embody agility, a concept that lies at the basis of customer satisfaction through continuous delivery. The agile mindset of leadership is the starting point that allows for the full formation of a highly collaborative and high performing culture.
As opposed to traditional top-down decision making or to a directive management style, leaders of agile culture focus their efforts on vision, strategy, growing people and removing organizational impediments. These agile values create an environment that supports empowered teams, allowing the specialists on the field to make decisions while aligning with the leadership direction.
Purpose of the survey: Define how present and widespread is the agile mindset across [Company Name] and identify existing opportunities for improvement and potential challenges to start adopting/proceeding with the agile transformation.
Guide on how to complete the survey: The survey is divided into 6 sections each of them containing a series of questions with single or multiple-choice answers. Where required, please provide a rating while using the guidelines below. All questions refer to culture and ways of working used here, at [Company Name].
Ad-hoc agile:
Doing agile:
Being agile:
Thinking agile:
Culturally agile:
Select your business area from the following list:
e.g. How would you rate the leadership communication strategy and frequency?
e.g. Identify improvement opportunities to adapt and respond to constant changes.
e.g. Efficiency means: timely, frequent interactions, clear communication, specific guidelines.
e.g. Is data/info communicated clearly, visible and using a single source of truth, etc?
e.g. It’s visual and clear to everyone how and where people are allocated?
e.g. Do you feel that we are going in the right direction?
e.g. Is your team/business area flexible enough that can manage incoming requests?
e.g. Can the team deliver business value with a high level of quality?
e.g. Does the team feel that they are stuck with issues outside their control?
e.g. Do you feel that they are valuable or a waste of time?
e.g. Do you have a clear and prioritised backlog or just what you are currently working on?
Note: For corporate functions consider this role as the person organising the workload.
e.g. Is he/she available to the team? Is he/she engaging with the other stakeholders, and getting their input?
Note: For corporate functions consider this role as the person organising the workload.
e.g. Is your team delivering as fast as desired by your business analyst/product owner/costumer?
e.g. Is the team within 90% of your target consistently?
Leading a Business Agility transformation takes planning, time and effort and often represents a large investment. For the change to provide lasting value, it is important to “make it stick” and avoid falling back into old patterns and behaviours.
———- Survey ends here ———-
It would be great to hear your thoughts and have your feedback about this survey.
Finally, I would like to give a special “thank you” to Anett Stoica, Diana Antão, Aurelie Rodrigues, Margarida Carvalho, Mike Sousa and Helder Pereira for the survey revision and all their feedback.
Thank you!
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:
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:
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 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.
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.
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.
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.
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.
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.
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
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 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…
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:
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
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
Beyond Lean Agile 