Product Vision : The Key Role and Responsibility of Product Owner

Continuing with the discussion on Product Owner role and responsibilities, and based on two excellent comments from Martizza and SJJH, let us review the key role and responsibility of the Product Owner. One can argue that the four skills/ competence areas highlighted in the Who can become a Product Owner post along with people management and interaction skills, help the Product Owner articulate, defend and refine the Product Vision. One can also argue that this is a separate skill and competence area and some people can just be better at this job even if they do not have the domain knowledge, are not technically sound or have the necessary experience. What will these people then typically possess? I think it would be a mixture of ability to learn [learn very fast], a highly analytical mind [capable of drawing analogies], intuition [strong emotional connect with real and abstract] and a thinking mind [one that can think even when it does not know it is thinking]. These people would generally believe hopelessely in what they are working on – and it is this belief and the conviction that helps them exude the product vision. Hence, when one is looking to appoint or hire someone for Product Owner position, one should see if they identify with the product and what are the ideas they bring to the table. If the connect is established, the rest of the work would flow a lot better.

So, what exactly does a Product Owner do with the Product Vision. They do 03 things:

1. Define the Product Vision – This involves close connect with the customers and market needs. Hence, domain expertise and exposure to tech support/ marketing comes in handy. Further, exposure to some sort of modeling methods helps the Product Owner define the product vision. Often, the Product Vision phase can take long. As a Product Owner, you may consult other domain experts, technical team or embark on marketing feasibility studies to confirm and reconfirm the vision.

2. Articulate the Product Vision – This is more important than 1. Typically, the Product Owner should be available to the development team anytime and everytime. The Product Owner should be able to sit down with different team members – together, in groups or alone – and discuss aspects related to the product – what will happen in 02 years, 02 months and what do they think could happen. This helps build the trust and orients the developers from a Product Owners perspective – a key requirement to build a great product. One of the means available with the Product Owner, to articulate the Product Vision is Product Backlog and ceremonies like Sprint Planning, Sprint Review help achieve this too.

3. Refine the Product Vision – Each time the Product Owner meets people from marketing, sales, technical support, development team, testing team or customers – they will keep uncovering new things about the product. It could just be new technology [Google Wave was launched a few days back for instance] or a new trend [micro-blogging and social media]. This can represent opportunities or threats. Product Vision is not stagnant. It is dynamic.

If a Product Owner can take care of the Product Vision, the Product would largely take care by itself.

Who can become a Product Owner?

Who is qualified to become a Scrum Master or Who can play the role of Scrum Master, is one of the most frequently asked questions in the Agile community. I believe the more important question and often the one that does not get asked is, Who can become a Product Owner? Why is this question more important? It is because what you are building (and why you are building this) is often more important that when are you building and how are you building it. The last two questions are important but not as important as the first two. The first two questions also help frame the vision for the product. That is not the only reason why this question is important. There are others too:

1. Chronologically, Product Owner role starts before any other role in an Agile or Scrum team.

2. Depending on what is your vision for the product, you could outsource a part of whole of it right at start or at a later date.

3. You build the product to achieve a particular purpose. The person responsible for the same is the Product Owner.

If this is such an important question [and correspondingly role], then what are the qualifications one should look for when selecting a Product Owner? I have been a Business Analyst and Product Manager. I have interacted with many Product Owners too. There has been an interesting discussion on who can be a product owner on the Scrum Development Yahoo Group recently too. Based on the feedback collected from all these sources, I have compiled a list of who would make an ideal Product Owner:

1. Product Owner is a part of the team and should hence be available as much as possible to the team [close to 100%]. Hence, PO can only be someone who is available to the team 100% of the time.

2. Product Owner needs to understand the big picture – the philosophical as well as practical aspects of what is being built. This would often require excellent domain knowledge.

3. Product Owner should know what will work – hence, exposure to marketing and sales is important. This is also often called Voice of the Customer. Basically, Product Owner should deeply empathize with customers – their needs, their frustrations and their wishes.

4. Finally, any exposure to technology – programming, UI, QA is an additional bonus [in most cases a required bonus].

The next question is which of these is the most important requirements? I think all 04 and in given order of priority.

One additional requirement, which I believe all people should possess and so should Product Owners and Managers : People Management and Interaction.

A Sprint Retrospective – The Ideal way to Start Agile

