One of the key needs in lean, scrum, and other agile processes is for continuous improvement. We constantly review how we do things to do them better. The most common method of doing this is the retrospective. After 5 months of writing the Baby Steps to SOA series, I decided that I wanted to review what I had done and figure out how to do it better. Of course, since this is an agile-related blog, I wanted to share this experience with those of you out there so you can learn about how a retrospective works, and how you can apply it to any work you are doing.
The practice of A/B testing follows the Lean methodology of Build, Measure, and Learn (BML). By using tools capable of performing these tests, we can build a quick test, measure the interaction with the tests, and learn from the results gathered. This is fundamental to improving your content and your application.
If you’ve been following my company’s Nonlinear Thinking blog series on A/B testing, you may have seen the article that my colleague Gavin and I put together on the Top 10 reasons to A/B Test everything you publish. We initially started this from a Sitecore angle, gathering all the reasons we wanted to do A/B testing with Sitecore. As we pared down to the top 10, however, it became obvious that this was something that applied to any tool capable of A/B testing. The reasons for doing it were not tool-specific, they held up on their own.
However, for those of you interested in using Sitecore as your content management tool of choice, you may be wondering how you can use Sitecore for tackling these items. So here we go… tackling the Top 10!
In the continuing Baby Steps to SOA series, we follow Doug and the IT team behind BuyMyWidget.com as they take steps to renovate their digital asset architecture. In this final stage, the team moves to using an Enterprise Service Bus (ESB) to handle the inter-application communication. This step allows for an increased ability to manage the disparate systems and scale to an enterprise level while also removing tight coupling between the applications.
Have you encountered a failure while executing an automated Sitecore deployment with TDS where the type initializer throws an exception and you are asked to reinstall the TDS application? Apparently, if your TDS installation becomes corrupted somehow, you need to get rid of the web service and let TDS reinstall itself. This might occur if you upgrade versions, at least, it did for me! Here’s how to handle the issue…