This is my blog about Scaling Software Agility: Best Practices for Large Enterprises.
It is based in large part on my book by the same name from Addison-Wesley. 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 book. Taken together, it is the best content I can provide to the agile software enterprise.
Fair warning though – as I learn new things and observe new and successful fact patterns, 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 particularly newsy or chatty blog, rather it is intended to serve as a relevant and deep content repository for describing and understanding agile best practices as they are applied 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 twice daily or even daily blog posts. (But then again you won’t if you don’t subscribe to it either!).
Note: There is a fair amount of content here, so I try to organize it around a consistent set of categories which you’ll find 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!
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.
[...] not see or perceive a big issue with Scrum. Based on my previous post around the roots of agile; Dean Leffingwell and I are in the same camp; Scrum is [...]