Hello and welcome to my blog, which is generally on the topics of my most recent work and books, including Scaling Software Agility: Best Practices for Large Enterprises and Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise.
These two books represent my latest, published thinking on the topics described in the titles. However, as I continue to help some of the world’s larger software enterprises achieve the benefits of adopting agile methods, I continue to learn new things. As I do, I record them here. So in a sense, the blog serves as the “tip revision” for the books. Taken together, it is the best content I can provide to the agile software enterprise. (If I knew more, I’d probably write more…)
Fair warning though — as I learn new things and observe new and successful patterns in the industry, my thinking evolves and I have been know to change my opinions from those I have published prior. For even a part-time author and methodologist like me, that isn’t always so easy. But, as you search for meaningful guidance on these topics, please consider the alternative.
This isn’t a newsy or chatty blog, rather it is intended to serve as a relevant content repository for describing and understanding agile best practices, including requirements management, as they can be applied to individual teams, as well as more advanced practices that scale to enterprise-class development — those organizations building software that requires collaboration amongst hundreds and even thousands of practitioners. So if you subscribe to it, you won’t be inundated by daily blog posts. (But then again you won’t if you don’t subscribe to it either!).
Since there is a fair amount of content here, I try to organize it around a consistent set of categories. You’ll find these in the Category widget on the right.
This blog is dedicated to those large and highly successful enterprises with the courage to reinvent themselves. Embrace Uncertainty!
Scaling Software Agility 
Hi,
on page 222 of “Scaling Software Agility” you mention Supplemental Requirements and the potentially massive effect they could have on the architecture of the system and indeed on the rest of it (IMO).
It seems to me that the implementation of these Supplemental Specifications does not fit well into the User Story approach and perhaps is more at home in the BUFR model.. given that they are not likely to be subject to user-feedback driving the iterations. Sometime around here this is called “Whim-driven” software but that is rather unkind. Any thoughts on Supplemental and scaling of Agile?
George
Hi George,
Whether they are defined up front (“each release must be localized to the following five languages…”) or they emerge (“transactions must be acknowledged within 500 msec of receipt or….”) they are certainly not “whims” and they must be known and communicated (documented) for all teams.
I agree that they don’t fit the “as a user I can” user story format and there is no need for contortions to make every requirement that must be known to the teams conform to that format.
if the system has to do something or there is a constraint that must be known, Just Say It!
Many teams create a special “common requirements backlog” and put them there for all to see and respond to.
Dear Dean,
I just came upon this blog by change, and albeit “lean” and “agile” are not the main topics of my own research within supply chain risk, there are still many bearings towards it, and I will definitely return to study more of your blog.