Shane's full question: Good day this is Shane Hastie with InfoQ, and we are here at the Agile 2014 conference talking to Linda Cook. Linda is the treasurer of the Agile Alliance. Linda welcome, thank you for coming along. You and I know each other pretty well but I am sure there are quite a few in the audience that haven’t met you yet, so would you mind briefly introducing yourself?
Hello Shane, thank you very much for inviting me to come and chat with you, here for InfoQ. It’s an exciting opportunity to talk a little bit about some of the things that I am passionate about, and as you said, while we know each other quite well, I will do a little bit of intro, for the sake of our audience. So one of my duties is that I serve on the Agile Alliance Board, as the treasurer, it’s a role that I’ve had for the past two years, and I truly enjoy the role because it does give me a very direct view of how we are doing financially, and then with that how well can we do for all of our members, properly using the funds for programs and things to further the Agile Alliance goals. So I really do enjoy that role and except some times some of these big expenses we have, I think some folks would be surprised to learn the cost of holding one of the best conferences in our industry does come in at quite a price, and I am happy to say that I am a part of the Alliance to help make that happen. I take care of that duty.
I would like to Shane, thanks. Truly as you know, some of the goals we have been working on are goals that we’ve had for some time, and it’s been our strategic objective to really broaden our reach better into the international community. And we’ve been talking for the last couple of years, so how do we select that right target market? Who is really interested in developing partnership agreements and where could we make some moves to that end. And along with one of our fellows board members Samuel Crescencio, Samuel made a proposal to us that we engage with the Brazilian Agile Community for the purposes of setting up a cooperation agreement, and I am very happy to say that this Sunday the Agile Alliance Brazil board members were able to join us here at the conference and we officially penned the agreement for our cooperation between Agile Alliance – I believe we are going to call ourselves Agile Alliance Global perhaps - with the Agile Alliance Brazil community. And our first major activity with Agile Alliance Brazil is providing them support and engagement for the Agile Brazil conference that will be held this year in Florianopolis from November 5th to November 7th.
Shane: Great so the Alliance is moving out of North America and into other communities around the world.
Yes and as you know Shane, we do make it a point that we try to visit communities outside North America at least once a year, and it seams as though the time we’ve spent in Brazil in the prior year was really very beneficial and I think was a key aspect leading to this cooperation agreement that we’ve formed.
Shane's full question: One of the things that I know that you’ve been doing and are very experienced at, more so than many many people in our community, is being with very large programs at work and one area in particular we were chatting about is the release planning in the large, at sort of the enterprise level, do you want to tell us some of the stuff you’ve been doing there and makes this difficult and what makes it successful.
Sure, I’d love to. And to your point I have been involved in large scale development really throughout my career; it’s been one of the true advantages of the work that I have been able to do, and work with lots of people and to that have a nice variety of experiences and one of the challenges we’ve experienced in the Agile Community and a lot of people talk about how are we dealing with problems in the large, what happens when we get to enterprise? Over the last several years I’ve worked on various practices and processes and looked at ways to transition enterprises from some of the more traditional approaches into more Agile approaches. One of the interesting things that I have experienced is that even in large, and what we would describe as very mature organizations, they very often don’t have effective planning methods once you get beyond something near term.
I often get into organizations and find out yes indeed there is a roadmap that the executive put together and somewhere there is a chart of it someplace that no one seams to be able to find, unless they are on that number one activity the number one project tends to get a lot of attention. But other than that people really have a hard time referencing the roadmap and then beyond that managers who often do the work in their own office, doing what we would typically refer to as release planning. And they are working in their office they certainly are tapping into their knowledge, understanding the organization, perhaps even some of the context, but in my experience that’s been a rather lonely activity. So taking release planning and enterprise planning particularly and putting the Agile values behind it we start with individuals and interactions, over people and process. So one of the key things here is that when you are moving to enterprise release planning with an Agile spirit it’s important to know and to figure out how do you include everyone? And therein starts the first challenge.
4. How do you include everyone?
It’s a very good question and this is probably one of the first things that you have to consider and it’s quite different from any traditional PMO role you may have had whether it’s on the domain side of the house or the technical side of the house is that if you truly are going to involve everyone (and I’ll describe the size I am talking about a program that is going to require more than a hundred people let’s say). Most offices don’t have appropriate space to house any sort of gathering for a hundred people. So you are talking about probably going off site, and there is a good chance that you may not have anyone within your little tribe that actually has event planning experience. So I encourage people, when you are looking at large scale enterprise release planning first consider what do you need to do from an event planning perspective. And I will share with you that event planners typically have their hotels booked well in advance. So it’s a little difficult to call up and say “We kind of like to get together next week, we have about a hundred and fifty people, and we want to have breakfast, lunch, couple of breaks, nothing unusual, AV equipment, all that sort, could we do this on Tuesday?” and they are like “Would you be talking this year or next year?” So know that you’ll need to plan ahead, just for setting up the environment so you want to start with that.
Shane: So just that simple physical environment having the space, and yes I suppose that if you bring a hundred and fifty people together, there’s hotel rooms, transport and all of those sort of logistics.
Absolutely. And how far away is the hotel from your current location, how will people get there and truly often times in at least North American economy you are going to have multiple locations that people would be coming from. So you will be planning from their travel as well as hotel arrangements, that really just is a specific focus that you need to add to your planning toolkit, when you are planning these larger activities.
Sure so what we really optimally do is start with the executives, and truly get them to articulate the vision in a way that we can take that vision into a road mapping activity so we are truly going to start at the highest level of the organization, we wouldn’t include all of the staff at this point typically, because these are conversations where executives really do get in and decide some of the key aspects around features that are needed in the product whether you are enhancing an existing product or perhaps you are off designing a brand new product. They want to typically put some time box around the activities even if the product launch is perhaps as far as a year or out we find that that date happens somewhere in the executive suite and is passed around along with the program. So Agilists be aware we do still do fixed dates, and especially in a major capital project. So once you get with the executives, get the vision articulated well then you can do release planning.
Now in release planning we are going to start to include some folks in the organization who are domain experts because at this point you are probably want to talk about either how you are going to work on feature sets or overall align epics, and talk at really high level because you are still working with the executives at this point hopefully not doing much sizing just yet, but just really that first step, getting that roadmap put together and laid out, over your calendar and then once you get that pretty much aligned, then you’ll also want to make sure you’ve got some of your technical leadership available, and then start talking about how many teams and how much time might this take. Now still we are going to be backing into the plan as I said, you are going to have an end date; so then the real discussion starts engaging at a technical level you’ll probably have some architectural design to consider, whether it’s aligning with the current organization strategy, creating a new strategy for technology going forward, and with that really kind of cement the roadmap.
6. How would you share that roadmap or express that roadmap?
So being Agilists we definitely want to include the big visible charts and even if it takes a ream of paper that you’ve taped together you have the opportunity to use a plotter, go to your local office supply store, or use their plotter, and I personally have seen rooms literally plastered with plotter paper taped together, lining up all the lines in the roadmap and starting that communication. Because by now you’ve probably started to form some teams, you’ve got some early adopters in the project those are pretty much starting to establish frameworks, environments, just getting all the plant and equipment you need actually for any large size program. And you want to start making sure that they clearly have line of sight to that road map every day. So with that too, it is certainly helpful to have the executive conduct a no hands meeting, and just start that communication chain. Which should be the first of a very regular and visible communication from your executive leadership.
7. So now we have that roadmap up on the wall, what next?
So next is where the fun really starts, now you need to start to engage the teams, up to now we’ve worked at some level of leadership primarily maybe with a few key subject matter experts, but now we really need to get into release planning. My experience shows that release planning in the large really does require all staff even down to the administrative staff so that everyone gets an opportunity to hear the single message; you want to start with reinforcing the vision, sharing the roadmap again, and then what I find useful, if this is the first time your organization is really attempting this sort of activity, look at this first event as a learning experience. There needs to be a fair amount of training provided, chances are your organization is large enough you might already have experienced coaches on staff, if not you might want to find a few folks who have actually done this before. And engage those people as facilitators for your very first release planning.
For that release planning you want to organize your groups either by feature sets or domains, or streams of activity, whatever really aligns best with your organization, because now you are going to be talking about, we’ve got a room full of ten to twenty teams, they should be organized in groups of three to five, and then take them through the learning process of here is what to expect from release planning, here is how often we are going to expect to do it, we could actually set a calendar for a long range of that time, and lock in schedules, so that people will know when to expect this activity, you want to have some normal rhythm just as you want to have with sprints. I think this is one of the differences with Agile enterprise release planning is you want to establish a rhythm.
8. A cadence every six months, twelve months?
I think six months is probably too long, teams can tend to get off base, in the course of six months, probably something either in a range of no less than two months and no more than four. So somewhere in there is probably going to fit in a sweet spot with your sprint schedule. So if your sprints schedule is every two weeks, you could do one to cover let’s say four sprints, gives you an eight week calendar, or if you have three weeks sprints, then you might want to move to something that fits in better with that, perhaps a three months cycle that might actually work a little closer. But those are the type of things that your leadership team should be working out in advance. You don’t really want to launch off into your very first release planning that way. So in addition to doing training there is actually other activities that you should consider as part of your first event.
9. And what would some of those activities be?
So you remember we are now forming this larger organization, and even if teams have been together a while, this is an opportune moment to walk the team through some of the basic steps of developing their charter. And from an Agile perspective we want to make sure we are including things like working agreements. So you could set up working agreements simply for release planning and you can also take that conversation into those organized sets and let them also develop their working agreements as part of them establishing their charter. A lot of the information teams need to really set up their structure and organization should fit into a rather nice Agile charter; there is very good work by Diana Larsen and Ainsley Nies, their Lift-Off book is a great reference tool for that and I think that is also a good early activity.
10. So that would be done by the teams inside this all hands meeting, as part of the work?
If your organization isn’t accustomed to doing chartering why not take the advantage of training them all at one time, they may not complete their charter, but you can share a model for a charter, and give them some of the basic elements so that they know what they could do when they go off on their own I think you want to at least establish the working agreements for release planning and to walk them through that exercise if they have never done it. It can easily be done with a very large group it doesn’t need to take terribly long, perhaps twenty minutes. If you have a hundred and fifty people you could probably come to some pretty well accepted working agreements.
So hopefully there has been a leader whether it’s on the program side or the tech leadership side, that’s really already very familiar with the roadmap, you should have several of those people with each of the main subject areas that are on your roadmap. They are going to be the people that work now within groups. And you’ll set a cadence in this meeting, to allow them time to work in groups provide them plenty of wall space, and lots of our favorites stickies and sharpie pens, and let them start the conversation “Here is our piece on the roadmap, here is where we fit in” and talk about what our best approach is to actually setting this in a release. With that, the teams should have lots of conversation, this is an activity that might take a few hours the first time, now given that it should take an amount of time to do this you want to set regular checkpoints so that your coaches or facilitators can go around and actually visit with each of these groups, make sure they are actually making reasonable progress, help them redirect if needed, and look for opportunities for points that need to be shared.
Absolutely, so there is another key aspect that I am trying to reinforce with anyone that I talk to about Agile release planning, is that we want to address change management differently and we certainly want to address dependencies, better than maybe we’ve addressed before. Because this is part of how Agile helps you manage your risk profile I think a little better. Hopefully change management really just rolls into your release and sprint planning activities. So we want to set an expectation there and if indeed we are talking about major changes for scope, there are clearly opportunities where something might need to be passed up to your executives steering committees so to speak. So you want to set the framework in place for that, and most importantly set up a way for the teams to express dependencies. We like to call them as gives and gets, so I am going to get something from you, and I am going to give something to someone else.
And we tend to express dependencies that way, it can start up very nicely on paper you can use different colors to distinguish - a give could be yellow and a get could be blue perhaps, whatever your color likes are there. And the idea is to actually form enough information to really start your backlog. We are talking first time out, we are really building a backlog, we are talking features, functions, epic level, perhaps not the most detailed in the world, but where practical at least establish goals for what does it mean for this epic to be completed? How do we know when this feature set meets all of our done criteria? At the very highest level so that you are enabling teams to go off and do sprint planning, more independently. And we are starting to build that common understanding at release planning, which is very different in my experience anyway than more traditional models where the teams don’t get involved until they find out what they have to have done by next week.
Shane: Planning them to them rather than with them.
Absolutely.
Absolutely. This concept of definition of ready is one I picked up when doing Kanban years ago, and in establishing the various steps in any process, that it was something that you would do normally is set up of when is an item ready for this next step? And the nice thing about defining definition of ready, is that it immediately defines the definition of done, for the prior step. I like to use definition of ready and definition of done in release planning and with that you would send out to the planning team an example of how do you know when we are done release planning, and what do you need to bring to the meeting. So how do you know you are ready? And you are ready to start release planning when at least some of the principals understand the roadmap clearly enough to articulate it to others, to answer questions around vision, priorities, high level priorities, things of that nature, and by now you’ve probably wanted to pick your ALM tool if you don’t already have one, and I would just add one quick bit of advice in here: if you don’t already have an ALM tool, don’t be afraid to do this on paper for a couple of months before you actually embark and put all this information.
You can capture it in excel for now and it will hold you before you get to one of the ALM tools and the good news is that most of the key tools that are available today except the excel file as input so don’t be too concerned about that, but as part of the definition of ready, so you are making sure you have identified all of the necessary subjects matter experts, even if they won’t actually be project team members, these are the people that really have the expertise around and the vision for particularly when it’s a new product, you want to make sure those folks are readily available, and with that checked date so part of your definition of ready is to make sure all key participants are actually available when you are going to plan. So there is a lot more forethought and planning well in advance when you are talking about getting on executive’s schedules. We like to provide a short checklist for the definition of ready for the first time, because as I said earlier there is a lot of learning to be done there, so we are going to be laying the ground work for what’s the right level epic, and even then later talking about how do we size our epics, things like that.
This is one of the good choices you have to make, the choice is you can engage your third party vendors, you can engage your other partners, let’s say you might need a managed service organization to help you out with additional taking out parts of the work because you simply don’t have capacity. As Agilists we believe in individuals and interactions first, we would recommend you engage those folks. And there again that might take some preparatory meetings, so that they understand how we are working as a group, and that we are including them and start to form a real partnership. Because what you don’t want to do is set up the opportunity for blockers that are set up by folks who simply aren’t on your plan. They are not involved in stories, things of that nature.
15. How do we deal with that from a contracting and legal engagement perspective?
It’s a very good question. Well certainly if you are still in an RFI position at this point, and sometimes you might be when launching a very large program, you definitely start with non disclosures. And we set up, I think non-disclosures might be one of the better examples we have in our legal system of really Agile conversations. Because all we are really doing is agreeing that we are not going to disclose information to another party, that we are comfortable to speak openly in the room, and that the conversation pretty much adheres to Vegas roles at this point.
Shane: So safe space.
We are trying to create a safe environment, yet another one of our practices, is creating safety for everyone, handling the rest of the details with these large programs typically does involve your legal organization. You are going to want to give them a heads-up, to make sure that they are actually involved and that they establish their own risk profile and timeline for the various activities that need to be done to engage any vendor or otherwise third party software.
I am sure there are Agilists who absolutely cringe at the thought of governance. I can tell you I can definitely get a hair raising at the back of my neck, some times with some of the governance models that I have experienced. And the reality of it is when you are talking a major capital investment of a company as leadership we have a fiduciary responsibility to our organization to manage those funds. And we are also often in regulated industries. I spent a lot of my career in the financial services industry so I am very accustomed to compliance and regulatory things that simply need to be given their space. You simply be as Agile as you want but you can’t ignore the governance and the regulations that they put in place. So it’s also true, in my experience anyway, that in a very large organization they typically have an established PMO. And one of the things that I would say is an anti-pattern, is when some guy comes in and writes the name Agile across the door of the PMO and then declares them: we now have an Agile PMO. Should you find yourself in that situation, you have some good coaching available that help those folks transition because truly professional PMOs with certified PMPs have a certain way of working, Agilists differ from that work in some ways and there are lots of similarities. So it’s important that you are also educating the PMO because one way or another they are either they are your governance or they are even your direct partners, aligning as your Agile program managers. There is a lot of knowledge transfer that needs to happen there and to gain the confidence that working this way we will all achieve the goals of the team.
Shane: Linda, thank you very much for that, it’s an insight and a view of Agile that is a little bit different from what we see from a lot of the conversations, so really good to get this picture looking at the large organizations.
Thank you very much Shane for the opportunity to come and talk today. And really my purpose in coming here was to let folks know that Agile in the enterprise is being done, it’s being done well, yes it does have challenges and encourage others not to shy away from it, and to debunk that myth that Agile is for small teams. Agile can be done anywhere there is a willingness to go and the fortitude to get there.
Shane: Thanks a lot.
Thank you.