Recently, while reading Adam Grant’s enlightening book, “Hidden Potential,” I stumbled upon the term “wabi-sabi” (侘び寂び), which encapsulates the beauty found in imperfection, impermanence, and incompleteness.
 
Reflecting on this, I have realised the importance of setting challenging rather than perfect goals. In an Agility mindset, adapting and evolving based on constant feedback is crucial. By not striving for perfection, we open ourselves to rapid learning and growth, taking more risks and embracing imperfections.
 
In a fast-paced world of constant change, individuals and organisations must keep this mindset at the forefront. Instead of aiming for flawless solutions, let us focus on crafting workable ones with unwavering quality. Pursuing perfection can be a trap, hindering our progress by fostering a false sense of completion and stagnation.
 
Embracing imperfection fuels our journey toward excellence. Let’s remember that perfection is not the destination but a continuous learning and growth process.

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.

The Time of Peace…

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…

The Time of War…

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!

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.

• https://www.scrumalliance.org/community/articles/2015/december/agile-maturity-self-assessment-survey
• https://beyondleanagile.com/2015/12/08/agile-maturity-self-assessment-survey-published-at-scrumalliance/

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 ———-

Intro

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:

• The organization mostly follows traditional processes.
• Agile is either not used or used inconsistently across the organization.

 Doing agile:

• The organization is just getting started with business agility.
• Starts to exhibit some consistent agile habits.
• Knowledge sharing begins to occur across the organisation.
• Agile tools and practices are common.

Being agile:

• The business agility basics are in place and more advanced methods are being explored.
• Most of the project portfolio is agile.
• Role and responsibilities are consistent across organization.
• Disciplined, repeatable process is in place with high-quality results.
• Trust in people/people empowerment and continuous improvement is occurring.

Thinking agile:

• The organization has made significant strides towards business agility.
• Agile habits are at a high maturity across the organisation.
• Successful use of agile at scale and across multiple geographies.
• Measurements systems are in place to track value realisation.
• Automation is highly enabled.

Culturally agile:

• The organization is a global business agility leader.
• Lean and agile are part of the organizational culture.
• Perfecting waste reduction, lack of overburden and inefficiency, smooth flow of delivery.
• There is a sustainable pace for innovation.
• Continuous organizational learning and optimization of ways of working is in place.

Select your business area from the following list:

• TBD by you – Specify your organisation areas so the person is able to select from the multiple-choice option.
• Which one? (Text field)

Leadership & Culture

1. Are you clear about our organisation’s mission, vision and values?

• Yes
• No
• Additional comments (Text field)

2. Could you please identify and select at least three of our values [Company Name]?

• TBD by you – Specify your organisation values so the person is able to select from the multiple-choice option.

3. Do you feel that the leadership is communicating clearly in a timely manner?

e.g. How would you rate the leadership communication strategy and frequency?

• Very dissatisfying (Ad-hoc agile)
• Dissatisfying (Doing agile)
• Neutral (Being agile)
• Satisfying (Thinking agile)
• Very satisfying (Culturally agile)
• Additional comments (Text field)

4. How would you rate the leadership focus in identifying trends and opportunities for improvement?

e.g. Identify improvement opportunities to adapt and respond to constant changes.

• No interest in seeking opportunities for improvements (Ad-hoc agile)
• Low interest in seeking opportunities for improvements (Doing agile)
• Compliance and process driven annual surveys with a low impact action plan (Being agile)
• Periodic identification of opportunities with small improvements implemented (Thinking agile)
• Regular/Periodic identification of opportunities with visible improvements implemented (Culturally agile)
• Additional comments (Text field)

5. How would you rate the leadership’s openness to listen and welcome people’s opinions?

• Doesn’t tell us much at all about what’s going on (Ad-hoc agile)
• Gives us only a limited amount of information (Doing agile)
• Keeps us adequately informed (Being agile)
• Keeps us fairly well informed (Thinking agile)
• Keeps us fully informed (Culturally agile)
• Additional comments (Text field)

6. How would you rate the level of communication and collaboration within your business area?

• Poor – only important information is shared with no particular collaboration happening (Ad-hoc agile)
• Fair – information is shared but collaboration is not encouraged (Doing agile)
• Neutral – information is shared regularly and collaboration happens occasionally (Being agile)
• Very good – information is shared regularly and collaboration is happening when there are dependencies (Thinking agile)
• Excellent – information is shared for transparency and collaboration is happening every step of the way (Culturally agile)
• Additional comments (Text field)

