Agile in Product Management

It is often seen that Agile has been implemented successfully in different projects. But when it comes to Product Management or NPD (New Product Development), many people get sceptical regarding implementation of Agile. Now it has to be understood that Agile is not a methodology which can be used in a cookie cutter way across any organization. A lot of tweaking and customization is required to make it work. So, in product management, a proper assessment is required to see if Agile implementation will improve performance or not.
Here also, we need to see if the following two criteria are being fulfilled or not:

1. Requirement Volatility : It is important to identify the volatility of requirements and whether working in Sprint will actually improve customer satisfaction, reduce uncertainty and help PM teams become more productive or not. If requirements are fixed in sand and are not dynamic in nature, it will not make any marked improvement even if the teams work in sprint. Also, Agile Product Life Cycle Management involves a lot of new learning, so it needs to be checked if the team will be comfortable in this transition or not.
2. Frequent customer Interaction: External customers are big stakeholders in any Agile effort. In many product management scenarios, we have seen that customers just give their specifications and just go away for months and months. And finally when they come back for the product, it is completely different from what they expected, because market dynamics change and the expectations change as well. So the biggest benefit is actually to the customers themselves, and this is what the PM team should explain in details to the customers so as to get their buy in. Without their pro-active support, it will not be possible to implement Agile in any way.

If we are talking about New Product Development, then Agile actually becomes even more crucial and important.  That is because neither the customers nor the PM team has any benchmark to follow. So, frequent discussions and brain storming sessions followed by change in requirements or prototypes will be mandatory for successful NPD. So, it is important to realize that Agile can be implemented successfully in Product Management as well, provided it is understood properly and used in the proper context. Also, management buy in and customer buy in are important components in this scenario, and a good AGILE coach will also be very beneficial.


Acknowledgement: This article has been borrowed from www.scrumstudy.com
Original Link: http://www.scrumstudy.com/blog/agile-in-product-management-2/ 

Managing Technical Debt in a Scrum Project

One of the guiding principles of Scrum is to develop the functionality of the highest priority to the customer first. Less important features are developed in subsequent Sprints or can be left out altogether according to the customer’s requirements. This approach gives the Scrum Team the required time to focus on the quality of essential functionality. A key benefit of quality planning is the reduction of technical debt.
Technical debt—also referred to as design debt or code debt—refers to the work that teams prioritize lower, omit, or do not complete as they work toward creating the primary deliverables associated with the project’s product. Technical debt accrues and must be paid in the future. Quick-fix and building deliverables that do not comply with standards for quality, security, long-term architecture goals, and so forth.
Some of the reasons for technical debt could be:

• Lack of coordination among different team members, or different Scrum Teams as teams start working in isolation with less focus on final integration of components required to make a project or program successful.
• Poor sharing of business knowledge and process knowledge among the stakeholders and project teams.
• Too much focus on short-term project goals instead of the long-term objectives of the company. This oversight can result in poor-quality Working Deliverables that incur significant maintenance and upgrade costs.

In Scrum projects, any technical debt is not carried over beyond a Sprint, because there should be clearly defined Acceptance and Done Criteria. The functionality must satisfy these criteria to be considered Done. As the Prioritized Product Backlog is groomed and User Stories are prioritized, the team creates Working Deliverables regularly, preventing the accumulation of significant technical debt. The Scrum Guidance Body may also include documentation and definition of processes which help in decreasing technical debt.
To maintain a minimal amount of technical debt, it is important to define:

• The product required from a Sprint and the project along with the Acceptance Criteria,
• Any development methods to be followed,
• And the key responsibilities of Scrum Team members in regards to quality.
• Defining Acceptance Criteria is an important part of quality planning, and it allows for effective quality control to be carried out during the project.

Technical debt may be a very big challenge with some traditional project management techniques where development, testing, documentation, etc. are done sequentially and often-times by different persons, with no one person being responsible for any particular Working Deliverable. As a result, technical debt accrues, leading to significantly higher maintenance, integration, and product release costs in the final stages of a project’s release.
The cost of changes is very high in such circumstances as problems surface in later stages of the project. Scrum framework prevents the issues related to technical debt by ensuring that Done deliverables with Acceptance Criteria are defined as part of the Sprint Backlog and key tasks including development, testing, and documentation are done as part of the same Sprint and by the same Scrum Team.
For interesting articles about Scrum and Agile, visit  http://www.scrumstudy.com/blog/managing-technical-debt-in-a-scrum-project/

Scrum and High Performance teams

