Automating unit testing is difficult but that’s no excuse
In this short article Rob Diana argues that developers are responsible for producing working code and that to do so, it is imperative that the code gets tested and exercised through unit tests.
This is perfectly reasonable and most developers I worked with don't have any issue with unit testing as defined by Wikipedia as long as the level of automation is low or non-existent. The Wikipedia article on unit testing explains that "[unit testing] implementation can vary from being very manual (pencil and paper) to being formalized as part of build automation."
However, a major gap exists between exercising the code through manual or semi-automatic tests and writing automatic tests to verify continuous integration builds. Of course the latter produce higher quality software in the long run but this gap prevents some teams from reaching a higher level of code quality while minimizing rework (i.e. higher productivity).
Implementing automated unit tests is not simply a technical exercise. It is also a complex problem that requires a sophisticated and coordinated effort among developers accompanied by a culture change where developers and other stakeholders:
- treat unit testing code with the same level of respect as the rest of the application (this code may not end up on the server or the user's desk put it is an essential element in minimizing defect escape rate);
- accept that an automated build is successful, if and only if, all the associated unit tests passed.
This combination of cultural and technical changes is essential to a successful and full-scale automated unit testing implementation.
Things to think about before and after a daily stand-up meeting
Daily stand-up meetings are at the core of the Scrum process. They help synchronize the team and quickly escalate impediments. Regardless if you have been participating in those meetings for years or you are just starting today, Mike Griffiths just published two useful posts to help us get more out of this critical activity:
Anchoring Effect
According to wikipedia:
Anchoring or focalism is a cognitive bias that describes the common human tendency to rely too heavily, or "anchor," on one trait or piece of information when making decisions.
This is a dangerous bias that can bite you when you are estimating tasks or stories in an Agile environment. I am even wondering if this plays a role when you are poker planning, and how much this influences your decisions from the get go.
Anyway, this article goes into detailing the anchoring effect and the "You are not so smart" blog is providing insights on common human behavior that plays an important role in software development.
While the phenomenon is well-known, I am wondering what a team can do about it. How can you overcome its nefarious effect and also how do you measure its effect in the long run.
[via You are not so smart]
Original photo by Plbmak
A Pattern for Using Scrum and Kanban
For a while now, I have wondered how you can combine Scrum and Kanban. Scrum is a good lightweight method that, if applied properly, can improve productivity, and more importantly, transparency for all stakeholders. On the other hand, Kanban seduced me for its simplicity and its ability to streamline your development. However, I never read anything about combining the two and most articles I have read so far seems to portray those two methodologies as oil and water.
This article take a different approach and shows how a well lubricated and performing Scrum team can benefit from Kanban.
This is food for thought.
[via AvailAgility]
The Cloud is Cheaper than Bare Metal
Well, I don't know about yours but many organizations are looking into the Cloud at large to lower their cost and increase reliability. Looking at Amazon EC2, prices seem expensive when you are on a tight budget, especially if you belong to a small organization.
However, as this article demonstrates, the price gap between using the Cloud and maintaining your own servers is narrowing.
[via High Scalability]