Choosing the right features can make the difference between the success and failure of a software product. Mike Cohn presented 'Prioritizing your Project Backlog' at Agile 2008 on how a project backlog should be organized and prioritized and non-financial techniques for prioritization such as kano analysis, theme screening/scoring, relative weighting and analytic hierarchy process.
In this presentation filmed during Agile 2008, David Anderson talks about the history of Agile, the current status of it and his vision for the future. The role of Agile does not stand in just having a practice, but in finding ways to implement the principles contained by the Agile Manifesto.
Ryan Cooper picked up Agile Adoption Patterns: A Roadmap to Organizational Success by InfoQ's own Amr Elssamadisy and gives this book a positive: This book belongs on the bookshelf on anyone who is interested in helping a traditional software organization make an effective transition to a more agile way of working.
Lean software development, which we hear a lot about these days, may be still a bit of a mystery for people who come to Agile via Scrum or XP. Earlier this year, at an Open Party was sponsored by InfoQ China, Ning Lu of ThoughtWorks China offered an introduction to Lean thinking, and said the biggest obstacle to Lean thinking can be the manufacturing mindset.
Return on Investment is a critical factor for decision making pertaining to following a particular software development practice. The post summarizes the ROI benefits of Agile and the inexpensive practices which lead to highest return on investment.
The never ending debate about the role, the relevance or the organization of IT has added yet another frustration moment. Susan Cram, an industry expert, shared the 8 things -she thinks- we hate about IT. In her analysis, she points out a surprising remedy: avoiding the IT alignment trap.
While SOA was the big name in the buzzword tag cloud, BPM is quickly getting bigger and bigger. As organizations are becoming more aware of the need to tame their processes in order to get the benefits of IT investments, BPM is gaining importance and mindshare inside and outside of IT. Is one more important for your architecture?
Scrum defines an impediment as "anything keeping the team from being more productive" and clearly stresses that teams establish means to remove them as continuously as possible. Joe Little proposes an impediment's scope may be better established as being anything keeping the organization from delivering value.
Aside from "Agile" itself, "Business Value" may be one of the most widely used buzzwords around the floors of any fresh agile project. But, how many of these projects actually have a good understanding of what they really mean when they're saying it? Joe Little presents his thoughts on this very question.
Sometimes, management encourages adoption of Agile but fails to help remove the overburden that cripples teams and keeps them in non-productive patterns. In his article, Roman Pichler looks at the "3 M's" of Lean, and how the concept of removing "muri" (overburden) provides help for Agile adoptions, by encouraging teams to give up wishful thinking and commit to their actual capacity.
Taking an empirical approach, Reality Driven Development promotes the idea of rigorous experimentation as a way to improve the user experience and technical qualities of software development.
Jennitta Andrea & Ward Cunningham recently hosted a WebCast on 'Envisioning the Next Generation of Functional Test Tools'. Also, towards the end of last year Thoughtworks' announced its intention to release a next generation functional testing tool. InfoQ investigates the growing momentum for change in the area of functional testing and how the thought leaders in this area see it developing.
A recent discussion on the Scrum Development list looked at: “How does a customer measure the success of an Agile project?” Emphasis on: “measure”. The discussion seemed to agree that clients do need a way to track success in their terms, and various metrics were suggested, though it was agreed: it depends on the situation and the customer.
In his latest article Martin Fowler suggests that what matters most while building a team is not experience or thorough knowledge of the specific platform and business domain, but rather some broader skills that allow building quality software and delivering value.
What value do teams get from measuring velocity, beyond the ability to reasonably estimate commitments for the short-term future? J.B. Rainsberger proposes that teams spend less energy scrutinizing velocity and more energy thoughtfully identifying and eliminating areas of waste in their projects.