For our first week of study, we were introduced to the world of agile methodologies. Agile as a working method was developed as a reaction to the cumbersome and documentation heavy practices of the past (Zelkowitz 2004). Many people who work agilely will give a different answer about what it means to them. Some see it as a learning process, and those organisations who employ it as adaptable companies oriented towards learning (Waldock 2015). However, at its heart, the agile methodology is a mindset. (Waldock 2015).

Under the agile umbrella, many different techniques exist, such as Lean, Kanban and XP (Extreme Programming) (Stellman and Greene 2014). However, Scrum is the primary project management technique we will use as part of this course. Just like its namesake, a rugby scrum, the philosophy is simple. A Scrum is a structure designed to create efficient teams who will find creative solutions to intricate problems (Schwaber and Sutherland 2023). Scrums are dedicated to creating valuable solutions. Not only that, they focus on innovative techniques brought about by a cross-functional team motivated to work on specific products (Bittner 2017). I find this concept particularly interesting concerning the Scrum method, that a team can be built SPECIFICALLY to raise the team’s motivation to create better results. It is so obvious that if you want a good product, make a team that actually wants to design and build the thing!

Within the Scrum system, we find sprints, “where ideas are turned into value” (Schwaber and Sutherland 2023: 2). Ideas, desires, and feedback are brought together by stakeholders to form a product backlog, a wish list, if you will. The most important from this list form the sprint backlog, and a specific set of goals is defined for the sprint period (Cho 2010). Throughout the sprint, these topics are fixed, and no changes will be allowed to threaten the goal of the sprint (Schwaber and Sutherland 2023). The concept of short sprints with defined goals is alien to me, and even more alien is the idea that external whims cannot change those goals until the sprint is over.

Comparing these management strategies to a much broader context, in this case, is worthwhile. My experience in architecture is that construction projects follow a monolithic project management style through necessity. Once a building has been constructed, it is pretty hard to change your mind. Innovation in the built environment is encouraged and awarded, but in my experience, innovative techniques are slow to develop and even slower to be utilised. So the idea that a world exists that focuses on working better should be applauded even though this has already been around for two decades (Bittner 2017)!

However, as much as Scrum sounds fabulous, one aspect has been tickling my brain. How does one make the teams? The composition of a team needs to be balanced before any hope of efficiency can be reached, which is especially difficult if members need to develop product-related skills (Cho 2010). On various Scrum-related forums, people shared their stories of management-built teams that ended in disaster or when all products were presented in a room, and team members picked which one they liked best. Each method has significant pros and cons that need to be weighed before the Scrum methodology can succeed. Also, to truly follow an agile mindset, people must first unlearn all their existing methodologies (Waldock 2015). Rewiring personal working structures is easier said than done, as unlearning requires accurate self-reflection, which is a tough skill to achieve.

Learning about these processes is really exposing the gaps in my knowledge surrounding agile working methodologies. I had no idea that thinking about working was even an issue. Knowing that there are many agile working structures out there has made me feel like I have been missing out. However, on reflection, I realised that my current company began using the Kanban method to keep the team updated on each other’s tasks. Unfortunately, they stopped pretty quickly as no one (including them) was quite sure what they were doing with all the post-it notes… This Kanban flop led me to make my own personalised Kanban system with excel, which worked so well that I came to be in charge of making and maintaining the board for the team. Now that I know some of the theory behind it, I can try the same technique in the coming weeks, but this time with more intention!

I will find the speed of agile very tough as I am used to complex problems that can take weeks or months to solve with many rounds of comments and changes. To deal with this, I need to practice not overthinking things and making decisions faster to achieve a goal. Additionally, I need to research the other options under the Agile umbrella to be ready for whatever UX employment throws at me. But despite the personal learning curve, I am ready to jump with both feet into agile work practices, but I will be jumping in with both eyes and ears open.

References

BITTNER, Kurt. 2017. ‘Scrum Studio: A Model for Innovation’. Scrum [online]. Available at: https://scrumorg-website-prod.s3.amazonaws.com/drupal/2017-12/Scrum%20Studio%20A%20Model%20for%20Innovation%20Dec%202017_0.pdf [accessed 23 Jan 2023].

CHO, Juyun Joey. 2010. ‘An Exploratory Study on Issues and Challenges of Agile Software Development with Scrum’. All Graduate theses and dissertations 599.

SCHWABER, K and J SUTHERLAND. 2023. ‘Scrum Guide | Scrum Guides’. Scrum Guides [online]. Available at: https://scrumguides.org/scrum-guide.html [accessed 23 Jan 2023].

STELLMAN, Andrew and Jennifer GREENE. 2014. Learning Agile: Understanding Scrum, XP, Lean, and Kanban. O’Reilly Media, Inc.

WALDOCK, Belinda. 2015. Being Agile in Business: Discover Faster, Smarter, Leaner Ways to Succeed at Work. Pearson Education. Available at: https://r1.vlereader.com/Reader?ean=9781292083728 [accessed 24 Jan 2023].

ZELKOWITZ, Marvin. 2004. Advances in Computers: Advances in Software Engineering. Elsevier.

German vocabulary of the week

Team – Mannschaft