Creating Agile Programs Vendor Name: Rally Software Development Johanna Rothman, Owner Rothman Consulting Group, Inc. Johanna Rothman: Hi. I m Johanna Rothman, author of Manage It!: Your Guide to Modern, Pragmatic Project Management and Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects and upcoming Agile and Lean Program Management Collaborating Across the Organization. Creating Agile Programs: Scaling Agile Past One Team: The Nuts and Bolts In this video, I want to talk to you about creating agile programs, scaling agile as one team, the nuts and bolts. There are a few distinct issues I want to discuss in this particular video, the nuts and bolts certainly, but creating a cross functional teams, keeping iterations short, keeping planning short because that s really key because otherwise, you cannot get to everything you need to do in the iteration.
Nuts and Bolts of Creating Agile Programs Cross-functional teams are a must - What is a team? Keep iterations short Keep planning short Architecture is just-in-time Use continuous integration Teams are networks, not hierarchies Think small to go large 2 The fact that architecture has to be just in time which will scare all of you, architects and designers, that you must use continuous integration, the teams are networks and not hierarchies, and that you have to think small to go large. So let s take each of these one at a time. What is an Agile Team? An agile cross-functional team contains all the roles - Agile teams have generalizing specialists - Everyone is a developer Think 5-7 people - 3 people is too small (not enough roles to cover) - 9 people is too big (too many communication paths) But we don t have enough <testers, DBAs, UX/UI> whatever - The team decides what to do about that impediment - You don t fund the project - You don t have a team - You can have visitors for an iteration 3
When I talk about agile teams, I m talking about the cross functional team that contains all of the roles. Now, you want to think about agile teams having generalizing specialists. I often talk about everyone being a developer on a team, but that doesn t mean that everyone writes code that ships. I often talk about testers being developers and writers being developers, and UI people being developers. Everyone is a developer it s easy for me to say, everyone is a developer because everyone has a hand in making sure that this feature gets too done. So everyone is our product developer on the agile project. Cross-Functional Teams Finish Features You need to finish, done-done-done at the end of an iteration You need cross-functional teams to get to done You need communities of practice, also - People have to learn across the program - People have questions across the program - People need questions answered quickly Silo d teams cannot finish features - You never want to throw anything over a wall 4 So think about that when you think about the cross functional team. That s where everyone has a role in getting the product to done. That s why I want to think about and I want you to think about that the cross functional team contains all of the roles and that everyone has to be a generalizing specialist. We ve talked about T shaped people or cone shaped people that you might have one specific specialization, you re a developer, you might even be a platform developer or a database developer, but you can help with the rest of the specializations on the team because your job is to help move this particular feature across the board and get it to done. That s your job on the agile team. Now, when I think about what is an agile team, you can have 15 people on the team. That s not an agile team anymore. You want to think five to seven people. That s your sweet spot.
Now, can you have three people on the team? Well, I don t actually think so. I don t think that three people is big enough. You don t have you can't cover the number of roles on the team. Now, nine people is too big. That s too many communication paths. Can you have four people? I think that s kind of small. Can you have eight people? That s on the verge of too big. Five to seven people is the sweet spot. So I know I said that, I m going to say it again probably before we re done, but that s just about the right number. Can you have one person? Well, I don t actually know of one person project. Who will review your work? Who will test your work? If you re like me, you cannot see your own defects. So I don t know of a one person project. Can you work in time boxes? Of course. Can you get feedback? Of course. But excuse me but you need to have at least a couple of people on the team, and if you have a couple of people on the team, why don t you actually follow that to be the right number. So five to seven person is about the right number of people on the team and that covers the right number of roles. Now, a lot of people say to me, But we don t have enough of the testers. This is actually a really common statement. We often find that there are not enough database people or enough UX people. Well, if you re an agile team, the team decides what to do about that impediment but maybe you you don t think that you have enough influence to do about that impediment to work with that impediment. Well, you re not the people who fund the project, so maybe you have to kick that impediment upstairs. You don t really have a team but you can have visitors for an iteration. Maybe then say to the people who do fund the project, We need a visitor. We need a database person. We need a UX person. If you have this UX person visiting for an iteration, you need to make sure that that person actually stays with you for the entire iteration and gets that feature or set a feature to done. Now, the real issue is what happens after the iteration, because if you are like me, Murphy s Law comes to visit you on your project. And you don t need this person for just one iteration, you need this person for several iterations. So you need a commitment from this person to stick with you for several iterations. And that goes to managing the backlog. So you need to figure out what to do with this impediment over a longer period of time. But at least get this person assigned
to your project for the duration of the iteration. It s not a great alternative but it is an alternative, and we ll talk about some other alternatives later. Now, as a cross functional team, you need to finish features. This is key in a program, because if you cannot finish features, you have this dangling stuff, and that means that your team does not integrate it s features and the rest of the program is depending upon you. So you need to finish to get the don done done or done done done done done, however many dones you want at the end of the iteration. Anything you cannot get to done is actually a huge, huge problem so all of the cross functional teams need to get to done. Now, you re human, is it no problem if you don t get to done every so often? It s a problem. You need to admit it, and you need to say to people, We didn t get to done on this thing. It s OK, but you need to be very transparent about what you did and did not get to done. And you need to understand why you did not get to done. You need to understand what deliverable you did not get to done and what deliverables other people did not get to done excuse me. So this is why you need communities of practice across the organization. Why? It s because other people will have questions about what you got to done and what other people did or did not get to done. They ll have questions about work in progress. They ll have questions that just needed to be answered. How do you get this thing across this interface? Do we need an interface over here? How does the architecture evolve when we want to do this thing over here and this thing over here? Things will occur during iterations and the communities of practice will help you understand that. People have to learn software development. Software product development is a question of learning. It s not a question of manufacturing. Every single time you create another feature, you have learned more about your particular product. So software is an effort in learning. This is why it s so hard. This is why it can't be outsourced to the lowest common (bidder). If it could, we would, right? That s what people want to do. So, communities of practice are all about answering questions. They are about understanding where are the questions in the program, where are the questions and how do we answer them quickly. Now, the issue with cross functional teams is that they tend to have the answers. Silo d teams cannot finish features. If you have a silo d team of developers and then
another silo d team of testers, the silo d team of developers can't really finish features. They think they can finish but they can't really finish because how do you know how did they know if they re done? They can't finish anything until the testers give them feedback, right? So until you get the feedback that you re actually done with the feature, you can't know that you re done. So this is why you don t ever want to hear, We handed off the feature in an agile team. Anytime you hear the word handoff, that should raise a red flag. So if you are in an agile team and you say the word, handoff or you hear the word handoff, you want to know why are we saying handoff, what is it about in our agile team that makes it OK for us to say handoff, because that s our that s a red flag, that s an impediment. That will make it harder for you to actually finish things. So you want to think about that. That s going to make it harder for you to get to done and cross functional teams finish teams finish things certainly before the end of the iteration, and certainly at the end of the iteration. The Shorter the Iteration, the More You Will Finish It s tempting to think you can have a longer iteration in a program Shorter iterations force the teams to: - Integrate more often - Understand what done means across the program - Learn more quickly - Adapt more often - Obtain feedback Consider an iteration longer than two weeks with care Iterations are as long as you can throw work away 5 Now, the shorter the iteration, the more you will finish. And some of you are saying, The shorter the iteration? Sure, you re nuts. No, the shorter the iteration, the more you will finish, and here is why. The shorter the iteration, the more that will force you to make your stories smaller. The shorter and the smaller your stories, the more you actually produce. The longer
your stories, the more you tend to cycle and spiral in your stories and not finish anything. So it s very tempting to think that the bigger your program, the longer your iteration can be. No, this is very bad excuse me a very bad thinking. You want for the longer your program, the shorter you will want your iteration. And this is all to do with batch size. The smaller your batch size, the shorter you can make your iteration. Batch size refers to the size of your feature. So the shorter your iteration, the smaller your features can be. The shorter the smaller your features, the more you have the opportunity to integrate. If you have shorter iterations, that forces the team the teams, all of them, to integrate more often, to understand what done means across the program, to learn more quickly, to adapt more often and to obtain more feedback. Do you see how this sets up a positive feedback cycle of learning and you might even get to continue this integration across the entire program. You want to get to continuous integration across the entire program. And the bigger your program is, the harder this is. But you want to get there because this is how you will adapt more often and obtain more feedback. The faster you can see your program come together, the faster you can see your product come together, the faster you will get feedback on your entire product. This will help you understand, are we producing the product that we need for our customers? Now, the newer you are to agile, the harder this is going to be which is why I don t suggest that people start with agile on a big program. You want to start with agile on a small project in the small team. But if you are starting with agile on a program, you want to keep your team small, low as five to seven people, you want to keep your iterations short, you want to keep your batch size small, very small stories that you can do with the short iteration. Because if you have a really long iteration like more than two weeks, you might have to throw the contents of that iteration away. Have you ever done something where you thought you were doing exactly what somebody wanted and you gave it to them and they said, This is what I asked for, but it s not what I need? That s exactly what happens on an agile program. But what you want to do is catch that right away and if you do this in an iteration of two weeks instead of an iteration of four weeks, you only have to throw two weeks away. So think about it, you have a program of three teams, call it six people in a team because my public arithmetic is not so high.
If you have three teams of six people on the team, that s 18 people. If they ve only been working for two weeks, that s two weeks times 18 people. You do the math because I m not going to. If you have to throw two weeks of iteration away times 18 people, that s a lot of person hours. Imagine if you had to double that for four weeks. That s even more of person hours. So if you are thinking of doing four week iterations on just a threeteam program, think again, this could be very serious if you have to throw a fourweek iteration away. Don t do it, just don t do it. This is why you need very short iterations on a program, because you will have to throw a work away. You will you will get to the end of the iteration, the product owner will say, I know I asked you for this. This particular feature, not what I wanted. Look at how it looks. It just doesn t work right. And, you know, I ll say, You couldn t figure it out in advance? And the product owner will say, No, I could not figure it out in advance. And if you re lucky, it s not the only thing you did in that iteration. But if you re unlucky, if Murphy's Law sits on your project or your program, it will be a very big thing you did in that iteration. So don t have long iterations. Short Planning Horizons Roadmaps for releases - Allow you to anticipate Iteration planning allow you to plan enough for now and coordinate among teams 6 Now, the other thing you want to think about is short planning horizons. You want roadmaps for releases where you have a quarter and a quarter and a quarter and a quarter. I live four or five or even six quarters on the roadmap because you want to be able to think of releases on a roadmap, you want to anticipate on a roadmap.
You re going to change that roadmap as soon as you have that first iteration or two and you and the product owner can see what your team can do because once you get into the swing of this, you re going to be able to put out features, you re going to be like no team you ve ever seen, you re going to hit into the rhythm, you re going to be fabulous. Run until you get into the rhythm, you re going to say, What the heck is going on? So you really want roadmaps for releases. On the other hand, you need to do enough iteration planning for now so that you can coordinate what you do for your team and among the teams. So you don t want to have to do a lot of iteration planning. If you are doing more than an hour or two of iteration planning for your team and any of the other teams are doing more than an hour or two of iteration planning, you re doing way too much iteration planning, right? And an hour or two of iteration planning for two weeks is efficient. Are you doing four hours of iteration planning for a two week iteration? You re doing too much. You re trying to over plan what you re doing. So really think about how much iteration planning. Are you doing planning for your iteration that belongs in the roadmap? I see this all the time. So think pretty hard about how much planning you do for which horizon, right? Think about that. And don t over plan. Plan just enough for now. It s easy for me to say, isn t it? I m not on your program.
Allow Architecture to Evolve You might start with a general idea of an architecture. Do not be wedded to it Embed architects on feature teams As you finish features, update the picture of the architecture - Refactor the code each iteration - Refactor the picture each iteration As the architecture becomes more solid, you know what works with the architecture and what s not working 7 Now, we like to think about architecture in our business. And I I am challenging you to let the architecture evolve. I am not suggesting that you just let the architecture fall on the floor far from it. I think you need to nurture the architecture and your architects should be responsible for the business value of the architecture. Now, I think that you need to have a general idea of the architectures, certainly to start, but don t be wedded to it. This business of, we can start with the architecture and know where this is going to be from the very beginning, I wish I had ever seen a system that s stayed with the with the specifics of the architecture. I would be rich if I had ever seen that. Because every single complex system I ve ever seen in a program is a very complex system. It has changed the architecture as it as it moved along and developed, so start with the general idea of the architecture, just don t be married to it. And embed architects on feature teams. Architects need to see how the code evolves. They need to see the problems that the feature teams see and live with every single day. Don t let the architects live in an ivory tower. That s the worst possible thing that you can do. As you finish the features, update the picture of the architecture. One of the things that I really like to do is have a picture of the architecture as a deliverable at the end of every iteration. And this is why the architects need to be on the community need to have their own community of practice. They need to say, You know, my feature team was really struggling with this part of the architecture, this iteration.
What we ll be going to do about that? We cannot leave my feature team in the dust. What do we do? How do we smooth out this part of the architecture to make it easier for them? Now, this might mean refactoring to patterns. It might mean designing the patterns. I m not sure what it means for your program. But the architects need to be thinking about the architecture. The architects might need to be spiking the architecture by experimenting with the spike during the iterations, but the architects should be very busy working on features and working on the architecture. So the architects and the feature teams need to be refactoring the code. The architects need to be refactoring the picture every single iteration. The architecture is a living breathing document as a picture. And as you continue to implement the code, the code evolves, the architecture revolves. As the architecture becomes more solid, you need to work with the architecture and see what s working and what s not working. And the architects have to be working with the teams. Any architect who is not working with the teams is not working on what s actually in the product. I m not sure what the business value of that architect is. Never mind the business value of that architecture. So the best architects work with the teams. They live with the teams. They understand the pain that the teams are going through. Make sure that they understand what you re going through so that you you can get the best value out of them.
Typical Three-Tier Architecture, Implementing By Feature 8 Now, here s the typical three tier architecture implementing by feature. You can see that the red and the green and the blue lines are all happened to be on the left side of this particular picture. And you can see that there is the GUI on the top and there is a thin API. That separates the GUI from the actual rest of the system. It is very tempting to put business objects and business information in the GUI. Don t do that because it makes it so much harder to test. When you have an API layer just underneath the GUI, you can have automated testing underneath the GUI. This makes it much easier to develop, automated tests that are at the system level underneath the GUI. Now, what s interesting about this picture is that if it happens, that your product owner wants you to implement all kinds of things on the left side of your architecture and nothing on the right side of the architecture, you don t need to implement anything on the right side of the architecture. The computer doesn t care, it just doesn t care. It will be fine if you don t implement anything on the right side of the architecture. You can keep updating the picture of the architecture. You know, every so often the product owner might say, OK, that s enough on the left side. Now, we have to implement features on the right side. And so that s fine. You ll implement features on the right side. But if your product owner doesn t care about any features on the right side for a year, don t implement that middleware layer component 3. Don t implement that app layer 4. Just don t do it. You don t need it.
Now, this is what we mean by agile implementation. If you don t need it yet, don t implement it. You implement through the architecture, not across the architecture. And if you do this, first of all, you don t have a lot of ways to code that just sits there gathering defects. You just implement what you need. It s fine. And a lot of architects, this really bothers them. Whether it s incomplete, yes, it s fine, it s incomplete. So write a note, write a comment in the code that says, We haven't implemented this other stuff yet. It should, go see this picture. It s fine because the computer doesn t care if it s not symmetric. Only the people care if it s not symmetric. It just doesn t matter to the computer because no one ever calls that code. Continuous Integration Each team continuously integrates each feature - Assume each team knows how The entire program continuously integrates across the program - You might need the help of a release/deployment team for a very large program 9 Now, I m a huge fan of continuous integration. I have yet to meet a project that did not benefit from continuous integration. But I have not met yet met your project, so maybe your project would not benefit from continuous integration. But on the program, I got to tell you, I really like continuous integration. When you integrate everything all the time, right, that means you write a little code, you test it. You write you take down all the changes that have happened today. You test your code against the changes that have happened today and then you put your code back into the main line.
And that means that any code that you have done today, you ve tested it against, you put your code back up, you ve integrated it. Only a couple of hours worth of changes and you have continuous integration. I really like continuous integration. Not a lot of integration at the end, not a lot not a day or two of day or two of changes and certainly not months worth of changes. It s a lot easier to find problems when you only have an hour or two worth of changes. Now, in the big program, do you need help the continuous integration? You might need help with the continuous integration. You might need people to help you, all team on a really large program. But if each team continuously integrates their features and assume that each team knows how then you have a lot less work at the end. Now, I really like it when the entire program continuously integrates. This means you don t have a whole raft of changes at the end of the program and you don t have a whole raft of changes at the end of the iteration trying to shuff everything into the integration at the end of the iteration. That just is a disaster when it happen. So see if you can approach continuous integration at the very beginning of your program. It really works if you can do it. Teams are Networks, Not Hierarchies Small world network - Six degrees of separation Communities of practice 10 Now, I really like thinking about teams of networks, not hierarchies. If you have if you think about the small world network, this is this is again, how many degrees
of separation than you are from Kevin Bacon? Best is six degrees of separation business. This really helps you think about how can we get the people on the program to help each other, not having to go through their scrum masters, not having to go through their agile project managers, not having to go through their managers for help. A Possible Organization for a Technical Program Team 11 This is how you go communities of practice. And I believe I have a picture well, I guess I don t have a picture there. But this is a possible organization for a technical program team. If you look at this picture, there is there are several feature teams and then there are possible communities of practice.
What a Technical Program Might Look Like 12 So the architects might have communities of practice. The product owners might have communities of practice. The testers might have communities of practice. And you want to really think about who do you need to have communities of practice for. You need to have people, anyone who needs to talk to each other, who needs to have questions get answered. Those people need to have communities of practice. Here is what small world network might look like for a community for communities of practice. Boy, it s easy for me to say that today. And you can see that some of these might have highly connected teams. And some teams are not so highly connected. Now, the teams only the left are not very highly connected. Those two teams on the very left only have a couple of connections between them. But the teams on the upper right have lots of connections. And this is what happens, think about your network whether you re thinking about your LinkedIn network or thinking about people that you know through your various communities. Some people have lots of connections, right? I have lots of connections in my LinkedIn network. And some of you I bet have not as many, maybe only a few, and the reasons for that are varied. But if you think about people who are highly connected, you can go to them for a question and they might not have the answer but they know who to ask. So those teams on the upper right, they either know the answer to the question or they know who to ask. The teams on the upper left who only have a couple of
connections, they might be the people with the answers. They might not know who to ask but they might be the answer people. So you don t have to have all the answers but you have to know who to ask. And this is the key with self organizing teams. You want to have people who are connectors, you want to have people with the answers and you want to have people who know who knows the answer to that question. This is why you want to think about the small world network. You want to really think about this. Because the small world network is a self organizing network, you don t have to depend on the hierarchy to get the answer. So the small world network is a much better way to organize than any kind of, I have to go up to the organization and down to get an answer. Here, I go across, and people with the answer will answer. This is this is a way that works, so you want to think about that. Think Small to Go Big Large programs are not linear scales of small projects - Short iterations - Continuous integration - Small stories - Keep planning short If you have not been successful on a small agile project, practice small first 13 So you want to think really small to go big for programs. Remember that large programs are not linear scales of small projects. Any time you have a small project, right, there are there are three kinds of large programs. There is the one to three teams, there is the four to nine teams, and then there is nine and larger. So you want to really think about what kind of a program do I have? But regardless of the kind of program I have, I had to think about short iterations. I have to think about how am I going to get to continuous integration. I have to think
about my small stories because small stories will keep my batch size small, and I want to keep my planning short so I have time in the iteration to keep to get as many features as I can done. And a note of caution, if you have not been successful on a small agile project, practice small projects first. Thank you. Thank you Questions? 14 END