Agile methodology of Planon

1. Agile Product
Management at Planon
Presented By:
Dipanway Bhabuk
1

2. Sector Overview
2

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.
3

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.
4

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.
5

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.
6

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
7

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.
8

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.
9

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.
10

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.
11

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.
12

13. Activity Sub-activity Description
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.
13

14. Activity Sub-activity Description
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.
14

15. Activity Sub-activity Description
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.
15

16. Activity Sub-activity Description
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 Product
Development
Value requirement The costs and the business value of a REQUIREMENT are determined. These
REQUIREMENTS are valued and prioritized in the next activity. 16

17. Activity Sub-activity Description
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.
17

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.
18

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.
19

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.
20

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.
21

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.
22

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.
23

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
24

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
25

26. 26

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
27

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.
28

29. Product Management Backlog Analysis
Mean Lowest Highest
Of task 75.4 43.0 121.0
Of prod man 5.6 5.0 6.0
Of hours at start 537.9 324.0 750.0
Of hours at end 197.1 102.0 320.0
Avg hours per task 7.7 3.7 12.9
Avg task per
person
13.5 7.2 22.4
Avg hours per
person
97.4 54.0 150.0
% of hours fulfilled 63.3% 47.6% 81.1%
29

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.
30

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.
31

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.
32

33. Thank You…
33