What Scrum Certification should I take?

A question I have heard a few times in my career “What Scrum Certification should I take?” They ask me most often because I am a Scrum Master.

This question is often from people whose direct role or responsibility is not in Managing Agile teams or even Project Management. I have had these questions come from developers and Business Analysts and QA Engineers. So I often try helping with a counter question “Why do you need a Certification?”

This question often takes me through some interesting learning experience. Here are a few responses I get

  • I get a blank stare like I asked them a question I should not have asked.
  • They look at me like I don’t understand why people take certifications.
  • Some people say they just want to learn more about Agile.
  • Some say better prospects.

I take time to converse with them irrespective of how they respond. It is important to me as an agile practitioner and coach, especially when my purpose is to bridge the gap between certification and execution.

If you are in the Project Management or Program Management role or planning to get into that, a Scrum Master Certification is definitely going to give you that edge. Just like I made my transition over the years. It makes perfect sense if you are planning to transition into an Agile role that is in line with what you have been doing, but in an Agile way. Though keep in mind that a Scrum Master and a Project Manager are not the same in anyway. You will find it as you transition. Though you find a lot of people out their who put out job descriptions like Technical PM aka. Scrum Master and so on. They are either not clear on what they want or want to mix a few roles into one.

You got to be better than them in defining what you want to do and what you are good at doing.

I have spend a good amount of time talking to hiring managers and recruiters when they put out a request for a Scrum Master and most time they just say things like “We want a Scrum Master who can also act as a Technical Project Manager and even write user stories and coach the team and on and on..” To them I would say, “Get realistic on what you want… go figure out and then put out a request”. I have to be honest that it does not always get into the next level of conversation. But you know what, if you land in a role that even your hiring manager is not clear, you are bound to be unhappy. But yes we all make compromises when the bills wait at the door knocking.

But you got to do your own thinking on your role, your present and your future.

I will try briefly explaining a bit into the various roles and certifications. I will do some detailed writing on each in the coming days. Subscribe to blog so they reach you. Or follow me on twitter

There are a several different bodies that offer the Scrum certifications; some more popular than the others. Everyone has their own way of representing their certification values, but I often like to see the certifications from three major roles. The Product Owner, The Scrum Master and the Team Member. I would say four roles if you add the Agile Scrum Coach. But for being a coach you need much more than just a certification and that is why I started this blog. This blog is both my work and my learning and thinking and findings all together.

If you find yourself wanting to make a team effective so they can deliver better products then you ought to be looking at being a Scrum Master. In my personal opinion you can reach there from any point in your career and with any role you are in currently. The need is for you to completely inculcate the core responsibility of a Scrum Master, ‘to coach a team on the Scrum Principles, help them with being an effective Agile team that is self organizing’. More on this later.

If your role has been more closely with working with business and that is how you want to continue, I would recommend the Scrum Product Owner Certification. This would help you understand how you can take ownership of building a product ground up in the Agile way. On how you can prioritize features and functionalities and have that big picture distilled down to releasable chunks as they all connect to a full fledged product by time-boxing those chunks.

Now if you are a developer or QA Engineer and would like to take up Agile I would recommend taking certifications that are tailored to developers. You need to get good at understanding the estimation methods and be able to commit what you can deliver and understand the concepts of continuous improvement, integration and the tools associated with it. You also need to have a firm understanding on the roles and responsibilities of other Agile roles. This will help you be a better team player.

We live in a world where certification acts as the first screening point for many roles. It gives the hiring party a way to filter the candidates they want to talk to. A certification can get you an entry to talk. Is that your intention to getting a certification? If so then get it, Getting certified is not rocket science, if you are thinking of a certification, then I think (without knowing you) that you can get it with some effort. Can you do the job well? I don’t know because that has a lot more than certification. It depends on your experience the person you are and your true genuine professional acumen. This blog is to bridge that gap.

Ultimately think about What makes you happy? To steer the Ownership of a Product, To help teams or to build a product. I like to help teams and that is why I am a Scrum Master and a Coach. And I have found that over time, I have been able to coach and mentor product owners, developers, QA Engineers and Managers by adding value through a 360 degree understanding of the Agile Scrum Methodology and an ongoing thirst for learning. All coupled with a personal agenda of continuous improvement, something I learned when I entered the Agile framework and chose that as my professional trajectory.

