Welcome Rachel. What are you up to these days?

I am coaching teams in what I would say is Generic Agile. Many teams that I work with are so interested in being Scrum, being XP and I am trying to work with them to expand their horizons and let them start thinking about what problem are we really trying to solve here, what are we really trying to do with our organization and our software development process and getting them to move away from just following an Agile method by the book.

What does Generic Agile look like?

Generic Agile, and I am not trying to trademark a term or anything, is basically I might be doing some Scrum practices or some XP practices or some DSDM practices that suit my situation, but I may have mixed in practices from other methods. For example, many XP teams use burn-down charts in retrospective from Scrum, and Scrum team often use user stories to describe items in their product backlog and velocity so that there's a general kind of mixing together of methods. And then it seems to me that teams don't really sometimes get the greatest benefit by applying everything, all in one goal, like this Big-Bang transition. You want people to be starting slowly trying things that are going to solve their top problems, I mean gradually introducing practices through reflection, through looking at what they are doing and trying to build on what their current practice are, allowing the teams to explore and add things and make suggestions: "I've heard there's a team over in the other building and they are using index cards. Can we use index cards?" rather than saying: "You must use index cards because it says so in the book" so trying to get people to explore, read more than one Agile method book, meet people at user groups and generally start discussing not how can we be more agile, but what are our current problems and how can we resolve them, and one of the options out there, what can we look to and try to do. One of the small experiments we can try in our team that we can then review and see if they really worked.

When teams think about working with Generic Agile are all the practices up for grabs, is everything optional?

What I would like is everything to be available for all the Agile practices to be open, to be used and to consider combining them but the things that's not optional is Agile is about delivering valuable software frequently, each rating on that, customer collaboration. So I wouldn't like to see those key elements lost. There are plenty of teams who would say: "Yes we do Scrum" and actually what they do is they do Sprint planning and daily Scrum meetings, but they don't do a lot of the other Scrum practices that would really make them more effective. But I would like to see them considering applying XP practices for example, mixing them together. I know a lot of teams that will for instance start off with basic Scrum, products back-logs, Sprint back-logs and then they start moving into more XP things, release planning, using stories to describe the things on their back-logs, they start thinking about acceptance tests, thinking about automated testings, so they are kind of moving into mixing their practices and they still might not be doing some Scrum practices. So what I am keen is that people try to work out not how can I be more agile, but how can I be more effective in delivering software and these different starting points depending on what your situation is. For example, I might recommend if a team had problems with software quality that they start with XP practices like test driven development and continuous integration, and then other teams they don't have issues with software quality but they really can't connect with their business owner so then maybe they need to work with user stories and trying to build up that relationship and doing regular showcases and demos to kind of draw their product owner in. So what I am trying to say is that there are many different starting points and there is also not a single place that you end up. What you have to do is to start by addressing your highest priority problem and then reflect on how that is going, start looking around what are the other Agile practices that I might weave in here, that might start solving my other problems. So you're trying to do and experimental approach and then reflect how it's working and then move forward with some new ideas.

What kind of mechanisms can a team use to tell if they are making progress on addressing their problems?

Retrospectives is a useful technique where the team can feel that they take ownership of their development process and they look at what they think it's working and what they think is not working. It's also a good way of framing experiments, so you can say: "Ok, I've heard continuous integration might be a good idea, so maybe next spring we'll put one of the stories on the board for getting that installed and try it out and then review how's that gone, should we try something else or is that not really working for us." So you are looking at people being able to affect the way that they work, maybe they see one of the other teams doing something; a real example, recently I worked with a team who they have a task board with all their tasks on the board and they make these little circles with the faces of the team and they put a face on the task that they are working on that day, so you can just go and look at the board and you can see what they are doing. And what I've noticed is that a team downstairs in the same building had started to do something similar, but they haven't use their real photographs, they have then used little cartoon magnets and they made little avatars for each member of the team and they are doing the same practice, but differently and nobody said: "We thing you ought to be doing that and it says in our process manual that you should do this", but they've just noticed it's useful to the other team and they started to think: "We could do that".

Does having teams interact, meet and pair notes, does that help?

