Chris, can I ask a question? Yes, of course, yes. Yep, stick around, sorry, Simon. So obviously you said towards the very end there that obviously Jira is about projects and not really for cross-project. No, what I said was out of the box Jira isn't very good at cross-project analysis or cross-project management. So if you, 'cause I think we're keen to do cross-project. I think some teams who've already, I think Duncan said at the start, some teams are already using Jira in our department. They're kind of using a, almost like a project, or a board as it were, for the whole team. So would you recommend that approach or would you recommend a project, a board for each project, or a board for the team?

Right, so I would recommend using a project as a project. So if it is the same project, then I definitely recommend doing that. Because when you start using separate projects as an organizational unit, it starts being a problem and you'll start having to copy issues from one project into another because they're atomic in terms of the projects. They don't mix with other projects very easily. You can link them, but they don't sort of mix very easily. And what you could do is you could use things like components, and you could have different teams, and you could separate teams by component and that often works better.

So that would be possibly the way to work, but if they are all part of the same project, you could potentially have, you can configure Jira to allow multiple sprints and just have one backlog. You don't want to have multiple backlogs for the same products. That's the key.

Okay, so keep projects as projects and not- That's right, and that gives you one backlog, and then one backlog is, means that you can then do, you can prioritize one backlog. And that's the only way, really, that you can manage, even if it's gonna have multiple teams working on it, you still want that one big backlog to be prioritized. So, yeah, even though it might be split amongst multiple scrum teams, you can keep them separate by using something like a component to separate them.

Okay, and so as you said then, so as you said, out of the box, so if I then wanted to, so say my team's working on four projects, I would like to see a overview of all those four projects, that would be that roll up boards that you said the administrator would need to set up. Is that right? Yes, that's right. So you could use a roll up board, but what you're doing is you're sort of, you're moving towards the edge then what Jira is good at. So although it does work, it starts kind of pushing the limit of what Jira is good at. And what I would say is that then you start wanting to look at advanced roadmaps and you're doing more of a portfolio management, and that's where the advanced roadmaps add-on to Jira might be something that you'd want to look at. And without using that, you might well find that using roll up boards isn't quite enough for what you want to do. It'll get you so far, but it won't take you all the way, and you might get frustrated with some of the limitations of it. Okay, something to have a play with. Something to have a play with, definitely, yes. Cheers, thanks very much. Okay, no problem.

And, Chris, just one more question from me. I have got the time management before, so the other thing I often get asked is, so I manage lots of different teams as a whole, I'm a senior manager here, and we often get questions about capacity. And obviously, if I need to grow the team, I need to demonstrate the levels we're working at, the capacity of the work coming in, and so it kind of really, it's (indistinct), so what we used to use was ActiveCollab. It was very simple. We assigned the work, you know, it's almost like the items, to an individual, and then maybe split the time between like 50% of their working day and this, that and the other. With my play through with Jira so far, which has been quite limited, I've not really seen a way of almost doing capacity.

So it's like, what I'd really like is to share, well, this is what the situation looks like for the next two months going forward, this is the levels we're working at. So if you give me a new project with a deadline which is in four weeks time, this will be the knock-on effect. Does Jira have anything like that, and if not, do you know anything that you could recommend?

So Jira doesn't, well, Jira can have something like that. So in Jira, you can make Jira do more of a project management, more of a sort of traditional project management approach. I mean, you can have things like Gantt charts, but you would need to add that sort of thing in, so a Gantt chart is an add-on into Jira. Jira is looking to get you to use it in, like as an Agile scrum method.

So really what that's looking to do is to say we are going to commit to delivering the highest value items in the backlog in the next two weeks and then we're gonna get your feedback from that. We are guaranteeing that we will deliver those things in two weeks and you don't care how we do it as long as we do it, and it's up to us to work out our own time because we're self-organizing. And so that's the perspective that they're coming at from Jira's point of view, and although you might want to do time management and they've sort of given you the ability to do it, almost reluctantly, so they have done it, but they also know that from the scrum perspective it would be the time management is the two weeks rather than the how long the subtask took.

So do you see what I mean? And so the capacity then is, the capacity planning in, say, scrum is the capacity of the development team saying, "We've lost one of our team members. How is that gonna affect how many story points we can deliver in the next sprint?" So that's how they view capacity. 

Okay, so in Jira, you don't necessarily queue up sprints one after another, so you couldn't have six months of two-week sprints laid out? No, because you don't know what the result of the next review is gonna be. The next review of your increment could change everything. Yeah, no, I appreciate that, it's just that I need to show at least six months work to my boss to show what's happening.