Is the Certified Scrum Master class I attended about 03 years back – Pete Deemer, the Guru who led Yahoo’s adoption of Scrum in multiple locations, said “Even if you did not do anything else but only Sprint Retrospective, you will see tremendous improvements in your process or way of working.” That is, even if you were not doing any of Sprint Planning, Sprint Backlogging, Product Backlogging, Sprint Reviewing or even Daily Stand Upping, you would be doing very well, by doing just one practice – Regular Sprint Retospecting. That is definitely a tall claim. And from my experience in the last 03 years, a true one too.

Let us look at the basics first. What is a Sprint Retrospective? Rather, what is a Retrospective? As per Wikipedia, Retrospective (from Latin retrospectare, “look back”) generally means to take a look back at events that already have taken place. For example, the term is used in medicine, describing a look back at a patient’s medical history or lifestyle. It is particularly useful to look at the medicine analogy here. Retrospective, in medicine, means looking back at medical history.  In Software Development, a retrospective means looking back at project history. This is typically, with a team and depending on the context it could include project managers, senior managers, directors, VP’s, whole team, testers, developers, business analysts in any combination. Extending the analogy with medicine further->typically, you will look at the medical history only if something has gone wrong or when the person has died [and you are doing an autopsy]. Unfortunately, most retrospectives in Software Development are also held, when something has gone wrong or at the end of a project. Agile Software Development uses retrospectives, like regular diagnosis [and not just when something bad happens]. After every iteration or sprint, the team gets together to discuss what was successful about the project or time period covered by that retrospective, what could be improved, and how to incorporate the successes and improvements in future iterations or projects.

Agile and Scrum are adaptive processes.Retrospectives and Daily Stand Ups are too practices which enable inspection as well as introspection – both necessary for adaptivity. Even if the team did not do a product backlog or sprint backlog or burndown chart and the team just did regular Sprint Retrospective, what will it unearth? One of the first things, they would probably identify is that we never knew where we are and what everyone is doing or where someone is stuck. They will come up with burndown charts [or some variant/ substitute] as well as more regular meetings [daily stand ups]. More features like sprint planning, sprint reviews, product backlogs etc. could come up. Some things like no change during the sprint could never come up. Hence, the team could come up with their own version of Agile – something that fits them the best.

The above paragraph assumes some critical things:

• The team is empowered and capable to drive a retrospective as well as implement the action plans that are highlighted for the next iterations. Significant management as well as team buy-in for being process leaders rather than process followers is hence, required.
• Given the nature of retrospectives, they can degrade from looking back to blame games quickly. Hence, good facilitation and guidance during a retrospective is required.

Some retrospectives can be more productive than others. We will take a look at more on retrospectives in the future articles. You might also be interested in the Start, Stop, Continue Technique of Agile Retrospectives.

Why does the Product Owner (PO) Disturb the Team?

In Agile and Scrum talks or training, Product Owners (PO’s) or people playing the PO role in projects/ products, ask : Is it alright to ask the team how is it going during a sprint?

A good team would probably direct him/ her to the burndown chart or the Kanban inspired to-do lists. duly sorted in in-progress, to be picked up or done. The teams who do not maintain the burndown chart only have themselves to blame for the Product Owner or Product Manager, asking the obvious. Now, let us say the team maintain the burndown chart and the PO can see it, what if he/ she asks – Is this your best pace or Could you do better or I don’t think this is good enough? This is probably getting into a territory, where there is no yes or no – it is just something you have to analyze context wise. Let us analyze some of the reasons [assuming that the team is maintaining correct working pace and is not padding up or slacking]:

1. Why the Product Owner could say such a thing? The Product Owner obviously does not trust the team.
2. Why does the Product Owner not trust the team? Probably the PO has no clue what all we do.
3. Why does the Product Owner not have this clue? Because he can’t see it.
4. Why can’t he see it? Because we did not put it on the sprint backlog or to-do list.
5. Why did we not put it? Because [A] We were lazy [B] All programmers and testers know what all it involves [C] It won’t make sense to business [D] It takes time

Other than [D] above, none of the above seems like compelling reasons for not listing all the tasks. Also, the consequences of not putting it because of [D] -> lack of trust in product management and development – is too big to account for extra minutes it takes to list all tasks and dependencies.

