Topic: Scrum

Post-Agile in the Game Development World?

V&A Kanban December 7
Creative Commons License photo credit: Rich B-S

Gwarred Mountain over at Climax Studios has posted a very thoughtful blog post about software development methods and the appropriateness of Agile Software Development. I was ready not to like this article, what with the title and things like this:

If I have to sit through another meeting with some little "agile" toe-rag defending their train wreck of a project then I may end up forcibly ramming a kanban where the scrum does not shine.

But then I thought about all of those fresh-faced management consultants we've run into recently -- who have read a book about agile -- trying to teach us how to do it. Well, yes. I've had some uncharitable thoughts myself. Continue reading »

Topics: ,

Fake Agile: All of the Symptoms, but not the Disease

For any software development professional who has contracted out from time to time, this story must seem familiar. You interview and are told that they practice agile development. Once you show up at the job site, they tell you they practice their own "brand" of agile, which turns into "sort of agile" or "we've take the best parts of a couple of different methods" or "it isn't exactly" -- wild and crazy hand gestures -- "XP."

It's a classic case of people following the form or ritual of a process without understanding the why of it. Take the morning scrum, for instance. The ritual around these usually calls for them to be done standing up. We've of course all heard of the standups that run an hour or two. Someone on that team doesn't understand the function and is following the ritual.

Continue reading »

Week in Review

Some interesting posts from around the blogosphere:

  • The GWT Plugin for Grails has been stuck in version 1.4.x of GWT for forever. Michael Galping has published a two part (one and two) series at IBM Developerworks on integrating Grails and GWT 1.5.3. Extensive, well illustrated with full source code available for download.
  • InfoQ has published an interesting conversation about Ajax and COMET versus HTML Web Sockets, i.e. hacky COMET versus real bi-directional communication mechanisms between the server and browser.
  • UXDesign.com has a concise summary of an Alan Cooper Interview video from 2008. User Experience Design, baby!
  • David Hamill has some provocative musing on the difference between usability and user experience design. Not sure I agree with everything he has to say, but it's a question that comes up often and is worth thinking about.
  • A bit older, but I just came across it: the original ScrumMaster, Jeff Sutherland, has an interesting article about ROI and incremental development. The conclusion? Incremental is better. :-) But seriously, we don't have enough rigorous thinking and writing about how good design and process reduces the cost of software in the long term (while perhaps increasing it in the short term).

These were some of the posts that I found valuable over the last week. Please share yours in the comments.

Are We Engineering Software or People?

I had a nice little vacation this past week in Los Cabos. It's always sunny, 80 and it never rains. Very nice. My wife and I had another installment of our long running discussion called "Computer Science is not a science." My wife is a real scientist with a Ph.D. in physical chemistry, and so she has a bit of a chip on her shoulder about the whole "science" thing. It's a one-sided discussion because I agree with her. Computer science is not about experiments and the scientific method, it's about three or four different and disparate areas -- mathematical computer science, AI or clever algorithms, chips and clock logic, and software engineering.

Then she told me that she thought of me more as an engineer. That got me thinking. Am I really an engineer?

Continue reading »

Scrum defined in under 10 minutes

Hamid Shojaee from www.axosoft.com put together a great video to introduce the core concepts of scrum and Agile practices called "Scrum in under 10 minutes"

Get Adobe Flash player

I really like what he said particularly the focus on the importance and simplicity of the burndown chart which helps to :

  • Visually show the hours remaining, and help anyone see "are we there yet?"
  • Allows decision-makers to make adjustments if needed

A simple burndown chart quickly shows the impact of some of the most common efficiency killers or blockers

  1.    late-breaking requirements changes
  2.    waiting for business decision
  3.    waiting for tech. partner (ssl keys, ops. vendor, etc)

He mentioned the standup, but didn't cover the 3 questions (What did you do?, What are you going to do? What do you Need in order to accomplish it?), or the idea that only people that have work can speak (Chickens vs. pigs)

I also liked his take on bugs, that you should plan a sprint to tackle them, and any bugs that come up during a sprint should be tackled immediately.

That's actually something that a lot of teams struggle with, "How do you plan for and estimate the time necessary to fix bugs?"

I always say Bugs Can't be estimated. While you may be able to plan how much time you will allocate to working on bugs, you can't really estimate how long it will take to fix bugs unless you have already looked at them, and have figured out the problem. From my point of view its the "looking at it and figuring out what's wrong", that takes the longest, and is the part that needs to be accounted for.

How do you plan for bugs?
Do you let bugs accumulate and then have a final sprint before a Release where you tackle all of the bugs? (How would you know that you can fix all the bugs in time for the release?)

Do you tackle all High-Priority bugs as soon as they come up, and leave the medium and small priority bugs for later?

Do you have a 'zero-bug' policy, where you fix any bugs that are opened?

UPDATE: I've expanded on this discussion a little more in a new post Bugs Can't be estimated, and after having some discussions around how best to plan for bugs, I was asked to do a last minute Security Analysis, and I wrote a post about How to avoid the last minute security review, and I think that the planning part can actually apply to how you manage a big list of bugs as well.

Launch: Pathfinder Newsletter

    Get a monthly update on best practices for delivering successful software.

    Subscribe via email


    Subscribe via RSS      RSS icon

Topics

Search

WordPress

Comments about this site: info@pathf.com