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.
In Are You a Doer or a Talker? Jeff Atwood of Coding Horror echoes the agile manifesto's 'Valuing working software over comprehensive documentation.' Noting an article by John Taber, Atwood draws parallels between transportation studies and transportation construction projects.
What is a developer's responsibility when a customer asks for a quick and dirty solution? Should they listen to the customer and take the short cut because, after all, they are paying the bill? Should they instead always do what is technically the "best" option in their opinion? Or is there a middle road that should be taken?