Hence, next time the PO has this urge to ask you>>please just ask yourself the 5 questions above and see if you can find a solution. If your PO asks you to change something/ do an extra thing/ tweak something>>then Scrum is pretty clear on how you should handle it

A Practical Guide to Distributed Scrum – Review the Upcoming Book

Distributed Scrum/ Agile teams is one area where most globally distributed teams struggle. There are issues of time zones, cultural nuances and languages apart from other local issues. However, globalization of work and workforce is a 21st century requirement and reality. Implementing Agile brings these differences and issues out in the open even more. A Practical Guide to Distributed Scrum – the Book hopes to provide people implementing Scrum or Agile in a distributed environment with some examples and experience insights. This book has been developed through the collaboration of the IBM Scrum Community [comprising more than 1000 members across 07 business units of IBM in 30 countries]. The book specifically will take a look at these aspects:

• Estimate user stories and work with the Product Owner as a distributed team
• Implement techniques to more efficiently engage in Release and Sprint planning
• Effectively conduct daily Scrum meetings
• Enhance communications between team members throughout the Sprint
• Conduct a productive reflection to improve productivity and quality over the next Sprint
• Demonstrate progress to stakeholders at the end of each Sprint
• Leverage tools to improve the productivity of distributed teams

The book is written by:

Elizabeth Woodward who is a Senior Software Consultant with IBM Quality Software Engineering under the office of Innovation and Technology.

Dr. Matthew Ganis is an IBM STSM and ibm.com site architect. Matt is the co-creator of the Agile@IBM community and was an early adopter of agile within IBM.

Steffan Surdek is a User Experience Lead and Agile Champion in IBM.

You can help review the early drafts of the book at Distributed Scrum website.

When Should You Implement Scrum or Agile?

Are there circumstances that are more favorable for implementation of Agile and Scrum and ones that are not very favorable for its implementation. Generally, the ideal conditions for implementation and spread of Agile/ Scrum in an organization depend on the market and customer scenario, rather than the development team scenario. Some such factors or conditions include:

1. Unclear product direction or a research oriented product – the fact that the direction is unclear, makes you plan only for a small time in the future, when you reassess and reorient
2. Too many changes/ feedback too often in the product – again this means that you take the minimum [agreed, clear or consensus] work – complete it – get feedback and move from there
3. Competitive industry/ market scenario – this generally would mean you have to get the features out to the market sooner rather than later as well as have more customer connect in the product [some will argue this should be the case anyways]

There are some factors at organizational end as well, which can impede/ aid the Agile Implementation. For instance, if there is no management buy in, or team buy in or worse if there is no customer buy in [in service industry scenarios]- it will be hard if not downright impossible to implement Scrum, Agile or any other framework. In addition, where a deliberate slow and assured pace is mandatory [think software for nuclear reactors or space ships] – there might be significant overhead. Hence, small increments or sprints might not be possible in such a scenario. Turning, this around, you should go all out to implement Scrum or Agile, if:

1. There is a relative buy in at all ends – customer>>management>>team [not necessarily in this order in all organizations].
2. The cost of a single bug is very high.
3. Everyone understands or make attempts to understand what is Scrum or what is Agile.

When you combine the outside [market/ customer] conditions with inside [organization] factors – you get a ripe condition for implementation of Scrum or Agile.

Agile and Scrum Jobs in India : Beginning to Appear?

It seems after about 03 years of activity on the Agile and Scrum jobs are beginning to appear in Indian job portals. Naukri displays 109 jobs for Scrum and 296 for Agile as of today – 5th August.

About a year back some of the developer jobs started adding a line “Experience with Scrum/ XP/ TDD is an advantage”. This continues to date. Here are a few such jobs:

