Shibusa: Framework to Enable Enterprise Level …...Page 1 of 14 Shibusa: Framework to Enable Enterprise Level Agile Adoption and Drive Author: Swati Garg, Co-author: Zaheerabbas Shaukatali

Page 1 of 14

Shibusa: Framework to Enable Enterprise

Level Agile Adoption and Drive

Author: Swati Garg, Co-author: Zaheerabbas Shaukatali Contractor

Consultants, Agile Center Of Excellence, Wipro IT Business

Abstract

This paper elaborates a framework based on

experiential learning of coaches from Agile

Center of Excellence at Wipro. This framework

can enable large organizations to embrace Agile

in a systematic and dynamic manner. It

addresses key questions on how an organization

can make all projects get benefitted from Agile

methodologies irrespective of myriad

technologies and variable business scenarios.

Through this approach senior management

including Chief Technologies Officer

(CTO)/Chief Information Officer (CIO)/ Chief

Quality Officer (CQO) can take objective look at

progress of Agile momentum in the organization

on a periodic basis and direct their organization

to reach the pinnacle of Agility for business

enablement.

Introduction Since 2004, Agile Center of Excellence (COE)

at Wipro is actively involved in facilitating and

coaching the project teams that work on Projects

using Agile Methodologies- XP, Scrum, AUP

and so on. These projects are done for various

customers in different domains using multiple

technologies.

We, as mentors from Agile COE, consistently

observed that practitioners find it easier to adopt

when they are asked to experiment with a few

Agile practices and then gradually guided to

embrace all of Agile practices with applicable

nuances for given business scenario. All Agile

projects are not the same. The amount of Agile

practices used in different project scenarios can

vary depending upon business dynamics,

limitations imposed by certain technologies or

the culture of project team for example.

Through due course of evolution, we have

developed a framework to enable enterprise

level Agile adoption and drive at Wipro. This

framework relies on consolidation of

information based on Agile Coefficient which is

an objective measurement of respective projects

in terms of their capability to embrace Agile

practices. It helps Agile COE to stay focused

and guide the team to aim for fullest use of

Agile practices in their project scenario to gain

desired benefits. This framework is flexible to

accommodate heterogeneous projects. It

provides consolidated picture on Agile status of

all projects in the organization. Senior managers

including CTO/CIO/CQO can see how coaches

and mentors from Agile COE are contributing to

make an organization level Agile penetration

increase over a period. Senior managers

including CTO/CIO/CQO can leverage this

framework to set vision for Agile spectrum in

the organization.

Origin of Framework In order to enable Agile adoption and drive at

organization level, it is absolutely essential to

conceptualize an integrated and flexible

approach that is rooted into objective

measurement parameters to assess respective

projects. It should be easy to comprehend and

Page 2 of 14

scalable to fit heterogeneous projects. The

parameters should create consistent inference

when applied across several projects within

organization, so that senior managers including

CTO/CIO/CQO can rely on pictures produced

using the same over period of time.

Agile methodologies hinge on definite set of

practices that drive excellence of software

engineering along with adequate focus on

human aspect of team and customer

management to achieve best possible returns on

investment through an IT project. Therefore, it

is crucial to ensure that measurement parameters

must objectively evaluate the amount of Agile

practices used in respective projects. For

example: we should be able to differentiate

between a Scrum project doing once a week

builds to another Scrum project doing daily

builds. We should be able to differentiate

between an Agile project Team doing offline

code reviews to another Agile Team following

pair programming. In both of these cases the

former project has less agility as compared to

another.

Next important aspect is to ensure that different

nuances of respective Agile practices are

considered. For example a project having two

week iterations is at higher level of agility with

respect to itself when it was following 6 week

length of iterations, though both scenarios

represent an Agile project with time boxed

iterations.

In summary, Agility of a project depends on

amount of Agile practices applied and the depth

/nuance of each practice pursued for project

execution.

Agile Coefficient The Agile Coefficient is an objective measure of

project’s agility with respect to amount of Agile

practices applied and the depth of each practice

pursued. A project that leverages all Agile

practices to fullest for business enablement is

called a core Agile project. This kind of project

is represented by 100% Agile Coefficient. There

could be several projects that may have chosen

to use different and partial Agile practices, this

