Hacker News Reader

Comment by nowarninglabel | Hacker News Reader

We have successfully pulled off 20% for 5+ years now at Kiva, doing some of the things suggested here.

However, the key thing we do is actually make the 20% be a full two-week sprint, it just happens every 5th sprint. That way, you can have the time to do some planning, suggesting, and documentation before setting out to build something and you get the full amount of time you needed to build it. We purposefully do try to keep features limited to something shippable during that time period, though some folks will spread it out over a few for bigger efforts. It's pretty great and a key part of our culture that I'm happy we've been able to keep. It's also produced some of the best features Kiva has (as well as served as a great time for engineers that like to tidy things to clean up the codebase).

http://pages.kiva.org/buildkivablog/2011/02/10/kiva-engineer...

View on HN

If a developer places an idea up requiring only 4 points, can they pin their own 4 points to it and work on it alone without having to answer to anyone?

The entire point of the 20% concept to me is that I get to work on my own idea. I do not like your version that makes it a popularity contest between developers and their separate ideas. Most of the fun that can be found in 20% is the lack of constraints and oversight. The 20% should not have to be justified to anyone, let alone planned out and required to fit within a single sprint.

To be fair, I despise agile (or is it capitalized Agile?) in all its bullshit incarnations. The most interesting aspect of a 20% project is that the business keeps its filthy hands out of my time. Applying agile into the 20% makes me sick.

Approach to instituting 20% projects is going to vary wildly from company to company.

After thinking about it, the method proposed makes sense for structured companies trying to introduce the concept.

Unfortunately, I still think it's non-ideal, but it is a good start.

Out of interest, could you elaborate on what is it about agile methods that you dislike/despise?

I've been through the agile process at 5 different companies, and it has never been successful. My biggest issue is with the people who are brought in to implement it. The scrum masters always try to spin the whole thing as a positive for both the development team and the business. Both the team and the business's management are supposed to be disciplined. But the scrum masters always wind up being scum masters, always bowing to the will of the business's management. Meanwhile the team is left with nobody to defend their right to have the process respected.

The primary selling point is always the removal of the "old waterfall method". And yet every single sprint, 20-40-80 hours worth of "more urgent tasks" get dropped in without proper grooming or advanced planning. Whether or not other tasks get removed from the sprint to equalize the incoming work does nothing to alleviate the frustration.

Every agile process I have seen always winds up being the same old bullshit of management having no discipline to actually follow the rules. We call it agile, but it's still just waterfall glossed over with a name - with none of the actual principles being taken seriously.

Ok, I can see why you might be jaded about it! I've had very different experiences, and, as you say, it probably depends on the people who are implementing it - the discipline is very important, and perhaps we were fortunate in that regard without realising it, because it was something we implemented as a group rather than being imposed on us from above.

Yep, a developer can work on their own 4-point project and doesn't require collaborating with anyone or any oversight other than approval from a PM before making it live if it is a user-facing feature.

The only requirement is documenting how the project is good for Kiva. Some people would like to do something like say go learn Perl with their time. That's great for the person, but better covered by the professional development budget than innovation iteration. So, sometimes something like that gets shot down, but it's rare.

I like the idea of every 5th sprint being devoted to this – a day week is barely enough to just switch context and get into gear. I can see how getting a couple of days distance between "real" work and the 5th sprint would be beneficial just to clear your mind and start fresh, knowing there are two glorious weeks of focus ahead.

Everyone is different. Some people stagnate without switching contexts frequently enough. That happens to me sometimes.

I worked at a large company which in its quest to deploy agile everywhere introduced an innovation sprint. The actual concept went well, and we even had some great show-and-tell sessions from it, but absolutely zero things created during those sprints were allowed to ship. So in the end it was more of a blow-off valve for engineers before sending them back to another 10 weeks of normal engineering drudgery, while their innovative projects collected dust on a manager's shelf somewhere. If these were research spikes I feel like they would have gotten a little more respect from the higher-ups.

That's a really great idea. Two weeks is just about enough time to see if an idea is going to go anywhere.

I've worked under 6-8 week fail fast R&D regimes before as well and have found they really help provide focus...though in all cases it seems to push the R&D effort much more towards an Applied R&D approach than a theoretical one.

Scaled Agile Framework (SAFe) recommends a similar approach as an "Innovation and Planning Iteration" after every 3 – 5 regular development sprints.

http://scaledagileframework.com/innovation-and-planning-iter...

That's funny, psychologically it seems much easier to accept 1 day per week spent on side projects. But a whole block of 2 weeks to work on whatever you want sounds really crazy, even if it's after 8 weeks of regular work. It sounds like it would work a lot better though, context switching can be a real pain.

Reply on news.ycombinator.com