7. How would you rate your business areas’ communication and collaboration across the business?

• Poor – only important information is shared with no particular collaboration happening (Ad-hoc agile)
• Fair – information is shared but collaboration is not encouraged (Doing agile)
• Neutral – information is shared regularly and collaboration happens occasionally (Being agile)
• Very good – information is shared regularly and collaboration is happening when there are dependencies (Thinking agile)
• Excellent – information is shared for transparency and collaboration is happening every step of the way (Culturally agile)
• Additional comments (Text field)

8. How would you rate the organization’s approach in empowering people to take a certain level of decision and self-organized team level work?

• No empowerment, people execute only what is cascaded from leadership (Ad-hoc agile)
• Low-level empowerment only for work with small impact on strategic objectives (Doing agile)
• Empowered to take major decisions and self-organize during occurred incidents (Being agile)
• Empowered to take major decisions and self-organize business as usual work (Thinking agile)
• Fully empowered, people have the power of decision and trust form management (Culturally agile)
• Additional comments (Text field)

9. How would you rate the empowerment that you and your team have to try new things, without fear of blame?

• No empowerment, the team executes only what is cascaded from leadership (Ad-hoc agile)
• Low-level empowerment only for work with small impact on strategic objectives (Doing agile)
• Empowered to take major decisions and self-organize during occurred incidents (Being agile)
• Empowered to take major decisions and self-organize business as usual work (Thinking agile)
• Fully empowered, a self-organizing team with trust from management (Culturally agile)
• Additional comments (Text field)

10. How would you rate your leaders support (feedback, mentor, etc) in continuously growing the team and achieving established goals?

• Unsupportive (Ad-hoc agile)
• Fairly supportive (Doing agile)
• Neutral (Being agile)
• Supportive (Thinking agile)
• Very supportive (Culturally agile)
• Additional comments (Text field)

Lean Business & Portfolio Management

1. How do you think people perceive [Company Name] in terms of agile culture?

• Ad-hoc agile
• Doing agile
• Being agile
• Thinking agile
• Culturally agile
• Additional comments (Text field)

12. How would you rate the efficiency of our customer’s interaction and communication?

e.g. Efficiency means: timely, frequent interactions, clear communication, specific guidelines.

• Very dissatisfying (Ad-hoc agile)
• Dissatisfying (Doing agile)
• Neutral (Being agile)
• Satisfying (Thinking agile)
• Very satisfying (Culturally agile)
• Additional comments (Text field)

13. How would you describe the organization ability to cascade and provide clarity around business objectives (strategies/desired outcomes) and specific roadmaps?

e.g. Is data/info communicated clearly, visible and using a single source of truth, etc?

• Doesn’t properly cascades information nor does it provide clear objectives (Ad-hoc agile)
• Occasionally cascades limited amount of information with basic clarifications (Doing agile)
• Cascades most important business objectives and provides clarity on vital roadmaps (Being agile)
• Cascades information on a periodic basis and ensures visibility on business all area road maps (Thinking agile)
• Communicates transparently all strategic objectives and offers consistent support to business areas (Culturally agile)
• Additional comments (Text field)

14. How would you rate our planning vs demand capacity?

e.g. It’s visual and clear to everyone how and where people are allocated?

• Very dissatisfying (Ad-hoc agile)
• Dissatisfying (Doing agile)
• Neutral (Being agile)
• Satisfying (Thinking agile)
• Very satisfying (Culturally agile)
• Additional comments (Text field)

15. How would you rate our lead time to deliver business value to our customers?

• Very dissatisfying (Ad-hoc agile)
• Dissatisfying (Doing agile)
• Neutral (Being agile)
• Satisfying (Thinking agile)
• Very satisfying (Culturally agile)
• Additional comments (Text field)

16. How would you rate your confidence in your team/business area achieving the current goals?

e.g. Do you feel that we are going in the right direction?

• Strongly unconfident (Ad-hoc agile)
• Unconfident (Doing agile)
• Undecided (Being agile)
• Confident (Thinking agile)
• Strongly confident (Culturally agile)
• Additional comments (Text field)

17. How would you rate your team/business area responsiveness to changes and new requirements?

e.g. Is your team/business area flexible enough that can manage incoming requests?

• Resistant (Ad-hoc agile)
• Reluctant (Doing agile)
• Neutral (Being agile)
• Embraces changes (Thinking agile)
• Agile (Culturally agile)
• Additional comments (Text field)

Organisational Structure

18. What is your team size?

• 1-3 members
• 3-5 members
• 5-7 members
• More than 7 members

