- Agile Leadership Development
- Product Owner
Scrum changes the way everyone in your company interacts and will likely influence your organizational structure.
When an organization considers “moving to” Scrum, it’s easy to think that Scrum is a new process that just needs to be learned and implemented.
“This year,” says your friend (who’s never run a 5K), “I’m going to do a marathon.”
“Yeah? How are you going to do that?” you inquire, trying to sound polite and curious rather than incredulous.
“Well, I haven’t figured that out yet…but I’m looking at maybe Chicago or Boston…”
Last month we talked about good software design and introduced the notion of code smells. Code smells are names given to those instinctual thoughts you have whenever you look at a chunk of less-than-elegant code. Some are subtle, and some really stink.
I’ve learned not to assume a team has experienced a variety of software design skills. Some are writing elegant functional-paradigm code in archaic, challenging languages. Others are writing strongly-coupled, heavily-commented, and procedural static methods in Java or C#.
“We need you to help this team. They are struggling to deliver. But don’t worry; you’ll love this team. There is no conflict and they are willing to help each other.”
I was assigned as the ScrumMaster for this team many years ago, and this is how my boss described the team I’d be a part of. Every part of his statement was true because this team had settled. They settled for cooperation instead of working toward collaboration.
As an Agile trainer and coach, I have worked with hundreds of companies over the past 10 years. After reflecting back on my interactions with all these companies, I have found there is a strong correlation between a single decision companies make and how much dysfunction there is in the company.