Self-Improvement In Agile Teams
Self-Improvement In Agile Teams
Join the DZone community and get the full member experience.Join For Free
Discover how TDM Is Essential To Achieving Quality At Speed For Agile, DevOps, And Continuous Delivery. Brought to you in partnership with CA Technologies.
“There is nothing noble in being superior to your fellow man; true nobility is being superior to your former self.”
- Ernest Hemingway
A developer once told me that in Scrum, “I feel like I can never have an off day”. After digging underneath that facade (developer joke!), the underlying issue was that the developer wanted an “off day” to work on “technical architectural things”. He felt that the way to keep up-to-date on his skill set was by introducing the latest technologies into the product we were producing.
This portrays a larger issue regarding self-improvement on agile teams that frequently impacts agile teams. It can be an underlying reason individuals at the team level are resistant to an agile adoption. There are a number of ways to “solve” this problem. Some, including me, might create communities of practice. Spotify created chapters and guilds. My focus today is at the immediate team member level. Here is my challenge for them so that they can create an immediate way to get those “technical” items in the backlog.
Agile For Business
It’s very easy to relate agile to a business. What business does not want early ROI, predictability, and increased quality? But the “what’s in it for me?” or WIIFM question often holds individuals and teams back from adopting agile. So how can we move forward knowing that the business wants value for the business and the team member wants value for themselves?
Agile Self-Improvement Case 1: I can’t do the technical “stuff” that I want to do
Let’s delve into the root cause using a bit of the 5 why’s variation…
Programmer – “I want to work on technical stuff”
Coach – “Why can’t you?”
Programmer – “No one cares about technology. Every time I bring it up the product owner just stares at me.”
Coach – “Why should they care?”
Programmer – “Without the technology change, we can’t do all of these cool things like giving the website a real-time response feel”
Coach – “Why do you want to do that?”
Programmer – “That’s what competitors are doing”
Coach – “Why does that matter?”
Programmer- “We will loose money if they go”
Coach – “Alright, work with your product owner to find out how much we are loosing and the trend”
Programmer- “Got it, but that sounds hard to quantify”
Coach – “I’m not saying don’t do it, but you have to make it important for the business to do. What is the value of you doing it? If you know that, you have something we can prioritize. If you have something we can prioritize, you can work on that technical stuff.”
Relate it to the Business
So the point is to relate the technical issue back to a business driver. What is the ROI for improving technically? What is the improvement in quality? What about predictability of the team?
If you can’t do this, then you are blindly improving. Improve with intent and it will be more rewarding for you and your organization.
I hear variations of this all the time. Here are some additional ones I have heard or felt myself over the years.
Agile Self-Improvement Case 2: I don’t want to test. I shouldn’t have to do others jobs… etc.
Anyone that can do multiple disciplines well is of high value. If you are silo’d in an expertise, just think back to the last time that you learned a new language. How marketable are you? Learning a new skill such as automation frameworks for QA or as I found on my last programming gig, Angular, were critical for me gaining a large picture understanding of development organizations. It also gave me the confidence that I can do anything. Talk about empowering!
Agile Self-Improvement Case 3: I can’t find or don’t have the time.
We find time to eat because it sustains our life. We find time to take out the trash because it’s of high value that the house doesn’t stink. Find the things that add value to you. View yourself as a business that serves your business as the customer. What are you going to spend your R&D budget on for your own infrastructure? You have to believe in the value of your study of craft enough that you believe that you will ultimately go faster and do more. The key is to own it. Don’t ask, just do it. If you don’t turn out better results own that too. Understanding craftsmanship and committing to things like practicing your craft with katas or researching and digesting the SOLID principles are gateway drugs to self-improvement that is meaningful, long lasting, and sustainable. You will never ask for another “off day” again because you will be in the drivers seat.
I would like to explore some more cases with you. As I said, I hear variations of the same issue all the time but seldom write them down. What are some that you hear?
Published at DZone with permission of Mike Cottmeyer , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.