Slashdot Mirror

> Four times a day!?

According to:

https://www.mountaingoatsoftware.com/agile/scrum

Disclaimer that they gave me nice Fibonacci sequence cards for scoring stories, scrum should take 15 minutes per day timeboxed for each scrum team. Since i'm on six scrum teams, that means I'm in scrum meetings for fifteen hours each two week sprint. Actually that is much more since most scrum meetings take more than 15 minutes.

Not quite. In daily Scrum meetings only the team and the Scrum Master are allowed *to participate*. Product owners, non-team business stakeholders, or anybody else for that matter are permitted but they have to stay quiet. Nevertheless I believe that the mere "presence" of these actors can have a negative effect on the quality of discussion ...

https://www.mountaingoatsoftwa...

https://www.mountaingoatsoftwa...

"Anyone else (for example, a departmental VP, a salesperson or a developer from another project) is allowed to attend, but is there only to listen"

Official Scrum says the stand-up is open to all, but only team members can actively participate - this is a mistake in my humble opinion. In my experience the presence of a senior figure can have a "chilling effect" on the quality of discussion.

"The daily standups should be about 5 minutes and are mainly for communicating problems encountered, if any."

You are incorrect, though "You're doing it wrong" is the standard comeback for anyone who criticizes Agile.

http://en.wikipedia.org/wiki/Stand-up_meeting
http://www.mountaingoatsoftware.com/scrum/daily-scrum/
http://agile.dzone.com/articles/agile-health-check-daily-stand

There are three things that each Scrum team member is expected to relate in turn:
- What they have done since the last standup
- What they are working on now
- Any impediments that are getting in their way

Of course, such meetings aren't unique to Agile and aren't what makes Agile suck. There are other, far worse, problems.

Wikipedia has a brief, general description.

One example of Agile approach is named Scrum. c.f Beginners Guide to Scrum - my referring t Scrum as an agile approach, considering that it's not, per se, a formal process model.

Another example, which has perhaps been around for longer, is named Extreme Programming c.f Extreme Programming, at the Cunningham & Cunningham, Inc. Wiki

I've spent a lot of time working with many different teams and trying lots of different estimation techniques, and I've had the best success with the ones that let the team work together to come up with an estimate they all believe in. My best results came with Wideband Delphi, which I've been able to use in both Agile and non-Agile projects. I've actually got a chapter on estimation in one of my books -- you can download the PDF of it.

Also, Mike Cohn has a lot to say about planning Agile projects on his blog -- definitely highly recommended reading if you're trying to plan projects.

Whenever I help teams improve the way they estimate their projects, one of the things I've really concentrated on is that planning is about more than estimation. I've got a blog post about it (The Perils of a Schedule) -- a big part of planning is making commitments, and estimation is the way to make those commitments easier to stick to (or less likely to break).

some one explain this to me A short description of the role of the ScrumMaster. ... ScrumMaster. The ScrumMaster is responsible for making sure a Scrum team lives by the values and practices of Scrum. Source : http://www.mountaingoatsoftware.com/scrummaster

After a long spell away from project management, I bought a few books to catch up on what I'd missed. I did read the Art of Project Management, but I wasn't that mesmerized by it (though I did start following Scott Berkun's blog). It felt too sterile and academic as a starting point. Maybe it's better if you're already in the thick of it, and maybe the new edition is cleaner.

What did mesmerize me was Agile Estimating and Planning, by Mike Cohn, who also has a good blog. It's quick reading, in an appropriately lightweight style, and it introduces all the concepts of agile planning (independent of Scrum, XP, etc) in a way that... that...

Well, remember that one professor you had, who taught you biology by deriving it from chemistry from physics from mathematics? Cohn explains agile planning from first principles, in a way that made me wonder how we spent two decades not realizing how obvious it was. My forehead hurt from all the slapping. Of course! Why are we forcing humans to estimate time and to calibrate their estimates? All we know is "hard" and "easy"; estimate in points, track your velocity, and let a smart computer figure out what that means in weeks. Of course! We don't need to plan hour-by-hour for dates 18 months away; we don't even know what we'll consider important than.

If you're considering agile methodologies, you must buy this book. If you're considering traditional top-down/waterfall planning, do yourself a favor - just slap your forehead every day. It'll build up calluses for when you buy the book later.

'Agile' is a class of software methodologies. A popular Agile methodology is called Scrum. An excellent resource on how to conduct a Scrum shop is 'Agile Project Management with Scrum,' by Ken Schwaber. A good place to get started is http://www.mountaingoatsoftware.com/scrum/.

This should be one more argument to help your argument on getting faster workstations and servers. The less time you are waiting for your computer to complete something, the less task switching and loss of productivity.

Right now I'm more concerned about trying to set up coding standards...

Coding Standards? A good thing. Which ones? Doesn't really matter. Read Ken Arnold's Style is Substance for a good opinion. His point is that you shouldn't spend any time arguing about which style is best; just pick one of the few well-documented standards and enforce it as heavily as possible.

... so that any developer can jump into any part of a project and be able to figure out what's going on, without wasting a couple hours just to figure out the code.

Unless we're talking about really well designed, really well documented and really well commented code, this sounds like a pipe dream to me. Maybe I'm just not skillful enough, but attempting to absorb any non-trival amount of code that was written by someone else is going to take a few hours. You're better off assuming that will be the case.

As far as general software development practices, I think you have two viable choices:

1. Pick one of the popular Agile development methodologies; my first choice would be Scrum, but they all have common goals. Read a book or two on it so you get the idea. Then, go hire a consultant to help you run a Scrum project with one team. After you've done it all the way through once, you can probably run it yourself & expand the # of teams using it.
2. Read a whole bunch of books on software development process, and don't limit yourself to the Agile methodologies. Document your favorite concepts, and why you think they'd work in your environment. With the help of a small group (3 people max), come up with your own process that is loosely based on your research. There is obviously a fair amount of risk here though: lots of smart people have spent many, many years trying to solve this problem, so be careful.

The one thing you shouldn't do is quickly review a few random articles, pull out a couple of the buzzwords, then never think about it again. The number of development groups out there that say they're following a certain process when they're really just winging it is astounding....

Oh, and take all suggestions from strangers on Slashdot with a big, chunky grain of salt :)

--Mid

• What is it that you absolutely need?

• What would go along with these critical feature well?

• What would be "icing on the cake?"

1. 1) Mockup something and present it to them.

1. 2) Ask "Is this what you're looking for?"

1. 3) Architect your framework (real coders should be taking part here!)

...this one by Mike Cohn of Mountain Goat Software.

Mike's review is from the "agile software" point of view, so he comments favorably on (among others) Fact 22 - "Eighty percent of software work is intellectual. A fair amount of it is creative. Little of it is clerical".

Is a piece by Mountain Goat Software, they explain things with pictures, much better for us simpletons.

http://www.controlchaos.com, Home Page Good overview.