Kickstart your career with best deals on top training courses NY10 Click to Copy

Search

Scrum Values: Is The Focus Really On People?

I recently conducted an introduction to Scrum for a new team. My preparation started with the Agile Manifesto and the 12 Principles of Agile Software Development (http://agilemanifesto.org/). I have read and re-read the Agile Manifesto and Principles repeated, but the one thread that stuck out in this recent review was ‘people.’ Values of AgileThe four core values of Agile software development as stated by the Agile Manifesto areIndividuals and interactions over processes and tools;Working software over comprehensive documentation;Customer collaboration over contract negotiation; andResponding to change over following a plan.12 Agile PrinciplesThe 12 essential Agile attributes articulated in the Agile Manifesto are:Satisfying customers through early and continuous delivery of valuable work.Breaking big work down into smaller tasks that can be completed quickly.Recognizing that the best work emerges from self-organized teams.Providing motivated individuals with the environment and support they need and trusting them to get the job done.Creating processes that promote sustainable efforts.Maintaining a constant pace for completed work.Welcoming changing requirements, even late in a project.Assembling the project team and business owners on a daily basis throughout the project.Having the team reflect at regular intervals on how to become more effective, then tuning and adjusting behavior accordingly.Measuring progress by the amount of completed work.Continually seeking excellence.Harnessing change for a competitive advantage.When I began to reflect on my training materials, it came back to people.When I began to reflect on my experience, it came back to people.It all came back to people.In fact, one of the four Agile guidelines speaks to people (25%).Individuals and interactions over processes and toolsAnd five of the 12 Principles of Software Development speaks to people (42%).Business people and developers must work together daily throughout the project.Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.The most efficient and effective method of conveying information to and within a development the team is a face-to-face conversation.The best architectures, requirements, and designs emerge from self-organizing teams.At regular intervals, the team reflects on how to become more effective then tunes and adjusts it's behavior accordingly.Not just the people but the right people. Having the right people, is a part of the process. Not only it is a part of the process, it is essential to the success of a Scrum team. First, you need to ensure that you have the right skills represented.Does the team require architects, analysts, quality assurance, UI/UX, etc.? Does the team have an identified Product Owner (single wringable neck)? Does the team have a Scrum Master identified? The team should be 7 + 2 and should include the product owner and scrum master.Once you’ve determined that you have the right skill representation, you then need to evaluate if those people are the right people. Below are 6 “C’s” defining traits showing the ‘right people’ constituting the Scrum team.1. CommunicativeCommunication is a key element of the scrum as highlighted in the manifesto and 12 guiding principles. This is a fundamental change for individuals that are used to working in a silo. Scrum requires at least daily communication.Stories are often written with minimal detail in order to facilitate a conversation. Scrum requires proactive communication (don’t wait to be asked). Scrum requires great listening.  That means that the right persons need to understand the importance of communication and embrace that importance by exhibiting or learning to exhibit a proactive communicative disposition.2. CollaborativeCollaboration is also a key element of the scrum. Again, this is a fundamental change for an individual that may be used to working in a silo. Scrum highlights the ‘success and failure as a team’ mentality. That means that the team has a vested interest in and right to ensure that work is getting completed and done correctly.This is a two-way street, not only do you need to have insight into everyone’s work, but you must also be willing to provide the same insight into your own work. The team needs to be willing to pair program, swarm or even mob around stories for the team’s success.3. CreativeScrum team members need to be creative. They need to have an ability to be told what is needed without requiring someone to explain ‘how.’  Stories in their purest sense are single sentenced with perhaps a couple of sentences of acceptance criteria.4. ConnectedThe Scrum team member (including the Scrum Master and Product Owner) need to be connected to the team.  What does it mean to be connected? It means to be invested in the success of the team.It means that they know one another, they know how to interact with one another, they know how to make one another successful and in turn make the team successful. A good scrum team truly works hard and plays hard together.  A good scrum team member needs to be willing to develop a ‘work-family’ with his/her scrum team.5. Co-locatedIt’s controversial in the age of telecommuting, but a co-located team member is the best. Face to face conversations trump video conference calls, phone calls, emails, IM’s, etc. Collaboration is immediate and organic when the team is co-located. Connectedness and camaraderie come to a lot easier with co-location.  Co-location makes spontaneous collaboration via swarming, pair programming, and even mob programming that much easier.6. CoachableIf the person doesn’t possess any of the above attributes they are coachable. Not everyone will possess these skills, so coachability becomes one of the most important elements for any team member. Everything else can be taught and demonstratedIs Scrum all about People?Agile and Scrum are making the implementation of the software projects more successful by meeting the user’s, customer’s, and the business needs, and at producing software much more quickly and responsively than the traditional waterfall methodology.All the characteristics of a good Agile team is depend on these values. Once the team is identified and evaluated to be the ‘right people’ you can begin investing in team-wide training/education to establish a baseline understanding of the Scrum, the roles, the ceremonies, and the terminology is a great start to start any project in the organization.
Rated 4.0/5 based on 1 customer reviews

Scrum Values: Is The Focus Really On People?

5K
  • by Jeremy Smith
  • 26th Oct, 2018
  • Last updated on 31st Jan, 2019
  • 7 mins read
Scrum Values: Is The Focus Really On People?

I recently conducted an introduction to Scrum for a new team. My preparation started with the Agile Manifesto and the 12 Principles of Agile Software Development (http://agilemanifesto.org/). I have read and re-read the Agile Manifesto and Principles repeated, but the one thread that stuck out in this recent review was ‘people.’
 
Values of Agile

Values of Agile
The four core values of Agile software development as stated by the Agile Manifesto are

  • Individuals and interactions over processes and tools;
  • Working software over comprehensive documentation;
  • Customer collaboration over contract negotiation; and
  • Responding to change over following a plan.


12 Agile Principles

The 12 essential Agile attributes articulated in the Agile Manifesto are:

  • Satisfying customers through early and continuous delivery of valuable work.
  • Breaking big work down into smaller tasks that can be completed quickly.
  • Recognizing that the best work emerges from self-organized teams.
  • Providing motivated individuals with the environment and support they need and trusting them to get the job done.
  • Creating processes that promote sustainable efforts.
  • Maintaining a constant pace for completed work.
  • Welcoming changing requirements, even late in a project.
  • Assembling the project team and business owners on a daily basis throughout the project.
  • Having the team reflect at regular intervals on how to become more effective, then tuning and adjusting behavior accordingly.
  • Measuring progress by the amount of completed work.
  • Continually seeking excellence.
  • Harnessing change for a competitive advantage.


    When I began to reflect on my training materials, it came back to people.
    When I began to reflect on my experience, it came back to people.
    It all came back to people.
    In fact, one of the four Agile guidelines speaks to people (25%).
  • Individuals and interactions over processes and tools

And five of the 12 Principles of Software Development speaks to people (42%).

  • Business people and developers must work together daily throughout the project.
  • Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  • The most efficient and effective method of conveying information to and within a development the team is a face-to-face conversation.
  • The best architectures, requirements, and designs emerge from self-organizing teams.

At regular intervals, the team reflects on how to become more effective then tunes and adjusts it's behavior accordingly.

Not just the people but the right people. Having the right people, is a part of the process. Not only it is a part of the process, it is essential to the success of a Scrum team. First, you need to ensure that you have the right skills represented.

Does the team require architects, analysts, quality assurance, UI/UX, etc.? Does the team have an identified Product Owner (single wringable neck)? Does the team have a Scrum Master identified? The team should be 7 + 2 and should include the product owner and scrum master.

Once you’ve determined that you have the right skill representation, you then need to evaluate if those people are the right people. Below are 6 “C’s” defining traits showing the ‘right people’ constituting the Scrum team.

6 C's of scrum team1. Communicative
Communication is a key element of the scrum as highlighted in the manifesto and 12 guiding principles. This is a fundamental change for individuals that are used to working in a silo. Scrum requires at least daily communication.

Stories are often written with minimal detail in order to facilitate a conversation. Scrum requires proactive communication (don’t wait to be asked). Scrum requires great listening.  That means that the right persons need to understand the importance of communication and embrace that importance by exhibiting or learning to exhibit a proactive communicative disposition.

2. Collaborative

Collaboration is also a key element of the scrum. Again, this is a fundamental change for an individual that may be used to working in a silo. Scrum highlights the ‘success and failure as a team’ mentality. That means that the team has a vested interest in and right to ensure that work is getting completed and done correctly.
This is a two-way street, not only do you need to have insight into everyone’s work, but you must also be willing to provide the same insight into your own work. The team needs to be willing to pair program, swarm or even mob around stories for the team’s success.

3. Creative

Scrum team members need to be creative. They need to have an ability to be told what is needed without requiring someone to explain ‘how.’  Stories in their purest sense are single sentenced with perhaps a couple of sentences of acceptance criteria.

4. Connected

The Scrum team member (including the Scrum Master and Product Owner) need to be connected to the team.  What does it mean to be connected? It means to be invested in the success of the team.
It means that they know one another, they know how to interact with one another, they know how to make one another successful and in turn make the team successful. A good scrum team truly works hard and plays hard together.  A good scrum team member needs to be willing to develop a ‘work-family’ with his/her scrum team.

5. Co-located

It’s controversial in the age of telecommuting, but a co-located team member is the best. Face to face conversations trump video conference calls, phone calls, emails, IM’s, etc. Collaboration is immediate and organic when the team is co-located. Connectedness and camaraderie come to a lot easier with co-location.  Co-location makes spontaneous collaboration via swarming, pair programming, and even mob programming that much easier.

6. Coachable

If the person doesn’t possess any of the above attributes they are coachable. Not everyone will possess these skills, so coachability becomes one of the most important elements for any team member. Everything else can be taught and demonstrated

Is Scrum all about People?

Agile and Scrum are making the implementation of the software projects more successful by meeting the user’s, customer’s, and the business needs, and at producing software much more quickly and responsively than the traditional waterfall methodology.


All the characteristics of a good Agile team is depend on these values. Once the team is identified and evaluated to be the ‘right people’ you can begin investing in team-wide training/education to establish a baseline understanding of the Scrum, the roles, the ceremonies, and the terminology is a great start to start any project in the organization.

Jeremy

Jeremy Smith

Blog Author

Jeremy Smith is a 20 year IT professional. Jeremy started his IT career in Business Analysis where he was introduced to Scrum. Jeremy pursued his Scrum Master certification and in 2012 began serving as a Project Manager and Scrum Master for multiple teams. Jeremy has since moved into Agile Program Management. Jeremy has also provided Scrum coaching within his roles and independently. Jeremy graduated from Columbus State University with a Bachelor of Business Administration focusing in Computer Information Systems. Jeremy also holds a CSM (Certified Scrum Master) and a CSPO (Certified Scrum Product Owner) certifications from the Scrum Alliance.

Join the Discussion

Your email address will not be published. Required fields are marked *

1 comments

nikhila 13 Nov 2018

Great updates. technology is updating day by day on every field. These blogs are really informative

Suggested Blogs

The 5 Whys Approach To Root Cause Analysis In Agile Teams

Socrates once said ‘I know that I know nothing’Well,he did'nt mean that he actually didn't know anything or that he was absolutely ignorant ,but he inferred the fact that there’s much more to learn if he questioned it and dug in deeper. You would uncover deep-seated truths about constructs from the context and on why they exist and interact as they do. This is fundamentally how everything in this world works. This phenomenon can be seen at the workplaces as well.Especially when the project manager or scrum master enforces his team to do a root cause analysis. In other words, he asks them to retrospect on why certain things happened. Haven’t you experienced the same? Now, let’s talk a bit about root cause analysis.   Root Cause Analysis is a methodology used for analyzing problems in order to identify the main reason for that problem. It is an approach taken for problem analysis and interrogation. This is exactly what Socrates introduced in his Socratic Method. Each time when Agile teams practices any effective root cause analysis techniques, Socrates must be looking down from heaven smiling away. Root cause analysis can take many forms. Ishikawa or Fishbone diagram, 5 Whys approach to naming he most common.This article is not to talk about root cause analysis as a concept but to discuss how Agile teams can use use the 5 whys to identify the root cause analysis process. Introduction to 5 Whys or the Why-Why Analysis: This approach was first introduced by Sakichi Toyoda, the founder of Toyota Motor Corporation. The technique was used in the vehicle manufacturing plants to evaluate why problems occur during the production process. Often when a defect or an issue occurred, the team used to give a temporary solution, patch the problem and move on. However, the same problem used to resurface. Toyoda understood that the root cause was not being addressed in the solution given and only the symptoms were being addressed. Thus he formulated the 5 Whys technique to explore problems at hand. This is the best explanation for psychology, politics and programming I’ve heard in a long time. Attempts to boil anything down to a single cause are fruitless and generally a waste of time. Which is why “it depends” is so often at the heart of any answer. Unsatisfying, but true https://t.co/aNzQAQ7MQm — Ted Neward (@tedneward) July 24, 2018   As the name suggests, 5 Why’s is a process of asking Why 5 times to get to the root of a certain problem. However, 5 is not the minimum or maximum number of times you should ask ‘Why’. An example of why-why analysis for Agile teams would be something as follows:         Why did the user complain that notifications didn’t go out when he added a new customer to the CRM?            Because there was a bug in the last release Why was there a bug in the last release?            Because we didn’t test this scenario Why didn’t we test this scenario?            Because we only tested the features developed during the last sprint. We didn’t do a regression test on all the features in the application. Why didn’t you test all the features in the application?           Because notifications feature was something built a long time ago and it’s not practical to test all the app features in every release. Why is it not practical to test all features in the application during every release?          The application is now so big that performing regression testing on every feature at the end of each sprint is time-consuming. As we can see, this process helps you get a better picture of the underlying cause of the problem. We will now be able to go beyond the traditional answer of ‘We missed a bug’ or ‘Our bad, we will test the application thoroughly next time’ type of answer. The is simply because we now know the primary cause that needs to be addressed is to do with regression testing. We simply identified that testing is an issue, but it is not the root cause of the issue. How the 5 Whys approach helps The 5 Whys approach lets you determine what you should do to rectify the situation. It helps you make a decision on what action to take, whom to consult, what sort of effort is required and so on. In the above scenario it will help us identify the regression processes for the project, what tools to use, and help decide whether to automate regression testing activities. We can see that 5 why’s is a great tool for agile teams to use. There’s no set standard or guideline on how to use it. It’s up to the team to decide when to use it and how. It doesn’t need to be 5 why’s as explained earlier but just be done to an extent which allows you to make a concrete assessment and decision. Get everyone impacted or interested involved in the process and perform it diligently. Ever thought why a 5 or 6 year old child keeps on asking why? Isn’t it sometimes annoying? ‘Why is that car red?’, ‘Why does that dog bite?’. These are some annoying questions a child may ask for which you may sometimes have no answer. Isn’t it more irritating when the child keeps on asking why for each answer you give? Success factors for Root Cause Analysis There are many different approaches to find the root cause of problems. You can perform a general problem analysis with one or more professionals and demonstrate the results to those involved to deal with and refine them. For smaller issues, you can follow the 5 Whys technique discussed above.  Analyzing the error that has been found during testing or stated by customers helps to enhance your product quality. Agile teams can perform root cause analysis in the retrospective meetings or can have separate meetings they analyze carefully by asking why. It is essential to perform root cause analysis irrespective of the technique that is used to get business value out of it.  Final Thoughts Finally, my concluding remark is to invite you to call forth your inner child again. Ask Why how stupid or trivial it may be. Remember, we only see the tip of the iceberg. There’s lots more of the problem that we have forgotten to explore or ignored to accept!
Rated 4.0/5 based on 20 customer reviews

Agile and Scrum – What’s the Difference?

Agile & Scrum are two terms that have become very popular in recent years and with good reason. Together, they make project management and development more streamlined, faster, and more cost-effective. But what’s the difference between agile and scrum? What is Agile? Agile is a methodology for developing software and managing projects that focuses on small teams, iterative sprints, incremental successes, and empowerment. While many traditional project management methodologies focus on sequential development, agile promotes flexibility, acceptance of change, and frequent deliverables. Close team and customer contact is a requirement as is open communication, collaboration and an acceptance of change at any moment. Agile teams are typically self-organised. They’re empowered to achieve specific goals and are tasked with specific deliverables to achieve those goals. Those deliverables are provided through an iterative process called sprints. At the end of each sprint, the deliverables are evaluated and next steps are identified. This iterative process delivers incremental progress, and it leaves the door open for rapid response to changes throughout the entire development cycle. Unlike traditional project management and development processes, the agile methodology acknowledges that every requirement cannot be identified in detail at the beginning of a project and that changes will occur throughout the process. This more flexible process has been shown to deliver increased team member and customer satisfaction as well as faster delivery timeframes, higher quality outputs, and reduced costs. What is Scrum? Agile is a process for getting things done. It includes many methodologies under its umbrella, including Scrum, which is one of the simplest methodologies. Scrum provides a structure and rules to implement agile processes, define roles, manage meetings, and more. For example, scrum teams are made up of approximately seven full-time members and sprints last one to two weeks but never more than 30 days. There are three scrum team roles: 1.Product Owner – manages the product vision and return on investment 2.Scrum Master – manages the scrum process 3.Self-Managing Team – members complete the daily tasks required for each sprint There are five types of scrum meetings: 1.Sprint Planning Meeting – held at the beginning of each sprint 2.Daily Scrum and Sprint Execution Meeting – held at the same time and place every day for 15 minutes 3.Sprint Review Meeting – held after a sprint execution is completed to provide a working product demonstration to the product owner 4.Sprint Retrospective Meeting – held at the end of a sprint to evaluate the process and identify areas for improvement 5.Backlog Refinement Meeting – held prior to the next Sprint Planning Meeting to prepare the backlog for the next sprint For software developers, the goal is to have a shippable product ready at the end of every sprint when stakeholders view a demonstration. When a sprint is done, the next one begins. This real-time process enables scrum teams to make decisions based on real-world results rather than speculation. Are Agile and Scrum Right for You? Scrum is an appropriate methodology for projects with uncertain requirements or technology issues as well as for projects where change is likely. Its purpose is to make unmanageable work (because of the levels of uncertainty and constant changes) manageable through a set of defined processes that are structured to allow flexibility. Furthermore, if your project requires knowledge creation and collaboration and your team is committed to developing self-organized teams to get things done faster, then Scrum is a proven approach that is worth trying.
Rated 4.0/5 based on 20 customer reviews
Agile and Scrum – What’s the Difference?

Agile & Scrum are two terms that have become very ... Read More

Who Is a Cspo? - Roles and Responsibilities

1.1 What is a Product Owner?A Product Owner is a role defined in Scrum. Scrum is a framework for complex product development (*). The Product Owner is responsible for maximising the value of the product resulting from the work performed the Development Team. The role exists in Scrum to have 1 person with a clear accountability of WHAT product or service will be built. The Product Owner role is also used as a title outside Scrum, in other frameworks, but if you want to understand the definition of the role and responsibilities of a Product Owner, you need to start to look and to understand it in the scope of a Scrum Team. (*) (“product”, to be defined in context, this is a generic term for the product or service being developed for the end-users)(*) (“development”, also to be defined in context, this is a generic term for all activities needed to create and deliver value to the end-users)1.2 What’s the job profile of a Product Owner?The Product Owner role is Scrum is a role, both with a tactical, strategical and operational aspect. The Product Owner role is critical as the role is kept by 1 person (and 1 person only) for a specific product. Having 1 person holding the role simplifies the accountability in terms of having 1 spokesperson for product ownership and accountability of maximising value. This doesn’t mean that all activities are to be done by the Product Owner; otherwise the Product Owner could become a bottleneck. The Product Owner does remain accountable at all times. To be able to do the job, the Product Owner has business (domain) knowledge, affinity with end-users, affinity with “development” (activities needed to deliver a piece of value), and knowledge of how to do agile product management. Product management is a multi-disciplinary job, and it involves to understand, empathise, quickly inspect & adapt, each time with the accountability to make the right choices in terms of what to built next, in order to continuously (incrementally) deliver value to end-users. In order to better understand what kind of profile is needed to fulfil the product owner role, it’s valuable to list skills required and activities performed.When looking for a Product Owner, you’re looking for a profile with generic product management skills and product-specific skills.  The generic skills are needed to be able make decisions on a strategic and tactical level.People skills a Product Owner must have:A Product Owner also needs people skills:To empathise with users of the productTo build connections with stakeholders and to create a healthy working relationship with the team building the product. These people skills include- to be able to listen (to stakeholders, end users, team members), to translate information (between people with a different background), to be able to make  informed decisions without undermining longer-term objectives, etc.The product-specific skills are defined by the product or service that’s being built. This includes all the activities to understand the market, the needs, the job the product or service will fulfil, user-journeys, also more technical product-specific knowledge, legislation (if applicable), financial implications and any other constraintIn his book Product Mastery “From Good to Great Product Ownership”, Geoff Watts describes the skills of Product Owners with the acronym “1.3 Product Owner role and responsibilitiesThe role of Product Owner can be quite challenging and high-demanding. When reading The Scrum Guide, it says that product backlog management is the main activity for a Product Owner. The product backlog is a tool to ensure it’s clear what’s needed in the product and what’s the most valuable thing to build next. Managing a backlog, and refining items on the product backlog is a continuous activity.  The Product Owner often serves as the spokesperson of the product. This means he/she needs to be able to answers questions appropriately, for example regarding product vision, roadmap, planning, why certain choices have been made, etc. This also includes NOT answering certain questions, because the Product Owner knows the development team is in a more appropriate position to answer the question more accurately, and as well to facilitate a conversation with the development team involved.Go through other roles and responsibilities of Product Owner here.1.4 How does a Product Owner manage various stakeholders desires for the product?The Product Owner has the challenging task to manage requirements and desires of stakeholders. Each stakeholders will certainly advocate his/her demands are the most important. Here are some recommendations on how a Product Owner can deal with this:Treat requirements & desires as “desirements”, meaning, until by learning or by end-user feedback has been proven that the “desirement” is valuable, treat it as a hypothesisKeep the product backlog and its ordening as transparent as possible to all stakeholdersDon’t be seduced to prioritising in categories such as high, medium, low priority. A product backlog is ordered, no two items can have the same priority.Use techniques to prioritise impacts (impact mapping), simulations to learn stakeholders to prioritise (e.g. buy a feature), techniques to slice for value (user story mapping) 1.5 CSPO vs PSPO CSPO is an abbreviation which stands for Certified Scrum Product Owner. This is a certification offered by the Scrum Alliance, specifically for the Product Owner role. PSPO is an abbreviation which stands for Profession Scrum Product Owner. This is a certification offered by scrum.org, specifically for the Product Owner role.In my opinion, both certifications are equivalent and define a high-quality standard. There’s a difference in the way of obtaining certifications and how to maintain this. Certifications issued by Scrum Alliance are obtained by taking an online exam after mandatory attending a 2-day training given by a Certified Scrum Trainer.Certifications issued by scrum.org are obtained by taking an online exam without the prerequisite of attending a training. Certifications issued by scrum.org do not expire. Of course, to test and validate your knowledge, having a decent understanding of the product owner role is mandatory, therefore preparation and study are key. Participating in a training to learn, and to experience what Scrum is about, is always highly recommended.1.6 Product owner in agile software development The manifesto of agile software development does not specify anything about the Product Owner role. Therefore, it’s perfectly possible to have an agile team without a Product Owner.The manifesto for agile software development does state a few principles which illustrate how we want to work regarding product and value delivery, for example:“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software;”“Welcome changing requirements, even late in development;”“Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale;”“Business people and developers must work together daily; ““Working software is the primary measure of progress;”You can interpret these principles as following, in what you should NOT be doing…Waste time & effort creating long-term plans, long cycle times, etc without actually delivery usable product increments to the end-users, …Waste time & effort on unnecessary specifications; unfinished product (“inventory”); or unvalidated requirements (which are assumptions in disguise), …Waste time & effort on unnecessary handovers between business people and development teams, …Waste time & effort on assuming what’s valuable for the end-users, and not verifying this by letting end-users try out working software and based upon their feedback, inspect & adapt, improve the product together, …Wasting time & effort in demanding upfront detailed estimates for unreasonable long periods (e.g. all estimates for the next year…)Wasting time & effort on detailed long-term planning, fixing agreements, treating change as evil, …1.7 Product owner in Scaling AgileLets first make the statement that you need to consider it twice before blindly scaling up any development efforts. In general, we are trying to deliver value by keeping things simple, simplify working processes, and collaborate to maximise effectiveness and customer satisfaction. In case you need to align several development teams to work together on the same product, take the following into account:A product has 1 product owner, this means in case of several teams developing on the same product, there’s 1 product ownerA product is defined as something meaningful and valuable for a customer or end-user, not a technical componentA product has 1 product backlog, as long the product lives, the product backlog existsA product owner can delegate areas of the product to other product owners, but take care to not have “proxy” product owners, with a mandate to decide. The ‘chief’ product owner remains accountable for overall prioritisation. Some scaling frameworks make a distinction between “product management” and “product ownership”, in any case ensure there’s alignment regarding product management, no conflict in priorities, and no unnecessary handovers of information.1.8 Who is accountable for the business value delivered by a Scrum team?The Product Owner is responsible for maximising the value. A Scrum Team collaborates to deliver value together. The Product Owner remains  accountable.1.9 What exactly is the role of the Product Owner during the Daily Scrum?The Product Owner is not required to attend the Daily Scrum. The Daily Scrum is an inspect & adapt time-boxed event for the development and performed by the development. This is defined in this way because otherwise the Daily Scrum will quickly be run as a status meeting (and not a daily planning event). Of course, the Product Owner can be present during the Daily Scrum, as it’s a great moment to check-in with a team, listen how a team is synchronising, ask and answer questions - after the Daily Scrum. The Product Owner, nor the Scrum Master should be leading the Daily Scrum. They can be present, but the Daily Scrum is an activity (‘Scrum’ metaphor of Rugby), for and by the development team. The Product Owner defines a sprint goal (a sprint is a time-boxed iteration to deliver a potentially shippable product increment); the Development Team inspects its progress on a daily basis towards that sprint goal, using the sprint backlog.1.10 What are certain anti-patterns regarding Product Owner?Some example anti-patterns regarding Product Owners; this can be used in an exercise to coach Product Owners. Ask what should be done to be the WORSE Product OwnerIdentify what’s actually being done of that listIdentify what should be STOPPED doing, in order to improveSome anti-patterns of Product Ownership Becoming a bottleneck in communication, so that’s there’s a delay in the flow of value between the development team, end-users, and stakeholders, …Taking decisions in isolation, so that the reason why decisions are taken are not known, nor understood, …Specifying technical solutions, and not articulating the business value, … (technical solutions are the responsibility of a development team)Pressuring the speed of delivery, resulting in less quality and inability to validate if value is being delivered, …Not listening to the product development team’s recommendations, not engaging in any healthy dialogue, …Not articulating the product’s vision, and/or strategy, resulting in development teams functioning as “feature factory”, without investigating what’s valuable and what’s not, …Inadequate product backlog management, resulting in unready items to plan, long inventory, unclear prioritisation, …Not accepting or rejecting work according to the definition of done, resulting in unclear standards of what’s a done product increment, …Not thinking how to delivery slices of value, forcing development teams to deliver components, instead of ready-to-use product increments, …Not facilitating a sprint reviewNot participating in any retrospectiveNot updating any forecast after finishing a sprintNot engaging with end-users / customers to get feedback etc2 What is the process to get a CSPO certificate?You can also follow the below steps to understand clearly.Find a Certified Scrum Product Owner course on the Scrum Alliance websiteRead and understand the Scrum GuideRead and understand the manifesto for agile software developmentRead and understand the learning objectives of a CSPO courseAttend the 2-day CSPO courseComplete the online CSPO exam, the fee is included in the course price. After completing the course, your Scrum Trainer will upload your user information into the system of Scrum Alliance, next you’ll receive an invite to do the online exam. Recommended books and material to read and further prepare:Articles by Roman Pichler,Book Product Mastery, by Geoff Watts,  Path forward after CSPO at Scrum AllianceCertification gives you access to a renewable, two-year membership with Scrum Alliance. As a Certified Scrum Product Owner (CSPO™), you can continue your educational development to become an:Advanced Certified Scrum Product Owner (A-CSPO™)Certified Scrum Professional - Product Owner (CSP-PO™)Certified Team Coach (CTC™)Certified Enterprise Coach (CEC™) Certified Scrum Trainer (CST™)Remember, if you’re starting as Product Owner, the CSPO certification is only the start of your journey!ConclusionBeing a product owner is a satisfying job! You are the main spokesperson for the product. You act as a catalyst between the Development Team and the outside world. You take decisions to maximise product value while taking into account various constraints.
Rated 4.5/5 based on 14 customer reviews
5535
Who Is a Cspo? - Roles and Responsibilities

1.1 What is a Product Owner?A Product Owner is a r... Read More