Agile is simple, but there is nothing easy about implementing it. As Kristian Rautiainen put it: Bad Scrum is all about ceremony without understanding. It is tempting to assume that we can fine-tune the process to tick like a clock in a short period of time. As an example it seems that Scrum gives you a good head-start in new feature development and a hyper-productive team creates working product fast until it doesn’t. The missing bit is the lack of test automation as presented by Uncle Bob. This is only one of the things that makes change look easier than it is. Adopting new things is all about changing a culture, that takes time.
One of the general assumptions of an organization that practices Scrum is that everybody understands it. That is mistaking compliance with understanding. That is following only the prescriptive face of Scrum. For some members of the team the gathering in front of a wall with colorful stickers is the essence of the methodology. It is not uncommon that the board is considered to be equal to the methodology. That leads to people having a misconception that Kanban - being simpler in the prescriptive part - is easier to implement.
People in groups larger than three do not tend to be well disciplined. It is not uncommon, but usually it requires religious commitment, capital punishment, oppression or a military regime. I think that is not the case in most companies. For me Scrum, Kanban or Agile are nothing I would like to do on my free time. The major difference between a hobby and work is the direction the money flows. It is not always supposed to go the way I want it to and that is why I am getting paid. For a hobby I am ready to pay and I expect to get my money’s worth. Understanding this angle requires some discipline and I am not sure even that is universal.
I am seeing a lot of discussion about the changes that need to be done to the Agile Manifesto. There are always projects that would be easier to pull through if Agile would be more flexible. I would like that too. I would love doing things right to be easier. That way there would not be so much discipline involved. Some say that the whole thing should be rewritten. It is true that teamwork is important and it may be that individuals and interactions does not paint it in bright enough colors. It makes sense that business value is important, but is it more important than making sure the software works and taking a risk once in a while? What is partnership elaboration anyway? You need partnerships to be in business, sure. What happened to collaboration?
Preparing for change is the part I like the least. Back in the day when I was writing code all day, there was the principle that I should not be coding in support for future and rather refactor when the time is right. In that sense, preparing for change is just the opposite. I think Dean Leffingwell said that roadmaps kill companies. You need to keep your backlog short to respond to change. Preparation is the other extreme we set out to change even if it is important for companies that do not expect any change. There is going to be change but the software has to be shippable in the meantime. I think the signers of the manifesto were in their right minds at the time. Ron Jeffries, one of them, did say in his blog that the likely reasons for such ideas are either going too far or not far enough. The former has never been observed.
I heard an anecdote once about a Japanese trainer who came to a company on two consecutive years. The second year somebody noticed that he is repeating his lectures from the previous year and decided to state his remark. The reply was that apparently it did not get implemented the last time. This again is the thing that I am talking about. We do not accept the discipline. We do not try the things out or try to understand why we should be doing them. The point of inspecting and adapting is that we do something that we can inspect and adapt.
This is true in many teams that are beginning their journey. It is tempting to assume that you can implement most of the simple changes from the retrospective in one sprint and keep them forever. After all most of the things need a cultural change and there’s more. The people participating the retrospective may have a different role than you assume. Agile Retrospectives presents a model of four roles: explorer, shopper, vacationer and prisoner. The explorer is there to learn and discover, the shopper is in for some new ideas, the vacationer is there for the ceremony and a break from real work and the prisoner would rather be fishing.
Deciding things with people who are not committed is a difficult matter. You might have them saying yes and never really following through. In the next retro they will say they could have told you so, though they did not bother. The same people may be committed to their job and get their kicks out of performing well. It is different to be committed to continuous improvement. Peopleware said that people really really hate change. The threshold for acceptable change is different. For some developers it is a major change to move from one language to another and others assume that is something they are going to do eventually. That is where the C only developers and manual only testers come from. Do not get me wrong, domain knowledge and mastering your current tools is important. I know many people who are specialists in a well-defined area who are really valuable. However it is not for everybody. Too much specialization leads to silos. The methodology is yet another dimension in the matrix.
The real problem in Agile is that people need to open up for the necessary change. In Scrum terms that is the point where the team is ready to improve on its own.
While the team needs to improve itself, it also needs to know how to defend its self-organization. Not all change is necessary or for the better. Especially during the project end-game there may be changes for the sake of change. People in panic become reactive and for every concerning detail there is a thrashing reaction.
The concept of a project is somewhat counter-productive to Agile teams. The teams should be able to release a working product every Sprint and be there multiple teams, there will be something to show the customers every few weeks. In such a situation the customers pay less attention to the contents of the improvement. They will simply see that there is a constantly increasing value. That makes the feature checklist a bit obsolete. Teams are designed to consume a prioritized backlog ad nauseam and when they enter a hyper-productive mode, marketing will get used to adding etcetera as the last items in your yearly new feature checklist.
Another thing about people outside the team is that they assume that the teams move fast and change fast. That may be true in some things but again not generalizable. Improvement still needs time and telling the teams once they need to adopt new practices does not mean that it sinks in. The message needs to be repeated. What I have seen many times is that some requirements are set and the repetition is rephrased in a way that makes it seem like the management changed their minds again. Everyone would be better off if the reasoning was explained thoroughly. Another thing is let the teams find the root causes instead of dictating new mandatory practices.
The company wants to redefine the Agile Manifesto and the teams want to go Kanban because it is so much easier and less disciplined than Scrum. In other words the company abandons Agile because it is just too disciplined and try whether going half way would be easier. The team changes Scrumbut to Kanbut so that they can stop pretending to plan altogether and get rid of those awkward discussions in the retrospective.
The point of Agile is that we keep doing the hard and necessary things. They are not on the marketing material because you could not sell that much trouble to many people who are not big on challenging themselves and their peers. It may be that when you go far enough, you can start creating your own form. In Japanese martial arts there is the concept of Shuhari: shu - tradition or form, ha - breaking the tradition or form and ri - departing the tradition or form, mastery. First you learn the form and understand why it is done. An experienced karateka told me that they know the form well, but do not know what the different movements mean in context. The same way you need to see beyond the surface of the ceremonies to the goals before you start changing the rules. Most companies do not reach mastery before they start to create their own tradition. One size does not fit all and some of the practices cannot be implemented right away in all environments. Still you should try to introduce them again when the time is ripe.