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/