This short presentation explains why software metrics are not the panacea that we thought they might be 20 years ago. This is why moving from a predictive model to a reactive approach is the only rational course.
Mike Cohn wrote an interesting post where he discusses he allows or even encourages to estimate with story points as large as 20, 40, and 100. He explains that they are useful when you need first and not necessarily precise estimate of the general size of a new project being considered.
Some estimates say that 80% of Software development projects are now global. According to these trends, if you work in or manage a co-located team, it will not last long. There are two approaches to global projects: outsourcing and distributed teams. My concern is distributed teams, where team members can work from a location of their choice.
Even if the the Agile Manifesto declares that you should value “individuals and interactions over processes and tools”, this doesn’t mean that you shouldn’t use any tool. The authors of this article shares their experience using agile tools and explains why they prefer non-software tools and why you should be carefully pick the tools that will support your practice and your company if you pick any at all.
Jeff Sutherland and Ken Schwaber met for the first time together in Europe at the ESE conference in Zürich. For the closing keynote they discussed on the theme “Agile Development in the Enterprise: Transforming the Way of Work”.
The topic of Managing Risk in Scrum projects is addressed by Valerie Morris in these two blog posts. The first part discusses the five risk areas found on most software projects: intrinsic schedule flaw, specification breakdown, scope creep, personnel loss and productivity variance. The second part compares risk management practices between traditional project management and Scrum.
Have you worked on a distributed team where management apparently thought it should hobble local members to make everybody equally frustrated and ineffective? The Agile Manifesto principles say that: 1) Business people and developers must work together daily throughout the project. 2) The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.