3 Reasons Why My Perfect Scrum Teams cannot Make Perfect
Wow! It’s been 9 months since I’ve written a blog post. A lot has happened since I wrote Part 1: Sometimes Change is Really, Really Hard. I’m still at the same client, finishing up a year of agile consulting. Let me fill you in on what’s been happening there.
Before I get started, I’m excited to tell you about what else has been happening since my last post. Last November, I gave a TEDx talk that explains how to Apply Agile Practices in your Life and be Happier. I share my backstory and describe how agile transformed not only my business life but my personal life too.
That TEDx talk was so well received that immediately afterwards, Gerri and I started to develop a 12-week guided workshop that can help anyone achieve their goals through applying agile principles. If you’re interested in learning more about our upcoming FREE goal setting workshop, contact us and we’ll put you on our brand new email list.
Now, back to my agile consulting client.
Part 1 Challenge Update
When I wrote Part 1, my biggest client challenges were:
- Teams organized without a permanent Product Owner.
- Project Management Office (PMO) tracking methods at odds with agile methods
- Poor Release Management practices.
In the last 9 months, I’ve made good progress in these areas.
I was able to influence team organization through my relationship with the PMO. I helped management see the confusion caused by conflicting priorities when Product Owners are assigned to projects and not teams. I’m happy to say that now my scrum teams have a permanent Product Owner to prioritize project requests coming into the team from across the globe.
I locally fixed the tracking methods issue. The PMO still sizes and monitors progress in Dev Days, but now all the scrum teams at our local office have switched to relative story size techniques. After all the stories are sized, I roll up the story points and calculate Dev Days for the PMO. My teams receive the benefits of relative sizing and the PMO gets what it needs for management reports. Win-Win.
Release management is outside my local sphere of influence. Although I could not change the poor release management practices, I report time lost due to these issues in every sprint status report. This way, I quantify the impact to upper management every 2 weeks. Hopefully, someday upper management will see the light.
Perfect Scrum Practice Doesn’t Fix Everything?
Now, we practice scrum the best way possible. We plan Projects, we write Stories, we groom Stories, we plan Sprints, we Standup, we Demo and we reflect through Retrospective. Then why, why, why are my teams not perfect? Because at the end of the day, we’re building software, and we must follow best software development practices too.
Top 3 Reasons Why My Teams Are Still Not Perfect
The top 3 software development practices that prevent my teams from realizing all the gains from perfect scrum practice:
- Skip analysis and design as part of Definition of Done (DoD).
- Minimal or no unit testing by developers before passing story to testers for verification.
- Maintain unstable Develop and Test (Pre-Production) environments.
In traditional waterfall software development, the entire project goes through a systems development lifecycle (SDLC). One phase in the cycle must be completed for all the requirements before continuing to the next phase.
With scrum and other agile frameworks, every story (or small set of requirements) should go through the same SDLC as an entire waterfall project. Agile does not equate to lack of design. In fact, design is even more important with agile projects, which are built story by story. Without a solid design, the team runs the risk of incrementally developing software that does not fit together correctly at the end. Poor design or lack of design also increases risk of technical debt.
When developers don’t take unit testing seriously, the quality of code passed to the testers for verification is low. The initial builds do not produce code that works the first time. Stories go back-and-forth between develop and test. Stories take longer to close. Maybe the team just likes the drama?
Shared test boxes are wholly maintained by the developers and testers instead of Operations. This causes a litany of issues for version control, upgrades and releases. Issues multiply when multiple changes deploy from multiple teams working on multiple projects in multiple countries. Environments break. Many hours, even days, are lost.
Introduce Changes in Software Practice at Retrospective
At every Retrospective, I recommend appropriate changes when problems are discussed that I believe stem from the lack of best software development practices. Every time. Even if crucial practices are not adopted, I continue to teach until my team is ready to learn.
Environment issues cannot directly be be fixed through internal team process improvements, However, Retrospective provides an excellent opportunity to discuss different ways to approach and work with management. Teams can have powerful influence when they manage up.
As consultants, we always hope we can bring our clients from darkness into the light.
I guess that’s not always possible, even with the best intentions. However, continue to make constructive suggestions and find ways to track then report the impact. Telling a consistent story ensures that when teams are ready, they will hear you and take action.
If you have any techniques that you’ve applied in your own practice that could help, please share,
Cynthia Kahn
Cynthia Kahn
CynthiaK@gsd.guru
503.799.5500