Agile What?
| Posted: | August 5th, 2007 |
| Tags: | Innovation, Splunk |
What’s so great about agile software development? Sure engineers think its great. I think it helps them feel empowered. Product managers think its great too, but secretly I think they’re still trying to figure it out. Apparently Oracle thinks it’s great. The company just paid $495 million for Agile Software Corporation (Nasdaq: AGIL), representing a 14% premium.
As a user I just want to know, what’s in it for me?
We just shipped Splunk 3.0. During the past seven months I’ve heard agile, scrum, sprints — all the cool concepts that are part of this revolutionary framework to spur innovation, more efficient product development cycles and a tighter loop with customers. So why then did it take us half a year to release something? I mean we’re still a start-up after all.
Don’t get me wrong, Splunk 3.0 is fantastic. All kinds of amazing, ground breaking stuff. I’m running it on my OS X laptops and desktops to monitor ps, top, iostat, vmstat and it comes in very handy for figuring out why things crash by indexing everything in /var/log. It also now generates cool interactive reports and Flash graphs of who’s getting the most SPAM on my FC5 mail server running Sendmail and Dovecot IMAP front ended by my Ironport box. Look out mom I’m gonna charge you extra. Check out all the new Splunk 3.0 features and download your own free copy.
What I’m getting at is we had many of the latest greatest features available months ago. But they were unavailable to me and other end users. Turns out even though we’re developing software by living and breathing much of the agile manifesto, we’re still struggling with how to conceive of and adhere to an agile release cycle which incorporates more than just engineering. Sure if we wanted we could just deliver everyone half broken releases every few days without an installer and lousy or no documentation. However, our business thrives by satisfying users with a complete and easy to use product that is high performance and high quality. See IT people are much less curious and tinkering when it comes to solutions and tools than developers. They just want the stuff to work. Turns out the massively complex infrastructure they’re managing gives them enough to toy with.
Sometimes we get customers saying they can’t install releases more than two or three times a year, but I have a hunch with a technology that’s moving as fast as IT Search — we need to release new features faster. So we’re working on moving this agile, defactored architecture we have underneath the covers all the way to the surface. And in the process challenging ourselves to move the whole stack to faster release cycles. We get input through our live product roadmap every day and we’ve got innumerable parallel engineering scrums going on at any one time. But it’s the last mile of figuring out what pieces to release when and how to package them which always seems to slow things down.
So what can you expect to see from us in the future?
- Smaller units of features.
- More frequent releases.
- An active beta program.
- A well supported Splunk developer network.
We’re VERY interested in your comments on how we’re doing and feedback on what you’d like to see. Feel free to contact me or our support team with your thoughts.
Happy Splunking!
- Posted by thebaum
RSS, Bloglines, Google or Yahoo!
September 15th, 2007 at 7:14 pm
[…] Now that engineering is moving to a scrum-based model (read what my boss has to say about that) in order to deliver functionality quicker and more incrementally, the whole notion of a PRD is obsolete. But that doesn’t mean that product management is obsolete - in fact a rational process of analyzing inputs, setting priorities and communicating about new feature capabilities is more important than ever. […]
October 21st, 2007 at 9:20 pm
[…] I’ve written in previous posts about our move to an Agile product development process. This required us to literally discharge our old way of taking input from customers, scoping features, planning releases and testing. Of course it also meant we had to ignite our underlying work flow and tools supporting product development. It all made me a tad nervous : { For more than a month I couldn’t tell you what would appear in our next release or when the release might be available for download. If you use Splunk, you know that we live and die by our product road map and release schedule. During that month our engineering, qa and product management teams went through a metamorphoses. They moved from being top down, planning driven to bottom up, innovation driven. We had reached the point where we couldn’t plan or prioritize features. The old process of having a team set out a plan and working towards a release wasn’t working anymore. So we blew it up. Now we have a process where by parallel scrum teams work on various facets of the product and they do the planning, constantly. It’s interesting how nobody, but yet everybody is in charge. The initial results are just in. Splunk 3.1 will soon be available for download in a mere eight weeks after Splunk 3.0 was posted. And Splunk 3.2 will be released in beta eight weeks from now. That may not sound like much but when you look at the amount of innovation in each release, the speed with which we’re moving enhancement requests from the field into features and the improved quality of each release it appears remarkable from where I stand. […]