kind of projects may not have 100% Agile

coefficient, however, they have moved away

from conventional waterfall represented by zero

Agile coefficient. These projects with help of

Agile coaches can continue to increase the Agile

Coefficient and reach the desire level of Agility

for better business returns.

Shibusa Fundamentally we have developed this

framework based on measurement of Agile

Coefficient. We recognize striking results that it

brings to enable enterprise level Agile adoption

and drive. Nevertheless, this framework itself

can be improved further as we continue to learn.

Hence it is called Shibusa. Shibusa (noun) are

Japanese words that applies to a wide variety of

subjects and refer to several fundamental

qualities including balance of simplicity and

complexity, in a way that one constantly finds

new meanings and enriched understanding that

cause its value to grow with passing time.

Demonstration of Shibusa

Framework In this section we are moving step by steps using

sample information to demonstrate the Shibusa

framework at high level.

1. In the beginning Agile COE identifies

number of projects to pilot the framework.

For example: 100 projects out of 1000

current projects in the organization.

2. Agile COE interacts with key project

stakeholders to understand the current level

of Agile practices followed in respective

projects as identified in previous step. Based

on the understanding and evidences, Agile

Page 3 of 14

COE usages Agile Coefficient measurement

system which is explained in subsequent

section of this paper, to objectively obtain

the Agile Coefficient of respective projects.

3. Data with respect to Agile Coefficient of

respective projects is captured and

consolidated. In the beginning, a few

projects stand at zero Agile coefficient.

Some other projects reflect different Agile

Coefficients ranging from more than zero to

less than 100% respectively. For example:

Project ABC and four more projects have

25% agile coefficient. Project LMN and 7

more projects have 40 % agile coefficient.

Data emerges like the sample captured in

sorted table (Table 1) below:

Table 1

4. Consolidation of above mentioned

distribution emerges as table (Table 2)

below:

Table 2

5. Agile COE creates a consolidated picture by

plotting the distribution, while having x –

axis to represent the Agile Coefficient as

percentage, y –axis as Count of Projects.

The baseline curve is created by connecting

the distribution points starting from first

point that is created for the Project’s count

with least Agile Coefficient and continuing

to move towards 100% Agile Coefficient

cutoff as marked on y-axis. A sample

distribution plot is depicted in the figure A.

This plot represents the initial baseline of

Agile penetration in the organization with

respect to number of pilot projects selected

in step1.

6. Subsequently, in consent with project

stakeholders, Agile COE identifies areas of

Page 4 of 14

improvement with respect to Agile practices

in some or all projects as selected in step1.

Agile COE coaches the implementation and

assess the level of Agile practices once

again to plot the distribution of Agile

Coefficient. In all possible cases, the number

of projects with low Agile Coefficient

decrease and the number of the projects with

higher Agile Coefficient increase. A sample

distribution curve of improvement in Agile

Coefficient with respect to initial baseline

(Figure A) is depicted in the figure B.

7. Agile COE can overlays the figure A and B

to display the impact with respect to

increase in Agile penetration within

organization. A sample is depicted as figure

C below.

8. The improvement in Agile penetration is

quantified by plotting the distribution of for

deferential improvement in Agile

Coefficient of respective projects and

calculating the area under the curve. A

sample curve for area calculation is depicted

in figure D.

9. Agile COE can continue to repeat the step 6

to step 8 to achieve a level of Agile

penetration where no projects as identified

in step1 remain with low Agile Coefficient.

A sample of shift in curve due to

improvement with respect to figure B is

depicted as green curve in figure D.

10. Steps 1 to 9 can be repeated to include more

number of projects under influence of

Shibusa framework for Agile adoption and

drive at enterprise level.

11. The ultimate goal of Shibusa framework is

to bring all projects within the organization

represented as a dot on 100% Agile

coefficient, as depicted in figure F.

Page 5 of 14

12. Nevertheless, to be realistic CIO/CQO of an

organization can decide to operate in

appropriate spectrum of Agile Coefficient

closer to 100%. The Agile spectrum of an

organization is mainly constrained based on

landscape of its IT business.

Measurement of Agile Coefficient This section provides detailed insight on how the

Agile Coefficient is measured using aspects of

several practices that make a project objectively

