7 star development methodology

1 iSense Prowareness – Seven Star Development Methodology


Contents

Introduction ........................................................................................................ 3

Star 1: Attitude of an Entrepreneur……………………….……………………………………..6

Star 2: Development Process .............................................................................. 6

Star 3: Tools ...................................................................................................... 39

Star 4: Communication ...................................................................................... 42

Star 5: Key Performance Indicators .................................................................. 47

Star 6: Technical Skills ...................................................................................... 52

Star 7: Domain Knowledge ................................................................................ 53


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

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


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


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.

Developers

Tester

Scrum Master -Architect and Team Leader

Product Owner

Developers

Tester

Scrum Master -Architect and Team Leader

Netherlands Bangalore, India


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.

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.


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.


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

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 and Sunday

Monday

Tuesday

Wednesday

Thursday

11:00 am – 1:00pm – Sprint Planning I 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 4:30 pm onwards – Sprint Starts

Holidays

11:30 am -11:45 am – Daily Scrum Meeting 8:00 PM- Update Burndown chart




Friday

Saturday and Sunday

Monday Tuesday Wednesday Thursday

11:30 -11:45 – Daily Scrum Meeting 8:00 PM- Update Burndown chart

Holidays




11:30 am -11:45 am – Daily Scrum Meeting 7:30 pm– Sprint Delivery to Clients 8:00 PM- Update 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 Type

Sub-activity Description

Required Summarize Project Background

Provide a one or two paragraph context for the 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.

Required Explain Driving Factors

Describe the major requirements or timeframe 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 value and the stakeholders of the application

Write the value proposition of the new system.

Determine the set of stakeholders who obtain 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.

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.

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

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 AvoidExcessiveClassCoupling

Warning at above 80 for class 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 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.


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.

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


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.


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

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.

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


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

Technical Debt ✓

Design Changes are reviewed and conforms to quality gates to prevent this.

Pair Programming ✓

Energized Work ✓

Informative Workspace ✓

Root-Cause Analysis ✓

RCS of the defects raised is done during weekly iteration meetings and Sprint Retrospect meetings

Retrospectives ✓ Weekly Iterations and Sprint Retrospects

Collaborating ✓ High usage of collaboration tools and techniques - VSTS,TFS,Skype etc

Trust ✓ High trust among teams

Sit Together ✓

A team has their own room and space where they can meet and work together

Real Customer Involvement ✓

Skype ( Web conferencing) and client visits make the involvement real

Ubiquitous Language ✓ Developers use the Business terms in their Development track

Stand-Up Meetings ✓ Every Morning performed per team

Coding Standards ✓ Use MS VSTS in built coding standards, also use Code.it Right

Iteration Demo ✓ Biweekly Demo of Iterations

Reporting ✓ Daily, Weekly , Mothly Reporting, and TFS Reports on the fly

Releasing ✓ Week Iterations and biweekly Sprint Releases

Done Done ✓

Done is defined by the scrum team and the Product Owner. Every item checked in is signed of with quality guides to the test team and then to the client.


No Bugs ✓ Test-driven development structures work into easily-verifiable steps.

Version Control ✓

Usage of TFS checkin rules allows people 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 ✓ 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 ✓


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

Requirement Phase

Project Backlog based on Priority

Visual Studio Team System 2010+ Scrum for TFS Template

Design 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

Team Foundation Server 2010

Project Dashboard ( Burndown Charts, Team Velocity)

Scrum For Team System Dashboard

Development Phase

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


Test Phase

Automated Testing and –

Visual Studio Team System 2010 (Team Test and Lab Manager) + Usage of Agile TMAP Template

Deployment Phase

Web Server

IIS Deployment

Deployment Document Template


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.

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 how to deal with Indian colleagues. A 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 its 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 the 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


Figure 3: IP Phones for Communication

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.

Video Conferencing, Chatting and Desktop Sharing and E-mails – 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 E-mails 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.

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.


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.


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.

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. 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 Major Defect – 2 Minor Defect – 2 A

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.


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

User Experience UI Design and Prototype

Follows all standards from Microsoft User Interface Guidelines (Web/Windows) and W3C Standards (Web apps) and Reviewed and Signed off

Requirements

Product Backlog

Requirement Traceability, should be able to map all requirements to expected test cases and Reviewed and Signed off

Design

High Level Design (Architecture and Component Diagram and Database Design)

Follows all standards from Microsoft Architecture Guidelines (Web/Windows) and Reviewed and Signed off

Low Level Design (Use Cases and Class Diagram)

Follow all UML Design best practices and Guidelines document, and Reviewed and signed off

Development Code and Unit tests

Microsoft Code Review Guidelines, Code Metrics and Minimum 60% Unit test coverage and Reviewed and Signed Off

Testing Test Cases and 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.


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.


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.