Ignoring the problem
I’m sure that what I say here will resonate with some of you, but you may find my opinions and this post a little controversial. I have quoted freely from Pink Floyd and Red Dwarf, but I’m not going to cite them all.
Unless you’re new to the Agile community, I’m sure that by now you will have participated in several implementations of Scrum/Agile in various interpretations and mutations. My last engagement was an unimpressive example of how to run a total Waterfall approach wrapped in a few Agile ceremonies. The biggest problem with that approach was that there was no recognition of how broken things were. More important, this meant there was no desire to change.
So let’s be controversial. When things don’t go as well as they could, people often recognize this problem but, instead of calling it out, they sit quietly watching the frog get slowly boiled. I believe that this is probably one of the biggest issues the Agile community currently faces. Aspiring to mediocrity may be OK for some, but I’m not prepared to exchange my "walk-on part in the war for a lead role in a cage" (Pink Floyd).
I guess I can accept this sort of behavior from the foot soldiers and camp followers that all Agile implementations seem to accumulate. But Agile coaches and ScrumMasters with more flesh in the game definitely should know better!
The 3 most important Agile practices
"If you had to pick three things that were the most important to making Agile work, what would they be?" I was having a light lunch south of Smithfield Market in London, and I was about to give up on a client. But my questioner put me on the spot, and my Agile credentials were on the line. For the Red Dwarf
fans out there, this was a sort of Dave Lister moment: "So justify yourself."
She had a point. It’s all very well to sit there reflecting on what’s not going well, but I needed some clarity, vision, and direction if I wanted to put things right. Pulling a metaphorical rabbit from my arse, I quickly thought up three practices:
- Ensure that the voice of the customer is at front and center of everything that's done.
- Keep all your discussions in the language of the business.
- Deliver as early and as often as you can.
Some of you may wonder why I listed the top three practices and not the items that follow. The reason is that although there is value in all these practices, I believe that the first three practices are more important!
- Short iterations
- Daily stand-ups
- Reducing waste
- Responding to change
- Sprint reviews
- Definition of Done
I’m not going to dwell on any of these practices, because to me they represent a mixture of solutions to the challenge we face. They are all valuable practices and your Scrum implementation needs to include them. But they also have the potential for creating unnecessary noise and sometimes an excuse for not focusing on what’s really important.
So if I were delivering Scrum as a product, those first three items would be at the top of my product backlog.
Ensure that the voice of the customer is at front and center of everything that's done
History is replete with IT initiatives that have gone wrong, mainly because super-clever IT professionals thought they knew what their customers wanted better than their customers did. Scrum and Agile practitioners recognize this old-school thinking and have learned to cherish the voice of the customer.
Whether you like to admit it or not, you need your product owner more than your product owner needs you! The Scrum Guide is explicit on the importance of this role, yet even in the best implementations, we still get "leakage" (i.e., work being done that the product owner never agreed to).
I’m not claiming that architectural changes, technical tasks, bug fixes, and so on have no value, but these need selling to your product owner. This brings us to the next point.
Keep all your discussions in the language of the business
As stated earlier, you may need to refactor some code, make an architectural change, or perform some other technical task. Your product owner must understand why delivering any of this should be more important than the functional user stories in his or her product backlog. You may have to apologize and explain how you rushed forward for them and didn’t keep things clean as you delivered (refactor), but now you really need some time. Or maybe you explained this in advance and now need to pay back the technical debt you accumulated.
Explain to them what you need to do, why it’s important, what will happen if you don’t do this, and how much it will cost. You may be surprised by their response. That conversation sounds far better than hiding it and performing a thankless task.
Similarly, wording requirements and handing down solutions in the language of a user story is quite unacceptable. The focus on outcomes should be explicit, and the reasons for this should be explained until everyone "gets it."
So keep discussions with the product owner in a language he or she can understand. As the go-to person for all stakeholders and the person trying to maximize the value of the product, the product owner has a tough job. You shouldn’t make it tougher than it is already.
Deliver as early and as often as you can
I think the word "early" is what we need to concentrate on here. Empiricism may have become a throwaway word in the Agile community, but to me it means that knowledge is based on experience.
The customer is the only person who can tell you whether you're successful, and they can only do this when you have given them something. Only when they use the system in anger will they be able to tell you whether it’s good or bad.
Delivering something that’s very small early on and getting valuable feedback is far better than waiting for that mythical MVP, which in reality is an MVPP (Minimum Viable Political Product). This means deploying a usable increment of the product after a few sprints. The product should be just good enough, with lots of room for improvement! If this is the first time your organization has attempted this, don't underestimate the change in thinking that is required to accept this.
In the past, and even today, many organizations have long Waterfall-style release cycles involving a cast of thousands. These processes and procedures are baked into the way these organizations do things, so you will probably be opening a battle on two fronts:
- The technical challenge of continuously deploying code into production in a consistent and reliable way
- Negotiating change to a process that has more to do with bureaucracy and politics than with value
By now I expect that you can see the second point is going to be the most difficult nut to crack. My response to this would be: The first of your competitors to do this will probably take the lion’s share of the market; the rest probably don’t need to bother.
Report problems to stakeholders
It’s all well to complete an analysis and recognize that things aren’t going so well. But how do you deal with this recognition?
Everyone has seen Agile at work and understands the importance of the second set of practices mentioned earlier. Most of them are tangible and easy to understand and implement. Because of this, organizations tend to focus on these low-hanging fruits under the mistaken belief that they are making progress. Although the big three may seem just as simple, I think they are the DNA of Scrum and a lot tougher to get right.
Whether you're just starting Scrum or the development of your product is in flight, if you can see a problem with one of the three practices, then your first point of call should be your key stakeholder. This probably isn’t your product owner — it's likely to be someone with senior ranking in the organization with the power to starve or feed the initiative either through politics or funding. Of course, such folks have gatekeepers, so use the correct channels. However, be careful of the "yes men" whose job is to protect these individuals from information that "is not in their interest to know."
You need to explain the following critical information to the stakeholder:
- You know the problems and the changes necessary to solve them.
- You will need their support to drive this change.
You may get their support, or they may explain why they can’t help you or suggest an alternative approach. If possible, try to gauge how hungry they are. Are they prepared to support you and remove people who block progress, or are they going to maintain the status quo? Either way, if you got this far and they understand the problem, listening to their opinion regarding the three practices matters more than giving them yours!
Choose your direction for success
If you have completed your analysis and run up the red flag, you now have some choices to make (as the Yoda character in the Star Wars movie The Empire Strikes Back
directed, "Do or do not, there is no try”):
- Sit quietly and watch your Agile integrity gently seep away.
- Reenter the fray with your sword freshly sharpened. Challenge the status quo and rely on your stakeholders support when it gets bloody.
- Move on.
It may be that only one of the three practices is a challenge to your organization, or maybe all three are.
If you are at the start of an implementation, or even if your delivery is in flight, act now. Dealing with the three most important practices will increase your chances of success!