Agile Team Lead confessions & where it all began…

From Development to Scrum Mastery 

My first encounter with agility and Scrum in particular happened at my first job as a Software Developer. At the time I already did not get along with the concept of a project manager. Client this, product such, deadline there, we need it done yesterday, this is not what client wanted, I know this might be better but do it like the client wants etc… Things that many of us no doubt heard more than many times over. Granted there were exceptions but generally speaking I didn’t like managers on the workfloor.

It wasn’t uncommon to hear me talk about never wanting to be a project manager. Oh how little did I know and naive I was…

So it happened that I entered a training course on agile development based on Scrum, organized by the company. I’m a person who likes plans, tables, and things of that nature, so when the consultant came with a kanban board for visually tracking work and a backlog, I was more than up for trying it, this had to be better than a vague list of ToDo’s somewhere! Scrum was the new kid on the block for us, so out came the post-its and whiteboards, daily syncs started happening and while that felt refreshing initially, the same kind of issues were still happening, now we just had a board and a regular meeting to talk about the issue that happened. It often became more of a mess when the project manager came with project demands that clashed with what was shown on the board. It wasn’t uncommon to hear me talk about never wanting to be a project manager. Oh how little did I know and naive I was…

Scrum = Agile, right?

Fast forward a few years, I joined TeleSoftas and joined a full Scrum Team. I came in with my notion of Scrum and Agile being the same thing, but they very quickly showed me the error of my ways, coached me in agility and I got in deep, fast. I spent my off time studying, observing, reading up on agile mindset, the manifesto, kanban, scrum, the infodump was real and I felt like a kid in a candy store. I knew about the role of Scrum Master, as I had seen it before, but everything else was essentially new and fresh. I’m a person who gets satisfaction from helping and supporting others, so I got very interested in becoming a Scrum Master though I had no idea at the time how to even become one, I also didn’t think I had close to enough experience to try it so instead I did my best to help with our self-organization or our process where I could.

I was (and still am) quite vocal about agile management and how I believe it can help developers be happier and more productive

I moved onto mobile development where I worked on several smaller-scale projects, some with agile structures, some without, but through my colleagues, I saw many examples of “agile” projects and how different managers saw agility, both in good and sometimes just plain bad ways. It became painfully clear that it was very easy to cherry-pick and miss the point of agile entirely. I was (and still am) quite vocal about agile management and how I believe it can help developers be happier and more productive in their projects and how in turn, that benefits clients and stakeholders, so I had a first taste of coaching others.

The Rollercoaster

One day, I got called into a meeting with my project manager and our account manager. “I am asked by our stakeholder to move into Product Owner position, we know you are quite active in agile, would you like to be the Scrum Master for this project?” There it was! My chance! I jumped at it. “Yes! Gladly!” This is the project I’m still Scrum Master for today. I also joined the Project Management team at the time, a group formed of all project management in the company to align and learn from each other. The rollercoaster began.

This was a different kind of challenge altogether, assisting my Developer colleagues with advice is an entirely different beast compared to changing a project manager’s mindset from traditional management to an Agile one. I struggled and failed many times, both with my PO and my colleagues in the Project Management group but the topics revolved around the same thing. 

What is the most important element for a project? “The Team”. If you create an environment where a scrum team feels connected, heard, empowered, has a positive impact on the client’s business, shares focused goals, and are proud of the work they achieve (both business and professionally), the project as a whole will thrive as a result.

We are not focused on the numerical output of things done, but on the highest value business outcome we can deliver to a client.

By this, I don’t mean that a development team should just unilaterally decide everything until they are perfectly happy, not at all. I mean that there need to be a collaboration between clients and the Scrum team to create a partnership and deliver the highest possible value for a product or project. We are not focused on the numerical output of things done, but on the highest value business outcome we can deliver to a client. We do this by considering our clients as partners, where both are actively involved in the development and delivery process.

In this transformation process, it became clear that in the management group two parties were forming, where one was leaning towards supporting a development team and others – towards supporting business and clients. While in an agile world, those two are interlinked, it became increasingly hard to fill workshops and set targets productively so we started an initiative of forsaking the title “Project Manager” and created “Scrum Master” and “Product Owner” groups, in that way committing to a full agile management style.

An Agile Community

Does this Agile mindset only apply to development teams though? I like to see it in a larger scope. An agile mindset isn’t something you turn off when you shut your laptop at the end of the day or when you join a meeting that is not directly related to your Scrum Team. Agile is or should be a value that you uphold in everything that you do. All of us had our hands full in our projects and while we did some sharing, we were still a bit stuck in our boxes due to time or other constraints. But how to be transparent about what we are doing, inspect our overall process and mindset, and adapt to better practices if we all have our own things?

By no longer talking about a Scrum team, but to switch the conversation to an Agile community, not bound by how many members we have who hold the “Scrum Master” title or a certificate. What about if a project is doing Kanban? What if one of the developers has stepped up to take up the Agile management of his team? All are included. In fact, in my experience, a person who understands an Agile mindset can bring a lot more value to a team than a certificate holder who completely misunderstood the idea and only looks at the output of his team by numbers.

We don’t get more informed by just reading the scrum guide every 6 months to see what changed and adjusting some of our terms.

We do this by sharing our experiences with others in our organization regularly, by preparing workshops and presentations about what we struggled with and experienced, and by making these available for all to listen in and experience,  by supporting all who are in this servant leadership position with advice and encouragement. And why stop there? We are involved in the decision-making process of what kind of Agile management best fits incoming clients and we coach clients and other organizations who are wanting to make similar changes too! It’s with that vision that I got offered and took up a guiding role in our agile community, to try and guide all who join to be confident, empowered, and proud in their projects, just like we all do with our agile project teams.