Right, yes, so what that means is that the scrum master, and it's a very difficult process because it's a transition to a different way of working, and it sort of takes time for the stakeholders and the other people within the business to sort of adapt, to kind of take on board the way scrum works, to take on board the benefits of it. So although they may not see six months of work, what they will get is the ability to change very, very rapidly what's being produced, and so the result is something that's much closer to what they actually wanted, rather than a prediction of six months work that some of which may not have been necessary or may not actually be needed when it's produced.

So it's a slightly different way of working and it's very difficult to get to that point, and so I know what you mean. I know what you mean when you say what you've got to produce, and it's almost like a, it's difficult to get to that point, isn't it? Where scrum is trying to produce one thing and what you need to produce is still some of what we would normally produce in a more traditional process. Yeah, but you can. I mean, that's why Jira have allowed you to do things like time tracking, but that in terms of traditional project management, where you're kind of Gantt charting the things that are gonna be delivered and when they're gonna be delivered and how long it's gonna take to deliver them, that isn't as easily there in Jira unless you kind of start adding other things into it. And you can get it there, but they don't necessarily want you to do it that way unless you really want to. Yeah, no, I can appreciate that completely.

Can I ask another stupid question, then? 'Cause I've worked in the university a long time now, so I've forgotten what it's like in the real world. If I went to a development house and said, "Right, I need this system building," and they are fully Agile, without sounding too stupid, does that mean they couldn't give me a time when I can expect the finished product, so to speak?

Well, the product would never be finished. See, if my boss was here now, he would fire you on the spot for that. Sorry, Chris, can I step in now? Couldn't that be kind of managed by saying although you're doing iterations after iterations and you're reviewing the product at intervals and various gates, there could be actually a fixed time that should be allocated to the project. So you have got a fixed time to produce the product, but how many iterations you go through to produce it within that time, can't that be something- Yeah, so you could have, you could have a fixed end there, you could say, "Right, we've got to deliver something by this date," but what you deliver is the thing that you negotiate. Yeah, okay. So you're basically paying for a certain amount of time and then the development team will say, well, we'll... Exactly, exactly, and then you do a sprint and you say, "Okay, well we've, what you're saying to us is the things at the top of the backlog are the most important things to go in next, and we can deliver these first three and so we will in the next sprint." And then you say, "So what do you want next?" Hmm, okay. By knowing what the end date is, then it's up to the powers that be, it's up to the stakeholders to make the decisions over what's gonna go in, and ultimately what is going to be delivered on that fixed date.

So you've got your story then, and you've got the values against all your stories, so whatever's at the bottom and is not actually achievable within the time limit is what's sacrificed, I guess, and the customer makes that choice. But they make that choice, so they say, "What is the most valuable thing at the top?" And so it's, the thing you're compromising is what gets delivered. You're not compromising quality. You're not compromising time because you're gonna deliver on that date. Yeah, no, that makes perfect sense, it's just our business is not geared up for that much though, is it? They want it all, you know, some people on the call will appreciate this.

I understand the whole, like, we do try and do the what's the priorities, what's the must-haves, what's the incentives, what's the nice-to-haves, but it's very difficult to get the business to agree to that because they just want it all. And the problem we have is nobody pays us money to deliver the product, so trying for this Agile environment while we've still got customers not moving over, it's gonna be hard doing that for me, I think, to work both ways.

I've worked in both and when it's the other way around, it's easy for the business to say, "We want everything by this date." And what happens is the quality is the thing that gets compromised. And what we're saying in scrum, in Agile, is then, "Well, we don't compromise on that." That makes sense because if you're delivering the top story with the highest value, that means you're actually concentrating on the work that actually adds the most value to the outcome, not- Yeah, and you always deliver at the same quality. But if somebody is trying to assess whether a project is worth even undertaking, you must have to be able to give them some idea of it's gonna take us three months or two years.

