If you haven’t already seen these ads from Apple, you need to. If you aren’t doing this in your business, in your job, or in your life, you consider it. Focus on doing what you really want to do.
If you’re reading this wondering why we chose to do one feature over another, please note that you’re not the first (or the last) to shake your fist while shouting this question! We hope that all of our customers are this passionate about our software. I know I am with the products I use, so we expect nothing less!
Unfortunately for you though, we don’t often reveal much about the planned features on our product roadmap. What little we do reveal are those things that we are most confident about delivering. Frankly, we don’t show more because we don’t want to disappoint you! We have a very complex product with a lot of integrations and moving parts. Sometimes it can take a good while to create and test additional functionality. Oftentimes delivery is influenced by changes in the market, current technologies, and planetary alignment. We’d hate for any of our customers to become dramatically attached to a favorite promised feature, and then disappoint them by delivering a different, though equally valuable feature.
I admire many of the approaches taken by the 37Signals team and ran across this line from David Hansson about the dangers of over-promising,
“It’s better to turn customers away than to placate their instincts and lure them in with vague promises. It’s incredibly rare that a single feature will truly make or break your chance with a customer. If your software is a good enough fit, most people can make do without that one or two things that they’d like to see.”
I want to break down some of our process around how we choose which features to develop, but it’s very interesting to talk about why we choose certain features. I love a line I hear from Simon Sinek, “People don’t buy what you do they buy why you do it.” But this is a topic for another day. So here are the four steps we use to get the right features in the development pipeline: discovery, organization, prioritization, and timing.
Determining the next Moab feature can be overwhelming and it often feels as though we’re looking for a good read while standing in the middle of the Library of Congress. But we relish the fact that we are not alone! We hear our customers loud and clear and know exactly which areas of the product they’d like to see improvements in. We are working on some ideas to improve the quality of feedback we’re getting on this channel. We also work together with our partners to discover and evaluate new synergies and approaches. We are constantly looking for emerging technologies and market opportunities that align with our corporate strategies. And we regularly reflect on our own failures and search for better solutions. There is no shortage of good ideas, and we try to collect them all.
In order to ensure that we deliver real value with each release, we group all of these ideas into initiatives that address end-to-end functionality and practical use cases. We understand from experience that cherry-picking our favorite little features from various areas isn’t viable over the long-term. We try to make sure that we can deliver well thought-out solutions through the features that we provide; something that we can be confident will have a positive impact on our customers and their ability to accomplish to their goals. Once we’ve organized each of the ideas into feature initiatives, we also evaluate iterative approaches that would allow us to iteratively plan for work that might ultimately take more than a single release.
We can’t do it all. We wish we could, and we try, but we really can’t! We know how much we can accomplish in a given amount of time, and we’re always on the lookout for techniques and processes that will improve our development velocity, but we know that it won’t be enough to get everything we all want. Through prioritization we can ensure that the most impactful features are delivered first. This is the phase where we have to argue for our favorites and sometimes let them go. Some of the factors that we consider are: time to implement, degree of innovation, how competitors approach the problem, number of affected customers, bang for the buck, and how long we’ve already been waiting.
We all know from our own personal experience that if we simply work off a priority list, we can miss opportunities to innovate and optimize. For example, I missed seeing the new movie Pacific Rim last week because I didn’t consider rescheduling a high-priority but time-insensitive appointment. By the way, I am not sure if I’m worse off now, so maybe this is a bad example. But as we work out the implementation details of each new feature and its components, we discover multiple opportunity paths that can all lead to “good” delivery outcomes. We take time to plan these out so that we can rest assured that our timing optimizes our efforts and make changes as needed.
Once the timing of each epic’s features is nailed down, we hand the execution off to our capable Engineering team and monitor the progress as we work towards the next release. We can talk more about the engineering process in yet another blog post, but hopefully this gives some insight into our approach on feature planning.
Whether VMware, HP’s Cloud Service Automation, xCAT or any of the other myriad provisioning solutions, there are so many progressive stages of private cloud. Although that term remains somewhat nebulous, the pieces are familiar:
1. Standardization and consolidation of hardware and infrastructure
2. Virtualization and automation (most of us are around here)
3. Self-service infrastructure (next step)
4. Service lifecycle management
5. Service brokering and hybrid environments
The barriers are also ever present, among them manpower, optimization, guaranteed SLA enforcement and accounting – each increasing the difficulty of making progress or really even getting a good understanding of the end-game for your private cloud. The best place to start your push to cloud is a strong focus on return on investment. Gathering an accurate understanding of current costs and demand is a significant first step, and from there a hope can build around the potential for cost savings. It is no stretch to claim between 10 and 100 times faster deployments, depending on your current setup! Our research has shown that our customers are spending 2-3 times more in manpower and hardware before moving to a cloud.
Another strong selling point for cloud and a potential for savings is the concept of a self-service portal. We’ve all dreamed of facilitating users, in a safe way, so that then can request and manage their own workload without requiring much IT team. Another bonus is the addition of chargeback concepts to help manage resources in an accountable manner. Workload placement and migration is another level of management that is expensive and time-consuming to handle manually. Even setting up the rule sets and auditing policies can be overwhelming.
So if you are focusing on a consolidation of hardware into a single datacenter, consolidating deployment efforts and processes, looking to increase your ROI on your infrastructure, decreasing IT staffing and computing investments or just wanting to add additional machines and VMs without staffing up, Adaptive Computing’s line of cloud solutions can help your success.
Using Moab’s service templates, actual service consumers can ask for what they need, when they need it. With chargeback you can govern accountability for resource uses, which will limit overuse and waste. Remember that a free cloud is a recipe for failure. Self service is what makes a your datacenter a cloud, and can facilitate 10-100x increases in deployment speed.
Move from automation to orchestration. VM sprawl, just like server sprawl, can fill up your datacenter quickly! Do you want your VMs to be scattered across your datacenter for better performance, or would you like to consolidate so that you can take advantage of licensing constraints or VLANs. Don’t overlook the value of accurate initial placement with granular service allocation policies that can target by processors, memory, chipset, software licenses or other arbitrary metadata. Also, you can always reserve pockets of your datacenter for certain kinds of work, or work from certain users. Once those services are running, they can be locked down on that hypervisor to secure high availability and security. Now all this can be done manually, but let’s be honest, it’s a lot of work, and your ability to keep in sync with upcoming needs will be limited by staffing and the other fires and stuff your IT staff it doing. You don’t want to just add capacity like we have in the past. Now is the time to efficiently allocate what we already have with a variety of policies around placement, overcommit and allocation.
Integrating Moab in Your Cloud
Dip your toe, try this out. We know that you may want to keep one foot in the traditional IT infrastructure model, or even outsourced IaaS . We know that this perpetuates inconsistent development environments, disparate architectures and different management and security, so pick a single small group to focus on. You want to provide all the capabilities (optimization, chargeback, service catalog, etc.) for a each grouping one at a time so that you can demonstrate the ROI as you work to cloudify (bring standardization, automation and self-service) your datacenter.
Software development companies have long been abuzz with talk of agile development. Its virtues have been extolled and significant gains in productivity promised, but not very often do we talk about how hard it is to make the transition to agile development. There are compromises that can come so easily when we face processes and pressures that are difficult to transition away from. Old habits are so welcoming and progress can seem so far away. At Adaptive we experienced the same growing pains. Over the past year and a half we have seen a lot of success from our efforts and it hasn’t been easy. But it’s been worth it. We’ve been able to set more accurate timelines, and the accuracy of those timelines has been available sooner. Each release we have been able to move ahead with confidence that we can scope out the relevant functionality completely with user stories. We’ve been able to target our hiring to bring on the specialists we know that we need to have success. And we’ve been able to plan future features more fairly, having a better understanding of the customer needs we’re addressing and how long it will take to deliver value in each feature.
How does this translate to our product? We’re seeing higher quality, faster performance, longer uptimes, more scalability and more fully rounded-out features. Higher quality comes as feature is subjected to longer durations of targeting testing because we spend less of our release cycle in a no-man’s land between completed features. Performance, uptime and scalability are the result of deeper dives into specific user stories and their impact on the system and its components. Each of our new features is more fully thought out and executed as we have taken more time to examine mainstream and edge customer use cases.
In the end, we’re confident that the investment we’ve made in improving our agile development process has produced the most valuable version of Moab we’ve released, and we expect even better versions in the future!
I’ve had a couple rough days sliding between tactical and strategic worries as we work to complete a release while planning ahead for the next one. I just drew this up on a whiteboard to provide some context for my concerns. I was surprised by where it ended up so I’ve decided to spend a few more minutes on it and share it.
While the visibility from the top down and from the bottom up is absolutely critical, you can’t really expect to have all that loaded in your head at the same time. This is aggravated by the size of your organization and certainly becomes unmanageable at different points depending on your mental fortitude and your organization’s setup. Most companies address this problem by creating a hierarchy so that those at the top, your C-levels and other executives, worry about those things at the top of the list, and your middle managers take the middle, and so forth all the way down the list. This can work, but I’m an advocate for dynamic approaches that can quickly compensate for different needs at different times. But I digress. My point here is that when it comes down to it, you can’t really do it all, and there are only two things that can make you feel better about that:
- Transparency – it should be simple for someone to take a look at a dashboard or a blog or even a posted printout and see how things are going in an area and where things are headed in the future.
- Trust – if you can’t trust (often through delegation) those that are heading up areas of the business then you will never be satisfied that things are running well.
I don’t have all the answers here, but I hope that this helps you to reconsider where you’re at like I have, and I’m glad I did because today (two days later) I’m feeling pretty good.
Weather.com has, at least in my mind, always been the go-to place for weather forecasts. I don’t know why I made the association… oh wait! It’s because its probably one of the best domain names on the Internet. Nice job. Anyway, my only complaint has been that there is so much clutter in between me typing in my ZIP code and getting the actual forecast. Wait no longer, the site had a redesign this last week!
Weather.com did an excellent job branding the redesign as an overwhelming improvement, stating that the changes were based on the following customer feedback:
You’ll probably see that same kind of feedback on a lot of ad-supported sites! In the redesign, Weather.com added new features like saved locations, weather apps and user contributed pictures and video, as well as a large slide show that highlights top stories and regional coverage. The redesign added a more comfortable layout, better top-level navigation and menus and did an excellent job of blurring site content with ads – check the right column.
Overall, I give it a B+ and a better commendation of continuing to use the site.
I think this is a clever way of presenting the user with an explaination about why a page can’t be loaded – well it’s better than a logout or a 404 anyway.
It would be even better if the link I just clicked on from the last page would take me where I am supposed to go, but I guess that concept is outdated.
I usually meet new standards with a bit of trepidation, fearing that the new standards will mess with things that are already working fine – the old “if it ain’t broke” mantra. Well, HTML4 isn’t broke, but I am really getting pumped about what HTML5 and CSS3 are going to do for the web!
I ran across these sites today, give them a look and tell me that your mind wasn’t opened to a whole new breed of websites that get interactivity without being locked into a bulky Flash interface.
Also see HTML5 Reset to get a blank-slate stylesheet to start new web designs with.
These new standards are really bringing it, the question is, how long until Internet Explorer supports it?
I’m posting partly because I loved Van Halen in high school and partly because I was surprised to see them on the Interwebs this way.
My challenge to you is this, where are your brown M&Ms?
I’m reading the 4-hour Workweek right now, and one of the principles author Timothy Ferriss repeats over and over is to remind yourself to not invent things to do just to avoid doing the important things. Taking that into mind, yesterday I filled out a sticky note of things that I wanted to do today, and stuck it squarely in the center of my monitor, vowing to focus on the most important things. It’s still there, and I’m actually moving my windows around the note, trying to read my email first anyway. Even now, I’m typing this quick post around the sticky note. Clearly, I have a problem with avoiding the important. More to come.