Posted on Fri, Aug 12, 2011
by Monica Yap
Thank you for reading my series on the mess that Scrum exposes. In case you missed any of the posts, here they are:
As a whole, the practices of Continuous Integration, TDD, Refactoring, and Pair Programming complement each other in many ways. CI is more effective when there are tests at different levels to validate the code during each run, creating a valuable artifact of TDD and Story Testing. To refactor, one would need enough unit tests to provide a safety net for changing the design without altering the behavior. Having done a lot of Pair Programming myself, I believe that pairing helps us to write better code and tests
So now you are asking, "How do I do all these new practices? Each of them has a steep learning curve and it’s impossible to learn about them from a book!" I have been in that place myself. I learned most of these by trying them myself based on reading books, one practice at a time. The process was painful and it took a really long time. I am passionate about helping others avoid the same path I had to travel, so I helped developed a Certified Scrum Developer workshop called Essential Practices for Agile Developers (taught in both Java and C#) to enable you to learn from experienced people and to be able to see how these practices complement each other. Although this is by no means a magic bullet to convert you into an XP expert in a few days, this workshop will help you ‘get your feet wet’ and get a feel for these practices, then the rest is practice, practice, then inspect and adapt. The course also fulfills the 3-day technical training requirement that is part of earning the Certified Scrum Developer (CSD) credential from the Scrum Alliance.
Again, thanks for reading this series of posts -- I hope you've gained some new perspectives about Scrum teams and Agile practices!
Posted on Mon, May 16, 2011
by Monica Yap
I often tell people that Scrum is great, but that it exposes a lot of the mess which normally hides under long development cycles. The mess of integration, fragile and unstable code, quality not built in from the beginning, and specialized roles that cost overall efficiency on delivery. Let’s look at each of these and the technical practices from Extreme Programming (XP) can help address them. In each blog of this series, I will cover one mess.
The mess of integration
In a much longer development life cycle, we are talking about months or even years here, we wait to integrate until the end before release. This creates a huge integration risk, and it usually comes with big surprises that ultimately lead to a lot of rework that inevitably delays the release or certain already ‘built’ features to be cut. Also, the delay integration creates a much higher cost on fixing any defect. Scrum exposes this issue by delivering end-to-end potentially shippable features during every Sprint in the framework, so we are required to integrate the changes into to the overall product in each Sprint, and hence lower the cost of any defect found within a Sprint.
Figure 1 - Cost of fixing defect curve
So now the question is – how do we do this? Doing manual integration (which we used to do) is just way too painful for every Sprint, so some teams revert to having ‘hardening’ Sprint(s) before releases, where the integration happens. This is still a big risk and surprises will definitely arise, so now we are back to the question of how can we integrate every Sprint in a sustainable way? One of the Extreme Programming practices, Continuous Integration, is the key practice to help us get to sustainable integration pace. As small changes are checked into the common source code repository, along with tests (more on this later), we have an automated engine to perform a build, run all the tests, and spit out the errors when it fails — then whoever checks in has to fix the errors and rebuild, while no one else is allowed to check in until the build is fixed. (Note that this is not just a technology or magical server, it’s a practice carried out rigorously by all team members and all teams.) So in time, we will have a code base that is always integrated and tested.
In the next blog I will talk about the mess with no quality built in.