Three Agile and Scrum questions from a reader

Three Agile and Scrum questions from a reader

Delivering work using Agile practices can be tough because work environments vary and different organisations throw different kinds of challenges on us. I often receive questions from readers about agile delivery practices. What I have been observing for a while is that the questions mostly relate to dealing with people. As Jerry Weinberg said through his Second Law of Consulting, “No matter how it looks at first, it’s always a people problem.”

This post answers some of the common questions that I recently received from one of my contacts. I have made some minor edits to make the questions generic. 

Coaching teams and organisations

Question 1. How should I as a Scrum master go about coaching the organisation about Agile. I come from a consulting background and coaching is usually limited to the Scrum team that I work for. Are there any techniques that can help me coach organisations or stakeholders?    

Answer: As a Scrum master, oftentimes you will only work with a couple of teams. Coaching one or two teams is easier, manageable and more convenient. However, there’s no optimum number of teams that a Scrum master can work with. Although it might appear useful that a Scrum master should only work with one team, a lot depends on the nature of the work the teams are doing, their maturity in terms of the agility, the complexity of the work, the structure, size and the culture of the organisation etc. 

One thing is sure that as a Scrum master, an organisation wouldn’t want you to be spread too thin. In his book Secrets of Consulting, Jerry Weinberg offered us his Law of Raspberry Jam, “The wider you spread it, the thinner it gets.” And, as you may know, good jam has lumps. I think a thinner jam loses taste too. In our terms, that’d be losing focus or interest.

Now coming back to your question of coaching the organisation. It pays to confirm what someone means by coaching. People often confuse training and coaching. Let’s assume that they want you to coach the organisation on using Agile practices. How would you do that? Of course you will understand their context, the training and skill gaps, and possibly the problems they want to solve through coaching. Accordingly you will find the things that will offer you few quick wins and time to find a long term solution.

Techniques of coaching depend on who you’ll deal or work with. I often mix things to make them accessible and practical. For example, I’ve organised brown bag sessions, arranged team surveys to find out what they want to learn, scheduled coaching sessions with other Scrum events so that teams don’t use the sprint time for training, coached teams by organising team contests etc. My experience is that given sufficient notice, stakeholders enjoy taking part in contests or challenges.

 

Getting pushed back on Agile Delivery

Question: Many times I get to deal with Clients who have low agile maturity. Either at the team level, or at the stakeholder level. I get pushed back on Agile process delivery as this would disrupt their business. In such a scenario, I initially did an Agile/Scrum 101 training. Talked about my successful experiences from the past with successful Agile delivery. However, I still felt that the clients or teams were not convinced. How should I have approached this as SM differently to get the stakeholders or team to buy into Agile ways of working?

Answer: That’s a good question and many Scrum masters, Agile coaches and delivery managers experience similar challenges.

First thing that we should understand is that Agile itself is not the goal. Even though some organisations might say that they want to be Agile, their main objective is possibly to solve some other problem through applying Agile methods or the mindset.

What often seems to happen is that when given a responsibility, many Agilists blindly start applying frameworks, tools or methods. This results in pushback from teams as well as stakeholders. (You might want to watch this video about tools and frameworks). Agile is about change and we know that people don’t like change because change is hard. (But remember that change is not always resisted. Having new born babies brings a huge change in people’s life, but almost everyone enjoys that even though it turns their lives upside down, at least for a while.)

Your clients must have hired you for a specific reason or reasons. They wanted you to solve some problem for them. Understanding their problems, their context and what bothers them builds your own confidence in the problem solving process and also instills confidence in the client. Running Agile 101 is the easy part. Knowing whether that is required, is the hard part.

Old School Product Owner?

Question: I had a tough PO who needed all requirements into the project delivery roadmap. What would be the best way to convince a PO that we cannot have all the features in the product roadmap and can only accommodate a MVP approach ensuring we can only focus on features that can be developed in a given period of time.  

