

How we run our agile dev process using only Trello and Google Docs - rrwhite
http://www.uservoice.com/blog/founders/trello-google-docs-product-management/

======
hkarthik
I really dig this post. I've worked at waterfall companies and agile companies
doing Scrum, and in both places the tools tended to dictate the process a bit
too much for my liking.

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.

~~~
lucisferre
Yeah I pretty much echo this experience. The ironic part is how almost every
"Agile" company I've ever seen seems to completely reverse the very first line
of the manifesto.

> 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".

~~~
adrianhoward
_For my part, I'm completely done with Agile and the Agile community, there is
very little of value there any more_

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 ;-)

------
iusable
Respect!

We just turned every other 'project management' app off but Trello
(goals/tasks/bugs/feedback) & Beanstalk (repo);

------
endeavor
Very cool!

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.

~~~
rrwhite
It's been a long time since I checked out Pivotal so I don't feel that
confident in giving too much of an opinion.

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.

~~~
endeavor
Yeah I hear you. We use Pivotal for a few projects and my top two complaints
are the same as yours, although they've made some improvements in the last few
months. OTOH there are things that bother me about the Trello UI as well.

Thanks for replying!

------
tlogan
The interesting part (or scary part if you ask me) in all this workflows and
meetings there is no space for software design specification and code review.

~~~
adrianhoward
You wouldn't see them on my board either - for a few reasons (hopefully none
of them scary :-)

* 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.

~~~
tlogan
The reason to have a dedicated "software design phase" is to encourage
invention of "nobody can do it but us" - secret sauces which can make you (or
your company) super rich (i.e., algorithms in Oracle Database, Google's
algorithms, etc.). These things cannot be invented as "ongoing and continual
process".

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.

~~~
donw
That's more R&D than part of the day-to-day engineering process, though.

Anything that's going to be secret sauce is going to need a lot of prototyping
and experimentation, and might not even yield usable results. Oftentimes, it
isn't even possible to make an estimate as to the complexity of what it is you
are building -- all you can do is timebox it.

Mixing that in with normal day-to-day development feels, to my brain, like
mixing concerns.

Once those prototypes and experiments start to produce tangible benefits, then
incorporating them just becomes another story in the sprint.

~~~
tlogan
There are two kinds of innovations: "initial" and "incremental" innovation.
What you just described is "initial" innovation (some people also call it
"radical innovation"). And the process you described, I think it is called
"skunk work" (prototypes and experiments) which is only one way to achieve
"initial" innovation.

I think that "incremental" innovations are very important for companies and
sometimes a "incremental" innovation can end up being a "radical" innovation.

------
rollypolly
How big of a team / project could be managed reasonably with this process?

~~~
DanielBMarkham
Agile teams are 5-7 people.

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)

~~~
endeavor
My expectation would be that you would still have one central PM and Planning
board but you'd have a separate Current Development board for each team (i.e.
different teams for different components/modules).

~~~
DanielBMarkham
Yep, that's pretty close. There are some considerations with teams-of-teams.
Infrastructure, suppliers, scheduling, production support, release procedures,
etc. There is also a bit of organization and dynamic scaling necessary: you
don't want a program backlog with 4 thousand items on it. That's unworkable.

Usually it helps if you stay with fixed iterations instead of Kanban and do
program planning all at once (Yes, 150 people all in the same room working out
the next couple of sprints. Fun to watch and participate in!)

Other kinds of tooling issues become bigger in a large group, like how to
integrate separate physical pieces, how many branches to have in your CM tool,
how technical drawings will be cataloged, etc. But none of it is super hard,
and lots of other folks have already gone down this road. The important thing
is not to over-constrain your development environment just to make yourself
feel safer.

The biggest obstacle to running a larger group like this is dealing with the
parts that are counter-intuitive. It just seems natural with 100 folks that
you'd have a detailed charge-code breakdown, for instance. Or that 100%
capacity is something you want to achieve. There are a few more gotchas like
this, but if people are open-minded, it can mean a huge increase both in
performance and happiness.

The industry is moving towards plain kanban without the sprints. I like this
idea with smaller groups, especially groups with lots of support work on
existing code, but for larger projects creating something new, using sprints,
having a fixed point of coordination for a lot of different stuff, works much
better.

Note I didn't say you couldn't go total kanban at large scale, just that there
was a trade-off involved with each path.

~~~
adrianhoward
_The industry is moving towards plain kanban without the sprints. I like this
idea with smaller groups, especially groups with lots of support work on
existing code, but for larger projects creating something new, using sprints,
having a fixed point of coordination for a lot of different stuff, works much
better._

I mostly don't work with organisations of that size, but the technique I hear
people use to get around that coordination issue is to have events that happen
on a regular cadence, but don't have them tied to delivery in the same way
sprints are.

So you have stories flowing but also schedule fortnightly planning meetings
(or whatever) on top.

