On TUE May 19, we hosted Ron Jeffries (yes the guy who has been building software longer than you have been alive) at DFW Scrum. Ron is a frequent visitor of our group and has provided unbelievable guidance and direction to my own teams in our transition to Scrum and agile development practices
Ron spoke to our group on "Why so many agile teams often don't thrive". I think someone who actually helped manufacture the "Agile Manifesto" would probably be a good source of information on helping us identify our pitfalls in adoption and progress.
Ron specified 2 main points to this actual topic:
- Teams don't know how to ship software every sprint
- Cultural changes necessary do not take place (like helping a team become better at shipping software each sprint)
Ron's points above aren't really the meat to this topic in my opinion. I had a few people struggle with what Ron was trying to convey and I immediately came to his defense and asked "don't you guys get it?". Obviously not, therefore, this blog post. Ron's message hit me right in the sweet spot and validated my fairly close alignment with his views on agile development practices (he obviously has been a big influence in my journey).
The point? We spend so much "flipping" time (Ron would have used a different word) on making sure our Scrum Masters, Product Owners, and Organization Stakeholders are prepared for the agile journey that you know who we leave out of this preparation? You got it...THE TEAM!
If we break Scrum down into its components, we "should" have 1 Product Owner, 1 Scrum Master, and 3-9 Development Team members. Where do you think the force lies in where we spend time in equipping the teams? That's right, the backlog (which is important), how will the business react, will they engage, do we have the roles required, how will we estimate, how we will plan a roadmap, so on and so forth.
Those are all important questions to ask, but you know which artifact in Scrum we have lost focus on? The actual increment. The increment is the most important artifact in Scrum. If a team can't ship software each sprint, they can't tell a story; thus they can't get the trust and confidence needed to let the business people focus on the what; letting the teams focus on the how. Too often the teams retreat into a hell where they need to know everything up front because we leave no room for failure, mistake, or God forbid, a misunderstanding in the actual requirement.
Ron started the talk with relating to why Kent Beck created XP (eXtreme Programming). Basically to protect the team. I have a similar mindset in my transitions to agile and will usually build an API translation layer of communication over the team to protect them as much as possible from the cruft the organization might place on them. Our goal? Ship software! Not time-sheets, estimations, roadmap planning, meetings; SHIPPING SOFTWARE!
Product Development is a collaborative game. Each team has different skill sets, each human brings a particular experience and skill-set to the team. What we should focus on in our agile adoption is "do these teams have the skills necessary to refactor and work incrementally to deliver slices of software to a tested/integrated environment every sprint"?
Most of the time, the answer is no, but we will spend all kinds of money on the process, the roles, and the PMO type communication abstraction layer to ensure our teams can be left alone. As they are left alone, they struggle greatly in the organizations deployment, branching, merging, and build strategies. Please don't misunderstand, I truly believe a team needs to provide the level of transparency to the business and PMO group on our progress, but too often this turns into an inordinate amount of work for the team.
Ron painted a picture about a company party. Most of the time you find people socializing and talking about business. You usually find the development team folks bunched up together talking about technology and cool patterns they learned over a hack-a-thon project. They do this because they are passionate about the technology in their job and solving problems. Let's incubate that environment and provide more opportunities for these folks to learn more about technical practices that encourage quick delivery. Branching/Merging techniques that allow us to receive changes frequently to minimize conflicts. The nitty gritty of software development.
Ron encourages the various groups in Scrum (Scrum Alliance, Scrum.org, etc...) to think of ways we can foster growth in engineering practices. Let's build more programs around the team and not just the Scrum Master / Product Owner.
When you go back and look at your teams, let's see how much extraneous work we have around these folks that could be making them unhappy and uninspired in their quest to build innovative products. If your development environments are a large part of the problem, are we equipping the team with knowledge on how to incrementally refactor, incrementally make better paths to production, etc...?
Back to Ron's message, teams often don't thrive because we don't equip them with the knowledge and skills of how to incrementally build software. We focus on so much other activities and events in Scrum, that we tend to loose site of the most important thing, the increment. Ron is on a mission to help the Scrum Alliance and other organizations to start focusing on these types of activities that allow Developers an opportunity to show skills based on industry practices that can be learned through various techniques.
I have an old saying in service organizations that says "if you aren't servicing the customer directly, you better be servicing someone who is". In Scrum, I can say "if you aren't servicing the development team directly, you better be servicing someone who is".
We are in the business of shipping software, therefore, we better be the best shippers of software that we can. Are you?
