Scrummy Business
Following a scrum master course with Nigel Baker from AgileBear, a certified Scrum Alliance Agile training company, which I did as we do a version of “scrum” in our own company, I wanted to jot down a few thoughts and say why I found this course interesting beyond running projects in an Agile way.
It made me reflect on how we manage project teams at Code Enigma and justify why scrumming and many of the associated values are a good idea, even when the project is not Agile. Let’s be honest, in our agency we can’t apply Agile all the time, as it requires a very specific kind of customer or, to be fair to the people we work alongside, customer Organisation.
I believe Code Enigma wants to function as what Frederic Laloux calls a “Green Organisation”: “units of empowered teams with the notion of ‘inverted pyramid’, where higher management at the bottom supports senior and middle managers who support front-line employees.”
This is partly enforced by the fact that we are a relatively small business, we therefore would rather pay for more and higher quality developers and have fewer managers. We also don’t have software analysts and are thin on the ground with Project Managers. In fact, I am the only one, and I am from a non-tech background. This so far has suited us because we work on complex projects delivered by skilled people, so why carry the burden of all of the layers of a more traditional organisation?
Most people working at Code Enigma had their own customers working as freelancers or business owners. They know how to deliver value for the customer without having to be told, and this is why they need to be empowered and involved right from the start, so that they buy into the “Project Vision”, like in an Agile scrum team. Having a more traditional management attitude, where the boss tells the team what to do, I believe would lead to disengaged team members.
This is why, I have to say, I have always seen myself as a Scrum Master for the organisation rather than a Project Manager, whether the project is Waterfall or Agile.
I just enforce a process, I don’t tell the team what to do… The team has a voice at all stages of the project, for example, the Scrum Master doesn’t assign the task, the team picks the task from a shortlist defined by the customer. Estimating and “making” the team deliver is not what I, as a Scrum Master or a Project Manager, should do for them. I keep track, report back and facilitate the conversation for alternative solutions where necessary. Even with Waterfall, I don’t decide the plan; the team delivering the project needs to own it and agree to the terms and conditions of the delivery, the timeline and the scope, otherwise I would just be working with either angry or disengaged developers and designers.
The whole team, which ideally would include the customer, needs to buy into the vision of a project. Ahead of that, in my mind, the team needs to also buy into why we have taken on the project, discussing whether we should even go for the job, is it viable and worthwhile? Under which conditions? The risk of having a “sales team” or dedicated sales person that doesn’t communicate with the team is they may find themselves a very lonely business owner of the project, trying to force the delivery of something nobody wants to do! Which is why I strongly believe that a lead developer and/or designer should be engaged in choosing and writing proposals and give his/her honest feedback to the business owner/sales team. Ultimately, if we all row in the same direction, we go faster and are much happier. Even if some of us may row a little more reluctantly than others, we all had the chance to voice our decisions, and felt heard when we did, and now we all own the goal.
I strongly believe in the fact that you deliver true value only when you work as a team. A nice example for me happened during the building works at my mum’s house. Myself, the plumber, the foreman, the drywall installer were all debating over whether a new wall should be parallel to one or the other wall of some existing walls… There we were, all debating, looking down at lines on the floor, the angle of the windows, the walls… Meanwhile, another unfortunate guy, charged with removing old nails on the revealed ceiling beams, was listening to it all. After a while he shyly interrupted us pointing out that if we were to put the wall as debated, it would not follow the direction of the ceiling beams, which my mum would notice every time she was in bed staring at it! We all looked at him and facepalmed — he was absolutely right!
When it comes to managing delivery, my sort of “natural scrummy” attitude is probably helped by the fact that I am a non-tech, and also don’t have enough time to micromanage all the projects we have. This has forced me to see myself as a facilitator, one that gets the collective minds of the project team to come up with the solution, each with their own skills. This was convenient and, I have to say, doing the Scrum course has helped me to see it also as fair — I am doing important work, therefore I felt a little less guilty about not always understanding the tech and relieved to be justified in my role and skills.
Within the team we still maintain our roles with our strengths and weaknesses. A Scrum Master in a team like this should be a “servant leader”, there are two main aspects to the role. The leader part — and this doesn’t mean “leader” from a technical point of view — means at a minimum I am the one looking ahead at the general goal we collectively agreed (facilitating the achievement of the collective vision). The servant part is to do my best to pave the way for the team doing the actual delivery, remove blockers, organise resource, etc. In some cases we may not have a customer who is an engaged and committed member of the team — a Product Owner — so it may be I need to explain to customer managers when something is not achievable, technically, in budget, or in time. I can then facilitate the opportunity for an alternative solution. Ultimately I have to value the respect and trust of the team above all, and the right customer should value the fact that as a business you are not overselling yourself, lying, buying time, plugging holes, they should appreciate the professionalism.
In all this, and during my course, I recognised the Scrum values are applicable to the way we handle things as an organisation and with any customer: have courage, work as a team, be brave if the team says we cannot deliver something properly under the conditions requested by a potential or existing customer, have the difficult conversation, offer a compromise or, on occasion, refuse the work. Transparency, commitment and focus all lead to respect, internally and between the customer and the supplier, as the customer should feel as much a part of the team as we do. We all have taken on the challenge, to which we all agreed. No hidden agendas, no command and control from an individual over the a team, just a group of dedicated professionals pulling towards one agreed upon goal.
Those values are important whether we are running an Agile project or not, as at Code Enigma we “scrum” anyway. Most of the time without a customer Product Owner present, unfortunately. We do it so that the project team gets to touch base daily, as we are a distributed company, to facilitate collaboration between developers and, for me, it’s a window to identify/remove blockers and listen to concerns so that I can manage the conversation with the customer accordingly.
But of course, all this takes a lot of trust and courage and, above all, knowing each other very well. Which is why another thing important to Scrum, which is also critically important to Code Enigma, is staff retention. According to psychologist Bruce Tuckman’s stages of group development team formation usually follows easily recognisable stages: forming, storming, norming, and performing. Every time the team changes that process starts again; time is wasted and quality suffers. In other words, team change is bad, and a good team is one that doesn’t change much. This is actually important for any business. If you aspire to deliver highly effective projects and high quality products, the number one thing you should be doing is ensuring a stable team, so it follows your decisions, from equipment purchases, travel arrangements, how you sell, software you use, all need to be geared towards, above all things, a happy team! Happy people don’t leave, stable teams do the best work.