This fits with my experiences on smaller kanban style projects where we have
regular cadences for non-flow things like usability testing, backlog grooming,
etc.

[Edit: Which is what the OP folk are doing "The ideas on this board are
reviewed once a week during our Inbox Review meeting"]

~~~
DanielBMarkham
Yep, that's how to do it. You can have certainly have cadences without
sprints.

The interesting thing here is that the same problem arises at a larger scale
as it does on at the team level: architecture. Not how pieces of the software
is put together, but the architecture of the existing and future business
environment.

So, for example, a large project might include hardware, software, embedded
software, offshore testing, multiple vendors, fixed demo dates, fixed
regulatory dates, and so on. You can certainly manage all these cadences
separately, but for most folks sprints of a week or two in length give you
fixed reference points to then optimize around.

Of course, it's easy to think up a scenario with a pretty simple business
environment, say the next version of Google+. In that case, Kanban probably
would work a lot better. Do the simplest thing you can, but no simpler.

I find that business architectural issues can be difficult for the teams to
grasp. The Scrum guys have preached sliding stories under the door to the team
for so long, there's an entrenched mindset that things like that aren't the
team's problem. (Not everybody, but many folks think this)

Counter-intuitively, by fixing the planning and delivery times, you can simply
the cadence discussion. It all has to fit somehow in this list of dates. It
also makes it easier to simplify or add complexity to the business
architecture without having to worry so much about impacts.

You might think: why not just go kanban with one fixed planning cadence? Kind
of the best of both worlds. Technically this would be awesome. You run into
some communication and messaging problems though. If your message is "It's
kind of like Scrum only bigger" then you can send out for Scrum training and
explain how it all works. People will take the training and then ask questions
like "who is the product owner" which aren't perfect but at least they're in
the right direction. But if all you have is a bunch of boards and hand-waving,
it's very difficult to get everybody to have some kind of mental model on
what's happening. It's just too much (unless you already have established some
previous Agile practice). Folks have to have some sort of working mental model
of how things are supposed to work. Going from something like RUP to full-bore
program-level Kanban in a complex business environment is just too far. My
opinion only, for what it's worth. Perhaps in the next few years we'll see
people tackle this. One of the things we don't talk about enough is that we
struggle quite a bit with teams doing Agile, much less programs. It's simple
concepts, but application is a bear.

~~~
adrianhoward
_You can certainly manage all these cadences separately, but for most folks
sprints of a week or two in length give you fixed reference points to then
optimize around._

Curiously what I've been hearing from folk in this situation is that it's the
separation of the cadences that they see as an advantage. With the large teams
they were finding there was just "too much stuff" happening at a single point
and it became impossible to manage. Moving to a kanban style, and moving the
various end-of-sprint rituals and spreading them out into their own cadences
helped enormously - but I would imagine that it would be very context
dependent.

The other thing I find useful about the kanban style is when the cadences of
some work doesn't match up well with the sprint cadence. For example the more
generative UX work (user interviews, etc.) doesn't always naturally fit into
that 1/2 week cycle. Sprint-ahead/-behind is an abomination in my eyes - so
having separate cadences helps a lot there.

 _Going from something like RUP to full-bore program-level Kanban in a complex
business environment is just too far_

Heh. With RUP you can probably find enough things in method composer to evolve
it into something kanban-ish ;-)

Personally I'm not a fan of the big-bang rollout of new processes. Never seems
to work well. And having folks who can actually understand "It's kind of like
Scrum only bigger" means you've already got folk with a fairly sophisticated
knowledge (assuming that they _actually_ understand Scrum that is...)

 _One of the things we don't talk about enough is that we struggle quite a bit
with teams doing Agile, much less programs. It's simple concepts, but
application is a bear._

Seems that it's pretty much all I talk about - probably why I keep getting
sucked into coaching roles away from more fun thing :-)

~~~
DanielBMarkham
We reach a point of dimishing returns really quickly just talking about
situations. I can share experiences and what I think I know, but at the end of
the day this isn't about going off and following some author, speaker, or
book. It's figuring out what works in your particular situation.

The cool part about Agile is that it's not Scrum, ie, there is no
certification authority or magic recipe. It's just a bunch of schmucks sharing
what worked or didn't work.

I shy away from answers like "it's all Scrum" or "It's all Kanban" for just
that reason -- too facile. In a 15-project program, you usually have several
groups going strictly Kanban. Enterprise architecture is one (if you have
that) and program release is another. These things don't have to sync up, they
just need to be ready. So even my advice about using sprints isn't absolute.
Advice in this area is a lot of generalizations. You get what you pay for!

If you have any experience with these larger structures, I'd love to hear
about it. I'm always collecting tidbits like that. Thanks for the chat!