In the field of organization behavior, the notion of the high-performing team has been discussed. Many of today’s Customers need rapidly adapting development services. High-performing teams are the key to providing that service. A mature high-performing team is a united unit, not merely a throng of individuals. While such teams usually emerge by chance; a high-performing team can also be deliberately molded with an understanding of team member requirements in mind. Scrum framework which brings out the truly necessary essentials, can help with achieving this. While Scrum Framework increases the chances of such a team forming, it is not a necessary or sufficient condition for high-performing teams.
Certain enablers can herald formation of high-performing teams: Some of them come in the form of Human resource practices for the organization. However, they regularly get over-complicated or misapplied. Scrum team is often encumbered with overwhelming info, which cripples the ability to think clearly. The Scrum Core team members become burdened by esoteric language, process, principles or practices that clutter their minds and focus. Great Scrum Masters don’t strictly enforce working hours. What they do enforce is presence on the Daily Standups- everyone on a given team has to be there and there are penalties for being late. Daily Standups” instil discipline by requiring a fifteen-minute daily meeting.
Classic environmental enablers in Scrum include collocated teams, team rooms/war rooms, visible charts, and white boards. By being responsible for this environment, a great Scrum Master can help in creating high-performing teams that effectively address business’ needs. The product backlog is A Great Scrum Master’s best source of reality to give feedback as to whether they are making the right decisions and having the right conversations. With conversations a Great Scrum Masters can help the Scrum Team detect if understanding is there. Scrum advocates that the teams should have the freedom to decide how they will deliver the User Stories they committed to during the sprint planning.
High performing teams collaborate by visibility. With visible product backlog or a Scrumboard, Stakeholders see where effort is being applied. When a Product Owner can see where to apply effort, the Scrum Team members work together and do not flounder. In projects, much of the work is not easily visible and therefore self-organization is necessary. With visible work efforts Great Scrum Masters improve the odds that each conversation will be the right one and make reporting on team progress easy.
The Product Owner also has to balance between discipline and freedom, monitoring and separating what is crucial from what is incidental and hence can be delegated to the team. Great Product Owners maintain a disciplined process but allow freedom, both in choice of tools, rules, and in adding project-specific guidelines to the organization’s universal standards. Conversation can be setup by formal or informal processes language agreements, team location, and more. High-performing teams are basic assets that individuals, businesses, and organizations need to help them thrive. This approach; strictly enforces a few key things; be relaxed on others gives the discipline Scrum needs but allows the freedom Scrum members crave. Achieving this balance should be part of good practice on any Scrum team.


Acknowledgement: This content has been borrowed from www.scrumstudy.com
Original link: http://www.scrumstudy.com/blog/scrum-and-high-performance-teams/

Difference between Waterfall and Agile

The Waterfall model is suitable for ordered and predictable projects in which all the requirements are clearly defined and can be estimated accurately, and in most industries, such projects are dwindling.
Changing requirements from customers have led to an increased pressure on businesses to adapt and change their delivery methods. Agile projects are completed in an iterative manner wherein the functionalities with the highest business value are completed first. Various cross-functional teams work in parallel across Sprints to deliver potentially shippable solutions at the end of every Sprint.
As the customer regularly interacts with the team in Agile projects, the work completed is regularly reviewed; thus, there is assurance that the progress is per customer specifications. Because each iteration results in a shippable solution (which is a part of the overall product), there is a measurable objective that the team has to accomplish, and this ensures that the team is progressing and the project will be completed on time. However, in Waterfall there is no such interaction as the work is carried out in silos and there is no presentable functionality until the end of the project. Traditional methods do not present such timely checks and, therefore, result in situations in which the team might get off schedule and end up with a lot of work toward the end.
However, when completing simple projects with well-defined functionalities, and when the team has previous experience completing such projects (therefore, estimation would be accurate), the Waterfall method can be successful. In complex projects, in which the customer is not clear about what the end product will be and, therefore, the end product functionality keeps changing, the iterative model is more flexible in ensuring that these changes can be included before the project is complete. The Waterfall method struggles to accommodate such changes.
Agile methodologies require a change in mindset from traditional methods. The central focus has moved from the scope in Waterfall methods to achieving maximum business value in Agile. While in Waterfall, cost and schedule are altered to ensure the desired scope is achieved, in Agile, quality and constraints can be altered to achieve the main objective of attaining maximum business value. Agile methods are more successful in the current market, which is marked by unpredictability and volatility. Agile methods are based on inspect-adapt cycles as opposed to the command and control structures of the Waterfall method.

