PO traits

In meeting several wannabe agile enthusiasts and folks transitioning from waterfall to agile methodology, I realized that a blog post might be helpful for you to understand the traits of a product owner better. You might already be doing some pieces of it. These might be handy for you while applying for PO jobs.

The scrum guide describes the top responsibilities of a PO as below -         

• Clearly expressing Product Backlog items
• Ordering the items in the Product Backlog to best achieve goals and missions;
• Optimizing the value of the work the Development Team performs;
• Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and
• Ensuring the Development Team understands items in the Product Backlog to the level needed.

I would like to dive deeper into this from my personal experience. This might help you transition better into the role. -

Backlog management

•  Requirements come from multiple areas; typically from business stakeholders, regulatory, technology upgrades.
• This might sound trivial but is very important. You could get requests via email, chat or meetings. You need to ensure that these get listed in your tool eg: JIRA, TFS etc. so that they don’t fall thru the cracks. If you are organized then this is going to be very helpful.
• Constantly interacting with your stakeholders is key. In your previous roles if you have been interacting with stakeholders then you certainly have one of the important PO skill sets.
• You don’t get requirements cut and dry from the different stakeholders. You have to analyze these and get it to a stage where the team can implement them. You might have to factor in technical factors too and rope in your technical lead or developer to get closure on the final set of requirements. In your previous role, if you were a business/system analyst, then you are perfectly positioned to be product owner.
• Technology upgrades and constantly addressing tech debt is the enabler to faster delivery. This is also a backlog item and the skill is to schedule these items at the right time. In some companies, this is a concept that is understood by business but in others, you have to have a conversation with your business. You are not expected to code but you need to work with your technical lead closely to understand the impact to your product.

Decision making & Stakeholder management

• A well-rounded experience definitely helps you to become a better PO. This is because you can talk to business and technical stakeholders and clearly understand what they mean. So, if you have experience on the business and technical side then that is a huge plus. It helps you connect the dots between business and technical requirements.
• What separates you from all the other roles such as a business analyst/tech lead etc. is the fact you get to decide what the team works on next. You are the one person committee that decides what the most valuable thing is to work on.
• You see the whole picture for your product – Feasibility of implementing each of the projects and the value of each of them determines the order in which you do things. In the past, your inputs could have been crucial to the different decisions made in the project. This is also a trait of a product owner.
• This means that you need to negotiate with the different stakeholders on the delivery dates of their requirements.
• Training users with your product – You are the 1^st point of contact for the product.
• Status reporting to all stakeholders – Many of the times the stakeholders are interested in only their requests and so timely status reporting brings transparency to everyone.

Your team is the biggest asset!

This is a common trait along with the scrum master. As a PO, you have to extract the most value from your team. Talking to your team opens many ideas and helps build their trust with you. It helps to make decisions that the team will support and ultimately a win-win situation. You need to be team-person and if you are not a team person then you might want to rethink your role. (Nothing wrong with that !!)

Hope this helps you plan your foray into being a product owner.

Agile/Digital transformation

You may have heard these terms in your workplace or if you are a newbie scrum master/product owner, you may wonder what this is all about. Having been part of 2 companies that are transforming, I‘d like to share some insight.

History

Let’s take you back 100 years from today! No internet, no seamless collaboration between creative minds across the world. The jobs back then are obsolete today. I don’t have to sell you on that. Specifically talking about computers and mainframes, only big companies could afford them since they used to cost a fortune and occupy space for an entire room. This was the perfect situation for big companies to thrive. Scientific advances were there but not as much to threaten the existence of big giants.

Fast forward to the early 2000s

With the rise of the internet, more creative minds collaborating throughout the world led to rise of startups. Every possible industry is digitizing and thereby information technology and software development is hot. Companies are getting closer to the end-consumer because consumers have choices – national and international. The world is getting smaller in that sense. With artificial intelligence, companies are trying to predict want the consumers want. The line between industries is also blurring. Who would have thought the meteoric rise of a company Uber would pose a threat to taxi industry! In terms of financial services, there are several small startups offering better investments than the big giants – ALL making it easy to manage your investments online. Earlier, the companies knew their competitor. But with the lines blurring, it is hard to even predict who your competitor is.

What are these big/medium companies trying to solve?

As you might have guessed, with the landscape described as above, companies today have a ton of problems. Unless you are a company that just sprung out in the last 5 years, as the COO and CIO of an older company, I would be worried.

First off, the organization structure of older companies has accumulated fat over the years. Previously, your career path looked somewhat like this; team member -> team lead -> manager -> senior manager ->  director -> vice president -> C level.  In other words, your career progression was managing team leads, departments and there were several levels to that. Over time, this has caused teams building the product to move further away from customers. It took months or even years to get features delivered due to inefficient processes of getting work prioritized. Adding several levels within the organization has not added much value. In order to be more nimble, companies have to empower their people. They want to have all the relevant people on the team for faster delivery and proximity to customers.