Answer: It appears to me that your PO was not trained in product ownership and was only carrying the PO label. You might want to show them this video from my talk at the Agile POs and BAs meetup. In this talk I explained what product ownership is and how the prioritisation works. I’ve heard that many people found it useful. 

Although things have slightly changed since Henrik Kniberg wrote about MVP, sometimes I still use the sketch that he created to explain the idea.

You may also want to make sure that the POs you work with get training in product ownership and understand that their job is not to manage people, but to work with them for frequent delivery of valuable outcomes. You can do that by building a trusted relationship with them. Think about getting into a social contract with them.

Side note: there is no single ‘best way’ for almost anything, but there are always many good ways. ‘Best’ expresses ‘the only way’, while there can be more than one way of achieving our goals.

So, these were my responses to the questions. What else would you add to these answers? Would you answer these questions in a different way or would you give a completely different answer? Let me know.

Follow here
Commit to CRIME

Commit to CRIME

When Mike told me and few others that we should commit to crime and also get our teams to do that, I was like, “Huh? What do you mean?”. 

 He went on to explain what CRIME acronym was. 

CRIME stands for Collaboration, Retrospective, Investigating, Mapping and Exploration. I found the acronym useful as this reminds you of the basics that we should all be following and keeping track of. In fact, mnemonics has been a proven technique for remembering ideas and concepts for a very long time. People who have studied chemistry will possibly remember how they memorised the Periodic Table.

This website is a useful resource for learning more about mnemonics.  

I have attached the sketch for you that you can share with your teams.  If you can’t download it here, then please email me and I’ll send it to you.

Mike is a friend of mine from North Carolina. He is an author, speaker and QA Director. Although he used the acronym CRIME for testers, I modified it to suit Agile delivery people and teams.

 

Crime acronym

Follow here
How do you improve collaboration when everyone is remote

How do you improve collaboration when everyone is remote

Building trust, enhancing collaboration and establishing relationships is hard enough when teams work together in a physical office. Things become more challenging when teams are distributed. This issue doesn’t sound too challenging when one team is co-located and works with other teams that are at different locations or different time zones. Actually, ever since offshoring and outsourcing became mainstream, we have learned to live with the distributed nature of work. 

When do we collaborate?

We collaborate with others to achieve something of common interest. For example, entrepreneurs may collaborate to build and launch a new product. In corporate settings, different teams collaborate to build products and to deliver valuable outcomes for their customers.

Collaboration is successful when the level of trust is high among the people who work together.

However, the question remains.
How do we build and enhance collaboration and trusted relationships among team members?

There are hundreds of methods that help us do so. But we’re not going to list all of them here. Google is good for that sort of stuff. In this post, I’ll tell you what has worked for me and then you can tell me what has worked for you. Hence, don’t forget to add comments below.

Current challenge: 

When it comes to collaboration, the current pandemic has made the situation even more challenging. How? Now not just the teams, but every single person of a team is located remotely. That brings a different dynamic to the equation when we talk about collaboration and teamwork.

I’m going to share two techniques that I’ve found useful.

The first one is personal mapping.

Enhancing collaboration using personal mapping:

When team members know more about each other than just the work stuff, the bonding improves. It mostly happens that when we sit in the vicinity of others, communication begins. The generic, “hey, how was your weekend?” often becomes the icebreaker and increases the flow of communication. And it appears to me that this improved relationship also helps us deliver better outcomes. This might just be human nature. When our ancestors worked together, they survived and grew. 

Personal mapping technique is a simple mind mapping exercise where you tell your story through visualisation. Here’s my personal map.

Personal mapping

 

How to get your team’s started with personal mapping:

A good place to start is to use the technique as an icebreaker before workshops. Or, do it when New team members join. 

I often start with asking team members what they knew about me. One they respond, I share my personal map with them. I normally include details of education, work, hobbies, family, goals and values etc. The idea is to keep the session interesting. This often helps in making team members feel safe, relaxed and engaged.

