 So, I might make a start. Thank you very much for coming. It's quite overwhelming to see the number of people who've turned up for my talk, so thank you very much. But I think it proves that from some of the discussions I'd had yesterday I was very fortunate to meet a couple of people at the business summit and it seems that this concept of self-organization is actually something that a lot of people in the Drupal community and people who work in Drupal projects are quite interested in and it's obviously a very core part of what we do both as a community and on the projects that we work on in Drupal. So just to get started, my name is Jason Coglin, I'm currently the client services director at PreviousNext and I've come from Sydney, Australia to be here at Drupal Con this year. We're a specialized Drupal company in Australia, we only do Drupal development. We provide a lot of services based, well we provide Drupal services but we also do a lot of contribution to the community and a lot of our development team are core contributors to Drupal. It's something that we're obviously all very passionate about and I think we have, there's six of us here at Drupal Con this year. So just a bit of background about me and how I got to this point. I've been working in project management for about 15 years in the online space and sort of prior to starting to work on the internet machine I was in the field of engineering working on some fairly large scale construction projects and I think that drove probably the first part of my project management career in that it was a very rigid command and control type approach with great attention to detail and essentially I was the one who ran the show. Now I've certainly evolved from that point and learnt over the last five years since I started working in a more agile way that that approach especially given what we do is fundamentally wrong and so I consider myself a very strong convert to the agile way and one of the things that I've been thinking about a lot more recently is this concept of self-organisation so it's what's behind my talk today and I consider this something that is I'm just beginning really to think about and get a good grasp on so I'm certainly interested to hear other people's thoughts and opinions around this so I think one of the key things I realised even reflecting on my time as sort of a waterfall style project manager was that the two key things that really drove the way that I worked and the projects that I ran was all around communication and also around a creative approach to project management so whilst it was a very top-down requirements driven very specific sign-off sort of processes and moving straight into building what we were doing it was still along the way there was a lot of adjustment that went on and a lot of creative kind of approaches to getting the project to the end even though it was that waterfall style approach so what I've learnt is that that's a fairly old-school way of doing things and certainly the push is very much towards an agile approach and somewhere in the middle of those two I think lies the sort of probably not perfect solution but certainly the approach that is the most effective for running not just triple projects but any kind of digital type project or product development in the software space so at the heart of it all I think it's all about the right people and then their ability to self-organise and today I'm going to talk a little bit about the factors that influence us being able to self-organise so why are me-cats part of my talk? Well apart from the fact I suppose they're quite cute and an amusing animal they demonstrate a great deal of altruistic behaviour in the way that they work together and they also share what's called like a century duty where a number of the me-cats in the group will actually look out for the rest of the group but as I discovered as I did some more reading about me-cats and their behaviour I found out there was a little bit more to it than just that so the comparisons are quite strong so they work in large community groups together so as we talked about before there's a few of them will work as look-outs to look out for impending danger and protect the rest of the group from that. They have a various network of boroughs that they move between and adapt to the different environments in which they're working. They've developed a special adaptation whereby they can close their ears when they borrow and no dirt will get in so they can shield themselves from any distractions. One thing is that they need the early morning sun to get going and as the day begins they need a certain amount of stimulus and what they can only tolerate short bursts of activity during the day during the morning and then in the afternoon. They have a wide and varied diet and they've certainly developed an ability to consume dangerous foods. They even have the ability to take on poisonous scorpions and have them for their dinner. One of the key things that made me discover that they're not particularly as cute and friendly as they might appear is that they demonstrate a lot of alpha behaviour and there's alpha pairs within the group that reserve the right to be the ones to rule and they're the ones who actually reserve the right to reproduce and they'll quite readily kill any of the young of their subordinates in order for their own to have a better chance of survival. They're essentially not really as cute and cuddly as they might appear. One thing I just wanted to say before I get right into the presentation is that I would like this if everyone's willing to be a bit more participative sort of presentation. Certainly contribute your thoughts and ask any questions at any time throughout the presentation. It doesn't need to be at the end if there's anything that triggers a thought or a comment that you'd like to make or share with the group then feel free to do so. I'd also like to propose continuing this conversation because I've seen that it's certainly something that people are interested in just from the conversations that I've had and beyond the presentation today I'd like to even look at starting some sort of a community research project that focuses on the Drupal community because it's generally what we're all most interested in and see where we go from there. So I've organised a BOF which is actually tomorrow morning so if anyone is interested to come along it's at 10.45 so we can have more of a conversation than me just standing up here and talking at you. So one thing I'd like to do to initiate that discussion is I'll put some post-it notes there on that table in the one at the back so if anyone would like to grab one what I'd like to do is start by getting a sense of the one key problem that everybody has on their Drupal projects and the one thing that they'd really like to try and solve. Whether it relates to the concept of self-organisation doesn't matter it's just looking at the key problems that we experience on our Drupal projects. So what I'm going to look at today is the key factors and influences that relate to self-organisation and how a team can actually self-organise. So there's a number of factors at play here there's organisational factors so the attributes of a business or the way that a business is structured that allows it to be more suited to self-organisation is not the easiest thing for a very traditional company with traditional project management approaches to actually get to that point I certainly will vouch for that given the number of years that it's taken me personally just to get to this point of really truly understanding what Agile is all about and what the kind of core aspects to Agile are to be successful. So looking at also how clients so commercial factors so how clients and customers actually influence this project they can have a huge impact on the way that or the success of you creating a very well functioning Agile environment and having a very strong self-organising team. So the final thing really is also looking at the types of projects and the methodologies and processes that are suited to self-organisation. I won't be spending a lot of time looking at those because I think one of the key factors in all of this is about the people and about the roles that people take on and adopt in a self-organising team. So what is self-organisation? So self-organisation actually stems very strongly from a scientific principle and it is a natural process it's a naturally occurring process and I think that's one of the really fascinating things about self-organisation is and looking at it in the context of what we do and the context of a team is that it's natural it's something that comes naturally to it to us and generally in nature and it's totally sort of contradictory to the way that we have previously approached projects and also the way that we've structured businesses. So this sort of is a great quote it comes from the concept of chaos theory and it I think quite adequately describes the sort of environment that you feel you can be working in at times on the projects that we do. The idea of self-organisation is that you have a state of non-equilibrium or as in chaos theory you have a chaotic environment and through this sort of dynamic and interaction and feedback within the system itself you move more towards a state of equilibrium. So it's really about that exploration and exploitation of the information that is generated or the stimulus that's happening within a system that leads a system towards a greater order and this applies actually across a number of different systems. There's one particular type of system we'll talk about today but it's in physics, it's in chemistry, it's in biology. Anyone who's interested in that side of things I'd look it up it's quite fascinating. So just in looking at that some of the this sort of is just a visual way of describing that or understanding that you have entropy or what's a chaotic system and then we're moving more towards a much more structured system. So one example of this in probably most closely represents what we do and even Drupal itself is that the concept of a product or a platform is that once more people start using that particular product or service or platform the greater the value of that platform or service becomes. So there's a lot of local connections that are made and rapidly as more people join that and make those connections within the network it creates more positive outcomes and we move to something of much higher value. So it's proof that the kind of synergy between elements within this system so in this case it's people in a social media context or I don't really want to use Facebook as the example but you can look at this as an example of how Drupal has evolved as well in the more that people interact and the more inputs that happen that the greater that system becomes. So within nature a really good example of self-organisation is actually ant colonies and they're governed by very simple rules but exhibit and create these very complex structures and quite complex behaviour. So then it's a completely decentralised structure and a very very good example of a self-organising system. So the queen in an ant colony does not tell the other ants what to do they respond to an external stimuli which is a chemical stimuli from other ants and the organisation is distributed throughout the whole system and then all parts of the system contribute equally to that and then there's a resulting arrangement which is what we see as an ant colony. So how this in the context of what we do and what I was talking about before in terms of traditional structures this is the sort of thing that you would see in many businesses the very top-down hierarchical kind of approach to business you could also apply this to a project and it's dependent on a single coordinator so there really could be considered to be a single point of failure in a system like this. So what we want to try and achieve is something looks a lot more like this. So it's a much more resilient model and it's a lot more robust because of the distributed dependencies within the system so there is no single point of failure and if you do remove one element from the system it has the ability to self-repair to some degree. So self-organising teams so we've talked a little bit about the application to business and what we do and I'm just going to go into a little bit more detail about that now. So self-organising teams some people might consider this as what a self-organising team is. It's certainly not agile as a project methodology is not something that businesses take on readily and the concept of a self-organising trying to describe what a self-organising team is and how you would take an agile approach to a project both within the sort of senior management structures of a company or within or to a customer is sometimes a very difficult sell and a very difficult thing for them to grasp and they would potentially look at it as something like this. So self-organising teams or the concept of self-organisation is actually for those of you who are familiar with agile you'll know this already but it's built into the principles of agile. This is one of the 12 principles of the agile manifesto which of course is kind of the governing manifesto or guiding principles that drive a lot of agile methodologies like Scrum for instance. So built into that it is considered and I mentioned this before it's it's considered a human-based system or one where there's a interaction where we're generating information and processing that information in order for us to make decisions and and evolve a product or evolve on a project it's considered a cognitive system and that's one where there's a generation of information and that information that's generated within a system within a chaotic environment provides us with a very wide spectrum of options in order for us to make the decisions that we do. So the the thing that helps us to form order in that in that context is our ability to process that what is semantic information and and actually understand and interpret the actual meaning of that information so that we can then make decisions and perceive that information and then act on that in a way that achieves a decision or look has it has us go down a certain path when we're when we're when we're developing. So the so from from the information that's generated a new meaning is formed when when there's a different perspective on that or a new point of view provides a greater dimension to the to the organisation and the organisation within a team itself so that's the way that we actually manage that information and that is not always an inevitable outcome of this this process that I'm trying to describe there so self-organisation is not something that just happens and we don't we start with a with a chaotic environment we start with a sense of chaos moving towards order but that's not always the way there are actual other influences that we'll talk about in a moment that that are very important towards that becoming a more ordered and structured environment and and not one that remains in kind of a state of chaos so what there's a number of attributes that would need to be need to be present and a number of influencing factors that need to be present for a self-organising team to actually be to be successful so those are that the team should be autonomous and coming back to that concept before of of a self-organising structure within a business again that's something that's difficult to sell or difficult sometimes for management structures in the business to actually to understand and to and to be willing to to to let a team be more autonomous than than than they would normally expect them to be the team itself would needs to have a common focus so it's not a matter of just throwing people together and hoping for the best there needs to be a really you know strong driver behind what it is that they're doing and they all need to have a clear understanding of what where they're trying to get to and then there's this concept of course within self-organisation of distributed leadership and not all members of the team need to become a leader as such or adopt a true leadership role but there are stages throughout a project or at points at which everyone within it within your self-organising team can exhibit or undertake a position of leadership so it's it's that the it can happen at a high level so somebody just providing that direction and guidance to the team in order for them to to keep moving and to keep self-organising or it might happen at a lot lower level in the team where somebody exhibits a leadership on a decision that needs to be made regarding a critical piece of functionality or a or some kind of decision that needs to be made in order for the for the architecture of the system to be to achieve good outcome so the another a really important factor is is this idea of dynamic adjustment and adaptation so everybody in the team obviously needs to be willing to change and adapt to that change and make any necessary adjustments that they need to to achieve the outcome that that we want to do and the going back to the idea of chaos and and the whole driving force behind these things happening is that there are going to be chaotic acts and there's going to be chaotic events within any kind of project or any self-organising team and and that team needs to to to be willing and flexible enough to be able to adapt in that in that some situation and then finally there needs to be a very strong ability to elicit requirements when working on a project so when we're looking at the development of a proposed solution there needs to be a strong sense of how something should function based on the the inputs of information that we're getting from from the customer or the client or from from other sources so the very sorry so the next thing I wanted to to talk about is how how can a business be more ready to actually take on this approach and whether it be adopting agile as the way to manage their projects or whether it be simply that they they need to get better at that what they're doing in that in that in that way and and have more self-organising teams or a greater sense of self-organisation within within their teams um this is a another really interesting quote that I came across that it is a very good example of why uh it's the top down hierarchical kind of environment is really not conducive to to innovation or to us actually undertaking projects that have a really high value outcome for either for us as a community with with Drupal or for a project we're working on um the bureaucracy as you say is bureaucracy represents an organisation for which chaos has been completely eliminated now to some people that actually might be a good thing people who are uncomfortable with change or just want things to be very predictable on a daily basis but what's going to happen is what could be termed orderly idleness and and you're never actually going to achieve innovation or adapt to change or or really as I said before achieve a really high value outcome on the project that you're working on so the organisation organizational environment is is very important so if a business is not willing to adopt this kind of theory or adopt an agile approach or even get their head around the the idea of self-organisation they're going to struggle with this with this approach so the command and control approach versus the distributed kind of leadership and management is is the thing that needs to be looked at um looked at the most closely so um any transition from what is that bureaucratic kind of environment to a uh to a more kind of individual individualistic kind of environment or one that focuses on um people being autonomous and and and allowed to to work in this kind of self-organising structure um can be very challenging um can be extremely disruptive um it's certainly as I mentioned before it kind of plays on a lot of the insecurities that people have uh in traditional business and in traditional business structures and and certainly you can find that um in any kind of transitional period in doing this thing people will get very defensive about uh you know the sort of things that you're proposing or the the the the approach in general so um I guess in order to sort of relay my own experience on that one um I would say that the first time I took on an agile project as a traditional waterfall type project manager um it was very very confronting and very difficult um I think back to when I first moved from an engineering um engineering career to to a what is essentially kind of a a web development or software development environment it was very early days in in the web space and and I found that very confronting at the time um and but but now I reflect on that I see that that was actually the the start of this sort of journey that I've come on to get me to the point where I now truly understand that kind of chaotic environment that I was thrown into because it was certainly very chaotic um just 15 years ago nobody actually really knew what they were doing they were just kind of making it up as they went along um we've moved into a much more kind of mature um environment to work in now and like I said reflecting on that I now see that they were the kind of the seeds of change um that were being sown right back then for me to now really understand why it's important to take this kind of agile or self-organizing approach to um the sort of things we do because they are chaotic they are unpredictable they're probably more predictable than they used to be um but they certainly that it certainly requires a fairly unique approach uh so when I was when I was making that initial um transition uh the things I found that were the the most difficult was that no one in in the in the mix had were really at all um cooperating or understanding or looking at it um uh like I said before that there wasn't a really cooperative type um approach to it the the team who was working the development team essentially looked at it as a license to just do whatever they liked and spend however much time they wanted to on anything and just look at it as a a big grand experiment even though there was there was sort of fairly loose requirements to start with at the beginning the customer had no concept of the idea uh had no concept of agile had no concept of what we were trying to achieve there we were just sort of thrown into an agile environment told to work in that fashion so it was great for the developers because they uh a lot of them were came from sort of a product development background and had some familiar familiarity with it but saw that opportunity um to just essentially go and experiment because they realized that no one else really knew what was going on um and then the so the customer takes this approach of well it's fixed price fixed costs you know you're going to deliver this thing and we're just going to go away and we'll come back in six months and it will be great um which of course it wasn't and then the um senior management within the organization that we were doing this project we just were completely hands-off had no concept of what agile was about and really no interest in in trying to bridge that gap between the customer and the team and make sure that uh they were engaged and and that we were working as a as one big unit so the self-organizing team needed to include not just the development team or the project um managers within that sort of environment they needed to include the customer and also the management of the company so really at the end of the day the whole thing was just a complete debacle um so rather than sort of run screaming back to the traditional waterfall approach um it certainly was a great lesson in what how to do it better and what can go wrong because this is probably the worst possible example of of it but it was it was something if i mean what i'd like to say is that if anyone finds themselves in that environment coming from that more traditional old school type approach and background i would i would strongly um suggest persisting with it because it's well worth it and it was a very good a very good learning experience so um what are the influencing factors um that uh that that make an organization um more ready to do this and um and and the sort of uh sort of behaviors that need to go on to to um to make sure that this does occur well it's across the board with um everyone i just mentioned before from the development team right through to the the client um there's there should be just a very subtle element of control and direction and everybody needs to understand that um the customer the senior management of the company project managers within the team who may have come from a more waterfall background he's not about command and control um it's a lot about um facilitation and those people who do have a greater leadership role within the project need to be there to facilitate not to not to direct uh then the idea is that you really need to relinquish a level of control so those things i was just talking about then it is it is about relinquishing control and people who have um come from that um or come from that approach where they are in control um it can be it can be a difficult thing for them to grasp so um and again back to the whole idea of senior management that they're they're critical to um to being able to facilitate this um this whole idea in the first place to allow um teams to work in this fashion and to understand exactly the benefits of it and what's going to be what the outcomes are going to be and some of the research that i've been doing um prior to uh to my talk today has been looking at um various models and businesses that are very successful at this and one thing um which i'd recommend anybody who's interested in do some more reading on is um Japanese business models are a very a very good source of understanding and um seeing how success that you can achieve a very high level of success to take an approach like this and one of the one of the most um interesting things that i read was around a a CEO of a Japanese company who'd been there for many many years and just decided to resign one day and everyone was shocked with with the decision and the the specific reason that was given for for him uh resigning on that particular day was that he said that he got to the point where um more than 70 percent of the company um agreed with him and agreed with the things and the decisions that he was making so he just felt that that was just way too many people to be agreeing with him and that it was a much better situation for the company when the majority of the company didn't agree with his decisions and were constantly challenging um challenging the the decisions that were being made so this is again this is a really good way to look at it so um i mean every every kind of uh every kind of comedy you ever see about um office life for businesses it's always poking fun at managers and middle managers and and in your house of perfilates they are to the whole process well i think this kind of sums that up and that is that that you know leadership is incredibly important in this whole process and it's not just about people in senior positions within a company that need to exhibit that sort of leadership and leadership is is really at the core of of all of this um so commercial factors so i mentioned i've kind of touched on this before i won't spend too much time on it but um this idea of it's all about it all about the customer will i mean it is all about the customer um to some degree um it's probably a bit more of a salesy marketing type idea around it but in this context it is about them in a very uh it is they are a very important factor in this because if they're not willing to uh take this approach and they're not willing to engage and understand what it is that you're trying to achieve here um then it it really is it really is setting itself you're setting yourself up to fail i mean it's crucial to the success of a project and if a cut if the client that you're working with is not fully engaged in this whole process it's a complete hindrance to to the success of um of of the project uh so so what i've mentioned there is um one way to mitigate that or and and try and ensure that you can achieve a better outcome is is through education and support of a client so um in an agile um in an agile project um the methodology there is is that you really uh want to um have a strong product donor in in an agile project and you can't just stand back and uh sort of tell the tell the client they've got to come up with all the requirements and write all the user stories and get everything perfect and then the team will start having a look at it when they're done with that that just never happens when my experience it never happens and one thing that we've um what we've done um at at previous next is that we are really focusing on having um advocates within our our team mainly our our sort of more project management style people focusing very strongly on being advocates for the client and educating and supporting them through the process to understand what it's all about to to work in an agile environment and understand what this whole concept of self-organization is and how important their involvement in the process every step of the process is um so what sort of projects or products um lend themselves to this i was having a discussion about this yesterday um my opinion when i was putting this presentation together was was that this this sort of approach really only applies or works within a technology driven or software driven type um project uh one where it's it's dynamic uh there's there's the um there's the ability to make mistakes and uh adapt to change as you go evolving requirements those kind of things i still strongly believe that um but i think it's an area where a lot more research could go into this concept again of self-organization or how it could apply more broadly across other projects the thing that i used as an example was you wouldn't do this if you're building a bridge or you're building a large large scale building somewhere everything has to be a millimeter perfect you need to be in control and looking at the detail every step of the way someone's going to get hurt that doesn't happen um on our projects we make a mistake there is a bug in the software something doesn't happen correctly when you go live through the website and everything goes pear shaped well no one really gets hurt so we have that luxury to be able to do this and be a bit more experimental in in our approach so um but i'm still very interested to to get a better understanding more broadly as to whether or not um you know there are other there are other industries and and projects this could this could apply to uh so methodology and process so what what approach works or um where does self-organization fit in to um project management methodology well it kind of it comes down to a waterfall versus agile approach and i i did say before that um coming from a waterfall background i feel like i've put that behind me and i don't want to borrow it ever again and that self-organization has no place in waterfall well i kind of i'd kind of like to be challenged on that and and look at that as um uh as something as a topic of discussion because i i do believe that you can't just outright dismiss the waterfall approach people are still going to do it a lot it's going to take a long time for agile really to sort of filter through and become you know the only way that that everybody works um in this in this space and that's that's probably a bit of a utopian view i don't think that'll ever happen um but you know i there's probably elements of self-organization that could be applied in a waterfall context and i'd be really interested to know um or explore how how that could work but clearly agile is the way to go and you know agile is and self-organization is at the core of of agile itself so that really is um the right approach to be taking um if you're doing that so there's obviously very various flavors of agile um the one that i'm most experienced with is is the scrum based approach and uh and and that is is certainly working very well for us um we've made a lot of mistakes with it we're still adjusting um but again that's really the nature of this it's the nature of agile is that you adapt and change and and again some of the conversations i had yesterday it's really interesting where you start the companies or businesses start to take on agile choose a particular flavor of agile and you know they're five years down the track they they're not doing anything like they did right back at the beginning even though they actually um are using the same methodology in the same processes the way that they're doing it is completely different so it's all about that adaptation and change right throughout um i've got a few notes there about scrum but i think if those of you know agile we should familiar with scrum if you're not um i'd recommend going going away and having um a bit of a look at at that as an approach if you're interested in that um so i've listed this one to last because this really is um the most critical factor in all of self-organization and that's all about the people so these are the elements of the system um that are going to most greatly influence the outcome at the end so there's a number of things to to address when it comes to the behavioral influences on self-organization um the first thing i'll just run through quickly are roles now this comes out of a piece of research that i've read um which really struck a chord when uh when i was preparing my talk because this this is a really um a really well done piece of research and a really good way for people to get their head around how self-organization works and what what um what the the roles are of people in that so there's um there's six different roles that people will take on in a self-organizing team and that doesn't mean it's six different people uh it could be one person doing four of these roles at any one time or on any one day um it could be a number of other people so uh there but there's also the concept that people within a self-organizing team may not take on any of these roles at any point in time um so the first one is the idea of a mentor so the the mentor guides and supports um the team in the initial stages of this and they they help the team to become confident in the in the process the agile methodology and the processes that they're doing so they they then monitor and encourage the team throughout the whole project to actually um to to adhere to the practices of agile and make sure that they're kind of sticking to the sticking to the plan um this this role is probably most traditionally uh undertaken or adopted by a scrum master or a coach agile coach but that's not to say that anyone um couldn't step up at any point in the project and do this i know from our own experience at previous next everyone in our team um has gone through a scrum master training so we're of the view that at any one point in time if we really needed to um any member of the team could step up and act in that particular role and and even undertake this kind of mentoring type role again i think you know we're going through a strong period of evolution with the way that we're approaching this whether or not we have developers working as scrum masters or we have project management um professionals working as scrum masters um it's again it's it's a good example of that sort of constantly evolving model um the second role is the one of the coordinator so this this person acts as a representative of the um the team to to coordinate and communicate the change requests if we want to refer to them as change requests that come through from the customer or the client so um that person interacts with both the team and the customer themselves and this this role is not really like a scrum master type role or a project management type role this is this is the developer this is a developer in the team or if if you have business analysts um it would be somebody like that taking in interpreting uh not necessarily interpreting the requirements but coordinating that process of bringing in those requests then there's the translator so the translator um is the person that really understands the requirement best they're able to take take it in uh take a requirement in business uh in business language used by the customers and then translate that into technical terminology for the team so they're again interacting with the team and the customer and most likely this um this this person is is someone with business analyst type um skills then there's the champion so the champion um they champion the agile cause and um they're doing that to the senior management within the company that's running the project so they're constantly uh reminding senior management or um gaining their support for for the concept of having a self-organizing team or running projects in an agile way um again this person is probably most likely somebody like a scrum master then there's the promoter so the promoter is the one who does that with the customer so um they attempt to secure their involvement in the whole process and um collaborate and support with them to ensure that the the team can can function effectively and as I said they they interact with the customer only and again this is probably a scrum master type role so you can see as I mentioned before these roles there's multiple roles and they can be taken on by one person or they they they can uh be taken on by anyone in the team really if they have the capability or the desire to do so this is my favorite one the terminator so so you got a question yes right oh we we um we definitely would have that um that that role to um probably more from a methodology point of view and and talking to them about what we're doing and how we're running scrum more so than actually requirements gathering or interpreting or translating like I mentioned before um so yeah as I said this is this is my favorite one so what this role is uh it's quite a brutal one and that is this this is the person or in this role they they identify people who are disruptive to the team and they remove them from the team and the way they do that is they engage the support of senior management or whoever can make that decision and they remove them because if people are not operating effectively within the team or they are disruptive then it is going to affect that whole uh whole system again I mentioned before this could be anyone really anyone who wants to put their hand up and say this person is is killing us so um just to quickly wrap up there there's a number of other things so there's the number of roles but then there's the actual people and the disciplines that those those roles apply to so there's developers there's business analysts there's coaches or scrum masters and that coach or scrum master type role as those of you who know our job we're familiar with it's kind of a little bit you could use the analogy of a sports type a sports coach where they set direction they align the people um obtain obtain certain resources and then motivate the team to to to achieve the best outcome they can um the sort of personalities that you want to have this would apply to anybody in the team people who can manage their own workload um people who are good at decision making people who are collaborative um people who are trusting and respectful of the other people that they're working with and and then finally the people who are willing just to participate so not people who are going to just going to stick back and wait for things to land on their desk and and uh just um bang away at the keyboard um and then there's the wrong people so this is where the terminator comes into it the wrong sort of people are those who have that inability to adapt to this type of environment if they're not willing to change they're not willing to adapt to this type of model they just shouldn't be there it's not going to work um interestingly the other end of the spectrum people who are very idealistic and evangelical about agile because it happens you send somebody on an agile course they have this major epiphany and they come back and they're just you know every you're not that's not right you should have this you know um scrums need to to happen at this time every day they need we need to do sprints they all have need to be two weeks they can't be one week and so you get these people and they'll just they are completely um insane and that is actually a really destabilizing factor and so it's kind of it seems a bit contradictory but the people who won't change and the people who just you know go crazy about it both of those people are bad um so one thing i've mentioned there and this is something that i'm not going to cover off today but it's something i'd really like to explore a little bit more about and anybody who's interested in coming to the bof um maybe it's something we could discuss um is recruitment how do you recruit for this so i mean we use a number of tools and techniques and even online testing and that kind of thing to to to look for the right people um what we haven't been doing though is actually looking that looking at that and relating it back to some of the things that i've mentioned so the concept of um those roles and how people would fit in those sort of personalities but we certainly i think we get a good feel for that anyway from the sort of culture and environment that we've fostered in our own company so i'm uh i'm conscious that i'm running a little bit over time here but um just to just to uh just to summarize i've been through today so um the theory of self-organization and how it applies in the nature and human systems again i think it's a really fascinating thing so anybody who's interested i'd recommend going away and having a having a little spending a bit of time googling about it it's it's quite quite an interesting topic um and the factors and influences that that are really important to consider when um you're looking at self-organizing team um of course it's it's actually understanding the concept in the first place so i think looking at some of the theoretical stuff can really help um some of the more amusing stuff around ant colonies or whatever other swarming kind of behavior you'll see in nature i think is a really good thing a really good way to describe it to people uh organizational factors we went through commercial factors to do with the customer and then most importantly the people and all of those roles that are really important to be at play in in your project um so finally does it work uh well i mean for me the answer to that is clearly yes it works and it's a much more effective way um than than any other approach that i've i've taken in the past or i've seen other people taking that in the past um agile is it is definitely um a great way to go for Drupal projects um uh focusing in on the self-organization capabilities of the teams again i think that's something that's just really critically important to this whole thing but also making sure that you're doing that in the right way and those roles are all being fulfilled and people are being educated and supported in doing this and so um so my answer is yes but i i mean i am not professing to be the expert on this topic it's something i'm really just starting to explore i'm very interested in in researching it further and certainly um anyone else who's interested in contributing it so contributing to that so discussing exploring researching this thing is um is something i'd i'd like to hopefully be a catalyst for and certainly something i strongly encourage other people to do if they're interested uh so there's more to think about so just to remind you again i've organized a boff for tomorrow so anyone else who wants to come and actually have a chat about this in a little bit more depth um throw their own opinions around instead of just listening to mine um please come along and uh that's it thank you very much so please uh please uh jump on there and uh let me know what you think that would be uh most appreciated um but if there's uh any questions or anything anybody wants to um to talk about we've got about 10 minutes left yes uh look i probably wasn't suggesting i wasn't suggesting so um the question is um do we immediately terminate people just because they're not um they're not adhering to the process or participating in in in the way that we want um no i wouldn't be suggesting that immediately people just get kicked out i think if you can spend some time and and remind people or go back or um for one of a better term re-educate them on uh on the on the best way to approach this thing then absolutely i think that's the last resort yeah yes yes i think so yes you're supposed to be mentoring but who's also you know actually stopping uh this uh development within the team have you had any experience with how to deal with that eventually become very un-adaptable yeah well i don't think if somebody's in a mentoring type role they shouldn't be disruptive so that they're the wrong person for that that type of role if that's if that's what's happening um the reference to the alpha behavior i think is just the nature of the kind of it's the nature of the industry it's the nature of the kind of discussion and everyone has very strong opinions around development processes or particular ways to write a piece of code so um yeah it's sort of yeah absolutely i think that's the sort of behavior that you want to remove from the equation you don't want that there so you know that's where maybe the terminator all comes in but you'd want to be counseling those people through that sort of behavior so it's not going to work if you've got that going on speaking from a personal experience the bigger project becomes the the chaotic level of it becomes exponential how do you scale it actually how do you scale the self organizing aspect of the team yeah that's a very good question and i think that's something that i i would i would want to look more at as well but from my experience with um the the scrum process or even just agile generally the bigger a project becomes the more uh the more of a catalyst that is to actually break it out into smaller components and have multiple teams so you saw on that model that that diagram up there before the concept of you know interrelated self-organizing teams i think that's one way to approach that is that you break it down you don't just have this big amorphous enormous um team you should be aware if you have seniors and juniors in the team yep if you have a big complex and you also want to emphasize on self-managing teams don't have two minuses in the equation juniors that haven't been running as a self-managing before in a complex environment yes i think that and that's a very good point about having um senior and junior yeah that's right if you have that luxury because i think that's where that mentoring role comes in as well and having that balance because it does it does require a level of experience these like it's like we talk about it happening in nature naturally and that's just a natural account well that's that's millions of years of evolution um this is this is something that does require process it does require structure and there are certain roles that people need to take on so but yeah to your point yeah it's very important to have the right mix of people as well in terms of their experience yes why do people have the scrum master training well look i think that i think that the idea behind that in the first place was that we wanted everybody to to fundamentally understand the the ideas behind scrum and the ideas behind agile the concept that i mentioned later that we thought that we could get anyone in the team to be a scrum master uh well that came later so that wasn't something that we had as our intention when we put everybody on the course but we just want to make sure that that agile and scrum is deeply embedded in the culture of our company and i think that's really really important so even whether or not they end up working on a on a project i mean we do only put people through currently that actually are working actively on the projects but there'd be no reason not to put somebody even who was just sort of office management stuff on the probe on the course to so that they understand what the the everybody else is doing because i think the more it's embedded in the culture of your company the more likely you are to succeed well uh no um but one actually one initiative that we're looking at doing is actually putting some of our people through a certified scrum master training course so we'll have our own in-house training capabilities and that will actually be able to have credited courses run internally and we're also looking at doing that i talked about supporting and educating your clients we're looking at doing that where we run like a product ownership course for our clients so rather than just saying go off and do this two and a half thousand dollar course before you come back and start the project we could provide that service to the client and and then they'll get a much better idea of what their responsibilities are as a product owner it look it's very true and i think it was interesting at the business summit yesterday we got asked to write down what was our biggest issue on our projects and mine was effective product ownership because that really does make a huge difference to the quality and the outcome of the project and that's why we have that kind of very supportive role or we're trying to support our clients in that respect yeah yes anybody that's where you need the terminator yes that's where that macchiabellion idea comes into it politics to get rid of them eventually yeah but it is the whole idea of that senior management support is really really important yeah yeah absolutely i think that there probably are the tricks and techniques but i mean you are going to get people who just they're not interested they come from a very traditional business background they're in charge they're in control that's all they care about they don't you know somebody's yelling at them something hasn't gone live they don't care no look i think just around that so the concept of waterfall experience developers moving into an agile environment i think i think you could make that transition easier by doing better requirements and better story development better engagement with the client because if you provide any developer with a really strong requirement with a great set of acceptance criteria or whatever you want to call them in that context i think they'll all get on board eventually it's just they're used to maybe having a you know spec this big and they just go away and you know do what they do to get it done um if you sort of do that more iteratively with them and provide them with good information i think that you you know you find you get them on board eventually as well as as well as some training yeah that well that's right i think that's what allowing allowing we i mean all of our developers have full contact with the client on on a daily basis so i think that's a really really good thing to encourage and i think that i think people would enjoy that coming from that background where they were just hidden away in a corner from the client that closer contact i think would be really helpful no absolutely and that's yeah yes yep yeah yep yes well it's a self-organizing terminator team yep exactly okay all right well thank you very much for coming i appreciate you