Category Archives: Scrum

Scrum Archive

How We Can Make Agile Work

– October 15, 2009Posted in: Agile, Scrum

I just read a really good post at PM Hut titled Agile Myths Debunked. Sanjeev Singh listed 12 reasons people say Agile won’t work on their projects and how they are misinformed. His list included:
Indiscipline, lack of planning, no documentation, no QA involvement, not for fixed bid projects… and the list goes on.

From my experience, organizations commonly get caught up in their project management processes. I think they fail to realize, when saying they can not use Agile, the goal is to deliver value to the customer. As professionals, we should focus more on how it can work and less on why it can not. I do believe Sanjeev’s listed myths are the primary reasons Agile isn’t more broadly adopted in some markets. I’ve sat in meetings and heard those same myths listed as though being read directly from his blog post. Only by educating clients and debunking these myths will we see more adoption. I’m not saying Agile will work in every circumstance for every project. What I am saying is you should never discount something unless you’ve at least tried. Do your research and see where you can make it work.

Popularity: 1%

Tags: Agile, Federal, Myth, Value

Mike Cottmeyer talks about scaling Scrum

Derek Huether

– September 15, 2009Posted in: Agile, Application Development, Scrum

On our current project, we have over 100 people across 14 Scrum teams. The challenge? How do you communicate between Scrum teams? Well, that all depends. What are the dependencies between the teams? Though I could write a 1000+ word post about this, I figured I would just link to a short but informative video. In it, you’ll see Mike Cottmeyer talk about scaling Scrum and how you might have different types of scrum-of-scrums (the way you would communicate between Scrum teams). Mike is a Product Consultant and Agile Evangelist at VersionOne. You can read more from Mike on his blog, Leading Agile, or on the VersionOne blog, Agile Chronicles. I’m hoping if all goes well, we’ll be bringing Mike to Washington DC to offer a few days of training. I’m sure this will be one of the many important topics to cover.

How To Know When A Meeting Has Ended

Derek Huether

– August 24, 2009Posted in: Agile, Scrum

I just read are very intriguing post by Ken Clyne on the Agile Blog, located at RallyDev.com. The post was about how problems can arise when people don’t realize a meeting is over. Ken offered one way to avoid the never-ending meeting is by having a clear signal that the meeting has ended.

I could not agree more. Don’t you just hate it when a meeting has ended, not everyone knows, and people just start to filter out of the area? I’ve found myself looking at the meeting host and actually ask if we were done. That is not a way to conduct a meeting.

Though I believe this applies to all meetings, the daily stand-up (daily scrum) really needs to have a clear beginning and end. Though some may not agree with me, I like to use a visual aid like a big alarm clock. Everyone sees the clock ticking away and know a very loud alarm is going to go off at an agreed upon time. You see people get anxious if others are rambling on and the time is ticking away. Think back to your youth. Remember how you knew you were late for class because you heard that starting bell? Remember how you knew you were dismissed from class because you heard that same bell? Let those years of conditioning motivate the team. Though I like the visual queue, you should still say something to the team to close the meeting.

Unlike your school days and hearing your assignment is due Monday, I know I’ve closed meetings with So let it be written, so let it be done, Make it so and May the force be with you.

Link to the original post

Image: Pictofigo

Calculating Initial Velocity On Day Zero

Derek Huether

– July 8, 2009Posted in: Application Development, Scrum

While reviewing proposal documentation yesterday, I noticed the contractor’s predicted velocity rate was pretty high. Being they are not experienced in using Agile and they haven’t even started the project, I was curious how they were able to calculate such a high velocity rate for the first iteration. I know how many developers they intend to use and I know their proposed iteration durations. I’m not going to get into the specifics as to how they estimated features (user stories, requirements, backlog items, etc.). So, what did I expect?

Velocity is a very simple method for accurately measuring the rate at which teams deliver business value. To calculate velocity, simply add up the estimates of the features successfully delivered in the last sprint or iteration. What about the initial iteration?

Terms to understand when calculating initial velocity:

[1] Number of Developers – How many developers will you have doing actual work?

[2] Capacity – What is the maximum amount of work one person can accomplish in an ideal situation during the iteration?

[3] Number of Iteration Days – How many work days are in the iteration?

[4] Load (Capacity) Factor - The ratio of the actual work output over a period of time and the output if the developer had operated at full capacity over that time period. e.g. 1/3 = 2.4 Hours , 1/2 = 4 Hours, 1/1 = 8 Hours

[5] Velocity – How much Product Backlog value a team can deliver in one iteration.

Because you don’t know team velocity for the first iteration, plan initial velocity at one-third of total capacity in order to account for coffee breaks, design, email, meetings, rework, research, etc. As an example, with seven (7) developers and at one-third (1/3) capacity, a total of 2.1 ideal developers are available. Multiply the number of ideal developers by the number of work days to arrive at the total of ideal work days. These ideal work days will be applied against your estimated features, to arrive at an initial velocity.

(7 [Developers] * 1/3 [Load Capacity Factor]) * 21 [Work Days] = 44.1 [Ideal Work Days]

Popularity: 1%

Tags: Agile, Estimating, Formula, Planning, Scrum, Velocity

The Lights are on at HueCubed

Derek Huether

– June 26, 2009Posted in: Application Development, PMP, Scrum, Social Networking

In anticipation of my upcoming iPhone application release, I figured it was time to stand up a new website with the purpose of distributing my own brand of tools, templates, and talk. The Critical Path will remain as my blog. But, selling products requires branding. By following me on Twitter or reading this blog, I think people will enjoy the HueCubed brand.