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.

Scrum and Agile: A brief look

Many organizations all over the world are finding it hard to keep up with the fast-changing business scenarios, using the traditional project management methods. These scenarios may include periodic customer demands, fast-changing project requirements, and issues relating to support activities and so on. Increasingly, project managers and software developers have started to prefer Agile software development methods. Even the US Department of Defense, in a recent update to its procurement rules has made known its non-preference for ‘Waterfall model’-based project management solutions. Some of the most popular methods include Rational Unified Process, Scrum, Extreme Programming and Dynamic Systems Development Method.

An overview of the Agile methodology

The year 2001 saw the ‘Agile Manifesto’ being formulated by seventeen software programmers at Snowbird Resort in Utah, USA. The Agile Manifesto gives us twelve important principles, which include customer satisfaction, communication, co-operation, the importance of working software, and welcoming change.

Agile methods break-up complex tasks into small increments with nominal planning. Iterations are short time frames that may last between one to four weeks. The iteration involves a team with cross-functional skills. Planning, requirements analysis, designing, coding, unit testing, and acceptance testing are all taken care of by the same team. At the end of the iteration, a working product is presented to stakeholders. This reduces overall risk and allows the project to adapt to changes swiftly.

An overview of the Scrum Methodology

Scrum is one of the most popular Agile methodologies. As per the Scrum Book of Knowledge, Scrum is an adaptive, iterative, fast and flexible methodology designed to quickly deliver significant value during a project. It ensures transparency in communication and creates an environment of collective accountability and continuous progress.

The typical Scrum project will include the below-mentioned steps:

·         The Project Vision is created during Stakeholder Meeting, following which the Product Owner develops a Prioritized Product Backlog. This includes a ranked list of business requirements written in the form of User Stories).

·         A Sprint Planning Meeting is the first activity within a Sprint, during which high priority User Stories in the Prioritized Product Backlog are considered to be included within the Sprint.

o   A Sprint usually lasts between one and six weeks, where the Scrum Team works to create theoretically shippable Deliverables or product increments.

o   During the Sprint, short yet extremely focused Daily Standup Meetings are coordinated by the Scrum Master where the Scrum Team discusses progress.

o   Toward the end of the Sprint, a Sprint Review Meeting is held during which the Product Owner and relevant stakeholder(s) are provided a demonstration of the Deliverables.

·         The Product Owner consents about the Deliverables only if they meet the previously agreed Acceptance Criteria.

o   The Sprint comes to an end with a Retrospect Sprint Meeting where the Scrum team deliberates ways to develop processes as they move ahead into succeeding Sprints.

Is training with a training provider the way to go for a certification?

The IT domain is very dynamic in nature. Trends and scenarios change within a matter of months. Your skill-set might be in high demand right now but it may become obsolete in a few months down the line. Hence IT professionals need to undergo certification programs to keep their skills abreast with the market. There are thousands of IT certifications which are available in the market these days. Most of them train you on new technologies. There are certifications by different vendors such as Microsoft, CompTIA, Cisco, Apple and others. The training and certification industry has become a multi-billion dollar industry in itself.

Based on your existing skill-set and requirements in your job, you select a certification which you want to undertake. For example, if you are working in company X and your work is to deploy cloud solutions at your client site. Then you may choose to get certified for cloud computing. This will not only add credibility to your resume but also will empower you with the skills required to do the job more effectively.

Now that you have chosen the certification you want to do, the next question which comes up is that if you should undergo a training program with a training provider or do self-study. Opinions are divided on both the formats. A lot of people propose that self-study is the best way to prepare for a certification exam. While this might be true in the way that you will definitely learn more and will explore a lot of new ideas and information, you might not learn the exact details which you will need to clear the certification exam. In-fact, an empirical study shows that the success rate to clear the certification exam increases considerably when the candidate undergoes a training program to prepare for the certification exam.

These training programs are designed in such a manner that focussed information is provided to the candidate which will help them learn the concepts quickly and prepare for the exam. This increases their probability of clearing the exam considerably. The trainers which undertake these training sessions are industry experts and are well aware about the learning requirements of the students.

If you decide to train with a training provider, choosing the right training vendor also becomes extremely important. There are hundreds of training vendors in the market who are ready to take your money in the name of providing training. Hence the onus now lies on you to select the right vendor. For more assistance on choosing the right vendor, you can refer to this article.   

Tips for First time Scrum Master