After sharing my personal map, I encourage team members to pair with someone who they don’t know much about.

Team members talking of their colleague’s personal map:

When team members know that they will be introducing their colleague to others, they listen intently and they try to understand them better. 

How to do it remotely

Easy. If you’ve created your map on your computer and if you’re using a solution liked Google Meet, Microsoft teams or Zoom, you can share your screen. If you’ve created your map on paper, you can show it on camera.

Drawbacks of personal mapping:

My observation is that introverts can find this exercise a bit awkward. Some team members also do not want to share information about themselves for personal reasons. Each person is different and it’s better to familiarise the team with this exercise beforehand and find out whether it might make someone feel uncomfortable. You can work with them to adjust the exercise for them and make them feel safe for participation.

Using collaboration game Quinks for team bonding

I came across this interactive game when one of my friends invited me to join a free session with the game’s inventor, Viren.

The game is available online as well as a physical set and that makes it easier to either do it remotely or in person.

Quinks game

How to play:

Quinks is based on experiential learning techniques in which two players ask each other questions related to specific contexts by drawing cards. One person is assigned the role of Questioner, and the other the role of Answerer. The Questioner draws a Quinks card (a question card) and combines it with a Context card to create and ask a powerful question. These cards consist of powerful questions that Viren collected through his research and experience. 

Since the game limits conversations (responses of the contextual questions) to just 3 minutes, it compels team members to pay attention, learn to express themselves in a concise way, ask good questions, empathize and engage in deeper conversations.

Outcome:

I had fun playing the game even with total strangers in public sessions. It was interesting and surprising to realise that given a context and a relevant question, how you can bond with those who you’ve never met before. This was a great way to introduce people and build relationships.

Value map for further discussions: 

The game also lets players map various values of their partners based on their conversations. Once everyone completes the game, you see the value map that represents how others have perceived you through your responses. Through this process you learn about your blind spots and improve self awareness. 

 

A good reference regarding self awareness here is Johari Window. Have a look.

Personal mapping and Quinks can possibly be combined as one big workshop. I haven’t tried that yet. You may want to do that.

If you have used other collaboration techniques that gave you good results, let me know. Actually, even if your efforts didn’t succeed, we can learn from them. Why not share them here.

References:

https://quinks.co/?variant=32701557342283

https://management30.com/practice/personal-maps/

https://en.wikipedia.org/wiki/Johari_window

 

Follow here
The Curse of Knowledge bias: Why Stakeholders Don’t Understand Our Ideas

The Curse of Knowledge bias: Why Stakeholders Don’t Understand Our Ideas

I often play “tap and guess” with my son. In the game one player taps a song and the other one has to guess which song or poem it was. You can tap either a table or a box or the other player’s back or head.

If you’ve played this game, then you might have experienced that it is extremely hard to guess the song that your partner is tapping. My son always questions why I couldn’t guess the song which was so easy and obvious to guess. What he doesn’t realise is that while he is tapping, he is also singing the song in his mind. Actually, you cannot help singing or at least hearing the tune in your mind if you are the tapper. Try it, it’s really fun.

The game tap and guess

Let me be honest, I’ve had some good guesses at the songs that my son tapped. Why? Because he seems to be tapping only a few specific songs and rhymes including “Old McDonald had a farm,” (I know you’ve continued with an “E-I-E-I-O!”), “happy birthday to you..” and a couple more. However, he never ever guessed a song correctly that I tapped. Exactly like others who played this game with us.

It is very difficult to be a listener and a tapper. As a tapper you believe that what you’re tapping is obvious and it’s frustrating that your partner is unable to guess such an obvious thing. As a listener all you hear is random tapping on the table.

So why do tappers believe that what they were tapping was easy to guess? Because they already know the song. They have knowledge and they cannot imagine what it was like to not have it.

And this is where we learn about Curse of Knowledge bias.

What is Curse of Knowledge:

The curse of knowledge is a cognitive bias that occurs when an individual, communicating with other individuals, unknowingly assumes that the others have the background to understand. This bias is also called by some authors the curse of expertise, although that term is also used to refer to various other phenomena.

For example, in a classroom setting, teachers have difficulty teaching novices because they cannot put themselves in the position of the student. A brilliant professor might no longer remember the difficulties that a young student encounters when learning a new subject. This curse of knowledge also explains the danger behind thinking about student learning based on what appears best to faculty members, as opposed to what has been verified with students. – Wikipedia

(Chip and Dan Heath have explained Curse of Knowledge in their book Made to Stick through the same game but in a different context. In fact, it was this book that Made this concept popular. Their book is worth reading if you want your ideas to be more sticky.)

How does the Curse of Knowledge bias apply to our workplaces?

You might recognise the expressions below.

“It’s not that complicated, but they don’t get it. Everything I am trying to do is in their favour and will be beneficial to them, but still they are resisting it. What is wrong with these people?”

As a consultant I have heard it from people I have worked with and I often hear it from many others. Some of these people are senior management folks, others are managers, team members, people from business teams etc. Each of them have attempted to do something which was faced with resistance.

We know that change is hard. Yet sometimes we try to either push a change or hope that people will simply accept the ideas, our ideas, that will benefit them because there is merit in them.

One thing that we now know is that some of our ideas don’t get accepted because possibly we are the tappers and our audience are the listeners. What seems obvious to us, might just be random jargon to others.

What can we do about it and are there any solutions?

Dan and Chip Heath suggested two ways to beat the Curse of Knowledge in their book. One is not to learn anything. Two is take your ideas and transform them. I’d suggest that you read their book to learn more about their suggestions.

For the scope of this post, well not focused on their ideas. Instead we’ll look slightly deeper in the subject and explore what we can do.

Why don’t they get it?

There can be a number of reasons why people don’t understand your ideas. Some of them I have listed below:

  • You’re barking up the wrong tree: You haven’t clearly defined who your audience, stakeholders or customers are. Are you talking to the wrong people?

  • Your message is complex: Even though you have the right audience, your message is complex or complicated.

  • You are seen as an outsider: It is a normal tendency that we prefer listening to or paying attention to only those who we trust. In fact, a number of initiatives to improve health and well-being of communities failed because the initiatives involved external experts and volunteers. (Initial efforts to eradicate the Guinea worm disease from African countries failed because villagers often didn’t trust the experts).

  • Time crunch: Your suggestions can solve a big problem, but that might take a long time to be effective and they don’t have patience to wait that long.

  • Short term gains over long term benefits: The Stanford Marshmallows experiment suggested that there are benefits of delayed gratification. However, your customers might be focusing on the short term solution than a problem or benefit coming in long term.

What can we do?

  • Understand the context: it is vital that in order for others to understand us, we understand them and their context first. When we behave purely like tappers, we limit our ability to understand a context holistically. System mapping can help in learning about the context.

One of the aviation organisations I worked for, brought in an executive from a large financial institution to lead a transformation. This executive applied his learnings and solutions from the financial institution to this organisation. Since everything was different, from the culture, the country, the people, the processes, to the technology; the so-called tried and tested solutions that worked at the financial institution, didn’t work at the airline. There was tremendous waste of resources.

  • Don’t be an outsider: if you offer your ideas as an outsider, the chances are that they’ll not be accepted because you’re seen as an outsider and a trusted relationship is not established yet. Once you understand the context, find ways to build and establish a relationship of trust. Of course the scenario would be different if you’ve been invited to offer your opinion.

  • Find the ‘Early Adopters: (refer to Winston Royce’s Diffusion of Innovations theory). The early adopters are those who have understood your ideas and see the benefit of applying them. They’re often the opinion leaders who others not only trust, but also listen to their opinion. They have good influence over their people.

  • Avoid cookie-cutter approach: Take help from those who don’t impose an approach. While your organisation may not be unique, your context would be different than others, even though your industry or domain might be similar to others. Each organisation has its own dynamics. If you or the consultants you bring in don’t understand that specific dynamics, the solution they propose will fail.