Acknowledgement: This content is borrowed from www.scrumstudy.com (Original URL: http://www.scrumstudy.com/blog/difference-between-waterfall-and-agile/ )

Expert Scrum

We know that a Scrum project involves a collaborative effort to create a new product, service, or any other result. So we need to define, how the methodology works for a project, program or portfolio. But before that, we need to define these three terms.

Definition of Project, Program, and Portfolio

• Project—A project is a collaborative enterprise to either create new products or services or to deliver results as defined in the Project Vision Statement. Projects are usually impacted by constraints of time, cost, scope, quality, people and organizational capabilities. The objective of project team is to Create Deliverables as defined in Prioritized Product Backlog.

• Program—A program is a group of related projects, with the objective to deliver business outcomes as defined in the Program Vision Statement. The Prioritized Program Backlog incorporates the Prioritized Product Backlogs for all the projects in the program.

• Portfolio—A portfolio is a group of related programs, with the objective to deliver business outcomes as defined in the Portfolio Vision Statement. The Prioritized Portfolio Backlog incorporates the Prioritized Program Backlogs for all the projects in the program.

Scrum in Projects

Since Scrum favors small teams, one may think that this method can only be used on small projects, but this is not the case. Scrum can also be used effectively on large-scale projects. When more than ten people are required to carry out the work, multiple Scrum Teams may be formed. The project team consists of multiple Scrum Teams working together to Create Deliverables and Product Releases, so as to achieve outcomes desired for the overall project.

Since a project can have multiple Scrum Teams working in parallel, coordination between different teams becomes important. The Scrum Teams usually communicate and coordinate with each other in a variety of ways, but the most common approach is known as a Scrum of Scrums (SoS). Members representing each Scrum Team come together to discuss progress and issues and to coordinate activities between teams. These meetings are similar in format to the Daily Standup Meetings; however, the frequency of the Scrum of Scrums could be pre-determined intervals or they could be coordinated as required by the different Scrum Teams.

Scrum of Scrums (SoS) Meeting

A Scrum of Scrums Meeting is an important element when scaling Scrum to large projects. Typically, there is one representative in the meeting from each Scrum Team—usually the Scrum Master—but it is also common for anyone from the Scrum Team to attend the meeting if required. This meeting is usually facilitated by the Chief Scrum Master and is intended to focus on areas of coordination and integration between the different Scrum Teams. This meeting is conducted at pre-determined intervals or when required by the Scrum Teams.

In organizations that have several Scrum projects happening simultaneously, the Scrum of Scrums meeting can be scaled up another level to what is referred to as a Scrum of Scrum of Scrums meeting. In this situation, a separate Scrum of Scrums Meeting is held to coordinate each group of projects that are directly related to each other.

In this example, there are six projects taking place simultaneously. Three of the projects are directly related to each other: projects A, B, and C. The other three that are directly related to each other are projects D, E, and F. A Scrum of Scrums meeting is held to coordinate the interdependencies between the projects in each directly related group. Then a Scrum of Scrums of Scrums Meeting is conducted to coordinate and manage the activities of all projects.

Scrum in Programs and Portfolios

Programs

In programs, important roles to manage Scrum programs are:

Program Product Owner—Defines the strategic objectives and priorities for the program

Program Scrum Master—Solves problems, removes impediments, facilitates, and conducts meetings for the program

These roles are similar to those of the Product Owner and Scrum Master except they meet the needs of their program or business unit rather than those of a single Scrum Team.

Portfolios

Similarly, in portfolios, important roles to manage Scrum portfolios are:

Portfolio Product Owner—Defines the strategic objectives and priorities for the portfolio

Portfolio Scrum Master—Solves problems, removes impediments, facilitates, and conducts meetings for the portfolio

The needs and structure of each organization are different. It is the responsibility of the Scrum Guidance Body to scrutinize the organization at different levels to understand and define appropriate application of Scrum and to act as a consulting body for everyone working on a project, program, or portfolio.

 Working with Program and Portfolio Teams

 When applying Scrum to manage projects within the context of a program or portfolio, it is strongly recommended that the general principles of Scrum presented in this publication are adhered to. It is understood though, that in order to accommodate the overall program or portfolio activities and interdependencies, minor adjustments to the set of tools, as well as the organizational structure may be required.

Portfolios and programs have separate teams with different sets of objectives. Program management teams aim to deliver capabilities and realize certain goals that contribute toward the achievement of specific program objectives. In contrast, the portfolio team has to balance the objectives of various programs to achieve the strategic objectives of the organization as a whole.

Managing Communication with Program and Portfolio Teams

The problems and issues faced when using Scrum within a program or portfolio primarily involve coordination across numerous teams. This can lead to failure if not carefully managed. Tools used for communication need to be scaled to match the requirements of the many teams involved in a program or portfolio. Each Scrum Team must address not only internal communications, but also external communications with other teams and the relevant stakeholders of the program or portfolio.

Maintaining Stakeholder Involvement

Scrum requires complete support from the project stakeholders. The responsibility for keeping stakeholders engaged lies with the Product Owner. The following are actions recommended for maintaining stakeholder engagement and support:

• Ensure effective collaboration and stakeholder involvement in the project
• Continually assess business impact
• Maintain regular communication with stakeholders
• Manage stakeholders’ expectations

One key stakeholder is the sponsor—the individual who provides the funds and other resources for a project. Sponsors want to understand the financial bottom line related to a product or service and are typically more concerned with final outcomes rather than with individual tasks.

It is important that the sponsors who are funding the project have clarity on the following issues:

• Benefits of implementing Scrum
• Target deadlines and estimated costs of Scrum project
• Overall risks involved in Scrum projects and the steps to mitigate them
• Expected release dates and final Deliverables

Article Overview:- This article is borrowed from www.scrumstudy.com (Original blog URLhttp://www.scrumstudy.com/blog/scrum-methodology-in-projects-programs-and-portfolios/ )