Jenkins CI is a popular open source continuous integration server. I encourage teams to use continuous integration, however many teams setup the server, configure the automated e-mail blasts and think that’s all there is to it. Many teams don’t make the results of their builds part of an informative workspace. The team I’m currently working with fell into this trap and started having issues with failing builds going unnoticed. I looked around for some plugins and projects to help with this goal, but nothing quite met our needs.
Here are the slides for my presentation at the May 2012 Phoenix Scrum User’s Group meeting. If you attended the meeting and have any further questions, please contact me, email@example.com. Retrospectives: Best Practices, Common Problems and New Ideas Retrospectives: Best Practices, Common Problems and New Ideas from Clayton Lengel-Zigich View more presentations from Clayton Lengel-Zigich.
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage. The first thought here is the means, the second the end. Let’s start with the second. Evaluate We want to afford the customer the ability to adapt to rapidly changing markets. Processes that restrict the customer’s ability to adjust the implementation strategy of their vision make it impossible to use change as a competitive advantage.
The Agile Manifesto describes twelve principles of agile software. In a series of twelve blog posts, I will explore each principle. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. This principle can be broken down into two separate thoughts. Continuously delivering early, and always delivering value. Delivering Early and Often Delivering early is more than just delivering something before the competition.
While the drive towards a culture of “always be testing” has existed for some time, the recent detour into software craftsmanship has helped to create a new style of getting the word out. What used to be, “Test driven development is a great way to approach solving a problem” has turned into “If you’re not testing you’re a shitty developer.” The testing evangelism going on in the community today is misguided and would convert more people if it addressed the real reason people aren’t testing.
This shift in thinking is due in part to Liz Keogh’s Step Away from the Tools and Dan North’s Who’s domain is it anyway?. Both of these got me thinking about how I’m using the term BDD (rather loosely) and how much of an investment I’m making in a specific tool (Cucumber). More Meaningful Planning Having meaningful planning meetings with their customer/product owner is one thing with which many teams struggle.