Agile specialization: my learning story & key takeaways
Hello, dear Reader!
Today we are going to talk about "Agile." Agile is a buzzword in the IT world. It is a trendy concept in the field of IT projects. What do people mean when they say "We are Agile" or "Our project is Agile"? Is Agile a project management methodology... approach... framework? Why do we often hear Scrum when we speak about Agile? Or is it the other way around? There is so much confusion out there, and "there is no greater impediment to the advancement of knowledge than the ambiguity of words" (Thomas Reid)...
What will this article be about?
This article is a humble attempt to:
Summarise my learning path. I will share the resources I used and the certifications I obtained, as well as elaborate on why the chosen path was chosen.
Share key takeaways and reflections - of course, subjective as they are my key takeaways ??.
My learning path
Step 1: Discovery and brainwashing myself on the topic
For some, "learning Agile" takes as much as reading an entire blog for 20 minutes, while my goal was "building specialization." At Accenture, if we want to be recognized by the internal system as "specialized" in a particular area, we are expected to fulfill XYZ requirements: accumulate practical experience during a certain period, complete theoretical education, and support the knowledge with formal credentials. As such, my journey took me longer than 20 minutes...??
Even though for me, as well as for many of us in the IT field, Agile was not an entirely new topic, I started my learning curve by brainwashing myself. I am a big fan of self-learning and usually start with everything I can find for free (or almost free). For me, it means taking online courses, reading books, chasing gurus, watching youtube, listening to podcasts, observing what's happening at my work, and talking to people about their projects, etc. At this stage, I also look into informal yet resourceful platforms like LinkedIn, Udemy, Coursera, etc. - you will find many as soon as you start searching, so I will not overwhelm you as there are indeed myriads of resources online. However, I will highlight a few bright resources that stood out during my discovery phase:
The Art of Agile Development (2nd edition) by James Shore . Reading this book takes a while; it's not an immersive overnight reading. However, this heavy portal to the depth of the topic in 537 pages of tiny text is the heart and soul of my entire learning curve, I must admit. I read this book parallel to the journey, and many of its parts were revisited several times. In this book, James provides the End-to-End how-to guide for Agile adoption and provides comprehensive guidance on planning, delivery, and management.
Another book I found helpful for me as a Business Analyst is The Power of the Agile Business Analyst by Jamie Lynn Cooke. Absolutely another format, as this one is all about the daily practical activities of a Business Analyst in the context of Agile projects. Very focused, convenient, quick yet resourceful read in 211 pages, covered in a few hours over a few days - yet I keep returning to steal professional terminology from it.
A learning path on LinkedIn "Become an Agile Project Manager" - an excellent overview from a manager's perspective: what are the tools, practices, and areas of responsibility in Agile projects for a manager. Even though, according to Agile, there are no managers in teams, in reality, managers often hold projects together and are escalation points of contact.
I believe that these 3 mentioned resources, plus real-world exposure, will equip you with a rock-solid foundation for proceeding to the next step when you continue your journey toward formal credentials.
Step 2: Deciding which certifications to pursue
In my environment, I have many unique Agile Role Models. While exploring the profiles of my Role Models to understand how they got where they are, I have learned that there are two most reputable providers for Agile certifications: Scaled Agile, Inc , and scrum.org .
Scaled Agile, Inc provides very familiar agile credentials (the screenshot below is taken from here ):
Scrum.org has another very colorful collection of badges as recognition of accomplishments:
Naturally, I got to the point where I started wondering, what certifications do I need to do my work best? I am interested in product development, and I find it fascinating how a product materializes from an initial ephemeral idea into a tool people use. Considering my interest in product development, the most common roles in Agile Projects are Scrum Master and Product Owner. Also, it is not unusual for projects to include more than one team, so we need to know how to handle dependencies between them efficiently. Okay, let's see...
Both providers have Scrum Master certifications.
Both have Product Owner certifications.
Both tackle scaling challenges to handle dependencies.
Both are credible and recognized in the professional world. So...Which one to choose?
To help myself, I listed the criteria that matter to me:
Putting the insights into a small table made my choice very easy. Of course, I go with the scrum.org certifications as it's cheaper, I can do self-learning outside of working hours, and it's a life-long credential. Yes, it's more burdensome concerning learning and exam, yet these are secondary criteria (for me).
领英推荐
Step 3: Obtaining certifications
To get a certification, we need to pass a test. Every test has its format and scope, right?
Scope: I start looking into the curriculum of training providers to understand the scope. When I see a gap - I do more targeted learning to bridge this gap.
Test format: every test has its structure, type of questions and answers, and time factor (countdown). We must practice to pass a test, no secret, no magic. My approach is to play with all possible practice tests for a particular certification I find online until I easily pass them.
My goal was to complete three certifications during 2022:
I started with the Professional Scrum Master Certification in January 2022. The primary emphasis of this certification is understanding the project management methodology.
Then completed the Professional Scrum Product Owner Certification in April 2022. The key focus of this certification is on a product - how to own a vision, manage a Product Backlog,?and engage with stakeholders to maximize the value using scrum.
And closed the formalization of my Agile adventure 2022 with the Scaled Professional Scrum Certification in July 2022. Scaled Professional Scrum - Nexus. Nexus is an Agile framework used in a scaled agile project with approximately three to nine Scrum development teams. The primary focus is on project management methodology when several scrum teams cooperate. It is an augmentation/addition to traditional scrum project management focusing on managing dependencies between multiple teams.
All exams passed from the first attempt, the last one was the hardest as it included the least amount of preparation material and more questions with several suitable answers - so the risk of failure was higher, and the luck factor was somewhat important. ??
Learning path - summary. At the end of 2022 I am
So what? What are my key takeaways and reflections?
The year 2022 with my Agility mastery journey, was fruitful and productive. I took a lot from this adventure, yet I will bring up three key points that are the most meaningful to me. In this section, I will allow myself some strong opinions ??
One: Is Agile a magic wand?
Agile is a project management philosophy guided by a core set of values and principles, while Scrum is a practical Agile methodology aiming to facilitate a project. Brian Marick, one of the Agile Manifesto authors, used to say that "Joy" is an integral Agile value.?Agile philosophy presumes work as a game in the sense that we are the most creative, productive, and cooperative?when we enjoy our work - what we do and how things are done within the project. It is simple but powerful. While Agile promotes having fun and enjoying the work,?different aspects of SCRUM help with its practical implementation maximizing produced value.
To me, it's evident that Agile philosophy and SCRUM methodology complement each other. Without philosophy, methodology becomes a dry set of guidelines, a chain of calendar events, milestones, and deadlines. Dry methods without principles are meaningless. On the other hand, similarly to "dream without a plan is just a wish," - Agile philosophy without practical methodology is not a viable approach.
For sure, it's easy to describe the general idea of Agile ways of working, as well as it's easy to follow the Scrum methodology. What is not straightforward is how to secure buy-in from team members - keep them in tune and intact. How can we fix poor leadership (following methods isn't leadership), negative group dynamics, disengagement, team inaptitude (lack of professional skills), apathy, bad timing, lack of luck, fixed mindset etc. - you got it. Unfortunately, Agile projects aren't immune to any of these. How can we unfold the true potential of every individual and a whole team?
Coming into IT consulting with an Applied Psychology background certainly impacts how I see the world. People are complex creatures - everyone has their own needs. The list of possible private needs is endless - support, empathy, understanding, empowerment, security, admiration, affection, approval, guidance, inclusion, privacy, validation, praise, respect etc., etc., etc. . There is no one-stop-shop solution to build and maintain rapport with different people - everyone is unique, everyone requires an individual approach. Then add one more layer of complexity - how to make all these unique creatures cooperate and complement each other so they become a true team? How to make the team more than a sum of its parts? Agile philosophy and Scrum methodology are for sure not enough. Possibly I am exaggerating, yet to me:
This big blue bubble is the entire world of fluid factors, with most of the complexities coming from people. Two frameworks come to my mind in this context now. I will mention them briefly below - feel free to google them deeper.
The SCARF leadership model that I have already mentioned in this article - encourages leaders to intrinsically motivate others through positive reinforcement. This quote makes the model even more powerful: "People often say that motivation doesn't last. Well, neither does bathing - that's why we recommend it daily." (Zig Ziglar)
Another angle to look at people's motivation is the famous Hierarchy of Needs of Abraham Maslow. Always relevant. I love to think about why people behave the way they behave and what their main driving forces in life or a particular situation are. There are many angles to look at it, and this simple pyramid is my regular go-to point. An image is taken from here .
As you understand, despite respecting and appreciating the Agile approach (philosophy + methodologies), I firmly believe it is not an end-all-be-all. Agile is only part of the story, it's not a magic wand to secure ultimate success.
Two: Agility and (Ir)rationality
Even though the business model of Scaled Agile, Inc is artfully crafted to maximize profit at every single touchpoint (training, certification, maintenance) and lock clients into the system forever (famous lock-in effect) - certifications from this provider are still industry standard as many companies are hooked to SAFe framework as their default ways of working and continue the following inertia despite the associated extra costs. Not ideal, but a substantial chunk of industry players accepted it. As a result, it is often a formal requirement for potential consultants or new employees to have SAFe training and be holders of SAFe certifications.
Three: Agile is the meeting point for technical and non-technical people
Based on my current worldview, my career path is linked to roles such as project management, product ownership, scrum mastering, etc. These roles lie at the intersection of Business and IT. All these roles presume a collection of pretty Agile Certificates and colorful badges - meaning that Agile expertise is the common ground for people in such positions.
I see two typical profiles for such roles: (1) business/management background; (2) technical background. Which is better for the role of project manager/product owner/scrum master? I do see a lack of technical insight into product development in professionals with business/management backgrounds. On the other hand, I see a lack of people skills and business acumen in professionals coming from a technical background.
To make things work, we for sure need to be Agile, yet it's only the tip of the iceberg. Maybe I'm harsh, yet I believe that in different proportions, we need to be everything at once - we need technical insights, people skills, and business acumen. I have a tough time favoring or deprioritizing any of these areas. We shouldn't aim to be equally good in everything as we have our passions, yet we do need to stretch ourselves on the spectrum and go a bit deeper into each other's areas. People from technical backgrounds need to invest in finding and building their people skills for everyone's convenience. People from business/management backgrounds should take on the technical challenge and play with those technologies that are used for a particular project. It's essential to play to get a tangible sense of technology, not only through PowerPoint and simple abstractions. It seems now that Agile is the place where technical and non-technical worlds meet, yet as I already shared earlier - Agile tackles only a tiny fraction of the actual complexity in IT Business projects. We need more overlappings between technical and business profiles.
Reservation agent at Hotel Planners
1 年This is a great achievement!
Great summary, thank you for putting insights together Anastasiia Tsarenko ???? ??
Now I have a plan. Thanks for great summary and sharing.
Helping Businesses Optimize Customer Service with AI, CRM & Genesys Solutions | Consultant??????
1 年Great article! Thanks for sharing the journey ??