“Each framework or methodology or certification is not the holy grail for how something should be done. Now I’m a believer in “do what works for you, what produces value.” The art is not in how perfectly you can follow a framework. What matters is that you’re progressing and learning and experimenting every single day. What matters is that you learn the approaches and practices and use them to your advantage. ” –Darren Hoevel (Me), the blog post Certifiably Certified
This is true, except when it’s not.
(I know, a typical coaching answer.) Sometimes the art IS in how perfectly you can follow a framework. Following the “rules” is especially important when your scrum team is “doing” agile and still can’t seem to deliver, or when they’re not improving, or when they’re delivering the wrong product. If this is the case, there is a good chance your team’s practices go against the values and principles (the framework, the rules) of agile.
When Redefining the Rules Doesn’t Work
More often than not (upwards of 70% of the time), when I enter an engagement and observe a team’s processes and practices, I see that they aren’t doing Scrum or Kanban by the book. They’ve abandoned certain practices or ceremonies and have adopted, they say, their own “method” of Scrum or Kanban.
Most commonly, this customization (or bastardization) involves dropping things of value (including but not limited to):
- Daily Standups – This seems to be one of the first things to go. Teams will eliminate daily standups in favor of biweekly, or weekly status meetings.
- Retrospectives – Teams decide to do retrospectives only if time permits, or drop them all together.
- Limited Feedback Cycles (my favorite)- The team will “ghost” their customer for 6 – 12 months while they’re in “development,” eliminating any chance for customer interaction or feedback.
- Only Testing in the Development Environment – Sometimes, the team won’t have the appropriate, well-configured environments to safely test their code. This can be due to cost constraints, or more often, it because IT does not have a good handle on their own environments including configuration management.
- Not Pushing to Production – Your code will sit unusable if the cost of pushing to production (transaction cost) is greater than the value your code will create. So telling your customers that you “got to done” is not accurate, because it’s sitting in a non-production environment. You did not create or deliver value until it’s in production and usable by your customer!
- Multiple POs for the Same Product – It’s a bad idea to have a PO for each segment of the business when you’re building one product. If everyone owns it, then no one owns it. Having multiple people, divisions, and/or opinions driving your product strategy will not only be the death of your product, but probably any relationship you have with your customer, as you will deliver something no one likes!
These teams say they’ve learned how to work together and don’t don’t need the ceremonies anymore, but about 99% of the time they’ve dropped these practices because it gives them extra time in their day to get more things done (which points to another problem like over utilization, WIP, or predefined delivery dates), or because they are too hard, or in order to inhibit “full utilization.” Not surprisingly, they’re now struggling to deliver, building the wrong product, and not working well as a team. By the way, this is even done by high-performing teams who are in the “flow” and decide they’re so good they don’t need these “extra” practices anymore, when those practices are precisely what made them so effective in the first place. Even on high-performing teams, continuous improvement is not always organic; teams have to make time for it.
Listen up, and repeat after me: It is not wise to drop a practice if it is not in support of a value and principle of the agile manifesto.
So let’s take a look and see how the bastardization of practices goes against the 12 principles:
- Abandoning daily Standups and Retrospectives offends #12: At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly
- Limited Feedback Cycles disregards #2: Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage; and #12: At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
- Testing in a Development Environment defies #9: Continuous attention to technical excellence and good design enhances agility.
- Not Pushing to Production goes against #5: Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done; #7: Working software is the primary measure of progress; and, #3: Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- Multiple POs for the Same Product is in violation of #1: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software; #4: Business people and developers must work together daily throughout the project; and #11: The best architectures, requirements, and designs emerge from self-organizing teams.
If Your Team is Not Delivering or When You’re Delivering the Wrong Product, Go Back to Start
It’s a simple as this: All team members need to speak the same language. All team members need to know the ins and outs of the same processes. Maybe every team member has done Scrum or Kanban in the past, but each one of them may have been done a different “flavor” of Scrum or Kanban, or likely, they may not have been doing it right at all. So, do it by the book. Plan every sprint. Hold standups every day. Do every retrospective. Get on the same team. Follow the same rules. Get in the zone. Gel as a team.
Aside from developing team flow, and delivering the right product with low defects, and all that fun stuff, these practices good for team culture. Ceremonies offer direct communication and transparency, and if the teams are committed to continuous improvement, create a safe, respectful space for experimentation.
When you CAN Break the Framework Rules
It’s a simple as this: All team members need to speak the same language. All team members need to learn, adopt, and be in the same flow. Maybe every team member has done Scrum or Kanban in the past, but each one of them may have done a different “flavor” of Scrum or Kanban, or possibility, they may not have been doing it right at all (bastardization is everywhere). So, do it by the book. Plan every sprint. Hold standups every day. Do every retrospective. Get on the same page. Follow the same rules. Create your team norms. Get into flow. Learn it, be it, and live it as a team.
Aside from developing team flow, and delivering the right, high-quality products, and all that fun stuff, these practices are good for team culture. Ceremonies offer clear expectations, channels for direct communication, and transparency. And if the teams are committed to continuous improvement, they create a safe, respectful space for experimentation, success, and failure.
When CAN Your Break the Rules?
You’ve heard it before, but I’ll say it again: You can drop a practice if you’re still inline with the values and principles of the agile manifesto. Wait. We can’t drop the daily standups? Probably not, or at least it would not be my first consideration. Once you’re running like a well-oiled machine (could take a couple of weeks, could take many months), you could explore dropping something less “vital” (including but not limited to):
- Estimating. You’ll know each team members’ skills and capacity, the complexity of the product, how much you can accomplish in an iteration as a team, the needs of your customer, etc. In other words, you’ll know the flow and capacity of your team. You may value estimates less and realize the conversation and flow are more important and the teams delivers on a predictable basis.
- Remove the limited invite list to your Retrospectives. As your team starts to excel, delivering value every couple of days, constantly engaging with their customers, and sharing their successes with the rest of the organization, their hunger for improvement will grow. Pulling in other IT and customer groups will expand their Kaizen mindset, as well as the organizational reach for improvement.
- Eliminate physical team boards and move to virtual boards. I’m stepping in to controversial waters here, but go with me. If your team is well synced and emphasizes transparency and communication, there may not be a need for a physical teamboard. It may well be enough to have a virtual board that is shared amongst the team and their customers. (I’ll just stress my opinion on this one: physical boards are an amazing tool and any team I’m working with would have to really justify this one to me.)
Constantly Reevaluate
In the spirit of inspect and adapt, constantly reevaluate your practices. Any time things start getting loosy-goosy and you’re team is not delivering like you used to, things are stagnant, you’re delivering the wrong product, or the team is just “off,” go back to the beginning. What worked before may not work now. Analyze where things start to get wobbly.
In the Face of Change, Start at the Beginning
It’s a good idea to take it back to “start” when you change or onboard a new team member. Everyone needs to speak the same team same language and be indoctrinated into the “norms” of the team and the organization. Take the time to get everyone educated and solidly on the same page.
It’s also important to follow the rules when you are adopting something that is very new and there is minimal institutional (in-house) knowledge. Your team will be unlearning their current “standard operating procedures” and building a new set of practices and knowledge within the organization. Similarly, the new practices are not only a different way of doing the work, but a huge cultural change for the organization. You will be unlearning established ideas and behaviors, unlearning a mindset of “that’s the way we have always done it,” building new “muscle memory,” new capabilities, and new cultural norms for the individual and the organization. So, start at the beginning and play by the rules.
There you have it folks. Make sure to stay true to agile values and principles! In case you want to become a better leader or team member, join me at my next Dare to Lead course.
By: Darren Hoevel