There are several companies that still follow the waterfall process, where problems are not exposed until the end. The “2019 state of agile” survey still denotes that there is still a significant population of companies that haven’t adopted agile. To play devil’s advocate, it requires the C Level folks to understand the problem to be able to take the risk and also astute planning to transform an organization that was using waterfall to agile. It is a big shift and cannot be done overnight.

Enter agile delivery – Companies that started following agile are in for something else. Be careful what you ask for. J Whether you follow scrum or Kanban, any form of agile exposes the flaws of the system. C-level execs can now see when teams are working on projects that they requested and when they finished. As a result, it exposes the fat in the system. One of the things that management wants to measure is the time taken from the ideation phase to customer delivery. Typically, a significant portion of the time taken is due to the time taken to even get into the team’s backlog. That is why the C level execs are looking for ways to prune that process. In one of the companies I worked, they had all these senior managers in middle management reapply for the new roles because as part of the transformation they are cutting down roles that are redundant.

Managing career progression of employees is also a very big HR and C level problem. Junior folks are concerned about what their next goal should be. They don’t want to work towards something that will be cut off. Middle management folks are frustrated because in the past, they were rewarded for being managers and not being in the trenches. For many of them it would have been years before they were part of an actual delivery and all of a sudden they lost marketable skills! It is a huge change of mindset too for these folks. It is either change or get let go. So, the C level guys have to retrain these folks for new roles.

Finding a scaling solution for the company

To compete with startups in your industry, you have to solve the additional problem of scale. By now, most of you must have heard about the “Spotify model” for agile or even he SAFE model. Many execs treat it like a silver bullet to all their problems. For sure, agile has made teams faster. However, for big/medium companies that have over 5000 employees, you have don’t have a “model” that you can apply as-is for scaling. Communications from top management to the teams needs to be improved. You have to solve the real demons facing you. For example, the “Spotify model” doesn’t really solve the problem of how an idea can get into a team’s backlog for execution. It has to be something that the top management has to figure out. If you are a regulated company, there are several processes and documentation that has to get done. If you want to do weekly or even daily releases like Amazon, Google then you have to solve these problems too. No model can tell you that. Food for thought is depending on your industry, is releasing daily required? J Is this what your customers want truly? You have to inventory the problems that are truly slowing you down and solution those with your employees. There is only so much you get for free!

Hope that this gives you some insight into agile/digital transformation that you might be hearing about.

Disclaimer – Thoughts and opinions are personal and based on the author’s experience only

Should you have technical background as a scrum master/product owner?

Agile delivery has been popular over the last few years. Although it started with software delivery, it is now popular with other industries. Sometimes during interviews for scrum master on a software team or even during conversations, you could be asked if have a technical background. Personally I did have a technical background before I turned scrum master and product owner. There are both pros and cons.

Why are people interested with technical background?

Typically what they mean is, if you have been in any part of software development – For example -Analyst, Developer, Tester. If you were in any part of software delivery, then you would have experienced SDLC i.e. software development lifecycle. More than anything, software development is collaborative work. You cannot operate in isolation. For example, you have to collaborate on design, tests, other teams. If you would have worked in a software delivery team, you would know what it is to work with other people. It is not uncommon that if you were a successful team player, then you would be empathetic towards your team. Scrum ceremonies are important but that’s not the only thing that the scrum master is responsible for. No one wants a “task master” just trying to get statuses. Soft skills are HARD and perhaps harder than learning technical skills. They would want someone that understands the team’s problems.

Organization structure

Every organization is different and form scrum teams differently. Some teams are truly full cycle i.e. extremely less dependency on external teams. In my opinion though, many companies can never truly have full cycle teams because eventually they are too big to be independent. You could be more efficient and even release independently. However, it takes a village to release the final product! In most cases, to truly release a minimum viable product, there are multiple teams involved. Some common examples of the way teams are formed.

·         Technology focus - Some teams do API or UI or database work exclusively.

·         Own part of the flow – Some teams might own specific functionalities. For example, search feature page could be an app by itself and your team could do UI, API, database etc. However, the reality is that you get projects involving multiple features. In other words, you are just part of the project. Although you may be able to release independently, the project cannot be turned “on” unless everyone else is done. In short, in most companies, no matter how you slice and dice the teams, you cannot operate in isolation.

 Understanding the responsibilities of your team & your dependent teams is really important.

Pros of having a technical background

·         Removing impediments is one of the responsibilities of a scrum master. If you understand the organization structure as mentioned above then you will be able to figure out the network required for your team to operate.

·         Champion your team’s pain points – I see this even with the best of tech leads/developers/testers. If you need decisions/clarifications from external teams/senior staff then you need to champion your team’s pain points. A lot of times, your team might not be in the forum (for example - scrum of scrums meeting) to raise these but you as scrum master might be involved. Understanding pain points might help you raise risks appropriately. Knowing the network of people and understanding pain points will lead to faster removal of impediments. You can involve the right people at the right time depending on the situation.