move on scale of agility to meet its business

needs. When the same measurement criteria is

applied across several projects across

organization and plotted as explained in

previous section, it helps the whole organization

to gain Agile momentum.

At high level there are 33 different measurement

criteria. For sake of simplicity we have given

equal Influence Factor of 3 points for each

criterion to create a scale of 99 points or 99% of

Agile coefficient. We have set the limit at 99%

to accept the fact that 100% Agile Coefficient is

the state of perfection, which is really tough to

achieve. (Some reader may find it simpler to

make one of the criteria to have 4 points

Influence Factor and make the scale to 100%).

Each criterion has 3 or more options for

appropriate relevance in different project

scenario. Options are prearranged on increasing

scale of agile enablement ranging from zero to

five or less.

To measure Agile Coefficient of any project,

respective criterion is qualified with closest

applicable project scenario through listed

options. The Applicable Influence Factor of

Criterion (AIFC) is derived based on the

Influence Factor Multiplier (IFM) of selected

option with respect to Highest Influence Factor

Multiplier (HIFM). HIFM for each criterion

depends on number of options used for its

business scenarios. HIFM is a number less than

the available number of options (Number of

options for a criterion -1). Finally the aggregate

Agile Coefficient is achieved by summation of

Applicable Influence Factor (AIFC) of all

criteria.

Let’s take an example: A project find option C

of criterion One applicable to itself. Then the

Influence Factor Multiplier of this option (2) is

considered with respect to Highest Influence

Factor Multiplier (HIFM) as (3). Hence the

Applicable Influence Factor for Criterion One

comes as (3X2/3= 2). It finds option B of

criterion two applicable to itself. Then the

Influence Factor Multiplier of this option (1) is

considered with respect to Highest Influence

Factor Multiplier (HIFM) as (2). Hence the

Applicable Influence Factor for criterion Two

comes as (3X1/2= 1.5).

On the similar lines suitability of different

options in respective criterion is captured in the

table (Table 3) as part of this section

subsequently for further understanding of

readers who are interested in detailed approach.

Ultimately the project under example gets an

Agile Coefficient of 55.9 point or 55.9% which

is certainly better than conventional waterfall,

yet has a significant room for improvement from

an Agile Coach’s perspective. Agile Coefficient

of such projects can be improved by based on

stakeholders agreement in a given business

scenario.

Even so, the whole set of criteria and options are

open for refinements and necessary changes

based on organizational focus and needs. Agile

community can ponder collectively to give it

shape as more flexible and common

understanding framework for enterprises.

Page 6 of 14

Table 3: Detailed demonstration of measurement criteria, application options and calculation of Agile

Coefficient in an example project context

S.

N

o.

Influence

Factor

Multiplier

(IFM) of

respective

options

IFM of

selected

option

Applicable

Influence

Factor for

Criteion

(AIFC) =3*

(IFM/HIFM)

A One time development in clear phases with formal gate keeping for

each phase. Phases can include- requirements phase, design phase,

coding phase, testing phase and so on. Deployment to production

only once in the end of project.

0