Most new Scrum Masters have a rudimentary comprehension of their new role. Many have undergone training and received their Licensed Scrum Master designation. They are thrilled and keen to don on their mantle of a Scrum Master in the event their teams invite them in formally. Once their initial enthusiasm starts fading away, a troublesome hesitation begins to take shape. Daily, in the midst of paying attention to and smoothing the daily standups, a quiet thought begins to flow in the Scrum Master’s mind:

The role of the Scrum Master is a difficult one for a number of reasons, not least of which is the fact that they have no authority; in fact the Scrum Team can fire them. Scrum Master is an expression misconstrued so quite often, sometimes consciously, which causes misunderstanding. The appellation itself hints people to unseemly assumptions because of the attachment of the term ‘Master’. Some consider this person is in reality the administrator of the Scrum Team or a synonymous term used in place of “Project Manager” in Traditional Project manager frameworks. One approach used when adapting Scrum is to redefine the role of the managers and convert them into the Scrum Masters for their respective Scrum Teams. In reality, Scrum Master is not giving the orders, neither the expert, nor the intermediary, or the negotiator. Scrum Master is not the administrator of the Scrum Team and without doubt not the project manager under an innovative label.

The Scrum Master has four key duties:

·         Facilitation of the stakeholders and interfaces

·         Agent of change within the organization

·         Impairment remover

·         Remover of distance between business and development

Many people who take on the role of Scrum Master have to be, to some degree or other re-trained into their new role. The Scrum Master is a servant-leader to the Scrum Team.

A Scrum Master should embolden, encourage, challenge, intercede, interrogate, pay attention and perceive in equal quantity toward making the rest of the Scrum team as effective as possible and altering the organizational environment to be more cooperative to Scrum framework. Ultimately Scrum Master is inconsequential in the Scrum process because he/she neither is making the payment for, nor in receipt of, the product. Scrum Master should understand his/her part therefore as a facilitator. Those who are openly involved in production should come to the deductions they need to forge ahead. Every now and then, this is quite easy and the Scrum Teams recognize the answer but essential to be inquired a few unpretentious questions to comprehend this. Usually, it really is a multifaceted situation where not one person knows what the solution is and the best the Scrum Master can do is to search options before The Scrum team decides on the best answer for that time. Occasionally, it is essential to fail in order to find a better way. A Scrum Master may have to find techniques from diverse fields – thinking, inquiring, advising rather than directing – to be useful in her endeavor of Scrum Master.

Why is Empirical Process Control So Important in Scrum Projects

?

In the traditional Waterfall model, all the planning needs to be done before any execution and the customer does not review product components till the end of the entire project. Although the PMBOK may write eloquent poems about how elegantly this works, in the real world things go down completely haywire. This method presents huge risks to the project and it is far more likely to significantly impact project delivery and customer acceptance.

In today’s rapidly changing market trends, the customer may imagine an ‘apple’ and the finished product made by the project team may be an ‘orange’. This though is not the main problem. If the customer is aware of what’s cooking from the start he can steer the team to the ‘apple’ side. But in actuality the customer finds out about the ‘orange’ only too late.

This is why Empirical Process Control is very important and why Scrum is the winning horse people should put their money on. In Scrum, decisions are made based on observation and experimentation rather than on detailed upfront planning. Empirical process control relies on the three main ideas of transparency, inspection, and adaptation.

Transparency allows all facets of any Scrum process to be observed by anyone. This promotes an easy and transparent flow of information throughout the organization and creates an open work culture. In Scrum we have a Project Vision Statement which can be viewed by all stakeholders and the Scrum Team; an open Product Backlog with prioritized User Stories, both within and outside the Scrum Team; clearly visible Scrumboards, Burndown Charts, and other information radiators; Daily Standup Meetings conducted making sure everyone’s aware of everything; and Sprint Review Meetings in which the Scrum Team demonstrates the potentially shippable Deliverables.

Inspection in Scrum is depicted through the use of a common Scrumboard; collection of feedback from the customer and other stakeholders; review and approval of the Deliverables by the Product Owner and the customer.

Adaptation happens as the Scrum Core Team and Stakeholders learn through transparency and inspection and then adapt by making improvements in the work they are doing. In Daily Standup Meetings, Scrum Team members openly discuss impediments to completing their tasks and seek help from other team members. Risk identification is performed and iterated throughout the project. Improvements can also result in Change Requests, which are discussed and approved. The Scrum Guidance Body interacts with Scrum Team members during many processes to offer guidance and also provide expertise as required. During the Sprint Retrospective, agreed actionable improvements are determined.

These three pillars of Empirical Process Control ensure that the problems which projects face in the Traditional Waterfall way of doing things do not happen in Scrum Projects.