Self-Improvement In Agile Teams
“There is nothing noble in being superior to your fellow man; true nobility is being superior to your former self.”
-Ernest Hemingway
Introduction
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.
Variations
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?
Comments (6)
Kirsten
Thanks for the post. Just touching upon case 1, I personally think the example you’ve given provides evidence of a deeper lying dysfunction in the organisation. There’s dysfunction between the coach and the developer and dysfunction implied between the organisation and the developer and it demonstrates that Agile has not been embraced throughout the business. If the business was a technology business and this was occurring then there would be serious problems (ie: it shouldn’t be up to the developer to remind the coach – and the business – that they better be keeping their eye on the competition and that technology and developers can help them harness technology to meet business goals) more effectively).
The business – and coach – should already be aware of the insights and benefit a developer can bring to the business without needing the developer to justify it. Their should be an honest and open framework whereby the developers (and anyone else) feel they can contribute new ideas (new tech, new design etc) to the product development strategy.
Tim Wise
Hi Kirsten,
Thanks for joining the conversation.
It certainly does imply that agile has not been embraced. Much of my time is spent providing a framework such that agile can be embraced in large orgs.
I totally agree that there should be an open and honest framework (demo’s, planning, most anytime) that promotes bringing great ideas to the table. That’s then end goal right? I am writing about early or poor agile adoption on teams. I have seen plenty of individuals struggle with how to approach product owners and plenty of product owners have glazed over eyes when they do come to the table and speak about mocking for TDD. Alternatively, individuals can struggle with being driven only by business functionality and don’t empower themselves to give suggestions at all. They just do what they are told because that is their learned behavior over time. Team members need to learn to speak about value in a common language. Value is… valuable :) Once they learn how to talk, this goes away.
Scrum tool
Case 1 dealing with “I can’t do the technical “stuff” that I want to do” – Technology keeps on changing, and on a continual basis. Nowadays, success of projects depend a lot upon end user experience, and unless technology is updated from time to time, it is impossible to keep abreast of the latest stuff, and more important, improve the end user experience. That is an important issue. The team ought to be well versed, and feel comfortable with delivering the product increments in a sustained manner. It needs to invest time and efforts to cover newer technologies. And, unless the management supports the team in its activities, you’re talking about phased out development which can incur a certain amount of technical debt in the future. Not good for the management and for future projects. I guess it would be the management’s take on this issue – Whether to “make do” with the current technology, or start thinking ahead, and plan to remain ahead by incorporating newer technologies in future projects to improve the end user experience.
Tim Wise
Thanks for the comment ScrumTool.
I completely agree that we need to balance short-term technical tradeoffs with an eye on the future. I believe that we should invest in long term technical strategies that will enable future delivery of value. The purpose of doing so is to enable the delivery of more value.
What I find consistently is that organizations don’t know the relationship between technical tradeoffs and enabling value creation. It’s an enabler and not value in and of itself.
Example: A few years back an organization that I was working with changing a delivery organization from delivering Windows Forms for a UI experience to … they couldn’t make up their mind. They couldn’t relate it to value creation. They sporadically moved from Forms to Silverlight (remember years ago) to WPF to “just move it to the Cloud!” Eventually they settled on HTML5 with a different UI stack all together. But at the time they picked HTML5, they began to tie in the value they wanted. They wanted at a high level… a simplistic, yet informative design in the healthcare space (yep that’s hard) that could decrease the cost of mobile initiatives, perform best in class, and decouple product lines to be sold individually or as a package. To achieve that they needed a responsive design that behaved like a client application but on the web. They needed something like bootstrap, Node, SOLR, and the list goes on and so does the wealth of needs they needed. They pulled together teams and made the investment. They needed technology to enable value delivery for strategic initiatives of the organization.
female
This post explains in detail exactly how Redgate ran it s first formal team self-selection process, from initial planning to completion.
Vedica Scholar
Thanks for sharing this blog, it is very useful information for the person who wants to choose the right self-development for women I appreciate your work and consideration, and if one is looking for reliable self-development for women in Delhi, Vedica Scholar is an online portal for women to learn and share insights on self-development topics. Our goal is to empower and inspire women through affordable courses that are not available elsewhere. We have Vedica scholars who provide us with the best self-development for women.