You probably heard we have been moving into a faster release cadence with the new mountain ranges releases in this post and this one. For many Product Managers or Business Owners releasing faster could be the difference between success and failure. Being able to shorten the cycle between an idea and valuable user feedback enables new companies to understand better market needs and improve based on it. Releasing valuable software earlier is the sweet spot for Agile and Lean methodologies.
In a recent post, James outlined how MuleSoft is using Lean Startup principles to build Enterprise Software. We have been doing this for a while in our cloud platforms – CloudHub, Anypoint Service Registry and Dataloader.io; however, our core enterprise tools and products – Mule ESB, Mule Studio, Anypoint DataMapper, and Mule Management Console have always been on a much longer release cadence. Mule ESB Enterprise is the core platform on which many of our customers build hundreds if not thousands of services and integration processes on, so frequent releases and updates can be expensive for them to consume. Typically we release new Mule ESB enterprise versions every 9 months. As a hybrid product company with multiple products, we need to manage the demands of both the cloud and on-premise. Recently, we decided to make some changes to our development cycles and team orientation. We’re using names of famous mountain ranges for these new releases, the first is named Andes after the iconic mountain range in South America (relatively) close to our development labs in Buenos Aires, Argentina. The next is Big Horn, Cascade and then Dolomite.
There is a lot of talk about the lean startup and whether it works or not. Some proclaim it is critical to the success of any startup and that it is even the DNA of any modern startup. Others claim that it’s unproven, unscientific and gets your product to market in a haphazard way that is ungrounded in quality.
But the lean startup model, when you boil it down, simply says that when you launch any new business or product you do so based on validated learning, experimentation and frequent releases which allow you to measure and gain valuable customer feedback. In other words, build fast, release often, measure, learn and repeat.
How much time do you invest in estimating your backlog? Do you really get any value from it? When was the last time you thought about the value it provides you? I can see estimation as a source of problems in many ways.
I’ve been working at MuleSoft on the Sustaining Engineering team for a few months. In this time I watched how things work and find out what type of challenges we deal everyday have and how we solved them. I watched a great team working long hours to solve customers problems as fast as possible. Our primary goal is to enable our customers to meet their deadlines, and remove any problem they might have with MuleSoft’s products in the process.
Context on the type of work
The sustaining engineering team works on solving problems for our customers, improving the code, implementing new features and reviewing how things behave to answer questions. Usually questions come from our customers, and sometimes we get high priority issues with high visibility. Critical issues may appear without any planning and they need to be solved as soon as possible. This type of events cause disruption in the team’s work. If any disruption propagates over time, it causes bigger or permanent problems. There is a mixture of high priority things popping up, with planned features or improvements.
Problems and challenges
This is the list of problems I’ve seen during this time.
For those of you who develop in Eclipse, and are also running Tomcat as a stand-alone JVM process (the way Tomcat is usually run), it is fairly easy to debug your web applications using the Eclipse debugger. For that matter, you could also debug Tomcat’s code this way as well, if you want to inspect what Tomcat is doing with a request.
Once in a while I get questions about whether Apache Tomcat implements a way to include other files in server.xml, Tomcat’s main configuration file. The answer is that there is a way to do it, and that Tomcat didn’t have to implement a new feature for it to work. The way to do it is: XML entity includes.
At MuleSoft we use Agile development to build and deliver all of our software products. One of the more challenging and potentially time consuming part of agile is story estimating. Recently we decided to take a new approach to this that has proven to be a lot of fun and amazingly accurate. I call it Bubble Sort Estimation.