There has to be some level of working out how much work is involved before you even decide whether to go ahead with it or not. Yeah, and I suppose there's a- And I think you're point's good, but it feels like there's gotta be, you can't just completely say, "How much time have you got?" By that logic you could say, "Well, we need this new thing doing next month." You say, "That's cool, we'd have to hire 5,000 developers. We could do it next month." It doesn't really, you know. It's a feasibility side of it, you're quite right, but there's a shared vision, isn't there, between- That's right, so you would do release planning and you would say what goes into each of those, what's needed in each of those releases, but it's, I mean, things change and priorities change. And with the best will in the world, it's true that you might say, "We need to be able to say that we want all of this functionality by this date," but most of the time that doesn't happen. I mean, that isn't a situation that is usually successful anyway. That's what we do. (everyone laughing) When we do our (indistinct). But I think they'll fit in the perspective that you have all the people. If you had all the people who were involved in the project and understand with what they want, then you have technical people who can debunk business people who say they want this. The technical people will say, "Look, that's not feasible, or we would have to invest so much money." Those decisions could be made at the point where you're actually trying to discuss the stories and on the real requirements. You've gone quite a long way down the road then, haven't you? If you start there and you've got a large project, you might have hundreds of stories to create. Sure, but you can add that- Not feasible to do it. You can add that in waterfall, but at the same time you could be towards the end of the actual delivering the project when you realize that it doesn't actually deliver the outcomes or the environment has changed and the outcomes are not longer appropriate or of any value. Whereas when you're doing it at more smaller iterations, you can evaluate that quite regularly.

So therefore it comes back to that kind of phrase, fail quickly, yeah? So you know that it's not gonna work and you can it there and you save the institution loads of money. And that happens, that's happened, that happens a lot. And fail fast is, like you say, is another key part to this. And the ability to fail fast. I've worked on so many projects and that phrase, we know least about it at the beginning, most about it at the end. I mean, we've all been there, haven't we? We all kind of, if only we knew what we know now. I appreciate the benefit of those things.

If you took your car to the garage and said, "This car isn't working," and he said, "Okay, what I'm gonna do first is I'm gonna replace the exhaust pipe and that'll cost ya 800 quid. That might not be the problem." You wouldn't sort of sanction him to repair each little piece of the car and then it ends up costing you 10,000 pounds to fix the car because if you knew it was gonna be 10,000 pounds at the beginning you'd just buy a new car. You have to have some idea what's the total cost going to be before you embark on the project. You evaluate that as you go along, yeah? So you have an idea of what you're gonna spend, yeah? Which is your time and your resources.

But I think that's what Duncan's question is, how do you use Jira to evaluate that at the outset? You, in a situation like this, you have to just have a ballpark figure of how much time I'm willing to commit to this project, and then you learn from your development cycles, and how quick your developers are and the resources you have, how quickly you can actually get through those projects, and then you'd be able to estimate things better. But initially it will be, say, a project will come along and say, "I'm going to put a developer on that for six months and they're gonna produce it via this Agile methodology. They're gonna create iterations, consult with the product owner, and make sure that the outcome's better and that the most valued features will be delivered at the end of that period of time."

So the senior management who is looking after the thing saying, "What's your people doing?" Well, my developer is on this project and he's allocated for six months to do it, works. And if he can't deliver it in six months, then that's a different question, and then you have to see what's the value of adding more time to the project versus releasing the project or producing the application with less features, or perhaps it's missing critical features which means that it can't fill all of the outcomes.

So I was delivering something made further down, but that's no different than any other project that oversteps of its boundaries. Could be scope creep. Yeah. Interesting. Okay, it's gonna be a tough sell for my boss, but maybe I just tell him you can't get any more than the next few week's work off me. (laughs) Like I say, a lot of people do release planning and they will identify their releases. And you might do an initial analysis on how many sprints you think it will take to deliver that, but that is only ever a kind of a very, very high-level estimate, isn't it? It's always going to be superseded by what actually happens on the ground and what happens when people understand more about what it is that is being worked on and as more is discovered, like any project, yeah. Yeah, okay. I'm sure we'll find out whether it's gonna be a case of jumping in the deep end now and working out what works best for everybody.

Well, that's it, yeah. I mean, so what you find is a lot of organizations start, will kind of do a hybrid. And the hybrid can often mean that if you're doing scrum, the hybrid can often mean that the scrum bit doesn't work as effectively as it could, because the kind of, some of the things that you need to put in place to make the hybrid work reduce the empowerment and the self-organization and all of those other bits that are important in scrum, and it kind of can make the scrum process less effective.

So you always have to kind of take a decision as to what the impact is gonna be. So, yeah, so I definitely, 'cause you're gonna do more scrum training and that's definitely gonna help you, and then after that, that's probably a good point to choose how, which direction you're gonna go. Yeah, no, that sounds like a plan. We shall do that. Brilliant. Okay, thanks a lot, everyone. Thanks, Chris. Thank you very much, Chris. Thank you. Thanks, Chris. Take care, bye-bye. Enjoy your day, everybody. All right, adios, take care, bye.