Scrum!

[Frankenbeans]

In the Ustream feed today Adam mentioned doing daily scrums. What software (if any) do you use to help manage your scrums?

[kirottu]

Notepad and post-it notes? What else you really need?

[Blarghagh]

Physical ways are always best. I've been on projects using programs for it - Hansoft or Tickspot for example - and everyone working on the project tends to really resent it.

[Malcador]

The dev team at work uses the whitebaords, funnily enough. They don't really seem to like it all that much and from talking to them it does seem like it's a lot of overhead and meetings.

[KarroK]

tldr: somewhat broadening the scrum discussion a bit

 

 

I've been in two different teams (small teams, 4-6 people) working on different aspects of the same product for little over a year now, so I thought I'd share my experience.

 

First off, the initiative to use scrum came from management first, not the developers. But since our previous "method" we used was a little less.. organised we just went with the flow.

The first thing we noticed was that it was quite an interruptive process, that was used more as a tool for management instead of a tool for the developers.

 

We went on and loosely implemented our own version of scrum, with as little of the interruptive or time-consuming administrative jobs etc.

In the first team we kept a not-too-big scrum board (physical whiteboard) with magnetic reusable "stickers", green for a story, yellow for tasks within that story and red for impediments.

Then we divided the board into sections: not-started, in-progress and done. Took some of those round magnets and (since we're all gamers sorta) put our avatar on the magnets and used those magnets to show who is working on what.

 

In the next team, we basically used none of that and simply had a properly sectioned spreadsheet for our main tasks, subtasks and our guestimates for those tasks, none of which are shared with product management and are there merely to give us the insight we want. We keep track of days-left on tasks and keep a history of that. We include our availability and we can guestimate for ourselves if we're going to be short on time or not and take decisions accordingly.

 

A couple of things to keep in mind (as I've found out at least) if you want to go with scrum:

 

- Have the initiative to go and use scrum come from the developers and make sure that your bosses know that it is a developer tool before it is a management tool.

- Time estimates (story points) are exactly that, estimates, and certainly NOT a planning of any kind. The estimate accuracy can differ wildly depending on the difficulty of the task and any complications that might come with it.

 

- Smaller teams make for less overhead, shorter daily standups and more time for.. yknow, work

- Scrum duration should NOT, I repeat NOT be linked to a release cycle (assuming you're doing way more than 1 release cycle). Have a trunk that is always in a releasable state, have a "merge" trunk for regression testing and multiple feature branches, test the branches, if they pass, merge them to the merge-trunk, have that tested again, and if that is stable, toss it in the trunk. This way it doesn't matter if features don't make the cut for a release because then it will just go into the next one. This is important especially if your sprint duration does not sync up with the release schedule.

 

- Personalize your scrum process, do what feels good to you and the team, keep it as a tool for your group to benefit from and not let it be used as a management-stick to whack you over the head with because they don't see the difference between your estimates and "planning". Doing so will simply lead to team members vastly overestimating tasks.

 

- Scrum works good for work that you can slice up into tiny parts (ie setting up basic architecture, implementing a basic framework etc), where each of the parts is well known by all the team members. This means estimates will be more precise.

- Flip side is, for coding into unknown territory (ie advanced stuff that might require re-doing, re-evaluating, tinkering etc) the estimates will be off by quite a margin, this won't improve at all unless you come to a point where those tasks become repetitive.

- Storyboards are optional (imo) but can give developers a good insight of what everyone is doing and what the status is.

 

- Scrum can feel incredibly wasteful, so keep daily standups short and to the point, technical or specific discussions that do not involve all group members should stay outside of the standup. Keep the sprint-meetings to the point, before you know it you spend half a day or longer just making some decisions.

- Developers are in charge, if a developer tells the product owner that certain technical stories (ie framework expansion or w/e) need to be done before a certain feature can be implemented, then that is the way it is <deal-with-it.jpeg>

 

Above all though, a manager should be able to trust the developer teams enough to work autonomously, check in every once in a while but let developers do what they do best, develop, while rocking out to some tunes and being in the zone.. until some scrum meeting interrupts that flow

 

And of course most important:

 

Scrum is a tool (replace "resources" with "tools")

 

 

Now I just hope I didn't bore anyone to death, I've too much left to do in this world to get stuck up for murder-by-proxy ;-)

 

I'm also interested in what the industry vets think about scrum and what they do and do not use, please share!

Edited October 17, 2012 by KarroK

[Gorth]

Hmm... more than 20 years in the software industry and I've never heard that particular term to describe that process before. When I hear "scrum", this is what I think:

 

 

Not that our project meetings doesn't resemble that

[NoMan2000]

It's big in Ruby on Rails programming or other "Agile" architecture frameworks that rely upon rapid prototyping and iterative development. I hear it a lot in Python, Ruby, and Javascript environments, not so much in Java and C++ oriented environments.

[dvis]

At my place of employment we previously used pivotal tracker which is designed around scrum with all its fancy words. The nice thing was it could pull commit comments from github if the commit contained the pivotal id.

 

However, we needed something a bit more tailored to our needs and settled on:

https://trello.com/

 

It is a lot easier to see who was doing what (gravatars), easy to attach files/checklists, write comments, have multiple boards and as many columns as we need. Sort of like a "super whiteboard" the posters above mention.

 

I'd suggest anybody using physical notes/markers to give trello a look.

[Blarghagh]

I heard good things about Pivotal Tracker, we considered using that but we went with Hansoft instead which turned out to be a disaster. I'll try out trello, that looks really good.

 

Hmm... more than 20 years in the software industry and I've never heard that particular term to describe that process before. When I hear "scrum", this is what I think:

 

 

Not that our project meetings doesn't resemble that

 

Is actually what it's named after.

Edited October 18, 2012 by TrueNeutral

[khango]

I worked at a place that uses scrum and I didn't really like it -- I think it's a management tool to give managers meaningless numbers to show off to various people above them mostly. At least where I worked Scrum tended to cause frantic development and a lack of design and engineering. I come from a background that's had some exposure to 'extreme programming' and systems-oriented project management/product design methodologies and I find scrum to be lacking comparatively.

 

I'm not for waterfall, but I do think it's critically important to do pretty deep spec of new products before implementing as it allows for a much better ability to work in teams and split up tasks. Scrum seems to give managers the impression that they can take a 'story' and assume it's good enough for immediate development, pass it off to a dev, who then just hacks at it only to find their time estimates are horrible because there was no planning and that nobody took into account how it would fit into the overarching infrastructure or existing systems.

 

'Hey, I implemented that thing you wanted.'

'Oh, does it do x and y, that I didn't mention in the user story, and also z, that all fizzbuzz-X add-ons need to do to be compatible with the venusian-flogger-X we don't really use anymore, but would screw up everything if it didn't work?'

'No, wtf is the venusian-flogger-X, I don't think anything we've developed has tied into it in over a year...

'Oh, Dave knows about it...'

...

Dave: 'Oh, that... well Jeremy wrote it before we decided he was a screwup and fired him 3 years ago, you can probably just read it and figure it out...'

...

Code: A few 200 line functions + 20ish slightly different copy pasted files + no comments

...

 

 

I really prefer a systems approach combined with extreme programming and highly iterative development that involves programmers in the systems requirements and design phases.

 

But I also got into trouble because 'business' side made lots of decisions that I found questionable but had to go along with. It's a matter of my view being that the customer's interests are always best for the business long term, whereas business side would screw the customers or take massive short-cuts that caused huge technical debt for short term cash flow.

 

In my experience extreme programming method along with loose UML meant a little more meeting up front, but delivery of features in a much quicker amount of time as well as all devs having a better comprehensive understanding of product, rather than piecemeal walled bits of expertise.

 

But I guess the problem is that if there never was an initial architecture or design to anything, you're just screwed. For all eternity.

 

Anyway, lesson being that companies that need to use tech without in-house competent technical experience to begin with are often a travesty and basically live in their own **** while believing it to be nectar.

 

 

Kind of like the litmus test for knowing if someone is a good PHP programmer is how bad they think the language is. The worse someone thinks PHP, the better a PHP programmer they probably are. Whereas someone who thinks PHP is a great language and loves it is probably not someone you want. Though I guess that test doesn't really apply to other languages as well. Just that PHP is probably one of the default places to find Nectar Lovers wallowing in crap.

 

VB and Asp.Net maybe being others.

Edited October 20, 2012 by khango

[alanschu]

We use Hansoft mostly. In the hands of a capable project manager, it's actually quite amazing.

 

Alternatively we use corkboards! XD

[Nightshape]

Yeah, Hansoft is an excellent piece of kit when correctly used.

 

Hansoft actually hire ex-game dev's too ;-) I know a couple there, one of which was a producer.