My recommendation would be that take a certification with a definite purpose in mind. See if that certification aligns with your professional aspirations and let it give you that entry in the door. But be aware that continuos learning is the key and not one certification after another.

Advertisements

Using Retrospective Meeting For User Story grading

We have all heard or asked this question at least once if not more

“How do we write better user stories”.

How do we put ‘in words’ what we want to be built. Both the Technical team and the Business team try to get their heads around this one.

What does a better user story mean? When people sayA better user story’ in most cases they mean that the it should be clearly defined with very clear acceptance criteria or Definition of Done. Think “How can the developer know that the story is Done”. If the developer does not know when the story is done then it will never get done.

The problem in writing better user stories- User Stories are written by people and people vary in their analysis, probing, breadth of knowledge and the way they articulate a need. We can draw guidelines for some completeness and uniformity but it is up to the folks who write and what tools and processes they have to get feedback, reflect and correct and better.

There should be a simple way in which bad or less complete user stories are identified, Analyzed and Communicated

The Retrospective Meeting – I recommend using the retrospective meeting to be the starting point. Start by rating the user stories in the Sprint for its completeness and clarity. This is done from the Scrum Team perspective once the delivery is done. Give a 1 to 5 rating and pass that feedback on to the Product owner or Product Analyst who is involved in writing the user story.

This process will be very effective as over time you will have a very clear understanding on what and how you can create a user story that captures the complete essence of a need and also make it complete enough for developers to deliver.

This is also important for developers because in many cases user story is not just an activity done by someone in silo, there are sessions where the technical team asks questions and gets answers. Once you start rating your user stories after delivery you also find other bottle necks that influence the completeness of the user stories.

Embrace Scrum at an Organizational Level

The Agile Principles and Scrum has been around a while now. If you take folks in the tech industry most of them have worked or been connected with a Scrum team sometime in their career. There are also many who will say they followed a Hybrid model and some would say they just follow the ‘Spirit of Agile’. Having more than one recognized certification body in the world for Scrum also opens more discussions on how and why and which way. All in the best interest of improving what they do.

There are also people who rally behind the Scaled Agile Framework while some who say the whole concept of scaling defeats the purpose of Agile. Some would even say that distributed teams are a complete NO for Agile and at the same time recognize that it is a necessary evil to deliver products and projects in today’s age and time. The fact is that there will be debates and difference of opinions when you have a model where you are given ample room to innovate and continuously improve while following the basic rules and principles. That is what Agile is all about. But here we are specifically going to talk of SCRUM and why organizations should embrace SCRUM, that philosophy of teamwork and alignment.

Over years to working on projects walking (or sprinting) on the pavements of the Agile, Scrum, Hybrid, Spirit of Agile and ‘our own Scrum’ models my take has been that this damn thing works well whatever name we call it as long as we follow the principles. And that is why it is important for companies to embrace it on an organizational level.

The mere psychology of breaking down something large and delivering in small increments to a customer who becomes delighted seeing something working in itself will add such a tremendous productivity over time. It is not a prefect world and we as human beings are a mix of colorful balloons all having a different color and degree of air filled in us but ready to pop anytime. That is what makes the whole Scrum team concept so interesting and lively, at least for me.

As Scrum Masters, Product Owners and Scrum Practitioners we have all had the opportunity to work with teams and stakeholders who all have their own perspective of what needs to be done. We all have come across the debate on what is the ‘Definition of Done’ even in teams who have been practicing Scrum for a while. Yet we see that many of them have moved from competition of individuals to collaboration within and among teams unlike our traditional waterfall methods.

One of the interesting challenges organizations face is that they do not always know if employees are happy, content and doing their best. Processes don’t speak well about the truth of human beings. And the traditional way of understanding the employees have also changed. Added to this companies often have a mix of employees and contractors (from different vendors). The collective happiness index of an organization is the happiness of all these groups added up. But organization wise they often only have systems to take care of employee’s happiness because contractors are always bound by contracts. But given a chance People will always rise above the limitations of company policies and create a better workplace for all.

The value we should see for Agile and Scrum in specific is that it has an inherent ability to infuse collectiveness. Scrum Method allows people in a team to connect and align beyond badges and titles to a common goal in a very close knit environment. If we look we can find that there is more synergy within people working on an Agile project vs. a project in a Traditional Waterfall Method. The sheer commitment to roles and responsibilities over titles.

