Developer Exchange Blog
Iteration Zero - Building Your Team
There's some debate in the Agile community about whether there should be an "Iteration zero." This article contains the slides and talking notes from my presentation to Agile Birmingham on Dec. 5th, 2013. In summary, I both explain what Iteration zero is and why I believe it's an important step in launching a successful, productive Agile project. It also includes some important notes about project leadership, as well.
- Iteration Zero : Building Your Team and Getting Started
- Presented by: John Pruitt
- to: Agile Birmingham
- on: December 5th, 2013
- at: Doozer Software, Inc.
What's an Iteration?
In an iteration, you repeat something you’ve done before. Think about iterating over a FOR loop.
In an increment, you tackle some new piece you have not yet tried.
In each Sprint in Scrum, you iterate on the process, but you are usually working on a new increment of the product.
In any case, we are talking about a time box - fixed set of time in which business value is delivered and features get “DONE”.
So, what is Iteration Zero?
The idea is that there are usually things that have to happen before we can really get started on the actual work.
Some have proposed an Iteration before the first iteration to address this stuff.
zero features; zero business value?
It’s actually a controversial topic.
Many say that it should be avoided. It’s not “agile”.
I’m going to assume you need one. We’ll discuss what would go in an Iteration Zero. Then, let’s vote to see what you think.
If we aren’t delivering features in iteration zero, then the only way we can deliver business value is if we eliminate waste that would have otherwise occurred.
Take measures to ensure that the team is more effective in Iteration One and beyond.
How do we determine what to do in iteration zero?
Easy... Why can’t we start iteration one? Eliminate those obstacles.
Anything else that might be prudent.
What can you do that would be a good investment in the long-term effectiveness of your team?
Features are for Iterations One+. By definition they don’t go in Iteration Zero.
It’s impossible to define “DONE” for architecture and framework work.
You’ll get stuck in iteration zero forever.
You WILL be wrong on your first architecture and framework designs.
Agile says – these should be produced organically as you go along.
Design is a process of knowledge discovery - you have the least knowledge at the beginning of the project.
What is preventing you from working right now? What do you need to get started?
3 areas to consider when planning an iteration zero.
We will address the easiest or most obvious first.
Easy stuff first...
Practical, common-sense, but often overlooked items.
How long does it take your company to on-board a new person?
If I showed up in the morning, how long until I could be contributing code?
Make sure you’ve identified and eliminated any environmental issues before Iteration One starts.
You don’t want any of these items to distract, impair, or demotivate the team.
If your team works remotely, you’ll have additional things to consider.
You may have other examples of environmental items to consider...
There’s definitely more meat to this consideration than the environment.
Projects exist to deliver a product.
Clearly we need to consider this before we begin.
The vision statement defines WHAT we are building.
Create a vision statement to provide focus and direction.
Again: both for yourself and your team.
This gives everyone a **target** to drive their focus.
Make sure you understand WHY.
Both for yourself and your team.
Have an elevator pitch?
Can you justify why **this** project and not another?
Should we really do this at all?
Don’t start Iteration One until you’ve answered.
You’ll get better results from your team if they understand this too!
Products usually exist to solve a problem.
Define the boundaries and extent of the project by defining the problem scope.
Categorize the problem-space.
What exactly ARE the problems we should be solving? Can you name them?
We can’t do everything at once.
No boiling the oceans.
Sometimes more importantly – what problems are we purposefully NOT solving and why?
Ignoring problems can provide mental relief to the team.
What are the product’s drivers?
Every project has constraints and priorities – iron triangle.
Driver = the constraint most crucial to success.
It’s impossible to optimize for ALL constraints.
Some may be fixed; Others must be negotiable.
Know them, name them.
People need to be able to place the project in chronological context.
It WILL be wrong, we all know that.
But need an initial concept – a goal to shoot for...
Will we build the product in phases? What goes in each? What order do they go in?
What deliverables go in each phase?
Release Criteria - what does DONE mean for a release?
Do you have time related drivers, constraints, or goals?
You cannot plan a sprint without a product backlog.
If you’re a Product Owner/Manager, you’re #1 job in Iteration Zero is to prepare the backlog for Iteration One’s sprint planning meeting.
Your goal for Iteration Zero...
Make sure everyone involved understands what we’re doing here and where we’re going.
These deliverables don’t have to be perfect, they are “initial” and subject to change.
How many of you are: Scrum Masters Team Leads Technical Leads Team Managers?
How many of you believe this?
I’m a firm believer.
If we’re honest with ourselves, few of us are doing anything technical that hasn’t been done well 100 times before.
How we work **together** is either our biggest weapon, or an anchor around our necks.
We probably have very few projects that can be done by one person alone.
Social skills are important too.
How many of you believe this?
Put it this way: If the people are incompetent or cannot work together, no amount or kind of process will make up for it. Chances are, you’ll fail.
On the other hand, if the people are all experts and great at working together, they will find a way to succeed regardless of process.
Don’t we all intuitively know this?
Do we run our organizations as if this were true?
Does your organization hire, grow, and fire people as if this were true?
See, Alistair Cockburn on People as First Order Components
People are “first-order components”.
This means they have a direct and substantial impact on the success or failure of the project.
Dominate drivers of project outcome.
We cannot change the nature of human beings.
We must manage to their strengths and around their weaknesses.
What can we do in Iteration Zero to prepare the people?
If you have a functioning productive team BY ALL MEANS keep it intact!
Ride the wave of their existing momentum.
You’ll have a whole host of efficiencies in working with a team that is used to working with one another forming -> storming -> norming -> performing -> adjourning.
Bypass the first two steps.
If you have to hire, or pick your team, what kind of people should you look for?
Subjective. My opinion here!
Intrinsically motivated – enthusiastic about doing quality work. It is part of their personality.
Good at looking around and asking questions – curious, wants to know “WHY”, wants to make things better.
Smart and gets things done – not just intelligent, but knows how to accomplish.
Good judgment – problem solvers vs. problem factories. Solutions are simple, reliable, elegant vs. complex, faulty, ugly.
Personally responsible – trustworthy. No babysitting.
Socially mature – works well with others. How many projects do you have that one person can do alone?
“T” shaped – broad exposure with at least one area of deep expertise.
I am going to take us on what is arguably a tangent now.
We are going to talk about the role of the team lead.
My goal in discussing the team lead’s job is to help us identify how the team lead can help prepare the team members in Iteration Zero.
Or technical lead, or scrum master, or manager, etc.
Started with... Gerald Weinberg = MOI, In becoming a Technical Leader: An Organic Problem Solving Approach!
These are the attributes of a team that determine the team’s health and effectiveness.
As team leads, it is our responsibility to monitor these life signs so we can guide our team to health.
You cannot possibly make all the decisions that have to be made over the course of a project.
You will not do a good job at this. You will burn yourself out.
You won’t be able to take vacation or sick days.
The team will never be better than you are.
If every decision must go through one person, you have a serious bottleneck.
“In the most effective organizations, everyone is solving problems and making decisions, as required to get the job done.” -Gerald Weinberg Becoming A Technical Leader
In manufacturing, parts are assembled in a series of steps that are fully known up front.
To build 1 million toasters, the series of steps must be followed 1 million times to assemble each one, in turn.
All the decisions about how to assemble a toaster have already been made when the assembly line begins.
Software development is nothing like this.
How many of us sit at our desk and type out the same line of code over and over and over each all day to deliver your software product to 1 million people?
How many times do you type each line of code? Ideally once, right?
In knowledge work, people are decision makers.
No matter how detailed a spec is, turning it into code requires decisions to be made.
Instead of thinking of work as a series of tasks, think of it as a series of decisions to be made.
Code is a recording of the decision made.
How can you help the team understand more fully?
You want both volume and quality in your communication.
High bandwidth, high signal to noise ratio.
People communicate best face to face.
Make sure at any given time, each person knows what they should be doing.
This is not about assigning tasks and micromanaging.
This is about providing context and understanding.
Everyone should understand the direction.
Everyone should know who/where to get the information they need.
Everyone should know when they need to get permission and when they can operation on their own discretion.
Everyone should know who their decisions will affect and how to inform them.
In Iteration Zero, set the tone, get communication channels setup.
How do you turn a huge incomprehensible pile of work into small units that can be tackled?
How do you turn a large chaotic team into smaller effective teams?
Discuss your options with the team. Decide on an initial approach.
Motivation is about “productivity-health”!
Extrinsic motivation – examples: money fame power status/rank/position, pleasure!
Intrinsic motivation – innate within the individual. Does not depend on an external source.
￼While intrinsic motivation does not depend on an external source.
External forces can impact it negatively.
What happens to a good programmer when an organization or environment prevents her from doing a job to her standards?
Your job: don’t kill intrinsic motivation.
Create an environment that allows intrinsic motivation to flourish.
Intrinsic motivation flourishes when people are empowered.
This means they feel like they make a difference.
They have a way to affect change on the work they do.
They are given the space in which to live up to the standards they have set for themselves in their work.
“...empowerment...means putting process ownership in the hands of the people doing the work” - Tom DeMarco - Slack
Speaking of standards.
We’re talking about craftsmanship here, NOT RULES and PROCESSES.
When a team is proud of the work they are doing, they are a force to be reckoned with.
They will not tolerate sub-par work from themselves or others.
Quality falls out as a natural by-product.
This is best when the team feels that the standards are their OWN.
Imposed from within rather than from “above”.
Innovation is about “problem-solving health”.
Software development is an endeavor in innovation..... Not manufacturing.
To have a healthy problem-solving culture, it has to be “okay” to make mistakes.
Not every hypothesis will be correct.
It has to be okay to take risks.
Expend some resources to try something new.
If it works – great.
If not – make it a learning Experience.
What did it teach us? Did it uncover some principles we didn’t know before.
This is the scientific method. Prototyping is like designing an experiment to prove or disprove a hypothesis.
The goal of a prototype is to discover some knowledge that was previously unknown.
People need “personal safety” to innovate.
They have to feel comfortable that they will not be punished for experiments that fail or making honest mistakes.
Shield individuals from blame for honest mistakes. Don’t point fingers. Don’t name names. It’s the team’s mistake. The team will fix it.
Promote successes. Never take credit for a team member’s individual efforts or ideas. Make sure they get credit, even if you helped.
As a team lead, that’s your JOB.
We’re talking about honest mistakes here. Not negligence, nothing illegal, not long-term poor performance, etc.
People need time to innovate.
There has to be some slack time for experimentation.
People cannot be scheduled to 100%+ and innovate.
Innovation == improvement
Efficiency = productivity
It makes sense to talk about efficiency and productivity when you are building toasters.... Not when you are making decisions.
An organization that is totally focused on efficiency is optimizing for a steady-state.
An organization optimizing for a steady-state will never improve.
Projects in a steady-state are DEAD. Give people time to think.
Coordination is the right-hand of organization.
If you break things apart, you better be sure they go back together.
How do we make sure that individual work products integrate with one another?
Daily stand-ups are part of coordination.
Version control tools.
Best lead by example.
If things are going wrong, it’s your job to get them back on track.
Ideally, they will drive it.
Every organization has a methodology.
It is “how you do what you do”.
Some aspects will be explicitly and purposefully defined.
Others will be implicit and organically defined (i.e., that’s just how it’s done).
Adjusting your team’s methodology is how you tune COMIC and drive team health.
Methodology per project.
These are topics you CAN address in a defined methodology.
All of them are optional.
When you put something in a methodology, you are adding a control.
This limits the degrees of freedom available to the team to do their work.
What you choose to address depends largely on the fears you have.
What outcomes do you wish to avoid, and what controls do you add to ensure that those outcomes do not happen?
Alistair Cockburn Methodology per project
How do you evaluate your methodology?
More people you have, the more weight you need.
The more critical the project, the more weight you need.
Excessive methodology is COSTLY.
You want the methodology to be “BARELY SUFFICIENT”.
How much is enough is a moving target.
Everyone must be evaluating and adapting the methodology to the situation at hand.
Can’t discuss all this. Not enough time Everyone go home and read his essays.
Methodologies must suit the situation at hand.
Continuously adapt to optimize efficacy.
You want the lightest methodology possible that is still sufficient to drive success.
Too much methodology is costly and counter-productive.
**People** drive methodology
Get people to talk about their individual backgrounds...
How do they like to work...
What has worked for them in the past...
What didn’t work for them in the past...
What are we REQUIRED to do