19. How would you classify your team level of skills in delivering business requests?

e.g. Can the team deliver business value with a high level of quality?

• Novice (Ad-hoc agile)
• Intermediate (Doing agile)
• Skilled (Being agile)
• Superior (Thinking agile)
• Proficient, driven by continuous development (Culturally agile)
• Additional comments (Text field)

20. How would you rate your team/business area level of self-organisation?

• Novice (Ad-hoc agile)
• Intermediate (Doing agile)
• Skilled (Being agile)
• Self-organising (Thinking agile)
• Proficient in self-organising (Culturally agile)
• Additional comments (Text field)

21. How would you rate your team members’ ability to step outside their role and occupy different functions?

• Ad-hoc agile
• Doing agile
• Being agile
• Thinking agile
• Culturally agile
• Additional comments (Text field)

22. How would you rate your teams’ ability to shift people upon demand?

• Ad-hoc agile
• Doing agile
• Being agile
• Thinking agile
• Culturally agile
• Additional comments (Text field)

Agile Mindset & Methods

1. How experienced are you with working in self-organised, empowered, trust-based teams with shared outcomes?

• Novice (Ad-hoc agile)
• Intermediate (Doing agile)
• Skilled (Being agile)
• Superior (Thinking agile)
• Proficient, driven by continuous development (Culturally agile)
• Additional comments (Text field)

24. How would you rate the level of trust within your team and business area?

• Very dissatisfying (Ad-hoc agile)
• Dissatisfying (Doing agile)
• Neutral (Being agile)
• Satisfying (Thinking agile)
• Very satisfying (Culturally agile)
• Additional comments (Text field)

25. What is your experience in leading and facilitating people-centric self-organizing teams?

• Novice (Ad-hoc agile)
• Intermediate (Doing agile)
• Skilled (Being agile)
• Superior (Thinking agile)
• Proficient, driven by continuous development (Culturally agile)
• Additional comments (Text field)

26. How would you measure the level of opportunities to be creative and innovate?

• Lacking (Ad-hoc agile)
• Low (Doing agile)
• Medium (Being agile)
• High (Thinking agile)
• Very high (Culturally agile)
• Additional comments (Text field)

27. How satisfied are you with your leader or team facilitator abilities to manage and remove impediments blocking you and your teamwork?

e.g. Does the team feel that they are stuck with issues outside their control?

• Very dissatisfied (Ad-hoc agile)
• Dissatisfied (Doing agile)
• Neutral (Being agile)
• Satisfied (Thinking agile)
• Very satisfied (Culturally agile)
• Additional comments (Text field)

28. How would you rate your leader and/or team facilitator effectiveness in preparing, scheduling and facilitating agile ceremonies in an efficient and collaborative manner?

• Very dissatisfying (Ad-hoc agile)
• Dissatisfying (Doing agile)
• Neutral (Being agile)
• Satisfying (Thinking agile)
• Very satisfying (Culturally agile)
• Additional comments (Text field)

29. How would you rate the effectiveness of your team/business areas regular meetings?

e.g. Do you feel that they are valuable or a waste of time?

• Very dissatisfying (Ad-hoc agile)
• Dissatisfying (Doing agile)
• Neutral (Being agile)
• Satisfying (Thinking agile)
• Very satisfying (Culturally agile)
• Additional comments (Text field)

30. How would you rate your visibility on the upcoming plans (backlog) for the next weeks/months (sprints)?

e.g. Do you have a clear and prioritised backlog or just what you are currently working on?

• Very dissatisfying (Ad-hoc agile)
• Dissatisfying (Doing agile)
• Neutral (Being agile)
• Satisfying (Thinking agile)
• Very satisfying (Culturally agile)
• Additional comments (Text field)

31. How would you rate your team/business area skills to break down strategic deliverables to smaller, measurable business outcomes?

• Novice (Ad-hoc agile)
• Intermediate (Doing agile)
• Skilled (Being agile)
• Superior (Thinking agile)
• Proficient (Culturally agile)
• Additional comments (Text field)

32. How would you rate your team business analyst/product owner’s effectiveness in keeping the backlog and efficiently redefining and prioritising tasks?

Note: For corporate functions consider this role as the person organising the workload.

• Ineffective (Ad-hoc agile)
• Slightly effectiveness (Doing agile)
• Average (Being agile)
• Effective (Thinking agile)
• Highly effective (Culturally agile)
• Additional comments (Text field)

33. How would you rate your team business analyst/product owner’s engagement with the team and knowledge in answering questions?

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.