• An opening with http://www.truglobal.com/ for Senior .Net Developers :  The desired profile is “.Net 2.0/3.0/3.5 (WCF, REST, CLR). Strong database skills. Exposure to Agile / Scrum methodology is mandatory. Linq, ASP, VB, OOPS, XML and JQuery” Contact recruiter@truglobal.com
• Another job is from Parexel International at Hyderabad. The requirements are “4+ years of commercial development experience Educated to minimum of degree level in a science related discipline Highly proficient in English (written, verbal and comprehension) Following Must Have technical prequisties: Java 1.5 —- J2EE —- Struts 1.1+, JSTL —- XML —- XSLT HTML/XHTML —- Servlets/JSP —- JavaScript CSS —- JDBC —- SVN/CVS PL\SQL —- Oracle 10g+, —- Tomcat 5.5+, OOAD —- Formal SDLC-Waterfall/Agile —- JUnit Desirable prerequisites: Sun certification ‘ SCJP/SCJD Knowledge of Integration middleware platforms, or SOA Pharamceutial/Clinical Trials industry/domain knowledge Following technical prequisties: IntelliJ –UML –Apache Derby ANT –SQL-SQL92/ANSI –VB6 Linux –JBoss –Glassfish WebLogic –OC4J –Websphere AJAX –Web Services –Scrum Report Development –Portal Development-JSR168/286 –Workflow JIRA Development –CheckStyle/PMD/Findbugs” You can submit your resume at
  http://www.parexel.com
• Symbian Developers in Bengaluru can apply at Tata Elxsi Ltd. The exact skills required are “Debugging Tools in Symbian platform – Emulator, TRK , ODD using Carbide and Lauterbach etc,  Tracing and Profiling Tools – TRACE32 ,Profiler and analysis of profiler data, Emulator – In depth knowledge of Emulator provided by Symbian / S60 SDKs, Compiler – Various compilers supported in Symbian platform, Memory and Code dump Tools – Hook Logger and other Tools available in Symbian / S60, Core dump and crash log tools – Crash Log analysis and associated tools, Awareness of Symbian foundation tools, Static code analysis tool – Coverity Prevent Tool, Experience in Agile development – SCRUM and Knowledge on PERL.
• There are jobs in North India too. There is one available through Vanguard HR Consultancy. The job is of a Senior Software Engineer – Java. Contact Mayank@vanguardhrconsulting.com and you need to have about 06 years of Java Experience with Agile/ Scrum methodology. Specific skills required are “Extensive experience of J2EE application servers and Java web applications, Should have worked in at least 2 previous large database backed Java applications, Should have good understanding of robust database schemas and database tuning,
  Should have worked on large scale databases, Experience with JSF (Java Server Faces), Spring and Hibernate and Should have a thorough understanding of email and SMS, technology, protocols, etc.”

There are other jobs available as well. Here is one for a Senior Technical Writer from Consona. “Experience working in an agile/scrum development environment” is one of the requirements along with standard technical writer jobs.

The big guns are hiring for dedicated Scrum Coaches. As of now, Dell wants a Scrum Master for its R&D Division in Bengaluru, there are at least two product companies looking for Scrum Coaches in Pune and there is one requried at Nokia as well.

There would be others which never get listed and are filled through reference or community events as well.

However, despite these jobs being listed, I think we are still some distance away from getting more jobs in Agile and Scrum space in India – especially Scrum Masters/ Agile Coaches/ Product Owners. But the things are better and over the next one year, it should be even better.

A Successful Retrospective

Someone asked me when do you know if you just led a successful retrospective.

My first reaction was that I will have to think and come up with some metrics which optimize the complete value chain. However, I started answering sooner than later. I stopped in between, reflected and continued. On the flight back, I reflected again on what I said. I thought it made sense. Let me know what do you think?

An effective or successful retrospective should have the following characteristics “come out”:

• No one should come out of the retrospective with ill feeling or negative thoughts towards anyone.
• No one should come out of the retrospective thinking they have not been heard properly.
• No one should come out of the retrospective saying they are not a party to this decision.
• No one should feel that the real reasons or suggestions did not come out.
• The team (and PO – if he/ she was present in the meeting) should be buzzing with enthusiasm in being part of something unique.
• The team (and PO – if he/ she was present in the meeting) should come out of the retrospective with more understanding about each others roles, expectations and requirements.

I think this made a good checklist – mentally, for a Scrum Coach.

What is a Sprint Review Meeting | Iteration End Review Meeting

When a sprint or an iteration ends, the time comes to demonstrate the working software as per the stories and requirements committed originally. This is usually done in what is called a Sprint Review Meeting. During the Sprint Review Meeting,  the team demonstrates working software corresponding to project backlog items they have completed in a given sprint.

