Agile methodology

1

Agile ProductManagement at Planon

Presented By:Dipanway Bhabuk

2

Sector Overview

3

India is the world's largest sourcing destination for the information technology (IT) industry, accounting for approximately 67 % of the US$ 124-130 billion market.

The industry employs about 10 million workforce.

India's cost competitiveness in providing IT services, which is approximately 3-4 times cheaper than the US, its unique selling proposition (USP) in the global sourcing market.

The IT sector in India grew at a Compound Annual Growth rate (CAGR) of 15% over 2010-15,which is 3-4 times higher than the global IT spend.

Estimated to expand at a CAGR of 9.5 per cent to US$ 300 billion by 2020.

4

India, the fourth largest base for new businesses in the world and home to over 3,100 tech start-ups, is set to increase its base to 11,500 tech start-ups by 2020, as per a report by Nasscom and Zinnov Management Consulting Pvt Ltd.

The computer software and hardware sector in India attracted cumulative foreign direct investment (FDI) inflows worth US$ 17.575 billion between April 2000 and May 2015.

5

Company Overview

Planon, founded in 1984, currently has a customer base of over 1300, which is supported by more than 325 employees.

The company made approximately 1.9 million profit with a revenue of 25 million in 2007.

Planon International is an international software vendor that produces Facility Management and Real Estate management software for organisations.

Planon's products are marketed through six Planon subsidiaries, based in the Netherlands, Belgium, Germany, UK, India and the US, and a worldwide network of partners.

Planon International, has, as one of the First known companies, attempted to implement an agile product management process based on the agile principle.

6

Introduction

One of the major innovations in software development methodology of the last few years has been the introduction of agile principles.

Several agile software development methods have been developed Since Agile Manifesto in 2001.

Examples of such methods are DSDM (Dynamic Systems Development Method), Extreme Programming and Feature Driven Development.

Demand for the extension of agile principles to other domains has risen. One such domain is software product management.

Software product management (SPM) is the process of managing requirements, defining releases, and defining products in a context where many internal and external stakeholders are involved.

7

What is Agile?

Agile methodology is an alternative to traditional project management, typically used in software development. It helps teams respond to unpredictability through incremental, iterative work cadences, known as sprints. Agile methodologies are an alternative to waterfall, or traditional sequential development.

What is Scrum?

Scrum is the most popular way of introducing Agility due to its simplicity and flexibility. Scrum emphasizes empirical feedback, team self management, and striving to build properly

tested product increments within short iterations

8

Facility Management

Discipline of ensuring functionality of the built environment by integrating people, place, process and technology.

Facility management encompasses activities such as long-range and annual facility planning, facility financial forecasting, real estate acquisition and/or disposal, work specifications, installation and space management, maintenance and operations management, and telecommunications integration, security, and administrative services.

9

Principles followed by Planon

Planon uses the principle that common data can be used among different processes. The common data is therefore only entered once into the data model that is central to all Planon software.

Secondly, because so many of the facility management processes are affected by Planon software products, Planon has developed its own implementation framework. With this framework a specific implementation path can be designed for a customer.

Finally, Planon trains the application managers at customers on a regular basis, as to provide them with more competence with the Planon products.

10

Product Backlog

One of the central documents in the SCRUM method is the product backlog

Product Backlog contains a list of all items relevant to a specific product

This list can consist of bugs, defects, customer requested enhancements, competitive product competitive edge functionality and technology upgrades

Product Requirement

Planned requirements for the project and is described in the product backlog

Each requirement has a priority and a number of complexity points.

The highest priorities are to be developed first.

The complexity points indicate how much developer time is needed to create it.

11

Sprint Backlog

Its consists of requirement of the employees, task assigned, an estimation of work to be done per task

Each team that participates in the project maintains its own sprint backlog

On the SB every requirement is broken down into several tasks, which are then assigned to specific team-members

Daily Update

After each sprint meeting, a daily progress comes out.

12

Activity Sub-activity Description

