Developing large software systems automatically generate some technical dependency issues. If this is often managed by software architects in traditional projects, how do you communicate this technical dependencies when you are organized using an Agile approach? This is the topic discussed in the paper written by a Swedish research group.
Why do so many IT projects fail? And what can we do about it? Most companies and organizations know (or at least have heard) that they should work in a more Agile manner. But it’s generally a hard sell to the people in charge. This talk dissects the Agile practices from an economic standpoint, showing that it actually makes business sense even if the project itself was to fail.
The Scaled Agile Framework (SAFe) is one of the best know approach for scaling Agile practices. In a recent article, Al Shalloway proposes his own assessment of this framework, explaining which parts are good and which parts could be counter-productive or difficult to implement.
Henrik Kniberg goes through a handful of concrete steps for diagnosing and debugging Scrum problems. He talks about using the process wrong, blaming the messenger, being impatient, not adapting the process or using the wrong process. Henrik Kniberg also introduces some new Scrum terminology such as Scrumdamentalism, Sadoscrumism, and Scrumbutophobia.
Women In Agile is a movement partly supported by the Agile Alliance that aims to get more women involved in the Agile community through blogging, speaking at events and networking.
We all know the “Definition of Done” used in Scrum for items that should be potentially shippable to the customer at the end of the sprint. In his book Essential Scrum, Kenneth Rubin discusses the “Definition of Ready” that applies to product backlog items that should be ready to be developed before the start of the sprint.