·         Better conversation with the team – Many companies are involved in agile transformation to be able to deliver faster. This means that modernizing the tech stack. Teams will face challenges and need help from outside the team such as from architects, open source companies etc. Supporting your team and understanding when they are truly blocked is important. Talking to your developers and testers can help your understand their problems better.

·         Identifying risks – With an understanding of your team’s ecosystem, you can watch out for risks. For example - Company execs love agile delivery but also still give you deadlines around production delivery! That mindset has still not changed. Sometimes your project might have fundamental questions unanswered. With a technical background, you tend to see RED sooner.

Cons of having a technical background

·         You have to learn to shut up J appropriately – While you will understand your world properly if you have had a technical background, you‘d have to back off when it comes to technical decisions. Software design is an art. There are several ways to accomplish the same thing. The tech lead/developers/testers will figure that out. If you have a different idea, you could ask a leading question but know that it is NOT your call. Your job is to get consensus and figure out if there are blockers. It is hard to do that, I admit and do not take anything to heart! Your role has now changed to a consensus builder and working with tech leads/developers/testers to create the best solution. Using your background for better conversations is a tough skill!

What part of technical background do I really use?

It is long since I coded but as a scrum master/product owner, I use my analytical skills more than anything else. Understanding the flow between major components/applications is the key to several conversations – like who owns different components. The right conversations with the right people move the needle. As a scrum master, you are often in a position to drive this. I try to use my background to have the right conversations!

What can you do if you don’t have a technical experience?

The good news is that you can still be successful without such expertise. Learning basic concepts can help you prepare for your career as scrum master in software delivery. The article describes the training and readings you can do to prepare for the future.

Disclaimer – This blog is just based on the author’s personal experience. Use your own discretion.

How to start as scrum master or product owner in software?

If you have never been a part of software delivery and want to enter this world as a scrum master or product owner then this blog is just for you. As a newbie SM or PO in software delivery, it might be good for you to take a couple of courses to understand basics of software delivery. The goal of these is not for you to learn coding although it is a very good segway should you be intrigued. These courses are not Nirvana! They will set the path though to help you understand where to look. There are many skills that are interchangeably used between scrum master and product owner. These are courses I found online (Not all of it is free) but there is a lot of material on this on the internet. You can go thru the course content and find free articles/content online. Take your pick.

Scrum master and product owner training

There are several avenues to get certified as a scrum master or product owner. Some of them are as below –

• Scrum.org’s PSM or PSPO – These certifications do not expire and are a little more work than CSM. IN my opinion this makes sense because these principles and techniques are not dependent on technology or industry. It is also cheaper than CSM/CSPO at least in North America.
• ScrumAlliance.org’s CSM or CSPO – The certification is valid for 2 years and has to be renewed. The test is relatively easier.

It is best if you can get your company sponsor these certifications. If your company doesn’t sponsor it or you are unemployed and trying to get in – Go for scrum.org.

Software Development Life Cycles

Although as scrum master or product owner, you would be working on agile methodology, it would be useful to learn more about other methodologies. You can employ techniques of different methodologies based on your situation. Every methodology has its pros and cons.  

1. Waterfall – Traditionally companies used waterfall for software development. What this meant was that it took months or years to release software to production, costing business several million dollars. Companies are now mostly switching over to agile because of faster feedback and better transparency.
2.  Agile – In order to shorten the feedback loops, agile came into existence.

a.       Scrum

b.      Kanban

c.       Pair programming

System Analysis skills

In order to understand your ecosystem of teams (dependencies and stakeholders), some level of system analysis skills is needed. The product owner role requires more of your analytical skills. This is just entry level stuff. In a later post, we will talk in depth about that.

There are several technologies like .Net, Java etc. and even open source ones which are springing up daily. RELAX – You are not expected to learn these technologies. You need to learn the concepts so that you can understand the work to be done. For instance you can write an API in Java as well as .Net. As long as you understand the various components you are covered.                                                                                                                                                                     

• https://www.udemy.com/business-analysis-ba/
• https://www.udemy.com/process-mapping-process-flowcharts/
• Basics of Application Programming Interface (API) -  https://www.udemy.com/course/learn-and-understand-apis-and-restful-apis/
• User Interface (UI) - https://www.udemy.com/design-rules/?couponCode=

Agile management tools

Companies use several tools to manage their backlog. These are very easy to use but very powerful. For many companies these are the popular choices. AS a product owner/scrum master, you will have to be proficient with these tools to enable your teams and improve productivity.

•          Atlassian’s JIRA and confluence - https://www.atlassian.com/software/jira https://www.atlassian.com/software/confluence 
•          Asana – https://asana.com/   
•      Trello – https://trello.com/en

All of these have similar features and there are several companies that have free/paid plugins on top of these tools. As you advance, you will try out these plugins. These are easy to learn.

Hope that this helps you get started.

Disclaimer - The links provided in this post are based on personal experience only. Please use at your own discretion.