• Novice (Ad-hoc agile)
• Intermediate (Doing agile)
• Skilled (Being agile)
• Superior (Thinking agile)
• Proficient, driven by continuous development (Culturally agile)
• Additional comments (Text field)

34. How mature is your team in providing accurate estimations and planning for delivery?

• Novice (Ad-hoc agile)
• Intermediate (Doing agile)
• Skilled (Being agile)
• Superior (Thinking agile)
• Proficient (Culturally agile)
• Additional comments (Text field)

35. How familiar are you in applying agile planning/estimating approaches (trade-offs, prioritisation, relative estimation, release plans, etc.)?

• Novice (Ad-hoc agile)
• Intermediate (Doing agile)
• Skilled (Being agile)
• Superior (Thinking agile)
• Proficient (Culturally agile)
• Additional comments (Text field)

36. How often does the team receive fully detailed, ready to be implemented requests?

• Rarely
• Not very often
• Neutral
• Often
• Very often
• Additional comments (Text field)

37. Does your team/business area have an agreed and clear definition of ready & done?

• Yes
• No
• Additional comments (Text field)

38. How would you rate your team/business area maturity in identifying and improving how you work?

• Novice (Ad-hoc agile)
• Intermediate (Doing agile)
• Skilled (Being agile)
• Superior (Thinking agile)
• Proficient, driven by continuous development (Culturally agile)
• Additional comments (Text field)

39. Does your team/business area follow any of the agile frameworks/systems described below?

• No, we still follow a traditional approach
• Scrum
• Kanban
• Scrumban
• Hybrid
• Other – Which one? (Text field)

Performance & Measurements

1. Are planned goals achieved in due time by the team?

• Never – 0 – 15% of the time (Ad-hoc agile)
• Rarely -25% of the time (Doing agile)
• Occasionally – 50% of the time (Being agile)
• Most of the time – 80% of the time (Thinking agile)
• Always – 100% of the time (Culturally agile)
• Additional comments (Text field)

41. How would you rate your team/business area delivery pace?

e.g. Is your team delivering as fast as desired by your business analyst/product owner/costumer?

• Unplanned pace (Ad-hoc agile)
• Low pace (Doing agile)
• Regular/Timed (Being agile)
• High pace (Thinking agile)
• Continuous /Seamless pace (Culturally agile)
• Additional comments (Text field)

42. How would you rate your team predictability (target vs actuals) deliverables?

e.g. Is the team within 90% of your target consistently?

• Highly unpredictable (Ad-hoc agile)
• Unpredictable (Doing agile)
• Neutral (Being agile)
• Predictable (Thinking agile)
• Highly predictable (Culturally agile)
• Additional comments (Text field)

43. Do you feel that our metrics (KPI’s) measure what matters (valued indicators)?

• Yes
• If no, why not? (Text field)

44. Do you feel that our KPI’s are fully understandable and visible?

• Yes
• If no, why not? (Text field)

45. Are our metrics (KPI’s) providing relevant insights and used as a source for continuous improvement?

• Yes
• If no, why not? (Text field)

Make It Stick & Sustain

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.

46. Do you understand your role and what is expected of you?

• Yes
• No
• Additional comments (Text field)

47. Do you understand the other roles and what is expected of them?

• Yes
• No
• Additional comments (Text field)

48. How confident are you that your team/business area has the availability, tools and skills to meet their current goals?

• Strongly unconfident (Ad-hoc agile)
• Unconfident (Doing agile)
• Undecided (Being agile)
• Confident (Thinking agile)
• Strongly confident (Culturally agile)
• Additional comments (Text field)

49. What tool does your team/business area use to manage work?

• None
• Physical board
• Jira
• Trello
• Microsoft Excel
• Other – Which one? (Text field)

50. Do you have the right environments and automated tools?

• Yes
• No
• Additional comments (Text field)

51. Does the organization follow the right guidelines and practices to operate according to an agile mindset?

• Yes
• No
• Additional comments (Text field)

52. How would you rate the level of knowledge within the teams to achieve technical Excellency?

• Novice (Ad-hoc agile)
• Intermediate (Doing agile)
• Skilled (Being agile)
• Superior (Thinking agile)
• Proficient, driven by continuous development (Culturally agile)
• Additional comments (Text field)

53. Do you have any suggestions on what [Company Name] our organisation could improve in terms of ways of working?

• Open question (Text field)

———- 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:

• 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?”

• Attempts to scale Agile to reach strategy fell short;

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 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