On a Personal note my passion for the methodology was also developed over a period of time and I have seen that it has created long term meaningful connections with people with whom we work on agile projects. I guess it is because Scrum gives us so many more avenues to interact in person with the team daily. May be the role of being a servant leader also helps in connecting better with the team.

Being a Servant leader should be the goal for every leader because you cannot lead without serving your team. And for organizations who do not follow Agile now, Start a pilot project and feel it evolve. It is not just about fast delivery it is about continuous improvement at both an employee and an organizational level.

How I became a Scrum Master

The best way to start this Blog is by telling you how I got here. I have several years’ experience working in the Hi-Tech space across three continents and 4 countries. It is nothing great looking at how traveled the general Tech Public is now a days. Before I got into Software Delivery I had a stint in Software Services Sales, Professional services, People Management and Product Marketing. I ended up at the Software delivery side of things via a Content Management route.

Around 10 years back I became fascinated with Content Management starting with my love for blogging. I started with delivering open CMS solutions and progressed to enterprise CMS solutions using Documentum Web Publisher and Adobe Experience Manager. Somewhere in between I landed on a Scrum Master role. It was more of a PM role that ran on Sprints. It is true that before this I had some knowledge of Scrum and had read a bit about Agile Programming as I was transitioning from the front-end customer engagement into a delivery role but nothing enough to be a Scrum Master. Some people say that is a reverse progression Customer Facing to Delivery :). I don’t think so because there is only progression, no reverse or forward progressions.

Wearing a Scrum Master’s Hat with no formal training in Scrum had both its benefits and Challenges. The benefits included that solid foundation learned from really getting hurt bad. The Challenge always the long learning curve and the bruises that came with it. But all went well for me by the time I got myself certified. And that was two years into the game and many decent Sprints.

So for me I was playing the role of a Scrum Master much before I was officially certified as one. May be that is why I always think Certification should be backed with real experience on doing the work, always. I am not saying it has to be in the same order as I had. Since I learned much of it on the job, I went through so much iterations of my own knowledge and skills, that I kind of started having a philosophical connection with the Scrum Model. I started seeing this whole process work for me personally that I started looking at Scrum beyond just the development of software.

Getting Certified was an interesting turn of events, because till then though I was a Scrum Master in my role, I did not really go out and say I was one even in my resume. I continued to call myself a Project Manager. But once I got certified I also started meeting many other people who had certification. To my surprise some of them had nothing to do with Scrum. A point when I felt my Pre-Certification experience added so much value to me as a Fresh Certified Scrum Master, when it comes to acting on the field.

Another turning point in my Scrum career when I did my first training online for a team of 25 people with an average experience of 10+ years and included Project Managers, Delivery Heads, Developers, QA Engineers and so on. A team of 25 who logged in for a 16 hour session across 4 days from many different countries. That is when I figured that my practical experience and learning from my own mistakes coupled with my story telling based Coaching and anecdotes kept a virtual class going well. This told me that it is time to switch into an Agile Coach role, but by always wearing the Scrum Master hat, because every team is different and there is so much learning on the field when you work with different teams.

When you are a Scrum Master for a while people always think what next. Some go the Manager Route, Some go the Coach route and some even go the Product Owner route. But I chose a role of Scrum Master for multiple teams which helps me to be a Scrum Master for some team and a Mentor and coach  for others.

Finally I decided that my career Goal is to bridge that Gap between Certification and Execution and the best way was to start a focused blog, that will help other aspiring Scrum Masters, people interested in getting certification  and also help me in advancing my career.

www.scrummodel.com is a blog as well as a place for people to reach me in y professional capacity (other than the poet, writer and podcaster in me). A place where I can add practical tips, questions I have and my ‘thoughts-gone-wild’ from my experience in a ‘Not so Perfect’ world.

Coming to the perfect world, An ideal scenario is good and an understanding of that is needed for a foundation, but we all know that ideal scenarios do not exist everywhere. Every organization and every team and every individual is in a constant state of change in one way or other and you need to be creative in your processes and its practical application in order to build great products without complicating things.

I welcome you all as in the coming days as I share my thoughts more in here.