The focus of sprint review is on working software. Powerpoints, speeches, lectures and other diagrams/ presentations are not allowed. In fact overall, the meeting is kept very informal. and typically, like the Sprint Planning Meeting, last only about 01 hour per week of sprint work planned. The teams attention, selection of practices and processes is all done with regards to faster delivery of working software. For instance, since the teams focus is on delivering working software, all the arrangements [arranging room, projector, getting the environment ready etc.] are done by the Scrum Master.

Product owner, The Whole Team and Scrum Master, all attend the Sprint Review Meeting. This is done to ensure that people who have developed the software are there to answer any questions the product owner has and for product owner team [customers, stakeholders, product owners] to see what is coming up from development team. This also improves the communication in the team, with each team member further strengthening the teams understanding of the product and product owner expectations. The team would typically demonstrate each code it has written either through GUI, mock objects or through API calls. The product owner team can give better feedback after seeing something working rather than on abstract IT diagrams. The teams are looking forward for the following feedback in the sprint review meeting:

• Whether they completed enough requirements
• Whether they completed requirements quite early
• Whether they understood the requirements and translated them to working features well enough

This feedback helps the team and product owner to plan better for the next sprint. The team [together] and product owner both take back points for themselves too. For instance, product owner sees if some more requirements need to be added/ edited/ deleted for next sprints and also for the team to see if they need to do better to understand or compelete more requirements.

After the sprint review is over, the date for next sprint review is announced and the team moves to Sprint Retrospective.

Sprint Planning Meeting – Introduction and Basics

If you follow iterations and sprints as part of your Agile Development Lifecycle, a key ceremony in Agile is “Sprint Planning Meeting” or also called “Iteration Planning” in other variants of Agile. Sprint in Scrum is a time period in which the team does whatever it can to develop software as per features/ requirements the team has committed to. A sprint or iteration is started with a Sprint Planning Meeting.

Lets say we are in the first sprint. The team would picks up “x”  [“x” requirements are selected through an educated guess] number of top priority requirements. A good project backlog would not only be prioritized but also estimated. The team totals the “relative estimation points” for all these requirements and that becomes the “velocity” of the team for first sprint. After discussing with the product owner, the team finalizes the requirements it would take up in the first sprint and the backlog roughly appears like this:

The team has committed to 20 points of work. As this is the first sprint, and the team has committed to the work more on an educated guess than exact science [and this would hold true for future sprints too], the team might need to take on more work [if they finish all requirements] or need to bump off some requirements [if they have taken more than they can handle]. The team will ask product owner as many questions as possible and they can think of [acceptance test cases/ test data/ UI designs etc] and give a final commitment before moving to Part II of the sprint planning session. In this session they take each requirement and break them into tasks and the team member voluneteer, discuss and self assign these tasks. A typical sprint backlog after this could look like this:

Hence, a sprint planning meeting is basically a communication channel for the team and the product owner to decide on what work the team should work on in a given sprint as well as the team doing some basic ground work on starting with a particular sprint.

It is important to emphasize here that in almost all Agile implementations, the team does not report to Product Owner. Both are independent yet important pillars of Agile/ Scrum frameworks. Hence, there are some rules of engagement which the team and product owner need to adhere to:

• The team would commit to work based on their understanding. Although, the product owner is free to ask the team if they feel they are under-committing or over-committing, there is no coercion available for the product owner. The product owner would not coerce the team into committing to more requirements than they feel comfortable with.
• The sprint planning meeting is a synchronization meeting for product owner and the team to decide what the team has to work on in the next sprint. However, the team can request product owner to be available during the sprint at regular interval [if they can sit with the team, nothing like it] to answer any questions or provide feedback – especially during the earlier sprints as the team would be spending more time understanding the domain, product, project, framework.
• The thumb rule for time to be spent on a sprint planning meeting is 2 hours for each week of sprint – 1 hour for discussion on requirements discussion and 1 hour for task breakdown.
• Finally, in Scrum at least and preferably in other flavors of Agile as well, once the team commits to the story – there would be no change: no change in development team, no change in the requirements and no swapping. However, clarifications can be provided. If the team and product owner is divided on whether it is a change or clarification, it is a change. This is done to maintain team focus on what they commit and get a rhythm going after a few sprints.

After the first sprint is over, and the team goes for second sprint planning meeting, the team has a better idea of know how many requirements they can commit to. This idea keeps becoming better and clearer with every passing sprint and sprint planning meetings would not have much of a discussion on whether the team has committed right or wrong [over or less].