Prepare Sprint Review product backlog An existing PB is reviewed by the team to see which product development need to be developed in the upcoming sprint.PB contains product requirement for a project.Each sprint has a number of product requirement to be developed. Rejected requirements are sent back to the Product manager. Accepted requirements are planned and assigned for the upcoming sprint.

Send to PM requirements that are rejected will be sending back to the Product Manager. Further description or adjustments has to be made for the team in order to be clear and able to develop.When the Requirements are further described or adjusted by the Product Manager,the team can review the product requirements in the product backlog.

Make planning A planning for developing REQUIREMENTS is made for each team with their SPRINT BACKLOG for the upcoming sprint.

Assign requirement The product requirement are assigned to the SCRUM teams. The product requirement are put in the sprint backlog of the teams. Each team has their own sprint backlog.

Run Sprint Hold daily SCRUM meeting Every team has their own SCRUM meeting. The SCRUM master gets an update and can remove certain

impediments. When this is done the progress can be clearly seen and the SPRINT

BACKLOG can be updated.

13


Develop requirement After the daily SCRUM meeting, the team does their own work and develops the assigned REQUIREMENTS.

Depending on the priority and importance of the REQUIREMENTS, developed REQUIREMENTS are chosen and tested.

If the sprint has not ended, it goes to the activity “Hold daily SCRUM meeting”. When the sprint ends it goes to the activities “Check developed software” and “Evaluate past sprint”.

Check developed software Developed software is checked if they meet the criteria and ready to be presented as a demo. The four criteria are:1. Junit test has been passed successfully.2. No urgent bugs.3. Documentation is made.4. Software is working.When one of the criteria is missing, the REQUIREMENTS are taken to the next sprint

and goes to the activity “Review product backlog”. If the software meets the criteria it goes to the activity “Deliver working software”.

Evaluate past sprint An evaluation takes place at the end of every sprint. The teams discuss what went well and what went wrong and what improvements

can be made for the next sprint. These IMPROVEMENT ITEMS are written down and a selection of one to three

IMPROVEMENT ITEMS is made. They are taken onto the SPRINT BACKLOG.

Deliver working software When the sprint has ended and the software meets the criteria, an INTERNAL RELEASE is delivered.

Also a DEMO is made to present the working software. Each team delivers working software .

The working software is the REQUIREMENTS combined together to an INTERNAL RELEASE.

14


Release Product Review sprint The team presents the demo of the working software in the Sprint review. Every stakeholder (employees, customers, product management) can attend

the sprint review. NEW REQUIREMENTS can be derived from the review. These NEW REQUIREMENTS are put into the PRODUCT BACKLOG.

Release external version When the DEMO is given and the sprint has been reviewed, The INTERNAL RELEASE is released.

Each half year an EXTERNAL RELEASE of the software is released. When the half year hasn’t passed, a new sprint starts and goes to “Review product backlog”.

Release customer If the half year has passed and there have been six successful releases of the INTERNAL RELEASE, an EXTERNAL RELEASE of the software is released to customers.

A new sprint starts if the project is still running and goes to “Review product backlog”.

Project can end because of several reasons; no business value, no market needs or software has been developed successfully and no more adjustments/extensions have to be made.

15


Identify Business Problem

The inception of the process always starts with identifying a VERIFIED BUSINESS PROBLEM.

These problems are the triggers for the process. Then the decision is made whether VISION and THEMES are applicable to

solve the business problem. If applicable or needed it goes to “set goals” or else “Create Product

Backlog”.

Identify Theme Set goals Set goals for the upcoming project and based on the goals and the business problems, VISIONS are chosen.

Choose vision The input for the VISION can come from customers, employee or a stakeholder.

Visions are chosen to solve the business problem.

Involve stakeholders Stakeholders are involved in the decision making process and information is acquired from them.

Decide business value VISIONS are depicted in a graph to see their business value. The cost is compared against their added value. The business value is described in the RELEASE DOCUMENT.

Identify opportunities Based on the business value, opportunities are identified.

Define theme The VISION is further described to a THEME. A VISION is defined to a THEME or a set of THEMES.

