If you are thinking of agile as part of a program, each team has to have its own approach to agile. Why? Because each team has its own risks and problems. You don’t need to standardize agile for anyone. If you treat people as if they are adults and explain the principles that you want (working software all the time and expose the interdependencies), provide training or whatever other resources they need, you are likely to get what you want.
That’s why I wrote Design Your Agile Project, Part 1 for teams who are collocated, and can use any approach to agile. Design Your Agile Project, Part 2 is for teams who have many challenges, but are collocated, and can work through those challenges. Design Your Agile Project, Part 3 is for teams who are geographically distributed and have to think about what to do.
In the program, what you need is for each team to deliver, all the time. The program wants as close to continuous delivery as possible. You can reduce the interdependencies—or plan for them. You can certainly expose them.
Feedback is Necessary
Did you see Jason Yip’s tweet (@jchyip) the other day, where he quoted this, “”Large organizations…lose their resilience simply because the feedback mechanisms…have too many layers of delay and distortion.”
This is why you cannot standardize on anything for any team in a program. Why? A program needs resilience. It needs to be able to release early and often. Just because it’s a program does not mean it does not need to be able to obtain feedback.
Each team must know the principles:
- You need to see all the work in progress.
- You want to flow work through the entire team.
- You want to see working software, sooner, rather than later.
Teams use agile and lean principles. Management treats the people on the teams as if they are adults. The teams look at their own issues and design their own approach to agile/lean, always keeping in mind the idea that they need to deliver early and often.
Now, let’s talk about what happens when you want to meld these teams into a program.
Each Team is the Heart of the Program
You might think that things roll down from the program manager or the core team. Not in my world. This is where each team’s autonomy, each team’s ability to make its own decisions about how it implements its approach to agile or lean is key.
The teams are the heart of the program. All of the teams: the core team, the technical teams, the teams that the core team represents.
This is a change from traditional process thinking. It’s a change from traditional program management thinking. This kind of thinking requires that the teams know how to do agile already, and are new to the program, not to agile. This kind of thinking also means that the program manager is a servant leader.
In a program, you will have interdependencies. You want to minimize them. How do you do that? By reducing batch size, the size of each feature. By coordinating the features with a program roadmap. And, by looking at the value of each feature, not its cost (estimate).
That means the teams need to become good at delivering, not estimating. It also means the product owners need to become very good at creating ranked backlogs for the teams, and changing them. It means that the program needs a roadmap that can and does change.
Remember, agile is about the ability to change, because the teams get to done at regular intervals, whether those intervals are iterations or because the teams work in flow.
What If the Teams are New to Agile?
What if you want to have a program with teams that are new to agile or lean? You can do anything on your program. You need to assess your risks. Let’s look at the Cynefin framework to see where your risks might place you, if your teams are new to agile.
If your teams are new to agile, and they are all in one physical location, and they know the domain of the product under development, i.e. you are only changing how they are developing, maybe you are just in the Complex part of the framework. You are changing the culture of the program.
However, if you have new-to-agile teams, who don’t know the product domain, who are geographically distributed or dispersed from one another, and you want to transition to agile, do you see that you might be in the Chaotic part of the framework? That you have no way of knowing the risks?
That is much more difficult.
Let me provide you an example. Imagine that you are working with developers in Europe who have a 15-person development team. They have only programmers on their team. They have never worked with testers. Why? They have never seen the need to do so. They have been successful, according to them, up until now.
You are in New York, where the product management is. You know the product domain. The developers? Well, maybe not so much.
Several years ago, I consulted to a company that had this precise organization. They were going to “revolutionize aerospace.” Only the product managers understood the aerospace information. The developers had no domain expertise and they were several timezones away. The developers had worked together before, but had never worked with testers. They had never seen the need. They had never worked on a regulated product before.
When I suggested they had “unknowable unknowns,” and that their risks were higher than they thought they had, the senior management laughed at me. I told them yes, agile was fine, but I thought they should use one- or two-week iterations with kanban boards to expose their bottlenecks.
They ignored my advice. The company went with four-week iterations, spent a pile of money, had no product to show after 18 months. Oh, the developers bandied words such as “refactoring” and “TDD” and “BDD.” What they did was BDUF (Big Design Up Front) because they had no idea what they were doing. The company went under.
What do you do when not everyone knows what “agile” is, when you create a new product, when you are introducing that much cultural change?
Don’t panic! You work in ways to reduce your risk.
Stay tuned for Part 5.
April 21, 2014 01:16 PM
I gave a talk at Agile Coaches Exchange meet up yesterday and someone emailed afterwards saying
"Rachel mentioned about few questions that she uses during one on one. Those set of questions could help me a lot because I am terrible to start and flow the conversation with my team."
So I thought it might be handy to do a quick write-up of what questions I tend use in individual coaching sessions.
Well just to be clear, I don’t follow an exact format or set list of questions -- I’ve been coaching for so long that questions seem to come burbling out of my mouth without much premeditation or forethought. Here's what I think I ask but this might actually differ a lot depending on the person or current issues.
Before we head off to our meeting, I check “Is now a good time for you?” and I’m fine to move to another time or skip the meeting. Coaching is always optional.
Once we sit down, I tend to start with open questions like:
- “How are you doing?”
- “Are things going well at the moment?”
- “Are there any issues you want to discuss?”
This tends to open out topic areas that we kick around -- discussing root causes , trying to see events from other perspectives and identifying possible courses of action.
I also look back in my notebook to see whether we talked about any specific issues at our last meeting:
- “Last time we discussed pair rotation in your team, is that working better now?” or
- “You facilitated a retrospective for the ABC team last week, how do you think that went?”
If they led a meeting, I ask if they’d like any feedback from me.
I might also mention current events such as team or process changes:
- "We have a new developer joining your team next week, have you thought about how she's going to get to know the system?"
- "We've changed the story time meeting format to run it with both teams together, how do you think that's working out?"
If the conversation dries up then we move onto specific areas such as personal development:
- “What research projects/Gold Cards have you been working on lately?”
- “Got any plans to give a lightning talk about that next week?”
- “You mentioned that you were planning to submit for XYZ conference, have you sketched out an abstract?”
I usually check at the end “Are there any other things you wanted to discuss?” and let them know that I’m around to discuss further any time.
There are no magic words or special incantations that I’m aware of. The main thing is to focus on what the other person has to say and try to listen carefully to what they’re experiencing and changes they wish for. I care about whether they’re happy at work and hope that talking will help them stop worrying about things that are holding them back and start acting on their concerns and ideas.
April 17, 2014 09:45 AM
Sometimes people get confused about velocity and edge cases of what gets counted or not. It doesn't matter greatly except it helps to do this consistently over time. I wrote a FAQ for our teams because these edge cases come up infrequently and developers often don't remember what rule to apply. I'm sharing a slightly abbreviated version of our Velocity FAQ as an illustration of working agreements around this. Your team might choose to do this differently and that's okay.
The purpose of this FAQ is to clear up any confusion about counting team velocity before story prioritisation. We average our velocity over past 3 iterations to level things out. Also we make adjustments if we know that team members will be on holiday during the next iteration.
1) Should I partially count a story if we did some work on it but it hasn’t been finished? No
2) Should I count a story if the code is all live but we haven’t had the story approved by stakeholders or sent out the release email? No because sometimes more work is discovered through doing this.
3) If we extended or shortened the iteration should I adjust the velocity to match the usual iteration length? Yes.
4) If the story was signed off and complete and then later we discover it has problems, Should we add another story for the extra work to fix it? No. If the implementation has a bug or we broke or clearly failed to deliver on the story we will fix it without an additional story, even if it was accidentally signed off.
5) My stakeholder says that she really wanted something extra than the story we’ve developed. Do we expand the story to do the extra things? No, this can be a new story if wasn’t agreed with other stakeholders. It helps to note the acceptance criteria clearly in the story and check them with stakeholders before starting work on development.
6) We had to do some story work in an iteration that wasn't planned in because the story was not finished from a previous iteration (due to any reason including dependency on other team). What do we do?
Step 1: Send stakeholder email or let them know in planning that this is happening and may impact stories currently lined up for current iteration.
Step 2: Fix the problem and then count the full estimate of the original story when its finished in the current iteration
Do not create an extra story for the remainder of the work and estimate it as extra work as this will result in artificially inflating the velocity.
7) We did an extra piece of work it took about 2 points worth, it was never planned in or estimated can I count it now because we did do it?
No. New pieces of work even if they come up mid-iteration, even if they are ultra urgent and should be done immediately should always be discussed, broken down and estimated BEFORE we start work on it. We need to warn stakeholders we are putting it in. So this situation should never ever arise that you only estimate a story after you completed it! If it does happen you should not count it. and discuss what went wrong in the process.
April 09, 2014 11:41 AM
I am happy to announce that Manage Your Job Search is available on all platforms: electronic and print. And, you get the presents!
For one week, I am running a series of special conference calls to promote the book. Take a look at my celebration page.
I also have special pricing on Hiring Geeks That Fit as a bundle at the Pragmatic Bookshelf, leanpub, and on Amazon. Why? Because you might want to know how great managers hire.
Please do join me on the conference calls. They’ll be short, sweet, and a ton of fun.
April 09, 2014 11:28 AM