~~~
adrianhoward
_I can share experiences and what I think I know, but at the end of the day
this isn't about going off and following some author, speaker, or book. It's
figuring out what works in your particular situation_

Likewise and ditto. As I said I would imagine that it would be very context
dependent.

------
chintan
> Don’t have a separate system for bugs

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

:)

~~~
evanhamilton
Ah, it's worth clarification here. Here's how we use the nomenclature:

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! :)

------
simonswords82
Great post and just the right level of detail too. Thanks for taking the time
to write this up. We're just about to encounter this problem with our own
startup (<http://www.staffsquared.com>) and my head of ops has been on my back
for weeks about how we're going to handle our roadmap for the product vs. bug
fixes vs. user feedback.

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.

------
burtlo
How have you trained your customers to NOT expect estimates? What's your model
for billing and managing budget, strictly Time and Materials, or do you
valuate the Planned Deliverables?

Many thanks for a thought-provoking, and wonderfully complete, post.

~~~
embwbam
A PM can often estimate delivery timetables by analyzing historical lead time.
For example, if it normally takes 10 days for a 2-star card to move from Next
Up to LaunchPad, then you can guess when it will get shipped. Pad it a little,
and make sure you give yourself time to get it IN to the next up column, and
you're good.

~~~
burtlo
I was wondering if you had some compelling (magical?) communication that
shifted your clients attitudes, but you're basically guesstimating based on
past performance.

I didn't see where a star rating equated to effort. I'll look again.

Thanks!

------
ams6110
How many would like to be doing something like this but cannot have customer
or product data in third party/"cloud" storage?

Is there anything like Trello that can be run in-house?

~~~
8ig8
A whiteboard and a big pack of colored sticky notes works for this. It might
sound simplistic, but it's surprising effective. It's difficult to ignore the
big board if you hang it in a public area of the office. Pretty shallow
learning curve also helps.

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.

~~~
adrianhoward
_It's difficult to ignore the big board if you hang it in a public area of the
office_

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.

------
productmanager
We've been using Pivotal, but are about to switch over to Jira completely.
Tried Trello. At end of day Trello and Pivotal are lacking 2 key features we
need for better predictability in scrum, particularly on enterprise software
with many projects: tasks with t-shirt/time estimates, and burndown charts.
Without these, the PM team has a hard time estimating a few months out what is
possible.

~~~
adrianhoward
If you're not getting a pretty constant velocity (if you're going the sprint
route) or cycle time (the kanban/flow route) then no tool is going to make
that happen.

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.

~~~
productmanager
agree.. technically the velocity should be constant and more or less is.. but
the story estimates still establish the building blocks for this.. a story
seems to need tasks and task estimates to make the overall story estimate more
accurate. Tasks help to break up activities. alternative is to groom the story
of course, then you're left with a larger list of stories to manage however,
and taking care of that in turn eats into our PM team's velocity :)

~~~
adrianhoward
It sounds like your spending a lot of effort on estimating. I'd _guess_ (I'm
not there so probably incorrectly :-) that you've got some combination of:

a) stories being too big

b) stories having to much variation in size

c) doing time based estimation rather that relative estimates or story
counting.

------
benr
What happens to the cards on the Inbox board during the Inbox review meeting?
I assume some are moved onto the planning board, others onto the bugs board.

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.

~~~
dejanabdejana
Several things can happen with a card that's in the inbox: it can go to
Roadmap, Planning, Engineering, Current Development, or just be archived if
it's not something we can prioritize at the moment. Bugs have a separate
board, so they usually don't end up in the Inbox. Most of our customers' ideas
live on our UserVoice feedback forum (feedback.uservoice.com). If an issue
comes up during the Inbox review meeting and we don't plan on implementing the
solution the next 3 Q's, we archive the card, or create an idea on our forum
(if not there already). The key here is that people are encouraged to bring up
that exact same issue next week, if it's still something that creates a lot of
buzz among our customers. That helps us understand what the current pain
points are and prioritize cards accordingly.

------
jmartens
Great post. Trello is amazing. We are also a Trello/Google Doc company, but
not as fancy as Uservoice.

------
jodeci
You mention that each week has it’s own Live column; do you only keep The
Current Week on the current development board? What happens to the older
weeks, are they just archived or moved to another board? :)

------
neilkelty
Any insight on how you prioritize cards? Do you keep the process as simple as
"I think A is more important than B, but less important than C." or do you use
some sort of scoring mechanism?

------
neilkelty
What does the "Roadmap" Board look like? (e.g. List titles)

~~~
rrwhite
There's simple a column for each quarter (ex: 2012 Q3) going about 3 quarters
into the future. The only things on this board are _big_ strategic projects.

------
blueskittle
What labels are used on the Product Planning Board?

------
embwbam
Do you have a Work in Progress limit?

~~~
adrianhoward
They seem to have individual ones, rather than stage based ones - from the
original post:

 _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._