B Incremental development in clear phases (with next increment and

it's phases at some lag than earlier one) with formal gate keeping

for each phase. Phases can include- requirements phase, design

phase, coding phase, testing phase and so on.

1

C Iterative and incremental development with overlapping phase yet

clear iterations of duration ranging from more than 1 month to 4

months. Output of one or more iterations ready for production

deployment cycles.

2

D Development in iterations of one month or lesser duration with no

phase demarcation yet capability of deployment to production at the

end of each iteration.

3

A One time requirements collection phase. Constant set of

requirements. Captured in a free flow document form as detailed

sections, sub sections and paragraphs . With direct access to less

than 50% project stakeholders (Mainly the requirements and design

phase stakeholders).

0

B One time requirements collection phase with tail period

overlapping to future phases. Requirements changes expected up to

50%. Captured in a tabular form of document or spreadsheet with

columns for vital attributes such as identification number,

description, priority, dependencies id, author, estimated effort/size

to implement, etc. With direct access to more than 50% project

stakeholders.

1

C Requirements collected until beginning of last iteration for

completion of project. Requirements changes expected up to 95%.

In an Agile enabled requirement tool with vital data points, and

capability to track till closer. With direct access to 100% project

stakeholders.

2

2 2

What is the project implementation strategy?

How are requirements captured?2

1 1.5

Criteria Details

Note1: Each criterion has maximum influence factor of 3 points

Note2: Each criterion has three or more options based on closest suitability

to project scenario

Note3: Highest Influence Factor Multiplier (HIFM) for respective criterion

depends on number of options. HIFM =(Number of options -1)

1

Continued…

Page 7 of 14

S.

N

o.

Influence

Factor

Multiplier

(IFM) of

respective

options

IFM of

selected

option

Applicable

Influence

Factor for

Criteion

(AIFC) =3*

(IFM/HIFM)

A No prioritization, all requirements are treated equally and signed

off to be implemented once for all.

0

B Requirements are prioritized by customer and signed off to be

implemented incrementally. Yet minimal scope for change in

priority.

1

C Requirements are prioritized by customer and team in

collaboration. Project stakeholder have common understanding for

implementation in current iteration. Yet priority of non-

implemented requirements can change any time.

2

A Based on Project Manager's experience. Completely ownership

with Project Manager.

0

B Some in-house estimation tools. Based on historical data bases and

a few project leads inputs are taken. Ownership shared by project

leads and Project Manager.

1

C Estimation sessions are live in presence of whole team. Ownership

shared by complete team and managers.

2

How comprehensively the requirements are captured from estimation point of view?

A More than 50% of project team finds it difficult to estimate due to

ambiguity and non availability of experts.

0

B Less than 50% of project team finds it difficult to estimate and

experts are available for clarifications to sort out ambiguities.

1

C 100% of project team is comfortable with estimation and there is

no ambiguity.

2

How comprehensively the requirements are captured from testing perspective?

A More than 50% of project team finds it difficult to write system

test cases/acceptance test cases due to ambiguity and non

0

B Less than 50% of project team finds it difficult to write system test

cases/acceptance test cases and experts are available for

clarifications to sort out ambiguities.

1

C 100% of project team is comfortable to write system test

cases/acceptance test cases and there is no ambiguity.

2

Criteria Details



to project scenario



How are the requirements prioritized for implementation?

How is project estimation done?

5

6

2 3

2 3

3

4

2 3

1 1.5

Continued…

Page 8 of 14

S.

No

.

Influence

Factor

Multiplier

(IFM) of

respective

options

IFM of

selected

option

Applicable

Influence

Factor for

Criteion

(AIFC) =3*

(IFM/HIFM)

A With technical details for completeness. 100% details are

documented. Access is given to less than 50% project team. Team

does not start coding or testing activities unless design is signed off

by customer. Possibility to change is ruled out.

0

B With technical details for modularity. 100% details are

documented. Access is given to more than 50% project team. Team

does not start coding or testing activities unless design is

completed for current increment. Possibility to change exists in

next increment.

1

C With technical details for modularity. Key aspects are documented.

Access is given to 100% project team. Team do design, test and

coding asynchronously. Possibility to change exists throughout.

2

A Complex architecture and design with less than 20% opportunities

for modular changes.

0

B Object oriented, modular design up to 70% opportunities for

change.

1

C Object oriented, modular design. Not restricted for change. 2

How often re-estimation is done and what is the scope of re-estimation? On what basis?

A Less than once a quarter, as requirements are considered frozen.

Scope of re-estimation includes the complete project scope due to

large impact on work already completed.

0

B Once or twice a quarter based on change in requirements. Scope of

re-estimation includes possible impact on work already done, yet

mainly focused on remaining left over work of project based on

remaining increments of size more than 8 weeks each.

1

C Once a month or higher frequency. Minimal impact on work already

completed. Re-estimation is done for next small increment of work

to be finished in iteration.

2

To what level the Project plan is created and milestones are modified at what frequency? On what basis?

A Made at high level such as tasks are assigned in terms of minimum

1 person week and ranging up to several person weeks. Milestones

modification is almost not possible.

0

B Made at high level such as tasks are assigned in terms of person

days ranging beyond 10 person days. Milestones modifications are

possible with reasoning and negotiations, but not end date.

1

C Made up to low level clarity such as some tasks ranging beyond 40

hours. Milestones modifications are possible with stakeholders

understanding, but not end date.

2

D Made up to low level clarity such as very few or no tasks ranging

beyond 40 hours. Milestones modification is possible with

stakeholders understanding. End date can shrink or expend based on

emerging business needs and scenarios.

3

Criteria Details



to project scenario



1.5

2 2

0

7

8

How are architecture and design created?

How object oriented/modular is architecture and design?

0

1

1 1.5

9

10

Continued…

Page 9 of 14

S.

No

.

Influence

Factor

Multiplier

(IFM) of

respective

options

IFM of

selected

option

Applicable

Influence

Factor for

Criteion

(AIFC) =3*

(IFM/HIFM)

A Available to high level stakeholders such as project manager and

customer for status updates.

0

B Published and available to next level stakeholders such as project

leads. They can contribute to status updates besides Project

Manager and Customer.

1

C Accessible and understood by all project stakeholders. All of them

have direct access to update the status of their work.

2

A More than 200 members 0

B More than 50 members yet less than 200 members 1

C More than 7 members yet less than 50 members 2

D Less than 7 members 3

A Spread across different offices in different towns, in different time

zones with difference with no overlapping work hours.

0

B Spread across different offices in different towns, in different time

zones with difference up to +/- 12 hours with some overlapping

work hours.

1

C Spread across different offices in different towns within same time

zone.

2

D Spread across different offices in same town 3

E Spread across different floors in same office building 4

F Collocated at common project floor/room 5

14

A Up to 10% team is technically strong (90% resources with less

than 1 year experience)

0

B Up to 40% team is technically strong (60% resources with less


1

C Up to 80% team is technically strong (20% resources with less


2

D Up to 100% team is technically strong (0% resources with less


3

A Up to 10% team is familiar with business domain 0

B Up to 40% team is familiar with business domain 1

C Up to 80% team is familiar with business domain 2

D Up to 100% team is familiar with business domain 3

A Mostly a challenge. Rookies are expected to ramp up by

themselves.

0

B Done through specific training sessions for rookies. 1

C Done through specific training sessions and diligent on job

mentoring by senior members and peers to ramp up rookies to

comfortable levels.

2

Criteria Details



to project scenario



4 2.4

1 1.5

2 2

2 2

1 1

How is resource skilling done?

1

11

16

How is the Project plan's availability?

How big is the project team?

How are the team members located with respected to each other?

How is team's business domain familiarity?

How is team's technical capability?

15

1.5

12

13

Continued…

Page 10 of 14

S.

No

.

Influence

Factor

Multiplier

(IFM) of

respective

options

IFM of

selected

option

Applicable

Influence

Factor for

Criteion

(AIFC) =3*

(IFM/HIFM)

A Documents, Mails 0

B Documents/Mails /Messenger 1

C Whiteboards/Wiki/Messenger/phone/v-con/web-cams /Mails 2

A Done once a week or less than that 0

B Done once a week and need basis 1

C Done formally more often than a twice a week like daily call or

sunrise sunset calls

2

A Manager is informed of priority issues on weekly basis 0

B Manager is informed of priority issues on need basis earlier than a

week

1

C Manager is proactively involved to catch and resolve the issues on

daily or real time basis

2

A Status report is sent and discuss once a week or at lesser frequency 0

B Status report is sent weekly and customer call twice a week or more

often

1

C Status report and customer call done daily once minimum or

customer is available of real time updates

2

A Documents / Mails 0

B Spreadsheets based risk resolution with specific risk attributes. 1

C visual chart on display like story boards, Kanban, Burn down charts

or others

2

A Unit testing is done after a code module is done. Formal testing

does not start until coding and unit testing (CUT) phase is not

completed.

0

B Coding and unit testing (CUT)cycles repeated at nearly a month's

frequency to complete the whole coding. Formal testing phase legs

behind by almost one month or more.

1

C Coding and unit testing (CUT) is done asynchronous with formal

testing within weekly or bi-weekly increment cycles.

2

Criteria Details



to project scenario



1.5

1 1.5

2 3

2 3

Is there some preferred team collaboration tool?

How is the status updates made at team level?

How the status is updates done at Project Leads/Project Managers level?

How is the status update done at customer contact level?

How are results and issues tracked?21

22 How is the development cycle for coding and unit testing (CUT)?

1 1.5

1

3

19

20

17

18

2

Continued…

Page 11 of 14

S.

No

.

Influence

Factor

Multiplier

(IFM) of

respective

options

IFM of

selected

option

Applicable

Influence

Factor for

Criteion

(AIFC) =3*

(IFM/HIFM)

A Less than 1 build in 2 weeks 0

B About one build per week 1

C Builds as frequent as once a day 2

Builds as frequent as multiple times a day 3

A Done for all code on offline and manual basis. All review

comments are documented manually and submitted in repository.

0

B Done for critical portions of code on offline and manual basis. Rest

of the code is reviewed on sample basis. Static analysis tools are

used of some portion of code. Key review comments are captured

with help of tools.

1

C Done pair programming for online review for critical portions of

code. Rest of the code is online reviewed on sample basis. Static

analysis tools are used of whole code. Key review comments are

captured with help of tools.

2

Done pair programming throughout and static analysis tools are

also used.

3

A Unit test cases are written at the end of coding phase. Later on Unit

Testing in conducted and unit testing results are documented

separately.

0

B Unit test cases are written at the end of coding for each module.

Unit Testing in conducted at module level and unit testing results

are kept to signoff coding and unit testing phase.

1

C Coding and Unit testing at done at module level through weekly or

larger duration increments to be pushed to next phase in

incremental manner.

2

D Unit test cases are written before writing the code for respective

requirements. small increments of code are written to pass the Unit

test case. Done on daily basis with any demarcation of Coding and

unit testing phase. Mainly done automatically, thoroughly and daily.

3

A Previously written code's quality is improvised only on formal

demand and approval by customer.

0

B once in a while team takes a diligent timeout to improvised the

code that was written in past.

1

C Previously written code is refactored to improve maintainability at

ongoing basis.

2

Criteria Details



to project scenario



1

3

1.5

2

2 2

25

26

How is unit testing done?

What is Code Quality/Refactoring approach?

23

24

How often the build is created?

How are Code Review conducted?

3

2

Continued…

Page 12 of 14

S.

No

.

Influence

Factor

Multiplier

(IFM) of

respective

options

IFM of

selected

option

Applicable

Influence

Factor for

Criteion

(AIFC) =3*

(IFM/HIFM)

A Formal integration and system testing execution start after formal

signed of overall Coding and Unit testing phase.

0

B Formal integration and system testing execution start after

completion of one or more increments of Coding and Unit testing

phase.

1

C Formal integration and system testing execution is done

asynchronously with design, unit testing, coding for different

requirements within scope of time boxed iteration.

2

A Clear demarcation of coding and testing phases 0

B Testing phases lag behind development phase 1

C No phase segregation between testing and coding activities 2

A Customer is involved for sign off on each phase deliverable such as

Requirements document, design document and so on until signoff

on system test result document and deployment document signoff.

Sometimes or often customer gets involve in User acceptance

testing phase to signoff.

0

B During Requirement and design phase, functional insight is

provided as 'Proof of concepts' demos. Functional increments are

deployed to testing environments during subsequent phases and

progress is demonstrated on demand. Deployment to production is

done after approval of User Acceptance Testing.

1

C Customer is involved in real time to experience the functionality

developed. At the end of iteration the functionality is demonstrated

and deployed in production.

2

A Requirements change anytime randomly during iteration for the

current iteration itself. Customer thinks this is Agile and team is

under continuous pressure to deliver.

0

B Requirements changes entirely on completion of iteration demo.

Customer shares responsibility to avoid reoccurrence in future

iterations.

1

C Requirements are affirmed and changes are proposed for yet to be

implemented functionality.

2

Criteria Details



to project scenario



0

1.5

1 1.5

1 1.5

0

1

29

30

How is the customer involved for technical or functional progress of project?

What is impact of customers involvement to change in requirements within iteration?

27

28

How is Intergration/System testing done?

How is development and testing phase demarked?

Continued…

Page 13 of 14

S.

No

.

Influence

Factor

Multiplier

(IFM) of

respective

options

IFM of

selected

option

Applicable

Influence

Factor for

Criteion

(AIFC) =3*

(IFM/HIFM)

A Internally by stepping up project team as customer is rigid to

change in plan

0

B Extensive rounds of impact analysis and discussions are done get

partial agreement on dropping some requirements or adding some

more iteration.

1

C Due to thorough involvement at shop floor good understanding is

developed between customer and team for agreement on dropping

low priorities requirements to meet the budget or expend it to run

more iteration for completing changed requirements.

2

A Not conducted or conducted at the end of project as Project post

mortem analysis.

0

B Not conducted at definite period. Lesson learnt during some

increments are discussed and corrective actions are taken for

burning issues in subsequent increments.

1

C At the end of every iteration formal retrospective meeting is

conducted to discuss both good experiences and opportunities of

improvements, so that the team commits to repeat good practices

and find solution to opportunities of improvements.

2

A There are some Customer Complaints. Team attrition is more than

15% till date.

0

B There are no customer complaints. Team attrition is more than 15%

till date.

1

C There is customer appreciation. Team attrition is limited to 15%

till date.

2

D There is customer appreciation. Team attrition is less than 5%. 3

55.9

Criteria Details



to project scenario



0 0

0 0

0 0

Aggregate Agile Coefficient of project = Sum of Applicable Influence Factor for all criteria =

AIFC1+AIFC2….+AIFC33

How is customer's satisfaction and team's satisfaction?33

31

32

How are requirements changes handled within and across iterations?

How is retrospective meeting conducted?

Key Pointer to remember about

Shibusa Framework Shibusa is a continuous and elastic framework to

enable Agile adoption and drive at enterprise

level. One can find newer ways to expend or

refine it.

Agile Coefficient is an objective measurement

of respective projects in terms of their capability

to embrace Agile practices.

When Agile Coefficient is measured and

improved in one or more projects of an

organization, it helps to improve the Agile

penetration of the organization.

Increase in Agile penetration of an organization

can be quantified by measuring the differential

improvement in Agile Coefficient for projects

that are brought under influence of Shibusa.

The Spectrum of Agile Coefficient for an

organization is largely influenced by landscape

of its IT business.

Page 14 of 14

Parting thoughts Currently at Wipro we have considerable

number of projects in 70% to 95% spectrum of

Agile Coefficient.. Over a period Shibusa

framework would continue to help us to focus

efforts for increasing Agile penetration at Wipro

and ensure that more (if not all) projects achieve

higher Agile Coefficient in the pursuit business

enablement. We are moving away from band of

low Agile Coefficient in agile manner.

Practically, an IT Services Company like Wipro

will take time to shrink the Agile spectrum (to

operate closer to more than 60% of Agile

Coefficient for most of projects) where as

existing core Agile companies may choose to

expand their Agile spectrum (Somewhat broader

than thin spectrum which is very close to 100%

Agile coefficient) if they venture in

heterogeneous IT business landscape. Shibusa

framework can be the guiding force both ways.

Your suggestions to improve the framework are

welcome. Please reach out to us.

References

Kalpana Sureshchandra, Jagadish Shrinivasavadhani,

Moving from Waterfall to Agile; Agile 2008

conference; ieeexplore.ieee.org/iel5/4599439/4599440/04599456.p

df. \ ISBN: 978-0-7695-3321-6

http://en.wikipedia.org/wiki/Shibui

Craig Larman, 2010 - Practices for Scaling Lean &

Agile Development: Large, Multisite, and Offshore

Product Development with Large-Scale Scrum - ISBN

0-321636406 (with Bas Vodde)

http://alistair.cockburn.us/Crystal+light+methods

Anthony Heath, Why switch a failing waterfall project

over to agile?

http://www.scrumalliance.org/articles/73-why-

switcha-failing-waterfall-project-over-to-agile

Mike Cohn; Patterns of Agile Adoption;

http://www.agilejournal.com/articles/articles/patternso

f-agile-adoption.html

John Hill, It's All in the Delivery;

http://www.scrumalliance.org/articles/18-its-all-in-

thedelivery

Matt Roadnight & Toby Barber, Using Scrum to

deliver a phase of a waterfall project : Experiences and

Warnings;

http://www.scrumalliance.org/resources/281

http://en.wikipedia.org/wiki/Special:BookSources/0321636406

http://en.wikipedia.org/wiki/Special:BookSources/0321636406