16


Estimate theme investment An estimation of the investments and how long it will take to realize the THEME is made. The costs and the business value are calculated.

Choose theme Based on the business value comparison, stakeholders of Product Management and theme investment, THEMES are chosen for the upcoming project.

The chosen THEME is described further in the RELEASE DOCUMENT. When THEMES are chosen, the next decision is if CONCEPTS are needed or go straight to defining REQUIREMENTS.

Define Requirements Define concept A THEME is broken down to a set of CONCEPTS. These CONCEPTS contains SOLUTION STORIES. These stories are used for defining the REQUIREMENTS. CONCEPTS are defined by

product managers and software architects.

Review concept When CONCEPTS are defined, they are reviewed by Software Architects and Domain Experts. If the CONCEPTS are approved, a set of REQUIREMENTS are defined in the next activity. If the CONCEPT is not approved, it should go back to the activity ‘Define Concept’.

Define requirement Each CONCEPT is further described and broken down to a set of REQUIREMENTS. A team is responsible for defining REQUIREMENTS. A REQUIREMENT can be broken down to smaller REQUIREMENTS to fit in a sprint. The REQUIREMENTS are put into the PRODUCT BACKLOG.

Review requirement REQUIREMENTS are reviewed by Lead Developers, Architects, Functional analysts and Domain Experts. If a REQUIREMENT is approved it goes to the next activity ‘Value requirement’. If a REQUIREMENT is rejected, because they are unclear or not sufficiently described, they need to be defined again and goes back to the activity ‘Define requirement’.

Create Product Backlog A PRODUCT BACKLOG is made to put in the chosen THEMES, CONCEPTS and REQUIREMENTS for the upcoming project.

Prepare ProductDevelopment

Value requirement The costs and the business value of a REQUIREMENT are determined. These REQUIREMENTS are valued and prioritized in the next activity.

17


Prioritize requirement First the countries are prioritized and a weighing-factor is assigned. After the country prioritizing, the requested features are prioritized. REQUIREMENTS get a priority and are put into the PRODUCT BACKLOG. The highest rated REQUIREMENTS needs to be developed first.

Make sprint planning When REQUIREMENTS are clear and have enough detail they are assigned to SCRUM teams.

The REQUIREMENTS are put in the specific sprint backlog of each team and the general sprint backlog of Product Management.

The progress of a project can be tracked and monitored. Each development team has their specific sprint backlog containing the

progress, planning and the members of the team.

Prepare Release Launch

Identify key new modules/features

After assigning REQUIREMENTS, the release needs to be prepared. New modules and features are first identified and prepared for the departments: Marketing & Sales and Services.

Prepare Marketing&Sales

A DELIVERABLE LIST (MARKETING LIST) is made to prepare the department Marketing & Sales.

The list contains items about how and what needs to be sold effectively to the market and the customers.

Prepare Services For an effective implementation a DELIVERABLE LIST is made. Items about advising customers, how to use the new features and

implementation of these new features are part of the list.

Prepare Training The departments Marketing & Sales and Services needs to be trained and is described in the IMPLEMENTATION LIST.

Besides a training description for the departments, also the customers and partners of the company need a training description.

Prepare Implementation The necessary items to effectively implement the new modules/features are described in the RELEASE DEFINITION and are also a part of the DELIVERABLE LIST and RELEASE DOCUMENT.

18

SCRUM at Planon

Planon switched to the SCRUM development method in 2004.

Before this time, work was being done according to the Prince2 method. However, management recognized that by working in this manner, several issues arose.

Firstly, release cycles could take up to one or one and a half year. This was combined with the fact that release end-dates were difficult to predict.

Another important issue was the fact that during a project, many changes were requested. The Prince2 method did not offer sufficient support for this, resulting in a lot of calculations that caused a large share of the product managements time to be put into these tasks instead of in product value.

19

Improvements due to SCRUM

Firstly, changes are now implementable against far lower costs.

software is developed in one-month sprint, resulting in two release per year, with marketing-versions delivered in between.

20

Effort Estimation