I think having teams where they are in a situation where they can see each other, walk through their spaces can help, but also yes, having that opportunity to get together and discuss how do we apply Scrum in our teams or how do we apply test driven development, so if you are in a situation where you got multiple teams who are applying Agile techniques, you want them to be able to share what they think is working and that is usually not a retrospective, that's usually much more a kind of we're going to do a talk about how we do things. I worked with one organization recently and they all use Scrum, but they are working on different products; we had a meeting where they all came together and shared how they did their product back-logs and how they did the Sprint back-logs and then people go back and they try some idea. The other thing is if you can go and you can say: "Why don't you go to their stand-up meetings see what they do and maybe you can do something similar?", just having the possibility to talk to the other teams. Another thing that can be very useful to introduce is communities of practice. Often when you introduce Scrum to an organization you slice the teams up in a different way, so right before they had all the C++ programs sitting together and all the JavaScript programs sitting together and all the database programs sitting together, now you've split those groups up in these cross functional teams. But if they spread quite thinly you end up with the database guys not really having a chance to get together to share good practice and so what you can introduce is this kind of almost like a scrum of scrums by discipline, but a time where people can get together to kind of share: "Here is the latest on what we like to do.", because you miss that once you separate all these cross functional teams.

In some places a PMO is applying Agile process uniformly across an organization. Have you seen that?

Not exactly. I have seen top-down transitions where the leaders of teams said: "We want to go Agile" and encouraged the teams to adopt Agile methods and said: "Here is the Agile flavor we'd like you to adopt" and I certainly see local adaptations within teams, different levels of adoption in teams, some teams are enthusiastically: "Yes, let's do this" and other teams are kind of quite slowly hoping that this movement is going to go away, but I've noticed, and this is talking to the community of practice, one thing I noticed was when there was no opportunity for these people to talk they would start going to have breakfast together, so the teams that existed before they were mixed up in cross functional teams used to kind of find opportunities to still stay in contact. But not only that, that was very useful for them because that's when they would start talking about problems in their environment that they needed to resolve together. And what I've seen happening on a few organizations is they've started to have this kind of virtual teams or another name for them is orthogonal teams that have to meet because they've got common interests, and so in scaled-up, Scrum for example, we end up with kind of a scrum of scrums around that kind of project management and issues, but we also end up with scrum of scrums that are more specialized to do with discipline. So you might have a scrum of scrums of all the testers or a scrum of scrum of all the developers not in the same frequency and no to do really with where are we in the current Sprint or where in the current release, but much more to do with one of the common issues we're all facing.

When they have a common issue who do they get to help them address it, if it's beyond their own ability to address?

It very much depends on the organizational structure and if you kind of got a matrix management where you do have kind of discipline heads then maybe you are able to do that, otherwise you are going to try to influence your project managers to do something about it. Maybe there is a way to escalate it by gathering evidence, so often what I advise teams to do is if they believe there is a problem, they want to do something about it. They will not be able to get to buy in sometimes unless they gather the evidence so they can sell the problem. They can say: "Look, here is how much time we are wasting doing this. It's every time, so it has a cost, so therefore maybe we'll be able to get some funding to mitigate that."

For teams that are either adopting Agile or that are looking at changing their process, do you have some general recommendations?

Yes. What I would like to say is that if you are a team and you're adopting XP or Scrum or one of the other Agile methods don't get to hung up on following the practices exactly and try instead, take the time to look around, look around at other Agile methods, go to user groups, talk to people about what they are actually doing in their teams, go to conferences, listen to experience reports, try to get a sense of what are people actually doing that they find useful and try to leverage that and if you are in an organization with multiple teams then try to get some kind of forum for talking about what are we doing and how are we implementing this.

Here is a question on behalf of management: is the time "lost" meeting in these communities of practice, is it regained?

I think so, yes, because otherwise those teams are not able to really move their discipline forward and they are going to get bogged down with issues and that's going to go slower and slower, things are going to fall between the cracks, nobody is going to take ownership for the common platform that they share and for the common skills they share, and in the end they are not going to learn from each other, so you end up with individual specialists knowing about particular areas of their discipline, but that no spreading across, so you are losing out in that way.

When can people find you if they want to ask you more questions about this?

One place where I might meet people, this is in the UK though, is at the Extreme Tuesday club. This is an Agile user group, it's a good place to go and find other people and bounce concerns or worries of other Agile practitioners. So you are saying: "Hey, I am having this problem on my team" and you've got other people that might say: "You could try this or you could try that or this is what we did." So I'd encourage you to catch up with me, I'll be at the XP group in London, but I'd advise you to try to contact other Agile practitioners in your area by doing the same.