Many thanks for a thought-provoking, and wonderfully complete, post.
If you try this sort of thing yourself what you'll often find is that you can get the cycle time of stories (the time from the story going on the board, to the time it gets deployed) to be fairly constant. It can take some work to get top this point, but it's possible and useful in almost all circumstances.
Once you get to this point you can pretty confidently predict that stories are 1week/1month/2months away from getting deployed - and you can use this as the basis you base customer estimates on.
Arlo Belshee coined this style and called it "Disney Line" planning (y'know - like the one-hour wait from this point thing). Arlo has a great video on this sort of approach to planning http://www.youtube.com/watch?v=6t4bZtnnQJA that might be worth a watch.
I didn't see where a star rating equated to effort. I'll look again.
Thanks!
I assume you've tried Pivotal Tracker at some point too? I'd be interested to know what you like/dislike about your new workflow compared to Pivotal.
However my main gripe with Pivotal was always two things: 1) Strict adherence to a Scrum methodology (forcing me to use a certain set of columns, etc) and 2) The UI. It frankly drove me nuts. The small text fields, small text areas and lack of wiki-style formatting. Anything longer than a few words was impossible to grok.
We flirted with trying it out about the time we adopted Trello but enough people had bad past experiences, like mine, that we never gave it a try.
Thanks for replying!
In addition, how do you track velocity?
From the description it doesn't look like they're running in sprints, but deploying as stories get completed, so cycle time would be the thing they would track. No idea if Trello can do this out of the box. They also explicitly said that they're not doing project estimates - so they wouldn't need to track velocity in any case.
If it were me I might be interested in visualising the flow somewhere - more of a tool to help spot problems as to make estimates any more accurate - but I'm a fan of just doing that with a whiteboard as part of running the project.
Estimates got treated as gospel and planning was deemed extremely important, but nobody was willing to make the time for it to be done right.
I think web apps with shorter release cycles and fast deployments can really benefit from a process like this. You just have to be willing to try out simple, light weight tools and iterate on the process just like you iterate on the code.
Most shops tend to just use what they know rather than attempt to hack the process to meet their own needs. Kudos to the guys at UserVoice for going against the grain.
> Individuals and interactions over processes and tools
For my part, I'm completely done with Agile and the Agile community, there is very little of value there any more. Those who did add value have moved on, tired of and pushed out by those looking to make a quick buck consulting or managers looking to justify their poor management skills. It's quite sad.
I'm on a small team now, doing something fun and cool. The process is leaner, faster, way more productive and without all the BS overhead of trying to be "Agile".
I don't think it's quite that bad myself, but I think it depends which bits of "the community" you find yourself in. There are still smart folk who do actually pay attention to the manifesto and don't wander around applying an "agile" label to everything around them and carrying on as before ;-)
* We view design as an ongoing and continual process - not a phase. Having a "software design phase" just wouldn't make sense for us since it basically covers the whole cycle from when the idea comes out to when it hits the streets.
* We generally pair on development where at all possible, and when we are pairing we don't find that we get a great deal of additional value out of code reviews on top.
* When we don't pair for whatever reason we do code reviews, but do them on a regular cadence rather than as a phase (say every Wednesday afternoon). A bunch of stuff fits in this kind of pattern. We are sure to talk to users every couple of weeks. We do some usability testing every couple of weeks. It's not related to how stories flow so it's not on the board.
I know that my examples are based on system software development, but I have no reason to believe they cannot be applied also for web development.
I confidently predict that if Pivotal is not helping you now, Jira will not help you in the future. What needs to change is how the team works, or maybe management's expectations of the team. Not the tool.
Predicting the future is hard.
Perhaps you mean how many people in total? I've seen lightweight systems like this scale out to 150+ developers. (Insert discussion here about Agile Program Management)
You really don't need a lot. Most enterprise project management systems are over-engineered by a couple orders of magnitude. (And they hurt much more than they help)
Is there anything like Trello that can be run in-house?
I actually think if you're trying to get people to buy in to a methodology such as this, it's easier to start with a physical board and progress to something like Trello. One step at a time.
If I have more than one up-vote to give... this would get it. I find people really underestimate the value of a physical board setup. I agree that it's a vastly better starting point than online tools for most teams if they're in the same location.
This is very interesting. We also use Google Docs for stories/specs and Trello for prioritization and roadmap. However, we maintain a separate bug tracker (Open Atrium) for our enterprise clients to report bugs. We'd also love to have a single prioritization list. Wish there was an ability to create a Trello list sync'd with RSS Feed from Open Atrium.
> It’s the product development version of the Hunger Games
:)
Ticket - a message a customer sends in about an issue or question.
Bug - an issue (that can come from any source) which we track and resolve.
We just Trello for bugs (which may be reported in tickets) but we use UserVoice Helpdesk (http://www.uservoice.com/helpdesk) for tickets. Helpdesk is designed around customer communication, Trello is designed around development.
Hope that clarifies! :)
But what about a feature request from a customer that you don't plan on implementing in the next 3 quarters? Do you just delete those cards, or move them to some other backlog.
Once you take a card you “put your face on it” (assign it to yourself). Dev etiquette is that you should never have your face on more than 2 cards at a time: 1 major project and 1 minor.
We just turned every other 'project management' app off but Trello (goals/tasks/bugs/feedback) & Beanstalk (repo);
One point I would make as a brand new start up - I'm not sure how willing/able I'd be to handle the uncertainty of not forcing my dev team to tell me the number of hours a fix/feature will take to implement. I say this because sometimes our road map will include a feature request that upon receiving an estimate for I then decide not to proceed with as the cost/benefit ratio doesn't add up. When this happens I de prioritise the task and put it in a backlog. Having said that, we're at the stage where every second counts; perhaps when we've got a steady stream of income I'll be less picky.