Availability of testers, complexity of a task and skill of the teams are some of the factors that make it difficult to define an adequate unit.

Planon currently uses ’complexity points’ (CP) to indicate the estimated effort required.

21

Task Assignment

Teams are still allowed to select those tasks of which they think that they can implement them within one sprint’s time

Every team is assigned only few projects.

22

Product Quality Assurance

One of the key-elements to a successful SCRUM implementation identified by Planon is product quality assurance

Effective composition of the development teams regarding the ratio of programmers over testers

Crucial aspect is test automation along with unit testing by the whole team. Since it is not possible to test all features completely, test effort has to be determined per backlog item.

23

Development Team Composition

Development teams at Planon are multi-disciplined, consisting of functional designers, testers, (lead) programmers and documenters. Besides this, two other functions exist outside of the teams, namely the lead architect and development infrastructure support.

24

The Process of Agile Product Management

The inception of the process starts with the identification of a verified business problem.

The input for the themes can come from various sources, such as customers, employees or stakeholders

Stakeholders are involved in the decision making process and information is acquired from them

In order to be able to determine which themes and functionalities are going to be implemented, both the potential costs and opportunities are estimated

25

The Process of Agile Product Management

The chosen themes are, in most cases, broken down into a set of concepts. Every concept contains a set of solution stories

A requirement engineer and a SCRUM team are responsible for the definition of the requirements. Requirements can be broken down into smaller requirements to fit into a sprint.

The highest rated requirements are to be developed first

27

Vision, Scope & Requirements

Before any project can start, it should to a certain extent be clear what is going to be built.

Planon has extended this with the concepts ‘vision’, ‘theme’ and ‘concept’.

A vision is basically the starting point for each project. It is an idea, brought up by an employee, a customer or any other stakeholder

28

Product Management Sprint

The agile aspect of planons product management approach lies mainly in the fact that, besides software development, the product management task is also performed according to thirty-day sprints.

Software development, new, completed or cancelled task are continuously kept up-to-date on the product management sprint backlog.

29

Product Management Backlog Analysis

Mean Lowest HighestOf task 75.4 43.0 121.0Of prod man 5.6 5.0 6.0Of hours at start 537.9 324.0 750.0Of hours at end 197.1 102.0 320.0Avg hours per task 7.7 3.7 12.9Avg task per person 13.5 7.2 22.4Avg hours per person

97.4 54.0 150.0

% of hours fulfilled 63.3% 47.6% 81.1%

30

Continued…

The above table tells about the task structure, including task duration and workload per person, as well as on the discovery of interesting patters.

The table shows the amount of task that were placed on the SPM sprint backlog in one month, the total amount of planned hours for those tasks and the average amount of hours per task, the average workload per person expressed in hours.

The final column shows an effectively-score, obtained by calculating the reduction in hours assigned to all the tasks. The bottom three rows show statistics about the lowest, the highest and the average score for all items.

The SPM backlog provides interesting information regarding the amount of tasks and their characteristics.

Firstly, we are able to distinguish a set of recurring, standard activities. The second interesting point is the introduction of themes, concepts and requirements into the SPM backlog.

31

Lesson Learn

Alternating cycles for SPM and Development

The software development and the SPM sprint are both performed continuously, but with a difference in starting date of approximately two weeks. This implies that each SPM sprint ends halfway the software development sprint, ensuring that the product backlog is ready to be used when the development teams start their new sprint.

Daily SCRUM meetings are essential

The fifteen-minute meeting at the start of each day is experienced as a positive, helpful aspect of the process.

32

Complex requirements are in need of structured detailing

This contribution lies in the division of requirements into themes, concepts and requirements Both high level and low level requirements are placed on the product backlog and handled in

time by the appropriate person.

Backlog administration requires discipline

The sprint backlog can play a useful role in controlling the SPM process and keeping track of the progress of a sprint, the motivation to keep the current set of tasks and the amount of time spent on a specific task up-to-date is still lacking.

33

Thank You…

Agile methodology

Marketing

Transcript of Agile methodology