When should you refactor? There are times when you simply need to pay down technical debt - you should stop and refactor. No, you should only refactor when one is working on a User Story. Which advice is best? Is there, perhaps, a third option?
Is quality supposed to mean a lack of defects that are holding us back? Mike Bria, Lisa Crispin, James Bach and JB Rainsberger debate the meaning of quality and the limitations our current definition is placing on us.
An increasing number of organizations are embracing Agile development as a survival tactic in these turbulent economic times. This in turn has lead to a number of pundits examining what attitudes and attributes their teams need to be successful. Business agility is important, but how is this agility achieved?
Anyone who has spent any time on an effectively executed agile project can attest to the fact that the Product Owner's (or, in XP, the "Customer's") collaboration with the development team plays a key role in the success of a team. Peter Stevens offers a bit of advice to help people in these roles do this well.
In this presentation held during Agile 2008, Alan Shalloway, CEO and founder of Net Objectives, presents the Lean software development principles and practices and how they can benefit to Agile practitioners.
At first glance, most agile methodologies define simply that stories be developed in order by business value. In many cases though, it is prudent to blend increasing business value with deliberate steps in "knowledge acquisition". Alistair Cockburn describes how to do this blending effectively, and how to leverage it to deliver the right feature set at the right time.
Scott Schimanski recently added his voice to those talking about the power of a clear definition of "done." Scott points out there is both business and personal value in a well-defined meaning of "done". The business can count on shipping features that are done, without making any additional investment, while individuals really seem to enjoy the sense of accomplishment that comes with "done."
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.