I sense prowareness 7 star development methodology
1. iSense Prowareness – Seven Star Development Methodology
An iSense Prowareness White Paper
http://www.prowareness.nl
7 Star Development Methodology:
Whitepaper on Microsoft.NET
Software Development Process at
iSense Prowareness
2. iSense Prowareness – Seven Star Development Methodology
Contents
Introduction ............................................................. 3
Star 1: Attitude of an Entrepreneur……………………….…..6
Star 2: Development Process ..................................... 6
Star 3: Tools ............................................................ 35
Star 4: Communication ............................................ 38
Star 5: Key Performance Indicators........................... 43
Star 6: Technical Skills ............................................. 47
Star 7: Domain Knowledge ...................................... 48
2
3. iSense Prowareness – Seven Star Development Methodology
Introduction
iSense Prowareness is a Offshoring IT Services company providing services in Software Development and
testing Services. iSense Prowareness is a 100% Agile Organization and its software development
methodology is no exception.
Our Vision: Software development is a profession and it should be done by professionals in a
professional way. iSense Prowareness wants to genuinely help IT companies with this challenge.
iSense Prowareness follows an advanced software development offshore software delivery method and
is called 7 Star Development Methodology for execution of its Offshoring software development and
testing process. Most of the software development companies think that they if they have a very well
defined process all software projects that they will execute will be successful, but unfortunately that’s far
from true. Development Process is only one of the components required to achieve a successful project,
but there are other variables involved too – like the tools used, the professionals and their skills etc. We
realize the same based on our years of experience at iSense Prowareness and came up with such 7 Stars
of successful project execution. Let’s go through these stars:
Star 1 – Attitude of an Entrepreneur
The key to the development of good quality and value software is the attitude of the development team
and its members. If the attitude of an individual and the team is to look at the application from the end
user and the business point of view then he /she can not only develop good quality software but also add
a lot of valuable suggestions as to how to make the software more suitable for a client’s need.
iSense Prowareness has a culture where entrepreneurship is central. Professionals in the Netherlands and
India are encouraged to act as an entrepreneur. Our recruitment process is enables us to eliminate the
professionals and hire only professionals with the correct attitude. In addition, we pay much attention to
the theme "Entrepreneurship" by showcasing entrepreneurial behavior in weekly and monthly meetings
and reward professionals who exhibit such attitude at regular basis.
Star 2 - Process:
This Process is a framework to guide software projects so as to make them more systematic and
efficient. The Process at iSense Prowareness is a perfect mix of agile and conventional practices defined
by CMMi which was derived on our years of software project experiences across cross domain projects.
It can be put as a summation of three important industry practices = SCRUM + XP + CMMi.
The 7 Star Development Method is a delivery model which retains the agility and speed of SCRUM and
adds more predictability, the right engineering practices and an efficient communication strategy which
enables software development Offshoring projects to be developed 30-40% faster than standard
software delivery models and at less than 50% the costs with a similar development project in Europe as
it adds the cost advantages of Offshoring to the cost advantages of agile software development.
(Link to the detailed Description: Star 1: Attitude of an Entrepreneur
3
4. iSense Prowareness – Seven Star Development Methodology
iSense Prowareness has a culture where entrepreneurship is central. Professionals in the Netherlands and
India are encouraged to think and act as an entrepreneur because of the tremendous value they can add
to the clients and the software product.
Our recruitment process focused on hiring the people with entrepreneurial mentality and are given tests
during their initial probation on not only how well they can program but also how well they can come up
with ideas and exhibit traits in entrepreneurship.
During the execution of projects in the team, a lot of stress is laid on the value addition to the clients by
these entrepreneurial acts. They are discussed in weekly and monthly meetings and professionals
exhibiting these skills are rewarded on a weekly and monthly basis.
Star 2: Development Process)
Star 3 - Tools:
Software Tools are basic software applications which can help in create, debug, maintain or manage
other programs and applications. With the increasing growth of software development tools in the last
10 years, using the right software tools to develop your software can significantly reduce the
development effort in the project. At iSense Prowareness, our extensive sets of tools not only help in
achieving and managing high product quality but also high process quality across the project teams.
Using these tools the teams at iSense Prowareness are able to develop software 30% faster and with a
much higher measurable quality as compared to other software teams. The tool infrastructure is
discussed later in this whitepaper.
(Link to the detailed Description: Star 3: Tools)
Star 4 – Communication:
Communication is a secret ingredient in every software project. If you see a failed project in the software
industry, very high chances are the communication between the requirement manager and the
development team was not very clear or effective. At iSense Prowareness we use a communication
framework based on our past experiences with Dutch software projects that allows our development
team and our clients to communicate effectively and efficiently, so that the teams can deliver the
expectations of the clients.
iSense communication framework are a combination of tools and practices used at iSense Prowareness
and evolved over years of experience on setting right communication channels between our offshore
location in Bangalore and our clients base at Europe.
Since Offshoring software development faces the challenge of distance between the clients and the
development team, our communication framework bridges the cultural and distance gap so as to create
a transparent and easy to work model for offshore projects.
(Link to the detailed Description Star 4: Communication)
Star 5: Key Performance Indicators
At iSense Prowareness we believe in setting and measuring scores similar to a soccer match as numbers
give a strong sense of purpose and targets to achieve. We belief in measuring the important aspects,
learn and improve from them. The projects team measures- productivity, reliability and the product
quality every day, week and month of the project. All these statistics are real time and put up on a visible
4
5. iSense Prowareness – Seven Star Development Methodology
dashboard for the team and the clients to see, so that there is a 100% transparency on how the project is
progressing.
(Link to the detailed Description Star 5: Key Performance Indicators)
Star 6: Technical Skills of the Professionals
One of the biggest challenges the ICT industry is facing today is the access to highly skilled and trained
ICT professionals. We call these highly skilled and trained ICT Professionals as “Superstars” at iSense
Prowareness. The advantage of having a superstar performer in one’s organization as compared to an
average skilled professional is manifold. Based on research statistics it has been proved that hiring such a
superstar performer is 4 times more profitable than an average performer. At iSense Prowareness we
ensure with our organization recruitment policies and training programs that we hire and nurture
Superstar talent.
(Link to the detailed Description Star 6: Technical Skills)
Star 7: Domain Knowledge
Software teams have hard times to develop business software when they are not familiar with the
business problem. At iSense Prowareness we believe in mastering our client’s business domain so as to
help them by not only giving them the right solutions but also new ideas and suggestions by which they
can improve their software product. Our process is designed in such a way that there our team has
sufficient knowledge about our clients business. Also our hiring process has a policy of perfect match –
we try to ensure that we hire professionals who have expertise on the required domain. During the
course of the project the teams send the clients a business understanding document every month so as to
update the clients on the team’s business understanding. This helps the clients to have a better visibility
about the teams understanding of their business.
(Link to the detailed Description: Star 7: Domain Knowledge )
With the use of 7 Star DEVELOPMENT METHOD we at iSense Prowareness are able to deliver software
faster and more consistently as compared to our competitors who use vanilla software development
models. These stars can be mapped to the stars of Hotel Industries, a 5 star Hotel has more stars if it can
offer more to its customers in terms of service, staff and convenience as compared to a 2 or 3 star hotels
where one has to compromise on some areas – like level of service or the professionalism or the facilities.
5
6. iSense Prowareness – Seven Star Development Methodology
Star 1: Attitude of an Entrepreneur
iSense Prowareness has a culture where entrepreneurship is central. Professionals in the Netherlands and
India are encouraged to think and act as an entrepreneur because of the tremendous value they can add
to the clients and the software product.
Our recruitment process focused on hiring the people with entrepreneurial mentality and are given tests
during their initial probation on not only how well they can program but also how well they can come up
with ideas and exhibit traits in entrepreneurship.
During the execution of projects in the team, a lot of stress is laid on the value addition to the clients by
these entrepreneurial acts. They are discussed in weekly and monthly meetings and professionals
exhibiting these skills are rewarded on a weekly and monthly basis.
Star 2: Development Process
As stated earlier the Software Delivery Process at iSense Prowareness is a mix of Scrum, XP and CMMi
Practices. Let’s take these practices one by one
SCRUM is a leading framework of Software development which was co-developed by Ken Schwaber and
Jeff Sutherland and is adopted 100% in our process.
What is SCRUM and why we chose scrum?
Scrum is an iterative incremental framework for managing software development projects and the
drivers for choosing SCRUM as our base framework for developing software were:
1) Deliver Business value to customers during the early phase of the project – 80% of the Business
value of the software to be delivered in 60% of the budget.
2) High speed software development with emphasis on automation and reusability – 30% faster
than any a standard software process.
3) High quality software development process with quality checks at each phase.
4) High on flexibility, adapt to change and adapt with changing requirements and delivery
continuously.
5) Complete transparency in delivery cycles to the business and associated stakeholders hence
providing them with the complete control on project execution.
CMMi and XP Practices:
What is CMMi and Why CMMi is a plus?
Capability Maturity Model Integration (CMMI) is a process improvement approach that provides
organizations with the essential elements of effective processes that ultimately improve their
performance.
6
7. iSense Prowareness – Seven Star Development Methodology
Successful software development is challenged by the supplier’s ability to manage complexity,
technology innovation, and requirements change. Management of complexity requires process
discipline while management of change requires adaptability. CMMI provides process discipline and
adds more predictability and Scrum enhances adaptability to these changes. It’s proven that Scrum
and CMMI together bring a more powerful combination of adaptability and predictability than either
one alone.
At iSense Prowareness light-weight CMMi level 2 practices are implemented to institutionalize Agile
methods more consistently and understand what processes to address.
What is XP and Why XP is a plus?
Extreme Programming is a software development discipline that organizes people to produce higher
quality software more productively. Extreme Programming was created by Kent Beck during his work
on the Chrysler Comprehensive Compensation System (C3) payroll project.
Scrum is mostly a project management wrapper for Extreme Programming engineering practices.
Scrum provides the agile management practice and Extreme Programming provides the integrated
engineering practices to achieve successful agile projects.
At iSense some important aspects of XP are implemented to provide sound engineering means to be
agile, some of these practices are – Continuous Build, Pair Programming, Coding Standards and
Refactoring, and Automated Testing.
Let’s go deeper into on how do we do SCRUM at iSense Prowareness.
The members who constitute the team are – Scrum Master (The Team leader who is also the Architect),
the Scrum team (which included Developers, Testers, User Interface Designers) and the Product Owner
(the Client Requirement Manager).
The Scrum team and the Scrum Master are located at the offshore location and the Product Owner is
located at his office in Europe.
7
8. iSense Prowareness – Seven Star Development Methodology
Netherlands Bangalore, India
Developers
Developers
Scrum Master
Scrum Master
Product Owner -Architect and
-Architect and Team
Team Leader
Leader
Tester
Tester
The Project Initiation starts with Sprint ‘0’ which takes care of the Project Initiation stage of the project.
During this period the Scrum Master travels to the client location in Europe. The Scrum Master is the
ambassador of the team and helps get the project kick started with the Product Owner.
The Scrum Master is at the Client location (Onsite) for a period of 4 weeks where he/she does the
following:
1) Train the Client Requirement Manager and the other team members at Onsite about SCRUM++,
and more details about the role of the Product Owner.
2) Together with the Product Owner the Scrum Master comes up with an overall
a) Backlog list and an Overall Release Planning
b) Infrastructure/Installations ( Like testing VPN/ Installing new Tools if required like
Team Foundation Server etc)
c) Overall System Design – At iSense Prowareness, we have predefined high level
architectures based on best practices. The Scrum Master suggests a high level design
to the Client team and defines how the design would manage their business
requirements.
d) The Scrum Master also develops a small prototype for the application on how some
basic but important feature would look like.
e) He does a briefing to the Client Management and the Product Owner on how the
project would proceed by setting up a project plan.
8
9. iSense Prowareness – Seven Star Development Methodology
After the duration of Sprint Zero the Scrum Master is back at the Bangalore office and does the
knowledge transition to the Scrum team in India.
Once the transition is done to the Scrum Team by the Scrum Master, the team proceeds to create a
detailed Release planning for the project. The Release Plan is sent to the Product Owner for his/her
inputs, usually the Product Owner makes his thoughts clear about which stories to be grouped together
in a release during the Sprint’0’ overall release planning. The Scrum team has a release planning meeting
where they discuss every story and estimate the stories in story points. The estimation is done by the
team by playing poker which is an XP and Scrum practice.
After this the delivery sprints at iSense get started and the result of every sprint is an almost shippable
product. Before the beginning of every sprint the Product Owner updates the backlog sorted with the
backlog items with the highest priority so that the Scrum team is clear with what’s most important to
develop.
Let’s get into the description of how the Delivery sprint at iSense Prowareness Offshore location looks
like. Usually the delivery sprint is for duration of 2 weeks.
Before the beginning of the sprint the Scrum team has a discussion with the Product Owner on planning
the Sprint – selecting the items they want to commit on the Sprint with the estimates for the each item in
the backlog. The product owner defines the goal of the sprint – like completing some important business
aspect of the application. The team internally creates a breakup of all User stories in a work breakdown
form and then defines the estimates matching to each work item in story points. The team along with
the product owner goes through the definition of DONE which is basically the expected state of the
delivered software product. At iSense the definition of DONE is basically designed, developed, tested and
each of them verified for high quality based on established quality gates. The commitment is then
discussed with the Product Owner and on acceptance with the Product Owner the team can start with
the delivery items of the sprint. The Sprint Planning meeting is time boxes to 2 hours. This meeting
happens on every alternate Friday after the previous Sprint review and retrospective meeting. The timing
for this meeting is from 2:00-4:00 PM IST which is 10:30 AM – 12:30 AM CET.
9
10. iSense Prowareness – Seven Star Development Methodology
Once the Scrum team is done with the Sprint Planning, it’s all ready to start with the Sprint. Every
Morning the team conducts a Daily Scrum Meeting at the offshore location called the Offshore Daily
Scrum Meeting. The Scrum team reports to each other on three points
- What did I do yesterday
- What will I do today
- And are there any impediments on the way?
This meeting happens every day at 11:30 AM IST (8:00 AM CET) among the team and the team member
sends the minutes of this meeting in a simple format to all the stakeholders (onsite and offshore) to keep
them informed as to update them of their daily progress. This meeting is also time boxed and lasts for 5-
10 mins for a team of 3 members. After which the team starts working on the planned items. After this
meeting the Scrum Master discusses the impediments with the team member associated and tries to
resolve them so that the team members can go back and achieve their daily plan.
10
11. iSense Prowareness – Seven Star Development Methodology
Morning Scrum in Action
At 1:30 PM IST (9:00 AM CET) the Scrum team does the Daily Scrum meeting with the product owner
and other members at onsite to update them aware of their tasks and see what the product owner is
working on with the items on the product backlog. This meeting is time boxed to maximum 15 mins.
At the end of each day the team updates the Sprint burndown chart with the amount of effort left to
finish the sprint, this gives the team and other stakeholders a fair idea of the accomplishments and the
effort left to finish the sprint. Also the team updates a similar graph called as the release burndown chart
at the end of every sprint. These burndown charts – Sprint and Release is available at the 7 Star
11
12. iSense Prowareness – Seven Star Development Methodology
DEVELOPMENT METHOD Dashboard for the stakeholders have an accurate picture regarding the
progress with respect to daily items and the release plan.
Burndown Charts - Sprint and Release
The team starts working on the tasks and the team self organizes itself to work during the sprint. This
document would discuss the requirements (product backlog), design, development and testing phases in
the delivery sprints in much more detail in the next section.
Daily Scrum Meeting Structure
12
13. iSense Prowareness – Seven Star Development Methodology
As stated earlier the sprint lasts for a period of 2 weeks and the scrum team delivers the sprint on the
Thursday end of day. On the Friday morning the team does the Sprint review with the Product Owner and
demos the delivery of what was achieved in the last 2 weeks to the other stakeholders. This provides the
team with valuable feedback and the Stakeholders have a transparent view of what has been achieved
till now by the team. This review meeting is time boxed for 2 hours.
After this the offshore team does a Sprint retrospective with an objective as to how the team can achieve
better results in the next sprint. The inputs from the review are also discussed in this meeting. The team
documents the retrospective findings and shares it with all the concerned stakeholders. This meeting is
also time boxed and lasts for maximum 2 hours.
After this the team is ready for the next sprint planning and this is how the delivery sprints repeat till the
project is accomplished. All meeting during this period happen over video-conferencing between the
team and the product owner and clients.
Once the product is completely developed the team does a sprint called as the Hardening Sprint (Pre-
release sprint) which entails polishing the developed software to a nice and finished product. As stated
this sprint is used for final polishing and not for coding, integration or design.
Friday Saturday Monday Tuesday Wednesday Thursday
and
Sunday
11:00 am – 1:00pm – Holidays 11:30 am -11:45 11:30 am -11:45 11:30 am -11:45 11:30 am -11:45
Sprint Planning I am – Daily am – Daily am – Daily Scrum am – Daily Scrum
Scrum Meeting Scrum Meeting Meeting Meeting
1:00 pm – 2:00 pm –
Sprint Review
2:30 pm – 3:30 pm –
Sprint Retrospective
3:30 pm – 4:30 pm –
Sprint Planning II 8:00 PM- 8:00 PM- 8:00 PM- Update 8:00 PM- Update
Update Update Burndown chart Burndown chart
4:30 pm onwards – Burndown chart Burndown chart
Sprint Starts
Friday Saturday Monday Tuesday Wednesday Thursday
and
Sunday
11:30 -11:45 – Daily Holidays 11:30 am -11:45 11:30 am -11:45 11:30 am -11:45 11:30 am -11:45
Scrum Meeting am – Daily am – Daily am – Daily Scrum am – Daily Scrum
Scrum Meeting Scrum Meeting Meeting Meeting
13
14. iSense Prowareness – Seven Star Development Methodology
7:30 pm– Sprint
Delivery to Clients
8:00 PM- 8:00 PM-
8:00 PM- Update Update Update 8:00 PM- Update 8:00 PM- Update
Burndown chart Burndown chart Burndown chart Burndown chart Burndown chart
Sprint Bi-Weekly Calendar (Timings in IST)
Now let’s define the different phases which go into making the delivery sprint.
User Stories Creation Phase (Requirements Creation) – This stage is usually the responsibility of the
product owner. The Product Owner creates user stories as a list which describes all
functionalities/Requirements for the software project. iSense Prowareness Team Leaders provide training
to our clients during the start of our co-operation on how to create clear and high quality user stories.
The Project Requirements should contain two important deliverables:
1) Project Vision – Usually a Microsoft PowerPoint file which can define the vision statement of the
project. A vision statement is a short, coherent statement that concisely describes the purpose of
building the new or improved system. It provides the justification for building the system to the
team. It should provide its readers with an understanding, at a high level, of the users of the
application, what they need, and how this application is going to provide that.
This document is discussed in a session which is attended by all the stakeholders of the project
and hosted by the product owner. The session would happen over a video-conferencing with the
offshore India team.
Sub-activity Sub-activity Description
Type
Required Summarize Project Provide a one or two paragraph context for the
Background project. These paragraphs should describe the
events that determined the need for a new or
improved system. This can be as simple as
indicating a new version of an existing product.
14
15. iSense Prowareness – Seven Star Development Methodology
Required Explain Driving Describe the major requirements or timeframe
Factors driving the release of the product.
Make it clear whether this project is driven by
date (such as a major tradeshow) or
functionality (such as the desire to outdo a
competitor).
Required Determine key Write the value proposition of the new system.
value and the
stakeholders of the Determine the set of stakeholders who obtain
application the primary value from the system.
Distill the key concepts down to a single value
proposition for these stakeholders to be
included in the vision statement.
2) Project Backlog Document – (Functional and Non Functional Requirement
Document)
- The Product Owner interacts with end customers and stake holders to gather project
requirements. These are captured in a Microsoft Office Word document named the Project
Back Log/Requirements Document and defines the user stories.
- This document also defines the Non-Functional/Quality of Service requirements of the
application and the project proposed – The non-functional (QOS) requirements are
mentioned so that they are taken into account during designing and development of the
application and can be tested using Performance testing techniques.
Output: (1) Project Vision Scope Document (2) Project Backlog Document
Both these documents are uploaded to the Documents Folder on the TFS
Requirements Analysis Phase
The steps followed during the Requirement analysis phase are:
After the initial business analysis of the project backlog with the product owner the Scrum Master is back
in India .The Scrum Master along with the team go through the product backlog and discuss the
technical aspects of the requirements.
15
16. iSense Prowareness – Seven Star Development Methodology
The Scrum Master divides the product backlog items into sub-parts and plans a meeting with the team
members where each team member presents a part of his/her understanding of the backlog to the team.
This brings the team up to speed in the project.
The team has a/series of project backlog Analysis Meeting/s internally where each member presents
different parts of the requirements and the team debates/and discusses over the backlog items. The
output of this meeting is a minutes of the meeting with these sections
- Clarifications (if any with the project backlog)
- Risks Backlog (Also created in TFS and managed till the end of the project)
- Re-Usable components/architecture ( Defining what kind of an architecture can be reused
for such an application, 3rd party controls and tools)
- Overall Test strategy ( The tester to come out with what kind of testing(automation/manual)
would be required in the project)
This minute of this meeting is send to all the stakeholders of the project.
The scrum team and the Product Owner go over the requirement together over a video conference
session and discuss the requirement in details along with the minutes of the meeting of the internal team
meeting. This can be one meeting or a series of meetings till the requirements are clear to the
development team and sufficient planning for the project risks are in place.
After this the project backlog is updated by the Product Owner. The Scrum Master creates a overall
project backlog list based on the backlog document in the Team Foundation Server. He further divided
these Backlog into smaller items if required and finally into tasks like
Spike/design/development/review/test and validation tasks and for all these tasks project dependency.
Together with the Product Owner the rank and priority of the project backlog list are defined and entered
into the TFS.
The tester meanwhile comes up with the Test plan for the whole project using the TMAP template for
testing using VSTS 2010 .On the basis of TMap the tester can plan the test based on business
requirements with higher priorities.
The output of this phase is
1) Updated backlog document by the Product Owner with the discussed changes / additions.
2) The Project Risk defined in TFS as per the Scrum template. The risks are directly added to TFS
and managed by team leader along with the other stakeholders.
3) Creation of Project Backlog list on TFS mapping Functional and Non Functional Requirements
4) The Requirement Traceability Matrix which can be automatically generated through TFS
5) Test Plan created by the tester.
16
17. iSense Prowareness – Seven Star Development Methodology
Project Design Phase
At iSense Prowareness to come up with a good backlog list, the practices include decomposition of work
into manageable pieces that are estimated and analyzed for dependencies, planning of stakeholder
involvement, and total project risk assessment as discussed above.
Once the team is done with the analysis, the scrum master and the team members come up with a high
level design document. This stage is critical for the project as iSense Prowareness has a series of pre-
defined architectures available based on best practices and can be re-used across projects. These
architectures have been composed using elements from Microsoft Enterprise library and others 3rd party
reusable components like log4Net, etc. Reusing architecture components at this stage can save at least
30% of the total development time and avoid technical debts.
The design notification standard used is UML at this stage and the high level design document contains
the following:
1) Overall Architecture Diagram – Describing the overall architecture ( example - tier based
model)
2) Component Diagrams of the application
3) Database Model of the application
These design artifacts are created using Visual Studio Team System 2010 architect edition. With every
sprint the design artifacts are refreshed and sent to the clients.
The design artifacts are sent through Quality Gates and are checked in only once the design document
passes all Design metrics and practices. More details of the Quality Gates for the design phase are
provided at the end of this section
Spike Phase - After the high level design the team progresses to conduct Proof of Concept which may be
required in the project.
Once done, the team has verified almost all major issues and progresses with working on the Low level
design phase of the application
The Low level design Phase compromises of
1) Use Case Diagrams
2) Class Diagrams
Also the low level design contains any description of any details and risks found. The risks and non QOS
Backlog are relooked at and addressed in case it belongs to any tasks. The low level design document is
then checked in TFS.
Meanwhile the Test Professional comes up with the test cases based on the project scenarios. The Test
cases covers all the requirement scenarios and are tracked using the requirement traceability matrix.
These test cases are created so that Performance and functional aspects of the application can be
17
18. iSense Prowareness – Seven Star Development Methodology
measures and compared to comply with the requirements before they are passed. The decisions to
automate a test are taken in conjunction with a client based on the business importance of a particular
requirement.
Design Quality Gates
Quality attributes represent areas of concern that have the potential for application-wide impact across
layers and tiers. Some of these attributes are related to the overall system design, while others are
specific to run-time, design-time, or user-centric issues. The following table provides an understanding of
the quality attributes and the scenarios they are most likely to affect.
Type Quality Attribute
System Qualities • Supportability - Supportability defines how easy it is for operators,
developers, and users to understand and use the application, and how easy it is
to resolve errors when the system fails to work correctly.
• Testability - Testability is a measure of how easy it is to create test criteria for
the system and its components, and to execute these tests in order to
determine if the criteria are met
Run-time Qualities • Availability - Availability defines the proportion of time that the system is
functional and
Working.
• Interoperability - Interoperability is the ability of diverse components of a
system or different systems to operate successfully by exchanging information,
often by using services
• Manageability - Manageability defines how easy it is to manage the
application, usually through sufficient and useful instrumentation exposed for
use in monitoring systems and for debugging and performance tuning.
• Performance - Performance is an indication of the responsiveness of a system
to execute any action within a given time interval
• Reliability - Reliability is the ability of a system to remain operational over
time.
• Scalability - Scalability is the ability of a system to function well when there
are changes to the load or demand
• Security - Security defines the ways that a system is protected from disclosure
or loss of information, and the possibility of a successful malicious attack
Design Qualities • Conceptual Integrity - Conceptual integrity defines the consistency and
coherence of the overall design
• Flexibility - Flexibility is the ability of a system to adapt to varying
environments and situations, and to cope with changes in business policies and
rules
• Maintainability - Maintainability is the ability of a system to undergo
changes to its components, services, features, and interfaces as may be
required when adding or changing the functionality, fixing errors, and meeting
new business requirements.
• Reusability - Reusability defines the capability for components and
subsystems to be suitable for use in other applications and in other scenarios
User Qualities • User Experience / Usability - Usability defines how well the application meets
18
19. iSense Prowareness – Seven Star Development Methodology
the requirements of the user and consumer by being intuitive, easy to localize
and globalize, and able to provide good access for disabled users and a good
overall user experience.
Project Planning Phase
The Scrum Master along with the team creates an iterative plan. The plan takes into account the ranking
of the requirements. The deliverables are planned and estimated as iterations and sprints. Iteration has a
set of defined functionality which can be delivered for testability to Product Owner and lasts for a week.
Iteration should at least contain a scenario which is testable by the tester and the client.
Every sub scenario which is planned takes care of the following aspects
Functional Test cases
Low Level Design
Design review
Code
Code Review
Unit tests
Unit tests review
Iteration Tests
Bug fixing per iteration
Overall Items which are be a part of the estimates are
High Level Design
Review of High Level Design
Project Planning
Creation of System Test Cases
Testing using the Test Cases
Bug Fixing on System Level
Any Buffers for risks ( As a guidelines 20% buffer is planned so that changes/ risks don’t affect
the final delivery Schedule)
Every project at iSense is planned at two levels – Higher Level (Release and Project) and Detailed Level
(Sprint and Work Items) to cater to all the participants of the project. It gives the business stakeholders a
clear idea about the overall plan and concurrently updated time to time in case there are any changes to
it and the team tracks progress of active sprint(s).
The Development Cycle
The team starts working on the deliverables and delivering them on Iterations.
The development cycle comprises of
Write Code for a Development Task
19
20. iSense Prowareness – Seven Star Development Methodology
Check Code against Design and Coding Guidelines
Create or Update a Unit Test
Perform a Unit Test
Refactor Code
Review Code
Integrate Change Set
The development KPI’s are defined in the section below, all code delivered in Iterations and Sprints will
have passed these Quality Gates. This is taken care by automating the Builds and Check-in Policy which
quality becomes a part of everyone’s job on a daily basis.
iSense Code Quality Gates
At iSense Prowareness all development teams follow a series of quality gates before they check-in their
code in the Version Control. The quality gates have three different aspects – Code Metrics, Unit Tests
Results and Coverage and Automated Code Review.
Code Metrics is a set of software measures that provide developers better insight into the code they are
developing. By taking advantage of code metrics, developers can understand which types and/or
methods should be reworked or more thoroughly tested. Our Development teams can identify potential
risks, understand the current state of a project, and track progress during software development.
The following list shows the code metrics used at iSense Prowareness. These code metrics can be directly
derived from Visual Studio:
Maintainability Index – Calculates an index value between 0 and 100 that represents the relative ease of
maintaining the code. A high value means better maintainability. The calculation is based on the
Halstead Volume, Cyclomatic Complexity and Lines of Code. Color coded ratings can be used to quickly
identify trouble spots in your code. A green rating is between 20 and 100 and indicates that the code has
good maintainability. A yellow rating is between 10 and 19 and indicates that the code is moderately
maintainable. A red rating is a rating between 0 and 9 and indicates low maintainability.
Cyclomatic Complexity – Measures the structural complexity of the code. It is created by calculating the
number of different code paths in the flow of the program such as if blocks, switch cases, and do, while,
for each and for loops then adding 1 to the total. A program that has complex control flow will require
more unit tests to achieve good code coverage and will be less maintainable.
Depth of Inheritance – Indicates the number of class definitions that extend to the root of the class
hierarchy. The deeper the hierarchy the more difficult it might be to understand where particular
methods and fields are defined or/and redefined. At the class level the number is created by calculating
the number of types that are above the type in the inheritance tree starting from 0 and excludes
interfaces. At the namespace and project level the calculation consists of the highest Depth of
Inheritance calculation of all of the types within the namespace or project.
20
21. iSense Prowareness – Seven Star Development Methodology
Class Coupling – Measures the coupling to unique classes through parameters, local variables, return
types, method calls, generic or template instantiations, base classes, interface implementations, fields
that are defined on external types, and attribute decoration. The calculation excludes primitive and built-
in types such as int32, string and object. Good software design dictates that types and methods should
have high cohesion and low coupling. High coupling indicates a design that is difficult to reuse and
maintain because of its many interdependencies on other types.
Metric Rules Corresponding Rule Threshold – Should not allow
to check-in incase of any
warning as code needs
refactoring
Depth of Inheritance CA1501 AvoidExcessiveInheritance Warning at above 5 levels
deep
Complexity CA1502 AvoidExcessiveComplexity Warning at above 25
Maintainability Index CA1505 AvoidUnmaintainableCode Warning at below 20
Class Coupling CA1506 Warning at above 80 for class
AvoidExcessiveClassCoupling and above 30 for a method
Code Coverage (Unit Tests) – Measuring code coverage for Unit tests helps developers to ensure what
percentage of a piece of code has been tested by an Individual developer and helps him and the tester
21
22. iSense Prowareness – Seven Star Development Methodology
plan the remaining testing activities efficiently. It also provides the development team a lot of confidence
on the code quality of the delivered code.
At iSense all code pieces require all unit tests to pass before checking in the code. The Minimum code
coverage achieved per class should be 60% via automated unit tests.
Unit testing Guidelines
Developers must write their own tests
Design organically, running code provides feedback
Development environment must provide a rapid response to small changes
Highly Cohesive/Loosely Coupled designs
Automated and Team Leaders Code Review –
Automated code review software checks source code for compliance with a predefined set of rules or
best practices.
At iSense Prowareness the development team takes care of all the code analysis warnings generated by
Visual Studio code review tool and are addressed before the piece of code goes to code review. Please
find a screen shot on how to perform this. To make it easier to qualify and check the code quality during
code writing the developers use – SubMain Code.it.right / Coderush/ Resharper. These 3rd party
components help the developers to raise their development speed and enhance productivity.
22
23. iSense Prowareness – Seven Star Development Methodology
Apart from the automated code review, iSense Prowareness pays more emphasis on the human behavior
of coding. All pieces of code undergo code review by the team leader before they are sent as delivery of
iteration. The team leader also has a meeting with the development team every Wednesday of the week
for 30 minutes to go through important pieces of code as a team. This ensures that all code practices
which can be improved are discussed as a team all best practices implemented is appreciated so that
every time developers write code they do it better than the previous time.
Team Structure
At iSense Prowareness the team compromises of these members: A Scrum Master, Scrum Team and the
Product Owner. The Scrum Master and the team are located in the Offshore Location at our Bangalore
Facility and the Product Owner is at our Clients Location a member of our Client Organization.
The Team leader plays the role of SCRUM Master because he also has direct access to resources, offshore
Management and the Clients and hence is in a good position to facilitate the team with their
requirements to deliver successful projects.
23
24. iSense Prowareness – Seven Star Development Methodology
Below we will go through the role and skills of individual members in the project team and the project
structure.
India Team:
1) Team Leader/Architect/Lead Developer ( Full Time) – Manage the delivery of the project
- Project Planning and Estimation.
- Risk Assessment and Mitigation Planning.
- Designing and Architecting – High and Low level Design.
- Development, Unit Testing.
- Code and Test Review.
- Deployment Plan with the Final Build.
- Planning and implementing Continuous Builds and Continuous Integration
- Project Delivery Responsibility
o Generating Code Review Reports and Unit Test Coverage Reports weekly
o Weekly Reporting of Tasks and Project Status
o Ensuring delivery every Thursday to clients
- End to End Client Communication
- Ensuring all of the below as a part of ensuring process adherence -
o Agile dev processes are being followed
o Test Driven Development is being followed
o Daily stand-ups and weekly iterations are being conducted
o All tasks, features, bugs are tracked through our Issue Tracker
o Continuous Integration is functional
- Ensuring documentation of Architecture
- Ensuring our Project Development Process is followed to the tee
- Ensuring all tasks have estimates associated with them, and all releases have schedules
associated with them
- Maintaining the heartbeat of a project
- Ensuring timely delivery of a Project and keeping dev teams and other teams informed of
timelines
- Publishing an accurate Release log upon release
- Ensuring test coverage for unit tests and functional tests is in line with our defined standards
- Facilitate and help the team.
2) Developers ( Full Time) - Manage the delivery of functionality
- Task Estimation and Planning
- Task Risk Assessment and Mitigation Planning
- Low Level Designing and Architecting
- Writing Code and Unit Test Cases with close to complete coverage
- Self Code and Unit Tests Review
- Tasks Delivery Responsibility
- Communication with Team Leader/Clients
3) Tester and QA - Manage the quality of the delivery
- Test Planning and Estimation
- Automation Testing
24
25. iSense Prowareness – Seven Star Development Methodology
- Planning and writing Functional Tests
- Planning and writing Quality of Service Tests
- Planning and implementing Continuous Builds and Continuous Integration
- Implementing test coverage reports for Unit Testing and Functional Testing
- Defining manual test cases and overseeing Manual Testing process
- Performing Bi-Weekly Audits on the Project KPI’s.
4) UI designer ( Part time, based on the UI Designing effort)
- UI Prototyping and Usability Testing – Using Microsoft UI Guidelines
- UI Designing – Application Pages/Windows
- UI Text – Writing Labels, write every email that will be sent to users from the software
- Reviewing User Experience of the product and ensuring UI is intuitive and appealing.
5) General Manager/Offshore Management
- Managing the team
- Resource allocation
- Providing feedback to team members
- Motivating the team regularly
- Being available to resolve any issues of any team member
- Recruitment Management
- Managing and implementing Training processes for team members
- Appraisal Management
- Client Management
- Infrastructure Management for project release at offshore.
Client’s team:
1) Client/Project Manager – Overall Requirement , Release and Acceptance Test Management
- Manage the Vision and Strategy of a Project
- Control the feature roadmap of the project
- define integration points within the Product which enable internal and external users to
provide feedback
- gather user feedback, communicate with users and prioritize feature requests
- prioritize bugs
- Competition review
- regularly post tidbits of information w.r.t competition on internal lists
- study new releases by competition and conduct at least one structured presentation for the
benefit of all teams on a regular basis (monthly / quarterly)
- Create Project Backlog/Document requirements and specifications
25
26. iSense Prowareness – Seven Star Development Methodology
Delivery Cycle – Deliverables and Responsibility Matrix
This image displays the Deliver phases followed at iSense Prowareness and the list of deliverables per
phase and the people responsible for the same.
26
27. iSense Prowareness – Seven Star Development Methodology
7 Star Development Methodology – Agile Terminology and Assessment
Burndown Charts
Burndown charts show work remaining over time. Work remaining is the Y axis and time is the X axis.
The work remaining should jig up and down and eventually trend downward.
At iSense we define two kinds of burndown charts - a sprint burndown chart as a place to see daily
progress, and a release burndown chart as where to show release (per sprint) progress.
Daily Scrum Meeting
A fifteen-minute (maximum) daily meeting for each team member to answer three questions:
1."What have I done since the last Scrum meeting? (i.e. yesterday)"
2."What will I do before the next Scrum meeting? (i.e. today)"
3."What prevents me from performing my work as efficiently as possible?"
The Scrum Master ensures that participants call sidebar meetings for any discussions that go too far
outside these constraints.
At iSense, this meeting takes place first thing in the morning, as soon as all team members arrive.
Impediments
Anything that prevents a team member from performing work as efficiently as possible is an
impediment. Each team member has an opportunity to announce impediments during the daily Scrum
meeting. The ScrumMaster is charged with ensuring impediments get resolved. ScrumMasters often
arrange sidebar meetings when impediments cannot be resolved on the spot in the daily Scrum meeting.
Product Backlog
The product backlog (or "backlog") is the requirements for a system, expressed as a prioritized list of
product backlog Items. These included both functional and non-functional customer requirements, as
well as technical team-generated requirements. While there are multiple inputs to the product backlog,
it is the sole responsibility of the product owner to prioritize the product backlog.
During a Sprint planning meeting, backlog items are moved from the product backlog into a sprint, based
on the product owner's priorities.
Product Backlog Item
In Scrum, a product backlog item ("PBI", "backlog item", or "item") is a unit of work small enough to be
completed by a team in one Sprint iteration. Backlog items are decomposed into one or more tasks.
Product Backlog Item Effort
Some Scrum practitioners estimate the effort of product backlog items in ideal engineering days, but
many people prefer less concrete-sounding backlog effort estimation units. Alternative units might
27
28. iSense Prowareness – Seven Star Development Methodology
include story points, function points, or "t-shirt sizes" (1 for small, 2 for medium, etc.). The advantage of
vaguer units is they're explicit about the distinction that product backlog item effort estimates are not
estimates of duration. Also, estimates at this level are rough guesses that should never be confused with
actual working hours.
Note that sprint tasks are distinct from product backlog items and task effort remaining is always
estimated in hours.
Product Burndown Chart
In Scrum, the product burndown chart is a "big picture" view of a project's progress. It shows how much
work was left to do at the beginning of each sprint. The scope of this chart spans releases; however, a
release burndown chart is limited to a single release.
Product Owner Role
In Scrum, a single person must have final authority representing the customer's interest in backlog
prioritization and requirements questions.
This person must be available to the team at any time, but especially during the sprint planning meeting
and the sprint review meeting.
Challenges of being a product owner:
1. Resisting the temptation to "manage" the team. The team may not self-organize in the way you would
expect it to. This is especially challenging if some team members request your intervention with issues
the team should sort out for itself.
2. Resisting the temptation to add more important work after a Sprint is already in progress.
3. Being willing to make hard choices during the sprint planning meeting.
4. Balancing the interests of competing stakeholders.
Release
The transition of an increment of potentially shippable product from the development team into routine
use by customers. Releases typically happen when one or more sprints has resulted in the product having
enough value to outweigh the cost to deploy it.
"The product is released to customer or marketplace obligations. The release balances functionality, cost,
and quality requirements against date commitments."
Release Burndown Chart
In Scrum, the release burndown chart is a "big picture" view of a release's progress. It shows how much
work was left to do at the beginning of each sprint comprising a single release. The scope of this chart is
a single release; however, a product burndown chart spans all releases.
Scrum Roles
There are three essential roles in any Scrum project:
•Product Owner
•ScrumMaster
•Team
28
29. iSense Prowareness – Seven Star Development Methodology
ScrumMaster Role
The ScrumMaster is a facilitator for the team and product owner. Rather than manage the team, the
ScrumMaster works to assist both the team and product owner in the following ways:
•Remove the barriers between the development and the product owner so that the product owner
directly drives development.
•Teach the product owner how to maximize return on investment (ROI), and meet his/her objectives
through Scrum.
•Improve the lives of the development team by facilitating creativity and empowerment.
•Improve the productivity of the development team in any way possible.
•Improve the engineering practices and tools so that each increment of functionality is potentially
shippable.
•Keep information about the team's progress up to date and visible to all parties.
Sprint
An iteration of work during which an increment of product functionality is implemented. By the book, an
iteration lasts 30 days. This is longer than in other agile methods to take into account the fact that a
functional increment of product must be produced each sprint.
The sprint starts with a one-day sprint planning meeting. Many daily Scrum meetings occur during the
sprint (one per day). At the end of the sprint we have a sprint review meeting, followed by a sprint
retrospective meeting.
During the sprint, the team must not be interrupted with additional requests. Guaranteeing the team
won't be interrupted allows it to make real commitments it can be expected to keep.
Out of practical necessity, some teams choose to bend this rule by declaring some team members 80
percent available at the outset so they still have some cycles left for "Priority One" bugs and
emergencies. But this is a slippery slope and should be avoided whenever possible.
Sprint Backlog
Defines the work for a sprint, represented by the set of tasks that must be completed to realize the
sprint's goals, and selected set of product backlog items.
Sprint Burndown Chart
A sprint burndown chart (or "sprint burndown graph") depicts the total task hours remaining per day.
This shows you where your team stands regarding completing the tasks that comprise the product
backlog items that achieve the goals of the sprint. The X-axis represents days in the sprint, while the Y-
axis is effort remaining (usually in ideal engineering hours).
To motivate the team, the sprint burndown chart should be displayed prominently. It also acts as an
effective information radiator. A manual alternative to this is a physical task board.
29
30. iSense Prowareness – Seven Star Development Methodology
Ideally the chart burns down to zero by the end of the sprint. If the team members are reporting their
remaining task hours realistically, the line should bump up and down chaotically. The profile shown
below is typical, and demonstrates why the "percentage done" concept of traditional project
management breaks down. Assuming we started measuring on July 26, what "percentage done" were
we on July 28?
Sprint Goals
Sprint goals are the result of a negotiation between the product owner and the development team.
Meaningful goals are specific and measurable. Instead of "Improve scalability" try "Handle five times as
many users as version 0.8."
Scrum focuses on goals that result in demonstrable product. The product owner is entitled to expect
demonstrable product (however small or flimsy) starting with the very first Sprint. In iterative
development, subsequent Sprints can increase the robustness or size of the feature set.
Have your team commit to goals that anyone will be able to see are met (or not met) at the end of the
sprint. At sprint review meetings, the sprint demonstration is conducted after which the team asks the
product owner whether (s)he feels the goals were met.
While some specific product backlog items may not be done at the end of a sprint, it should be very
unusual for a team not to meet its sprint goals. Scrum requires the team to notify the product owner as
soon as it becomes aware it will not meet its goals.
Sprint Planning Meeting
The Sprint planning meeting is a negotiation between the team and the product owner about what the
team will do during the next sprint.
The product owner and all team members agree on a set of sprint goals, which is used to determine
which product backlog items to commit from the uncommitted backlog to the sprint. Often new backlog
items are defined during the meeting. This portion of the sprint planning meeting is time-boxed to four
hours.
Typically the team will then excuse the product owner from the room and break the backlog Items down
into tasks. The product owner is expected to be on call during this phase (previously called the sprint
definition meeting) for renegotiation or to answer questions that affect the time estimates. This portion
of the sprint planning meeting is time-boxed to four hours. Sometimes teams insert placeholder tasks
(with rough estimates) for the product backlog items they don't expect to start working until later in the
sprint.
Sprint Retrospective Meeting
30
31. iSense Prowareness – Seven Star Development Methodology
The sprint retrospective meeting is held at the end of every sprint after the sprint review meeting. The
team and ScrumMaster meet to discuss what went well and what to improve in the next sprint. The
product owner does not attend this meeting.
The sprint retrospective should be time-boxed to three hours.
An expert writes: "The sprint retrospective meeting is an integral part of the inspect and adapt process.
Otherwise, the team will never be able to improve their overall output and not focus on the overall team
performance. The ScrumMaster must pay attention to this meeting and work towards resolving the
impediments that may be slowing down the team."
Consider using a Scrum scoreboard during the retrospective.
Sprint Task
In Scrum, a sprint task (or task) is a unit of work generally between four and sixteen hours. Team
members volunteer for tasks. They update the estimated number of hours remaining on a daily basis,
influencing the sprint burndown chart. Tasks are contained by backlog items.
Scrum literature encourages splitting a task into several if the estimate exceeds twelve hours.
Team
A team (or "Scrum team") is optimally comprised of seven plus or minus two people.
For software development projects, the team members are usually a mix of software engineers,
architects, programmers, analysts, QA experts, testers, UI designers, etc. This is often called "cross-
functional project teams". Agile practices also encourage cross-functional team members.
During a sprint, the team self-organizes to meet the sprint goals. The team has autonomy to choose how
to best meet the goals, and is held responsible for them. The ScrumMaster acts as a guardian to ensure
that the team is insulated from the product owner.
Scrum also advocates putting the entire team in one team room.
Team Member
In Scrum parlance, a team member is defined as anyone working on sprint tasks toward the sprint goal.
Velocity
In Scrum, velocity is how much product backlog effort a team can handle in one sprint. This can be
estimated by viewing previous sprints, assuming the team composition and sprint duration are kept
constant. It can also be established on a sprint-by-sprint basis, using commitment-based planning.
31
32. iSense Prowareness – Seven Star Development Methodology
Once established, velocity can be used to plan projects and forecast release and product completion
dates.
How can velocity computations be meaningful when backlog item estimates are intentionally rough? The
law of large numbers tends to average out the roughness of the estimates.
7 Star Development Methodology : Agile Assessment
We did a small assessment of 7 Star Development Method and the results are tabulated below:
Agile Process Yes/No Remarks
Design Changes are reviewed and
Technical Debt ✓ conforms to quality gates to prevent this.
Pair Programming ✓
Energized Work ✓
Informative Workspace ✓
RCS of the defects raised is done during
weekly iteration meetings and Sprint
Root-Cause Analysis ✓ Retrospect meetings
Retrospectives ✓ Weekly Iterations and Sprint Retrospects
High usage of collaboration tools and
Collaborating ✓ techniques - VSTS,TFS,Skype etc
Trust ✓ High trust among teams
A team has their own room and space
Sit Together ✓ where they can meet and work together
Skype ( Web conferencing) and client visits
Real Customer Involvement ✓ make the involvement real
Developers use the Business terms in their
Ubiquitous Language ✓ Development track
Stand-Up Meetings ✓ Every Morning performed per team
Use MS VSTS in built coding standards,
Coding Standards ✓ also use Code.it Right
Iteration Demo ✓ Biweekly Demo of Iterations
Daily, Weekly , Mothly Reporting, and TFS
Reporting ✓ Reports on the fly
Week Iterations and biweekly Sprint
Releasing ✓ Releases
Done is defined by the scrum team and the
Product Owner. Every item checked in is
signed of with quality guides to the test
Done Done ✓ team and then to the client.
32
33. iSense Prowareness – Seven Star Development Methodology
Test-driven development structures work
No Bugs ✓ into easily-verifiable steps.
Usage of TFS checkin rules allows people
Version Control ✓ to checkin without disturbing each other
Ten-Minute Build ✓
Continuous Integration ✓
Collective Code Ownership ✓
Documentation ✓
Vision ✓
Release Planning ✓
The Planning Game ✓
Risk Management ✓
Iteration Planning ✓
Slack ✓
User Stories
Estimating ✓
Incremental Requirements ✓
Customer Tests ✓
Test-Driven Development ✓
Refactoring ✓
Simple Design ✓
Incremental Design and
Architecture
Spike Solutions ✓
Performance Optimization ✓
Exploratory Testing ✓
Persona
System as mock data
Planning Poker ✓
Requirement Prioritization ✓
Domain Driven Design ✓
Emergent Design /
Evolutionary Design ✓
Coding Style / Coding
Guidelines / Coding
Standard ✓
Behavior Driven
Development ✓
Pair-Programming / Pairing ✓
Daily Builds / Automated
Builds ✓
Code Reviews / Peer
Reviews ✓
33
34. iSense Prowareness – Seven Star Development Methodology
Software Metrics / Code
Metrics & Analysis ✓
Issue Tracking / Bug
Tracking ✓
Configuration Management ✓
Frequent Delivery /
Frequent Releases ✓
Unit Testing ✓
Smoke Testing / Build
Verification Test ✓
Integration Testing ✓
System Testing ✓
Test Automation ✓
Story testing / Acceptance
Criteria / Acceptance
Testing ✓
Time boxing / Fixed Sprints
/ Fixed Iteration Length ✓
Sprint Backlog ✓
Task Board ✓
Velocity ✓
Value Stream Mapping
Burn Down Charts / Burn
Up Charts ✓
Big Visible Charts /
Information Radiators ✓
Small Team ✓
Cross-Functional Team ✓
Self-Organizing Team ✓
Co-located Team / Sitting
Together / Common
Workspace ✓
On-Site Customer / Product
Owner ✓
Sustainable Pace ✓
Move People Around ✓
34
35. iSense Prowareness – Seven Star Development Methodology
Star 3: Tools
At iSense Prowareness the Microsoft development team centers its development practices on Visual
Studio Team System 2010 and Team Foundation Server 2010, but the teams also use the latest and top
of the line 3rd party tools for hyper-productivity and to speed up the development activities.
Phase Tools and Templates
Project Backlog based on Priority
Visual Studio Team System 2010+ Scrum for TFS Template
Requirement Phase
High Level Design – Component Diagrams and Overall Architectural Diagram
Low Level Design – Class Diagram and Development Use Cases
Visual Studio Team System 2010 Architect Suite
Design Verifications and Validation
Architecture Checkpoints from Microsoft Patterns and Practices
User Interface Designs
MS Expression and Visual WebGui
Project Planning
Visual Studio Team System 2010 and Team Foundation Server 2010 +
Scrum For Team System Template and Work Bench
Work Item Tracking/Defect Tracking
Visual Studio Team System 2010 + Team Foundation Server 2010
Version Control and Build Tool
Design Phase
Team Foundation Server 2010
Project Dashboard ( Burndown Charts, Team Velocity)
Scrum For Team System Dashboard
35
36. iSense Prowareness – Seven Star Development Methodology
Development IDE , Code KPI’s , Code Review and Unit Tests
Visual Studio Team System 2010 , MSTest Framework
Development Tools and Code Coverage Reports
Code.It.Right, Resharper, CodeRush
Reusable 3rd UI Components
Infragistics, Telerik, Devexpress
Development Phase
Automated Testing and –
Test Phase Visual Studio Team System 2010 (Team Test and Lab Manager) +
Usage of Agile TMAP Template
36
37. iSense Prowareness – Seven Star Development Methodology
Web Server
IIS
Deployment
Deployment Phase
Deployment Document Template
37
38. iSense Prowareness – Seven Star Development Methodology
Star 4: Communication
Communication is a key aspect of iSense Delivery Model and its enables us to provide 100% transparency
and effective collaboration with our clients - It sets the clients and our team to travel in the correct track.
iSense Prowareness Offshore Communication Framework follows the best practices for Offshore
Communication practices and is broken into components below in the picture.
Inter-Cultural
Communication
Trainings
Communication
Modes and Hours
iSense India Offshore
Communication
Framework
Project
Communication and
Reporting
Project Dashboard
Figure 1 : iSense Prowareness Offshore Communication Framework
1. Inter-Cultural Communication Trainings
iSense Prowareness never undermines the cultural differences between the Europe and India.
We believe in knowing the cultural similarities and variations before we start the communication
between the India team and the client’s team. To adapt this we have a cultural training at the client’s
office by iSense Communication Specialists who train the clients as how to deal with Indian colleagues. A
38
39. iSense Prowareness – Seven Star Development Methodology
similar training is provided to the team in India as to how to deal with European colleagues. This brings
both the teams to the same level from which they can establish smooth communication with each other.
We actually use it as an advantage to use the best of both the cultures to achieve winning results and
has proved successful with our existing clients.
2. Communication Modes and Hours
iSense Prowareness used the latest technologies to ensure that the clients and the India team can reach
other during the business hours.
iSense Prowareness office has adapted it’s working hours based on our Central European Time (CET) so
that we can be in constant contact with our clients during the working hours on any business day. Our
Working hours in India are from 11:00 AM – 8:00 PM which match with the CET Work Hours of 7:00 AM
– 4:00 PM. So basically the team in India is also working at the same time in India office as our Dutch
clients are working at their office.
The Modes of communication between India and Netherlands is described below.
Virtual Private Network (VPN) – The VPN between
our India office and our client office keeps us
connected 24 X 7. This enables the team to have
access over the clients specified servers all the time
and enables the team to check-in all project
artifacts (source code, design.,etc) to the client’s
specified server at their location.
Figure 2: VPN Connection
39
40. iSense Prowareness – Seven Star Development Methodology
VoIP – iSense Prowareness has its own VoIP setup
which is accessible for free to our clients. With the
help of VoIP enabled phones at iSense
Prowareness the clients can reach the India team
by dialing a local dutch number with their phones
and also the team can contact the clients over
their business phones/handhelds.
Figure 3: IP Phones for Communication
Video Conferencing ,Chatting and Desktop Sharing
and Emails – With the usage of Video Conferencing
tools like Skype and WebEx the human aspects of
seeing each other, working and sharing information
on projects becomes much easier. In this way our
clients can call the team in India on the desktops
and can go through demos, plans and presentations
together in a more collaborative manner. Clients
also use chat sessions and Emails to share
documents and information with the India teams.
Figure 4: A Sample Video Conference Session
3. Project Communication and Reporting Structure
The Project Communication and Reporting can be divided into two parts of the project – Project
Initiation, Project Execution and Delivery Phase.
Project Initiation Phase
During the Project Initiation phase the Team Leader from India travel to the client’s office location and
spends around 3-4 weeks with the clients. This time is used by iSense Prowareness to give them more
details about our delivery procedures, overall project planning and short demos regarding the project at
hand. Our Clients use this time for training the India Team lead about their business, organization and
the current project requirements at hand. This time spend by the team lead at the clients place helps
iSense to capture the project expectations of the clients and the team lead comes back after this duration
and can execute the project with his India team as he/she is clear with the clients expectations.
Project Execution and Delivery Phase
At this phase the complete team is operating from India and hence we pay special emphasis on reporting
and communication at this phase.
40
41. iSense Prowareness – Seven Star Development Methodology
Daily Communication
- A Morning Scrum Meeting(Video Conference) takes place between the team in India and the
clients team/manager
- An action plan is sent over email to the client in the morning providing them with the overview of
the current days task and the status of the previous days task
- Any chat/video session if required between the teams.
Weekly Communication
- Weekly Status Call (Video Conference) with the clients where all the project stakeholders are
present.
- Weekly Status Reports are sent to the clients by the Team Lead in India providing details about –
Tasks Status, Progress Report, Plans for the up-coming week and Utilization of the team in the
week is provided.
- The team delivers every Thursday a developed iteration of the application, so that the clients can
see on a week basis what is achieved and propose feedback to the team in India.
Monthly Communication
- The iSense Prowareness team Leader sends a monthly report to the business Manager and the
client manager analyzing the output of the month and features delivered to the clients.
- The General Manager from iSense Prowareness has a monthly discussion with the Client
Manager to analyze the satisfaction level of clients and to see if the service offering can be
improved in any way for the clients.
- The Account Manager from iSense Prowareness visits the client’s office to discuss the co-
operation on a monthly basis.
Quarterly Communication
- The General Manager and the Account Manager visit the client office to discuss the quarterly
performance of the India team and evaluate the services offered by iSense Prowareness with the
Client Project Manager and the Business Manager.
4. Project Dashboard
To provide 24 X 7 access to the clients about the project status, iSense Prowareness uses MS Team
foundation server and a cockpit application developed by Telerik, so that clients can have a snapshot
helicopter view of how the project execution is progressing with the requirements. This provided
complete transparency with the activities of the team for both project and business managers on a day
to day basis.
41
42. iSense Prowareness – Seven Star Development Methodology
Figure 5 : Screenshot of the Dashboard Application
The iSense offshore communication framework has evolved at iSense Prowareness with experiences with
a variety of projects done by iSense Prowareness in the past and also plays a major part in success for us
and our clients in today’s competitive market.
42
43. iSense Prowareness – Seven Star Development Methodology
Star 5: Key Performance Indicators
At iSense Prowareness we believe in the saying “You can’t control what you can't measure”- Tom
DeMarco
The Quality Control is strictly applied to the process and the product quality for all the projects rolled out
from iSense Prowareness. The Software Delivery Quality is measured and controlled by KPI’s and the
Product Quality is achieved by using quality gates.
Traditional performance management practices such as the Balanced Scorecard use Key Performance
Indicators (”KPIs”) to measure the effectiveness of a team. The same concept is applied to an Agile
Development Team at iSense by considering performance in the following areas – an Agile Balanced
Scorecard:
1. Reliability – Are the team delivering what they say they will?
The main Key Performance Indicator for Reliability in an Agile Software Development environment is: the
difference between Committed Story Points vs. Delivered Story Points over time – the aim is to deliver as
close to 100% as possible (no higher, no lower).
Let’s say that the team committed to User Stories equivalent to 25 Story Point and out of which User
Stories corresponding to 22 Story Points got accepted by Clients.
This would mean that the Reliability of the team is: 22/25*100 = 88% which is less than 100% which
would be the target of the team.
Measuring Reliability (Velocity and %Delivery)
Velocity Delivery
200% 30
(Commited vs. Delivered
Percentage Delivery
150% 25
20
Points)
100% 96% 90% 95% 95% 100% 100% 100% 100% 100% Velocity
83% 15
50%
10
0% 5
-50% 0
Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Sprint 6 Sprint 7 Sprint 8 Sprint 9 Sprint 10
Track Reliability over time using percentage delivery plotted against velocity
Note:
Delivery should track 100%.
Delivery of +/- 100% will imply that expectations are being managed.
Velocity should even out within 3-4 sprints.
43
44. iSense Prowareness – Seven Star Development Methodology
2. Productivity in terms of Project Velocity - Rate at which the team is processing and closing work items
per sprint. It shows
How quickly the team is completing planned work?
How much the completion rate varies?
The Project Velocity measure is used to eliminate productivity variance, to promote data integrity and to
identify a target velocity for future iterations.
As Project velocity measures the quantity of work being delivered by a team, if velocity increases, then
the team is delivering more, which leads to increased productivity. One might argue that the team could
be producing more work at lower quality – this avoided by two aspects –
- The iSense Quality Gates which ensures that the product developed by the team undergoes all quality
checks before being delivered to the clients.
- The fact that you only count Story Points towards a team’s velocity if they are accepted by the Product
Owner.
Project Velocity
3. Quality – What is the quality of the Sprint just delivered? Is this the quality the Stakeholder expected?
The KPI to measure quality from Sprint to Sprint basis include the following-
The defects delivered to the clients at every sprint
The Clients/Stakeholders satisfaction index.
The Defects delivered with a sprint is as a direct measure of testing done during the sprint and how
integrated testing stands with development.
Lets say that the team delivered 5 defects in a sprint, which has the following distribution:
Critical Defect – 1
44
45. iSense Prowareness – Seven Star Development Methodology
Major Defect – 2
Minor Defect – 2
A
Quality Overview
Defects Total Point Score
1500
(Critical=100pt; Major=10pt; Minor=1pt)
1200
900
Point Score
600
300
0
Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Sprint 6 Sprint 7 Sprint 8 Sprint 9 Sprint 10
In order to simplify the reporting process, the value of each defect has been multiplied by a point value.
So a Critical Defect measures 100 points, Major defect measures 10 point and Minor Defect measures 1
point.
As a result the Defect Points Score for the team for the 5 delivered defects goes to:
Defects Points Score = 1*100 + 2*10 + 2* 1 = 222 Points.
A high number of defects may be a lead indicator to product owner dissatisfaction.
Defects are costly - they require additional QA, release and remediation time.
A Lower point Score is better!
The other aspect of Quality KPI measurement is the Client Satisfaction Index which is measured monthly
(every 2 Sprints) to determine the quality of delivery as perceived by the Client/Stakeholder or the
Product Owner. This measurement is done over 10 aspects on the delivery cycle in which the clients
report with their feedback.
Also the Quality Assurance specialist with each team audits every project on a weekly basis if they meet
these metrics are acceptable and make improvement plan with the teams on a week to week basis.
45
46. iSense Prowareness – Seven Star Development Methodology
Quality Gates – Product Quality KPI’s
At iSense all stages of software product development have to meet some pre-defined quality gates
before they can be releases to clients for acceptance. These fixed KPI’s(quality gates) help the team
members build quality software on a day to day basis.
Track Deliverable Quality Gates
Follows all standards from Microsoft
User Interface Guidelines
(Web/Windows) and W3C Standards
UI Design and (Web apps) and Reviewed and Signed
User Experience Prototype off
Requirement Traceability, should be
able to map all requirements to
Product Backlog
expected test cases and Reviewed and
Requirements Signed off
High Level Design
(Architecture and Follows all standards from Microsoft
Component Architecture Guidelines
Diagram and (Web/Windows) and Reviewed and
Database Design) Signed off
Design
Low Level Design Follow all UML Design best practices
(Use Cases and and Guidelines document, and
Class Diagram) Reviewed and signed off
Microsoft Code Review Guidelines, Code
Metrics and Minimum 60% Unit test
Development Code and Unit tests coverage and Reviewed and Signed Off
Test Cases and
Testing Scripts High Test Coverage beyond 80%
Let’s take the example of development stage, there are predefined KPI’s which is integrated with our
development environment in Visual Studio Team System. The code which is checked in to the source
control has to pass automated code review, have the meet the defined code metrics and all associated
unit tests have to pass for a developer to check-in his code. Not following this procedure will cause the
build to fail and hence the quality check is built to the level that it can help the team to discover and
match all quality standards before it is delivered on iteration.
46
47. iSense Prowareness – Seven Star Development Methodology
Star 6: Technical Skills
Technical Skills of the team members determine how fast they produce and the quality of the developed
software. At iSense Prowareness we believe in not only recruiting the best –“Superstars” but also ensure
that they get enough technical challenges and learning so that they achieve a very sharp technical
acumen.
The technical education is done through a set of channels:
1) Every Individual is a Certified Microsoft Professional Developer – which is the maximum
accreditation by Microsoft for Developers
2) Every Team Member at iSense Prowareness writes a technical blog every month about
something he learned during the month during the project execution or about his/her interest.
These technical blogs are published externally at iSense Prowareness blog website
3) Every Tuesday the team has a technical talk session where a member/team discusses with the
other members regarding a particular technical topic – like RIA, Silverlight, Application
Performance tuning.
4) Quarterly, the team celebrates a technical event called the “Geek God” – Where all the
developers are given a technical challenge to solve. This helps the team members to take
challenges apart from what they get on a day to day basis.
5) We believe that training is an inherent part of the skill development of an individual. The
members are given technical trainings every quarter on a new skill and then the team members
ensures along with the management that they become masters in that particular skill.
47
48. iSense Prowareness – Seven Star Development Methodology
Star 7: Domain Knowledge
Software teams have hard times to develop business software when they are not familiar with the
business problem. At iSense Prowareness we believe in mastering our client’s business domain, the way
we achieve them are as follows:
1) We hire professionals who are a perfect match for a client project – the recruitment strategy
ensures that we hire professionals who have sufficient experience in the clients business area, in
order to ensure that the professionals can start immediately with the project and also provide
valuable knowledge to the clients based on their experiences.
2) The Scrum Master travels to the client office during the first month of the project initiation –
Sprint 0 and spend time with the product owner, understanding the clients business areas,
organization values, clients and the project value which is supposed to be undertaken. This
ensures that the Scrum Master is completely aware of the client business and their problems.
Once the Scrum Master returns to our Bangalore office he then transfers all the domain
knowledge to the team through Knowledge Transition sessions with the team
3) With continued learning in the project, the team understands the other nuances of the client’s
business and applications. The team documents this learning and sends a monthly domain
expertise update to clients, containing the new learning.
48