Roy will accept your emails, but he doesn’t guarantee that he will read them.

The presentation is going to follow an agile method.  We’re choosing the list of topics, then we get to vote on them and the highest votes will be discussed first.  Here’s the list

• Scaling Agile to large teams (Scrum) – 9 votes
• Scaling Agile in the Enterprise – 7 votes
• Adopting Agile in organizations – 25 votes
• Agile in distributed teams – 35 votes (example of estimation gone wrong)
• Overview of Agile processes – 20 votes
• Introducing into a team – 20 votes
• Is Agile a defined process – 2 votes (I don’t think the idea person even voted on this)
• How to start pair programming – 12 votes
• Team structure – 24 votes
• Success story (bad to good) – 20 votes
• Same team multiple projects – 15 votes
• Customer involvement – 12 votes
• Why do I like Agile – 11 votes
• Agile estimation – 40 votes
• How do you measure results – 22 votes

Agile Estimation

Dev says 2 weeks

Dev Lead says 4 weeks

PM says 2 months

Project owner says 4 months so I’ll out source to India to reduce risk

Estimation is a guess based on the abilities and ideas of the people who are going to do the work.  It’s still a guess.  No two groups will do the same work in the same amount of time.  You have to remember that people have different situations…wives nagging, past experience, team doesn’t like you, crush on the hot agile girls sitting in front of me.

Let your team work for one iteration and see what their pace is.  Having team members who are sick or on vacation should not be removed from the equation.

The best people to know how to estimate are the individuals.  More and more iterations will help developers increase their estimation skills.  The only way to learn how to estimate is to do it.

There are at least 2 rounds in an estimation process.  Having the whole team estimate can help them to understand the whole project and get comfortable with each other.

Do all estimation before starting the iteration in a day or two that is part of the planning process for each iteration.

Don’t ever estimate for the entire project.  Just the coming iteration.

Estimating a project is a total guess.  Estimating an iteration is more educated because the situation is immediate and the prerequesites and team situation are currently know.

Requirements don’t change during the iteration.  This keeps things focused and allows for replanning and refocused

The hot agilista chick loves the geek sticker on my laptop.

JP points out that you sometimes see that tasks aren’t as fine grained as you want them.  You need to break them down on during the planning meeting.

Bellware jumps in and says “Breaking down the tasks into smaller pieces is a design process.  This is where the design part of an agile project occurs.”

Roy has the bad ass “geek” shirt with some quasi dress pants and running shoes…..Justice Gray should take some notes.

Should people be optimistic or pessimistic with their estimation?  How do you acheive group consensus on an estimate?  i.e. 1 dev says 2hrs and another says 40.  If you get this its a sign that you may be missing something.  You have to look at it again and restimate it without any buffers.  Be completely realistic and truthful to the team lead.  the TL is the only one who sees them.  This builds a feeling of comfort in saying that it will take longer than you may want, but it’s not a punishable offence.

Iteration planning is an operation planning session.  Project planning is strategic planning.  Very different goals.

JP is standing at the front without his water bottle!  He looks very lost!

Estimation may not fit with what the organization wants to hear.  i.e. “It must be ready by Q3”.  You can either remove features or increase spending to meet these fixed deadlines.  You can’t say “We will have it ready by Q3”.  You can say “We will have it ready by Q3 with the most requested features”.  This is a big difference and allows you to deliver a better product by the deadline.

Fixed money or fixed time table, the only thing that can change is features.  If it’s fixed you usually get an extentions and you just finished 9 months lying to each other.

The appropriate resolution for a task depends on the length of the iterations.  3 week iterations == about 3 day tasks.  1 week iterations == 1 day.  Adapt this rule to your project.  JP is the man!  He did a project where tasks were 5 hrs or less!

Planning Poker tool is very good.

Agile in Distributed Teams

Working in an agile environment is different that distributed.  You can’t be purely agile in a distributed team.  You need people to feel like they’re sitting right next to you.  Email doesn’t cut it.  Not having immediate access to the client is a huge problem.

Having a product manager is important.  They represent what the client wants.  They really need to know.  They need to be physically in the team.

Distributed teams are different from distributed people.  It requires the proper tools (IM, CI, Remote Desktop).

Hot agilista chick #2 has the name “Wendy”….some of you will know who I’m talking about.

You need to have one person managing the incoming requirements.  They have to work at managing the priorities.  This can be done using a point system where you give an allocation of points to a client and let them priortize by assigning points to tasks/features.

Hot agilista chick #2 (Wendy) is now talking about Scrum and how to do project management with it. 

Being agile means that you move resources to help teams meet deadlines.

Dependancy managment is something that is dealt with in design.  Agile or XP doesn’t ignore them just like waterfall doesn’t.

Adopting Agile in Organizations

People are reluctant because of irrational reasons.  i.e. TDD, test doesn’t compile?  or Pair Programming only saves on hardware costs.  Ususally these items result in better quality and productivity.

The only real way to introduce this is through training because it takes people time to grok the methodology.

Change either happens from the bottem where a team just decides to do it, or a manager decides to implement it.  Teams implementing is usually better because managers can force methods or try to implement too much.  Forcing will cause people to do less.  First rule is to start small. i.e. CI or automated builds or shorter iterations.  To much at once leads to failure.

JP pontificates on the immediate deliverables for developers when changing a team.  You need to make the team feel like you have a vested interested.  Small wins, small victories.  Always use a staged approach.  Mentoring is more important than training.

Scott Bellware says that software productivity, in orders of magnitude, is changed by software quality.  Anything less than productivity and quality is just scrambling for expensive productivity.

Don’t forget, Roy Osherove (minus friends) will be at Edmug on the 22nd of May.  If it’s anything like this, Edmonton’s software development teams will not be the same.