In this post, I have discussed problems that we face at workplaces when our stakeholders or colleagues do not accept our ideas. Some of those ideas even benefit them. But they don’t understand the value of those ideas possibly because they don’t have the knowledge that we possess.. What should we do?

The text above has offered some suggestions too. These options have helped me in the past, both in dealing with my own curse of knowledge and also in having more empathy and patience while working with “listeners”.

Everyone comes from a different background. A little empathy goes a long way.

Are there other options or ideas that you have used as solutions that have opened doors for you or have solved problems for you in working with others? What are those options and what did you learn? Let me know.

Follow here
Agile team practices that showed us immediate results

Agile team practices that showed us immediate results

There are times when culture and the practices that a team follows (or does not follow) start affecting their delivery work, primarily in Agile teams. Non-essential meetings, unplanned or unwanted catch-ups, feeling lack of safety that forces people to keep record of things such as emails, are often part of a bigger problem.

As a delivery professional (Lead, manager, Scrum Master and in some cases even product owners), your responsibility is to ensure that your teams delivers the valuable outcomes, at frequent intervals and with a sustainable pace. This responsibility also includes protecting them from non-productive tasks and mentoring them for de-prioritising non-value adding tasks.

Unfortunately, sometimes teams do not even realise that some of their practices were slowing them down. This often happens because of a rigid mindset that is ingrained in their organisations and the cultures. And as you might already know, it takes time to change behaviours and attitudes that become norms.

The good news is that you can possibly change that mindset.

How do you do that?

The answer lies in the teams. Teams are built of people, and people prefer to stick with social rules. In fact, it is often hard for people to oppose or show resistance to norms of a group that they are part of. As an Agile delivery leader, it is in your and the organisation’s interest that you encourage your teams to develop a social contract or a working agreement. These contracts define how the team members in a team prefer to work together and what they find as acceptable behaviours. Since everyone in a team contributes and agrees to the principles of a social contract, it is also easier to improve practices that affect them most.

Just to be clear, these social contracts are not legally binding agreements. They are there to enforce the values and principles that people in a team believe in and agree to adhere to. 

I was working with this team of nearly fifty people as a delivery manager. The team was consisting of four product streams and there were interdependencies. We were facing some common challenges regarding the day to day functioning of the team. Through the retrospectives, I came to know that there were few common patterns across those streams where the teams were feeling the pinch.

I was able to break those patterns in four themes: 

Productivity (and process improvement)

Culture (behaviours & attitudes)

Development & growth 

Clarity of Mission

All of these themes can be summarised in some of the key challenges:

– Too many meetings. Many of which unplanned and go on for too long

– Lack of agenda and expected outcomes in meeting requests

– Lack of a medium for team members to appreciate their colleagues across the program

– A need for a common platform for the whole team to come together and share ideas

– Finding time for training or capability uplift

A need to know each other better which was a challenge due to the size of the group

– Clarity of roles at program level

 

Here’s how we solved the problems:

Productivity + process improvement:

There were too many meetings and this large number of meetings was not only affecting productivity, it was also impacting delivery schedule. Since meetings were reducing productivity, team members were also getting visibly annoyed. 

This is what the team decided to do:  

  • No one within the team was allowed to schedule meetings after 3 PM. What that meant was that people get unrestricted productivity time after 3PM.
  • Everyone in the team agreed that each meeting request will have a clear agenda and if possible, the outcome they were looking for. 
  • We also attempted to limit the meeting times. That is, any 30 minutes were planned for 25 minutes and any 1 hour ones were planned for 45 minutes.
  • We also asked people to come prepared so that their messages were concise and crisp.
  • We emphasised on face to face conversations whether people were onsite or working remotely.  

We kept an eye on these practices for adherence and ensured that everyone, specifically the senior team members behave like role models.

