 Ie, dylai. Fi'n가요 i'n gweithio gyda ni'n cael am yr eich cyffredin iawn. Mae'n fuddwch chi'n grannu. Rydyn ni'n ddynch i'n ddpanpeidwyd ac amroeddiadu cyfleon hwn i unipro. Dyna'r eich cyffredin iawn o'r oedd o'r ffluodol mewn rhain o'r holl, oedd o'r camau gan gobiadu chi'n g seamless. Mae'n ddim amser mwyaf o'r nghyrchu dda ni, hynny i'r cymdeiligau chi arno a oedd yn ffliweddo'iım o'r ddod o fflusiol, may be time for a few questions or maybe not now because we've had tech issues. So, I'm not here to talk about an unusual situation, an unusual situation would be for a fully mature team operating on a single product from the same space with well established communication methods and execution methods as well. More realistically you might be joining a team, or you might be onboarding a new team member or even generating a new team in a greenfield environment across different countries and across different languages. You might have difficulty with your laptop or somebody else's laptop, which I'm having. You might have time zones of an hour or even 10 hours apart. Don't even get me started on time zones that start with a half hour. You might have seniors and juniors who need aligning and onboarding despite client commitments, and you might very well be dealing with people who have varying of familiarity with agile processes as pertain to your company, or to your project, or to your client. And given that these are people not machines, they will also have varying levels of productivity, accuracy, commitment and knowledge from each other that you'll need to factor in. The programme I'll be talking about over the next few minutes has some 40 developers and QA, six scrum masters and six product managers from Unipro, a dozen UX and design staff and six product owners from the client side or from other agencies. We've got up at eight of those other agencies contributing data, insights, code, content, messaging a strategy at any one time, and all the usual hangers on, like programme managers and client services and delivery directors whose role has frankly never been made particularly clear. All these people are ostensibly working towards the same aim and in roughly the same fashion, and all those agencies are also trying to stay profitable with an eye on contract renewal, which can easily get in the way of the programme's actual aims. So I'm going to talk for a little bit today about some of the things that we find work well, some of the things that we could keep doing better and I hope this will give you an insight into building scalable teams using scalable processes. Okay, who's Unipro? Well, we had our 20-year anniversary just a couple of weeks ago. That was celebrated in all five of our locations across the world. We've mainly come from a systems integration and database background and what we really do is build websites that deliver to our client goals. Standard. We're a development partner to global organisations and we have little or no design or UX function as you've probably realised by the low production values on my deck. There's about 110 people in the company and the programme I'm talking about today touches over half of them in some capacity. It's split into eight streams, including a separate stream for rollout. You're not supposed to be able to read this, don't worry about it. That means eight Scrum teams, most of which have their own Scrum master. The client stands up the product owner and we stand up the Scrum master, the product manager, the developers and the QA. A partner agency provides the UX and the designers. All resource is ring ffans across the Scrum team and allocated several sprints in advance via the quarterly sprint planning process. So resource is one thing that people don't tend to have to worry about, which is quite refreshing. This visualisation shows data usage across the globe over a 24-hour period for those who are interested. Unipro have worked very hard and frankly missed out on a lot of profit by keeping all the developers in one room as much as possible. We started with one office in Chichester. Hang on, there's an animation. Now we have three in Chichester, two in London, one in Australia and a wholly-owned testing facility in Mauritius. So everyone in the room has probably experienced issues with having clients and Scrum masters in one country and developers in another. In our Scrum environments, the benefits of being in the same room for stand-ups, collaboration, ceremonies and execution are really obvious for us all to see. Each of our Scrum teams have their own room with the Scrum master and product manager in it and the developers in the same room too. They all have their own virtual conference setup for communicating with the client, ceremonies, other agencies and testing and they will have their own permanent whiteboards and walls for their planning and their reference. The client also has their own room in our Chichester office and they're invited to physically attend all appropriate ceremonies and releases so they can be on-site for QA and UAT. Co-location is obviously very agile for developers and designers. They can sit together and nut things out but only if they're given the authority to do so by the client and the programme. Lean UX actually has a chance of working if you put people in the same room and we all know that the agile manifesto encourages more face-to-face working methods. All that being said, what's bad about co-location? We put one of our Scrum teams, the mobile team, into a partner agency, the UX and design agency because we felt that the mobile team would benefit a lot from having always on access to a design team for that. It was true to a point but we learned we're still two teams and two agencies and it became hard to remember this when we were guests in someone else's house. There were never enough meeting rooms and although the designers and developers sat on the same pod, they didn't work together enough at the same desk regular enough for us to feel a benefit. Meetings became unfocused and basic Scrum principles were forgotten. The Scrum Masters Authority was undermined and a lot of people became a bit sloped shoulder about their responsibilities. We had to step in and do a full Scrum research. The situation we discovered at that partner agency has some interesting parallels with the client relationship too. They're genuinely trying to embrace the notion that we're all one team. It's the product owner's responsibility to commission the Scrum team's work for the sprint and if the sprint or the program fall behind, the product owner is the single ringable neck. However, the product owners are all humans and they're all answering to their own bosses and they're the same people that we answer to as well. So despite strong encouragement, the product owners find it very hard to take the blame for poor output when there are so many other people involved who they could do it to instead. After all, we're the digital experts in tech or in UX and they're just people that know their product. We have to bear in mind that they have careers and pride and other agendas that we might not know about. So things can be going just fine. A bad sprint can be perfectly well explained away and the retro run well to prevent repeated errors and then the Scrum master gets thrown under the bus at the next sprint report meeting. We can also be stuck in a situation where our co-agency see our large team as a chance to increase their own involvement and missing the opportunities to throw an elbow in our direction if it might present a revenue opportunity for them. I think we've all been there. I have to say it does keep everyone honest. If the client just had one agency on this, there'd be missing all the checks and balances that come from having multiple agencies running disparate processes and a QA and diligence on everything that happens. The client and the agency seniors also understand that the teams need to be self-organising and that we are facilitators of this. So we maintain very transparent, very informal, safe space back channels to speak candidly about difficult subjects for the good of the programme and steer the team to self-organise, if you're not any, to adjust or improve any pinch points that they might have. Self-organising teams tend to level out and produce the kind of output and governance that's necessary for their project. That's the definition of it. That's fine across one Scrum team. It's fine across maybe a couple if there are common touch points. We have multiple Scrum teams interfacing with multiple product owners. Each of them have enforced or not enforced different methods of planning, reporting, jeera use, acceptance criteria, sizing communications. The list goes on. Again, in a fully autonomous environment, that's absolutely fine, but the client seniors struggle to get a view of the programme's progress and efficiency. Credit to them once again for operating according to very pure Scrum principles, but they're still running a business. The two things that tend to produce sticking points are when they ask for more output than a single team can provide or when they try to get involved in reallocating resource across multiple teams in a hope-for-the-best kind of way. When this happens, it's our responsibility to help them acknowledge that quality is a fixed constant and therefore scope should be adjusted or highlighting and pushing back when instead of agreeing that a small improvement in shipable product is desirable or they adjust the nature of the shipable product without proper planning. This tends to be when the agile manifesto and the minimum viable product clash with real life. I'll leave that there for a minute. I'm going to talk next about roles within the programme. I've always liked this image. It's remarkably accurate in the way that people see themselves and the way that other people see each other. That's me right in the middle, project manager. I'm going to focus on the difference between designers and developers as this is the area that tends to cause the most friction and the two that tend to be the farthest apart. Okay. Design dreams, development wake-ups. The product owner will identify for us a vision and sometimes that can be just a couple of words like voice ordering. It's then the product owner and the product manager's job to turn that vision into executable goals. The UX and the design staff are a key part of this and tend to be the first people the product owner will talk to. The design process, any design is in? Okay, cool. The design process is... A different slide. The design process is relatively simple compared to the development process. As you can see here, it's basically sketching and colouring in some unicorns and then there's this word here, build, which is represented by this much more complex process down here where all those unicorns have to be turned into reality using the tools available at the time plus a lot of diligence and testing. So a lot of our unicorns tend to end up looking a little bit like this. How can we prevent that? Well, we can get involved earlier. We can help the product owner and the designers understand what's possible now and what's only possible after a lot of work. We can help to prototype and test so that we're not just producing one person's interpretation of a vision but the correct interpretation of a vision based on solid data and testing. Most importantly, as a business, we can make sure that it's understood that whether we produce a unicorn or a pink rhino, we've all agreed that the end product fits and meets the acceptance criteria in more than one interpretable way. I mentioned a little bit earlier that one of the ways that we can help the programme is to understand when in-sprints adjustments need to be properly re-planned. In a sprint, every action will have a reaction. According to the basic rules, accepting more points into a sprint usually means that something of equal value will be discarded. Of course, that message tends to get lost amongst the humans along the lines of, can you just or best efforts? Then we end up with technical debt at the end of a sprint, a task that could have been completed during sprint 10, rolls over to sprint 11, despite sprint 11 already having been fully planned. Suddenly you're facing 10 days' work in 9 days. This repeats in sprint 12 because you were over-spread, stretched in sprint 11 and everything's already buggy. So now you're down 2 days. It doesn't take very many sprints, in fact it takes 4 sprints, before all you can accept is technical debt and no feature enhancement at all. I call this a dirty snowball effect. It gets bigger and dirtier every time it rolls and at some point it's going to own up in someone's face. The client has to understand that the very nature of sprints means this can't happen. An understanding has to be supported by the scrum master and by the product owner. In the name of the program, pru-gram, is key, as although on a human level failing in one task might seem bad at the time, taking the whole team out for an entire sprint to fix what should have been manageable levels of tasks is going to impact the program much more heavily. So we have to reinforce that every time somebody has to adjust even the smallest of things. Okay, stepping a confident path towards openness and transparency internally, including the client. Transparent communications and reporting are something that we're all familiar with as a concept. Our bosses on our clients will all say they want us to be transparent, but that tends to end when the reports are bad. In this program, the client genuinely sees us as a partner, not as a vendor. This massively helps us with transparency because it means we can also treat the client as a partner, not as a client from a commercial point of view. In turn, this means that we're not aggressively trying to save money, but to spend it in the most effective way possible with their agreement. The whole company are freed up from difficult end-of-month deliverables and profit margin scraping and we're never challenged to deliver something substandard in order to submit an invoice. As we're planning our feature enhancement and releases years in advance, we're able to play a long game rather than a project-to-project game. Inevitably, of course, this has an impact on our approach to sprints and sprint planning. As often our teams see their work as small iterations of bigger programs and poor habits creep in because they're not operating according to sprints. This is where constant project hygiene appraisal and resets are vital to keep everyone engaged on the sprint level. We're able to act as the voice of reason between our staff and the client and the other agencies, as we're the ones who have an eye on how everything ties together throughout the program. There's no benefit to us changing the message. We can't hide behind the code. It's also true to say that mistakes are a very agile way of operating. Apart from anything else, the truth is the easiest thing to remember, so it's best to stick to it. Using common language and definitions. It's really very important that everyone on the program is talking in common language. Although it's not very agile to have documentation, we have removed a lot of friction by establishing things like races and jargon busting glossaries and ways of working and roles and responsibility documents. We usually have more than one person who could be seen as the end-of-most of almost anything. Delivery director versus program manager or account director. Development manager versus quality manager. So it's important there's also a clearly defined process owner and an escalation tree. Most importantly of all is how everyone knows when we are done done. And that comes from the original story. The product owner needs to tell everyone what the acceptance criteria are and there are so many people involved in the process of defining and executing each ticket autonomously that has to start right from the beginning. The autonomy is key and that's where the agile can come back in. It's a framework, not a set of rules. You're free to play within design guidelines, just don't break out of it. Here are some of the tools that we use for planning and some of the tools that we use for executing and some of the tools that we use for communicating. I didn't have room to fit them all in. Town familiar? This is probably nowhere close to all of the tools that we use on a day-by-day basis much less across the sprints in the program. Everyone's got their own preferred method of talking to each other. I've been on, as I'm sure you have, calls where I've got one method for voice and screen share and another method for typing and that changes from a sprint to sprint basis. We try to cut these down but realistically if a tool is right for the job then you'll generate more friction trying to prevent its use than you will absorbing it. Some tools, Slack for example we can commission new builds on UAT via Slackbot and it can surface communications to us via Skype, so that's nice. But in reality it doesn't matter if we're exchanging messages using coloured stones or skywriting or a t-shirt cannon as long as it gets the job done correctly. Somewhere deep in the Angelo Manifesto there is still a very strong instruction to allow time for knowledge transfer, cross training, collaboration amongst developers and a decent work-life balance. But sprint mentality and commercial reality also tend to confound this a little bit unless a strong scrum master books time within the sprint for it. At Unifer we do have islands of success here. It's an area of continuous improvement above all others. Ironically we've actually had to train people out of the notion that they have to go hammering into their code 24-7 and to take time out to reflect and to learn. Okay. I've called up the time with the technical issues. These are the takeaways then. Make geography work for you, don't fight it. We found that we had a client that was making demands on us in Australia so we hired someone in Australia. Straightforward. Maintain cordial back channels. Think house of cards if necessary and just call people and say what would make you happy here. Don't go spending a lot of effort trying to make people happy until you find out what that is. Homogenise your ways of working so that everyone is doing the same thing. It'll reduce friction and make people more comfortable with their escalation processes. Enforce a digital design standard. Get involved early. Developers who understand what the end product should look like. You've got a better chance of actually creating it to look correctly. Push back fairly via your scrum master on things that you shouldn't be doing and melt the dirty snowball before it gets thrown in your face. Be transparent and honest about everything. It really is the only way you're ever going to get anything done. Establish and enforce common language. No need to go into that any deeper. Use the right tools. Whatever they happen to be. Just pick something up. Keep up with new developments. Link them together. If there's a tool that links together your estimates and your actual effort done within JIRA and services of timesheet like Tempo, then use it. Then you don't have to have duplication of data entry and you avoid that pinch point. Allow time for training and the work life balance. Our client allows us to schedule the developers to a maximum of 75% across a sprint because they understand that meetings and training are important and they're going to be a better product. That's pretty grown up of them. But it's something that we have to actually work quite hard to enforce ourselves and always keep analysing and adapting and changing and challenging. Those are all of the takeaways. We've got a few minutes for any questions. Cool. All right, George. I want to sit here quietly for a minute. We're at stand 3 if you want to go into any of those any deeper or talk to my colleagues who are frankly a lot better at this sort of thing than I am about what Unipro do and how they do it with Drupal. You're either very, very late or very early. Say again, sir. Get a bullet. Yep. Yep.