This Friday at Pivotal Labs Boulder, we're hosting an evening of food, drink and discussion, to bring some of our learnings around Lean User Experience to the larger design community, and in particular to attendees of the annual international IxDA conference.
We, in this case, is a group of smart folks I've had the privilege to work with over the past year, a working group called the Balanced Team. This particular event is the result of the hard work of people at Cooper, Hot Studio, LUXr, SideReel and Atomic Object.
For the past year, we've been sharing ideas and discussing new ways to approach design and product development, to create better products, make happier customers, and reduce waste. We've been doing this while creating better integrated, more collaborative, more responsive teams. In that time, a number of us have been getting together on a regular basis to really sit down and discuss what works and what doesn't, and to try to distill these ideas into principles and techniques that are repeatable and practical.
We've been itching to engage with the larger design community to start to break down the culture of Big Upfront Design, the Cult of the Rockstar Designer, and the culture of necessary infallability; to fight the blind application of Waterfall and to disrupt the antipatterns we've found so antithetical to effective collaboration with agile development teams; to encourage patterns that allow designers to embrace early customer feedback, and to test hypotheses quickly; and most importantly, to foster a deeper collaboration with the very folks who have the biggest impact on what we build. We've seen over and over that, when done correctly, a light-weight process gives designers more control, not less.
It's out of this series of discussions that I first arrived at a framing of the problem space that I talk about in Enough Design, and it's also through these sessions that we've found a growing community of designers, product people, enterprises and other developers who are working to develop better techniques for integrated product development. We've found the conversation immensely valuable in our practice, and we hope to learn and share with more of you.
If you're a designer in Boulder for IxDA, or just someone who cares about usable techniques for bringing Lean principles into the development of compelling User Experience, come join us on Friday for deLUX. This is a free event, but space is limited, so please RSVP through http://pivotallabs.com/landing/deLUX.
Pivotal Tracker makes it easy to add stories to you project. Hit Ctrl-A, type a quick sentence along the lines of “As a user, I can…so that…”. On most of our projects, we find ourselves discovering new stories all the time, based on the continuous feedback loop that Tracker encourages. Not all stories end up in the backlog, but it’s liberating to be able to capture new ideas and user feedback as they occur.
The downside of this is that the icebox, where all new and unprioritized stories live, can grow out of control very quickly. It’s not uncommon for longer lived, active projects to end up with hundreds, even thousands of stories on ice.
Yesterday's Priorities
A large and growing icebox can be a burden. Your project takes longer to load, it’s harder to find that story you’re sure you added just a few weeks ago. It becomes harder to focus on the future, due to what feels like ever growing debt of promises and yesterday's priorities.
In our eternal optimism as software developers, we like to hang on to our stories. We know we’ll have more bandwidth just as soon as we get through this month’s big release. Besides, we’re hiring, right?
Story Overflow
The reality is that on most software projects, the rate of new story discovery far exceeds the rate at which stories get completed. Typically, a new story in the icebox either gets prioritized and moved to the backlog fairly quickly (either immediately or in the next planning session), or it ends up staying in the Icebox indefinitely. New priorities have a way of displacing older ones.
Stories are perishable, and get stale over time, even when on ice (so to speak). It’s good practice to clean up your icebox regularly, and delete stories that have been sitting there for a while, and are unlikely to see the light of day any time soon. The old stories may have seemed really important at some point in the past, and involved the whole team spending hours in front of a whiteboard or a table full of cards writing them, but if the feature becomes a priority again in the future, you’re probably better off doing it again, based on all the new knowledge you’ll have by then. The important thing is the conversation and a fresh flow of ideas, not so much the stories themselves.
Export before Deleting
To preserve the ideas and any comment discussion in these old stories, it’s a good idea to export them before deleting them. You can do so by selecting them in the icebox via the selection boxes to the right of story titles, and using the Actions menu to export them. You can also export the entire icebox on the project Export CSV page, which is accessible via the Actions menu in your project.
Another option is to move old icebox stories from your active project to a separate project, which serves as a searchable archive. You can move stories from one project to another via the Actions menu as well.
Icebox as an Inbox
Use the Icebox as an inbox, for continuous review of new stories, rather than a permanent storage device. As new ideas, feature requests, and bugs come in, triage them regularly. If a new story is really important, for example a production bug, you’ll probably drag it into the backlog immediately. Otherwise, review newly created stories with the team at the next iteration review and planning session, and either estimate them and prioritize them (by dragging them to the backlog), or move them into a system better suited for long term storage, like a Google Docs spreadsheet or a more general purpose project management or issue tracking tool, like JIRA or Lighthouse. Tracker has built-in integrations with these tools, allowing you to bring back and link stories easily with drag and drop import.
I often hear questions from Pivotal Tracker users about how to organize teams and projects. We also see many requests for features that would make it easier to see stories from across multiple projects.
Tracker is designed for full immersion in one project at a given time. This stems from how we work at Pivotal Labs.
We organize teams such that a single team (and the people on that team) have a single backlog (and Tracker project). This means that within a team, there are no conflicts in terms of priorities, there is less context switching, and the team is completely focused. It leads to more consistency from iteration to iteration and therefore a steadier velocity, which allows you to have a more accurate insight into how long the rest of the backlog (or a release) might take to complete.
We also make it so that anyone on a given team can grab the next available story from the top of the backlog (or the current iteration). This implies few or no specialists (there is no back-end guy), and is generally referred to as collective ownership. It increases overall efficiency by allowing the team to dynamically re-balance, and minimizes reliance on any individual person (which among other things, leads to more relaxing vacations for developers).
The project's customer (or product manager) focuses on prioritizing stories in the backlog, and the development team is collectively responsible for delivering software based on the backlog.
We use labels to tie related stories together within a project. These can represent a major feature, specific end customer, etc. Labels can help answer questions like, how much work is left in this large feature?
A single backlog for the entire team does put more work on the plate of the owner of the backlog (customer / product manager), as he or she has to constantly make potentially difficult prioritization decisions, but, thinking hard about priorities is a good thing, and it allows the development team to focus on getting more work done. That ultimately makes everyone happier.
Also, there are people in certain roles (for example executives and designers), that given their nature, tend to be involved with multiple projects at once. Tracker could certainly use some features to help these roles, and we're thinking about these, but overall, it's more oriented towards enabling the immersed team.
A single team/project can get large enough to the point where it becomes challenging to manage a single backlog. For us, this point is generally reached with 5 to 6 pairs of developers (or 10 - 12 people). Assuming that more developers can actually add value to the overall project (this is not always the case), it's probably worth considering splitting the team into multiple smaller teams, each with their own single backlog.
To avoid knowledge and cultural silos with multiple teams, we find it helpful to rotate a few people around teams every iteration. It's important to maintain consistency (and therefore a steady velocity), so you don't want to shift too many people around too often - usually rotating just 1 person (on each team) each iteration is enough, assuming you're pairing and switching pairs within each team often.
In a multi-team (and Tracker project) environment, the product/project manager acts as a load balancer, and allocates work across the multiple teams/backlogs by considering velocity, dependencies, etc. This is typically a full time job. Tracker doesn't have much out of the box to help with this, but we're thinking about this as well, although it may be that some of this kind of work is better done in a spreadsheet, or other, more traditional project management tools. (As a side note, we did recently add the ability to move stories between Tracker projects, making things a tiny bit easier for people who manage multiple teams/projects).
I'd love to hear your thoughts on any of this, including suggestions for how to organize large projects and multiple teams (and how Tracker can help with that).
We've added Zendesk to the list of applications that Tracker integrates with. Zendesk is a "beautifully simple", on demand customer support help desk system. This integration allows your development team to prioritize and collaborate around Zendesk tickets as linked Tracker stories, bringing development and support closer together in your organization.
This Pivotal Tracker update allows you to see GitHub or other SCM commits in your stories, your project activity in your team's Campfire chat room, and introduces the first wave of integrations with other bug/issue tracking applications including JIRA, Lighthouse, and Satisfaction.
There is also a new version of the API (V3), with support for moving stories, file attachments, as well as activity web hooks. The first version of the API (V1) is no longer available.
Continue reading for more details on what's new.
If you've been looking for a way to turn emails into Tracker stories, take a look at tgethr. It's an email collaboration service for groups, and it now integrates with Pivotal Tracker.
Read about it in this tgethr blog post.
Rob and I were recently asked by a client for some help justifying the choice of Ruby as an implementation language for their SaaS product. They were very happy with the results, but wanted to be prepared to answer investor and customer questions about why Rails was a good choice.
One way that I've been talking about Rails is in the context of what I'm calling "The ARC Model": Agile + Rails + Cloud. I'll borrow from my abstract from my talk at BizConf:
The Ruby on Rails Revolution has been one of productivity and efficiency, and has coincided with an equally powerful revolution in the ownership of technological infrastructure. The Rails approach combines agile methods with a highly productive language to allow developers to focus on developing business value, instead of developing plumbing. The Cloud Computing Revolution at the same time has changed the economics of infrastructure, allowing computation to become a commodity not worthy of developer attention, further enabling developers to focus on that which is truly valuable, Innovation. These three factors, Agile, Rails, and the Cloud, combine to revolutionize the economics of software development and information management, in ways that directly impact return on investment.
The question should not be, “is Rails a safe choice,” but “[how long] can we justify the expense of traditional development approaches.”
I think this kind of approach plays nicely to the strengths of SaaS.
In terms of large enterprise deployments, it's early yet: Enterprises tend to be conservative (about Rails as they are about SaaS) so most of the innovation has been in the startup space, with companies like Hulu being good examples of the disruptive power of Rails.
But that said, there have been some major mainstream Enterprise success stories. AT&T chose to dump a failing Java yellowpages effort in favor of Rails, with excellent results in terms of scalability, time to market, code quality, and performance. (There's a decent write-up on BuildingWebApps.)
We are starting to see major companies develop ever more mission/business/revenue-critical components in Rails. BestBuy built Remix, their new public API app, with us using Rails. We have one major multinational client who is rewriting their entire ERP system in Ruby internally. We have another major hardware vendor building new products using Rails.
Large companies tend to be a bit shy about talking about new technology initiatives, and we suspect that most Fortune 500 companies have someone doing Rails somewhere in the organization. There are a number of others we've spoken to who are using the technology to their advantage, but who aren't ready to talk about it publicly yet. But you can also search for job listings from major companies and see how many big companies are hiring Rails developers. We see them all the time.
Hard statistics are harder to come by, but Mark Driver at Gartner projected that there would be 4 million ruby programmers by 2013. We're already seeing the smart companies get huge efficiencies out of these new development models: efficiencies of cost, flexibility, and time to market.
We're very bullish on Agile, Rails and the Cloud. In the current economic climate, the reduction in risk alone is worth the cost of admission. Coupled with the qualitative benefits of being able to out-flank your competition, it's no surprise that we're continuing to see adoption grow so rapidly. The results are too compelling to ignore.
I just spent a wonderful weekend with 75 of the brightest folks I know in the Ruby community. My hat's off to Obie and the Hashrocket crew for putting together a really great, intimate conference in a beautiful location. It's refreshing to really have to struggle to choose which talk to attend from so many choices at each session. I know too many choices are a Bad Thing™, but the format made for great small sessions, and a wonderful thing happened: Everyone got to really meet and get to know everyone.
Among many others, I had the pleasure of meeting CJ Kihlbom, who nails a lot of why these conferences are so important in his post, The Business Value of Conferences.
It was really pleasant to present to a community of business leaders who understand the value of agile, and who are serious practitioners in their own practices.
A lot of you have asked for the slides from my talk, Agile, Rails and the Cloud, so I've posted them here.
Those of you who thought about coming but didn't really missed out. Come next year. You'll be glad you did.
Last week, Wolfram Arnold of RubyFocus interviewed Edward Hieatt, our VP of Engineering, and Davis Frank, one of our engineers, to try to get at the heart of how you build a scalable software development team.
The interview is posted on RailsLab, at http://railslab.newrelic.com/2009/03/18/scalable-teams-part-1-communication
It's a nice piece. We look forward to the second installment.
I'm very pleased to announce that Pivotal Tracker has won the coveted Jolt Award, in the Project Management category.
I want to thank the judges for selecting Pivotal Tracker above a category dominated by Agile project management tools, and for rewarding Tracker for innovation.
I want to thank the community who have used, evangelized, and supported Tracker, and in particular Obie Fernandez, Ward Cunningham, and Nivi; plus everyone over at Engine Yard for hosting the app.
And of course I want to thank and congratulate the development team and visionaries, particularly Dan Podsedly, Alex Chaffee, Rob Mee, Mark Michael, and Edward Hieatt for envisioning and then building the tool that we've come to depend on.