Culture:

The program director and I were closely aligned on the values that everyone in the team adheres to. Having a shared understanding at the management layer certainly ensures how each member of the team will behave.

  • We encourage team members to be completely open and honest in retrospectives and otherwise too. We also made sure that our own behaviour reflects what we were advocating for.
  • I attended and at times facilitated team retrospectives. What was motivating for me was that often team members approached me after the retrospectives showing their appreciation for making them feel safe in those sessions. Team retrospectives were purely for the team members and neither product owners nor anyone from the program team were allowed to attend unless required.
  • We made sure that the program management team accepts the improvement areas and takes actions. We circulate those actions to the team members so that they can see the congruency.
  • We also ensured that we provided regular updates on the status of the action items.    
  • To encourage peer to peer appreciation, we introduced “Kudos cards” in the program. When we introduced the cards, we also explained why there was more value in appreciating those who deserve and why a reward system from management does not work. 
  • Monthly retrospectives: Due to the interdependence within the streams, it seemed vital that the whole team has a common retrospective. Team retros also reflected that need. Hence, we decided to schedule a monthly retros for the whole team. In these sessions everyone in the team came together to share ideas openly and respectfully.

Development & growth:

Many project or product teams do not have additional budgets for training for their team members. Depending on the structure of the organisations, team members might belong to different specialist groups that are responsible for their professional development. Sometimes People and Culture (a.k.a HR) teams are responsible for arranging training. Dealing with some of these processes can be cumbersome due to bureaucracy. So what do you do then? Well, see how might you get your team some training and mentoring. We found the answer in some unconventional ways. We agreed that you don’t always have to separate training from ‘business as usual’. Therefore:

  • We build small pockets of training time in each team event. We had a quarterly team events calendar and we specified training time in the calendar. For example, to enhance team collaboration, we added a ‘personal mapping’ exercise in a monthly showcase. Easy! 
  • We placed a flipchart in the project room with suggestions as well as space for other ideas. Team members could either opt for an existing training sessions or could suggest a new one. There was enough autonomy to add anything and we did see some funny suggestions too.
  • We made sure that there were options for lunch-time sessions, brown-bags, separate training and even ad-hoc sessions. Once we organised a session on user stories by extending our stand up to an extra 30 minutes. What you might find hilarious that we expected 5 attendees, but nearly 25 people showed up. 

 Clarity on roles: 

Sometimes within large teams, where you are adding new members regularly, it is difficult for team members and leads to explain various roles (just to be clear, I’m not talking about titles here). In our case, we had data architects, data engineers, CX designers, UX designers, delopers, testers, business analysts, solution designers, legal counsels, procurement people, scrum masters, product managers, domain architects and others. With so many roles, not only explaining them can be hard, but also keeping them clear to avoid overlaps. You don’t want people unknowingly stepping on each others’ toes. Neither you want any frictions among team members, no matter how psychologically safe you believe your team is. We’re all humans after all!       

  • We created a team structure chart that clearly showed who was working on what. We also made sure that the chart shows which stream people belonged to. We circulated this chart to everyone in the team and also added it to our induction pack that we shared with all new team members. 
  • Although I am not a big fan of RACI matrix (responsible, accountable, consulted, and informed), it deemed necessary to us to create one. Of course we consulted our team about what they thought about it.
    Why I’m not a big fan of RACI matrix? Because these matrix define linear responsibilities. That is, one person =  one specific role. If you are a self organising team, you may have team members playing different roles. However, having this chart helped us bring more clarity about roles and it also reduced overlapping and multiple channels of similar conversations. Additionally, team was clear that their self-organisation wasn’t at risk.
  • Skill matrix: Now this is something that was interesting.  I had used skill matrix before to create cohesive, well designed, self supported teams. What a skill matrix does is to show the availability, lack of and level of expertise for a particular skill. For example, you may have someone very experienced in C++ and you may also have someone willing to learn it. As a lead, you can take actions to balance the skill shortage. For me, this experiment failed as no one ever willingly added their skills. I also trouble validating why that happened. Anyways, this was added to our ‘Failure log’.

As you might have noticed, we solved many of our problems by bringing people together. Creating common understanding was our first step in ironing out some of the challenges we faced. We also did a number of experiments and not all of them were successful. However, keep running short experiments, validating them through feedback loops and not losing focus from your primary goal can do wonders for your team. 

Did you do something similar in your organisation? How did that go? Let me know in comments.  

Follow here
It’s not Agile that fails organisations. It’s the organisations that fail at agility

It’s not Agile that fails organisations. It’s the organisations that fail at agility

Agile has been touted by people (who understand it) as an approach, a value centre, a mindset and philosophy. Those who understand, have been observing some interesting posts and discussions going on social media that claim that Agile has failed in their organisation.
If we regard Agile as a tool that a team or organisation might choose to use, then perhaps we can understand the failure of Agile for that organisation. That’s be similar to any other tool that an organisation might use.  Sometimes tools work, sometimes they don’t! Understood! A hammer can certainly fail a carpenter if it breaks during carpentry work. But, if the carpenter does not know how to use a hammer, it is not the hammer’s fault, or is it? (Just too be clear, this analogy does not represent Agile as a tool).
Let’s not jump too prematurely to any conclusions. Instead, let’s try to cognitively analyse if there is a problem here. Jerry Weinberg’s Rule of Three* states that if you can’t think of at least three different interpretations of what you have received, you haven’t really thought enough about what it might mean. Another version of this rule that my friend Jari Laakso suggested was, “If you can’t think of three things that might go wrong with your plans, then there’s something wrong with your thinking.”

When someone says that Agile has failed them (in other words, their Agile way of working was not successful), the actual problem might have been:
They don’t know enough about Agile and they tried to “do Agile” rather than “be Agile”.
They thought that they knew about Agile and implemented it the way we knew it. What they did didn’t work. (Rajesh’s note: you don’t implement Agile in the same way you don’t implement truth.
They thought Agile was predominantly about specific practices and conventions: using post-it notes, having daily standups, having sprints and not much else. Despite those they couldn’t deliver anything.In some contexts, any (or all) of these cases may have been a key contributor to the failure of Agile.
What troubles me is that many people who blame an approach or a methodology, do not in fact try to first understand that approach or methodology.** There was a mention of waterfall methodology somewhere and most people in the discussion did not know about waterfall’s origin. Someone mentioned Winston Royce and disappointingly it turned out that even that person had selective take of the paper and decided to conveniently forget about the last few sections of Royce’s paper which are very important.
More often than not, Agile methodologies are implemented incorrectly. Some implementers don’t realize that there are Agile values and principles (Jari reminded me about ScrumButs). Some have not taken time to look at and understand the Agile manifesto. Many Scrum Masters never looked at The Scrum Guide. Some didn’t even know it even existed. I have done this experiment of asking anyone who mentions Agile whether they have actually read the manifesto. A large number of those had not. Many of those who had read the manifesto, did not try to  understand it well. Sadly those who understood it, could not implement what an approach as outlined by the Manifesto, because their organisations weren’t ready.
It is indeed often easier to blame a methodology or an approach. Agile adoption and implementations of related frameworks can fail for many reasons. What is important is to investigate what went wrong and whether that could be avoided. Even more important is to understand an organisation’s culture and whether the organisation and the approach are good fit for each other. Jerry says in his second rule of consulting, “No Matter how it looks at first, it’s always a people problem.” A good Agile coach might be able to help bring a mindset change if not the culture change.

So, as often the case may be, Agile hasn’t failed you, you may have failed Agile.

 

* The Secrets of Consulting: A Guide to Giving and Getting Advice Successfully

 

** http://www.slideshare.net/EmielVanEst/did-toyota-fool-the-lean-community-for-decades

Follow here