This session was presented by Mr. Ajay Kalra, during Playscrum Delhi meetup on July 16, 2016.

1. Adapting Scrum
in an organisation with
tailored processes
Ajay Kabra
16th July 2016

2. Hope,
everyone's
paying
attention

3. It is just chaos …
The Roman bridges of antiquity were very inefficient structures. By modern
standards, they used too much stone, and as a result, far too much labour to build.
Over the years we have learned to build bridges more efficiently, using fewer
materials and less labour to perform the same task.

4. It is just chaos …
• But there is difference between software failures and bridge failures, beside 3,000
years of experience. When a bridge falls down, it is investigated and a report is
written on the cause of the failure.
• This is not so in the software industry where failures are covered up, ignored,
and/or rationalised.
• As a result, we keep making the same mistakes over and over again.!
• We have time and again a number of lessons learnt report, but never acted upon.

5. It is just chaos …
• Research shows a staggering 31.1% of projects will be cancelled before they ever
get completed.
• Further results indicate 52.7% of projects will cost 189% of their original
estimates.
• The cost of these failures and overruns are just the tip of the proverbial iceberg.
• The lost opportunity costs are not measurable, but could easily be in the trillions
of dollars.

6. It is just chaos … Data is telling a story
Cost Overruns % of Projects
Under 20% 15.5%
21 - 50% 31.5%
51 - 100% 29.6%
101 - 200% 10.2%
201 - 400% 8.8%
Over 400% 4.4%

7. It is just chaos … Data is telling a story
Time Overruns % of Projects
Under 20% 13.9%
21 - 50% 18.3%
51 - 100% 20.0%
101 - 200% 35.5%
201 - 400% 11.2%
Over 400% 1.1%

8. Recipe for Failures …. It is guaranteed
• Factors that cause projects to be challenged/ failed
Failures attributes %
Lack of User input 12.8%
Incomplete requirements and specifications 12.3%
Changing requirements and specifications 11.8%
Lack of executive support 7.50%
Technology Incompetence 7.00%
Unrealistic Expectations 5.90%

9. Success can be achieved …. If following are in place !
• The three major reasons that a project will succeed are user involvement,
executive management support, and a clear statement of requirements.
• There are other success criteria, but with these three elements in place, the
chances of success are much greater. Without them, chance of failure increases
dramatically.!
Reasons for Success %
User Involvement 15.9%
Executive Management Support 13.9%
Clear Statement of Requirements 13.0%
Proper Planning 9.60%
Realistic Expectation 8.20%
Clear Vision and Objectives 2.90%

10. 1. Too heavy / Non value added processes defined
2. Lack of management support
3. Different understandings of mission and goals
4. Process adoption not well planned
5. Process and procedure definition forced on staff
6. Pilots of process too limited
Other contributors to failures

11. WHOLISTIC AGILE TRANSFORMATIONS
Where did it all start?
• Many enterprises these days are outsourcing software development to offshore teams.
Your organisation may have even tried it as a way to get access to highly skilled
resources at lower cost, and scale development resources up and down as you need
them.
• Recently at a client, I happened to see a wonderful chaotic organization, trying to force
fit Agile and Scrum concepts … in a pure play Onshore – Offshore engagement model.
• Why am I saying Chaotic ….. Well some reasons are well known to most
of us and yet we ignore them or consider it “Business as Usual”,
well that’s the way it works out here … is a common phrase used..

12. • The main difference between heavyweight and agile methodologies is the
acceptance of change.
• It is the ability to respond to change that often determines the success or failure of a software
project
• Heavyweight methods freeze product functionality and disallow change. However one of the
key, philosophical constructs making agile processes successful in today’s market is its
response to change at any stage of the project
The Other Side of the COIN …

13. • The first rule of Lean Manufacturing and TQM is elimination of waste. That is,
eliminate anything which does not add value to the final product.
• Documents, diagrams and models produced as part of the software development must be
minimized because once a working system is delivered the user may care little about these
deliverables. Agile methodologies follow the same rule for their processes.
• The second rule of Lean Manufacturing and TQM is that inventory is waste.
• Inventory in SW development is documentation, excess documentation creates a waste of time
in producing and reviewing the documents. Rather than having a 100 page detailed specification,
write a 10 page set of rules and guidelines. This is what agile methodologies rigorously maintain,
documentation should be kept to barely sufficient.
• The third rule of Lean Manufacturing and TQM is to maximize flow.
• Rather than taking months to show the customer the final product, use an Iterative development
where small but complete portions of a system are designed and delivered throughout the
development cycle.
Follow these Rules of the Game …

14. • The fourth rule of Lean Manufacturing and TQM is pull from demand and
deciding as late as possible.
• SW development practices which keep requirements flexible and as close to system delivery
as possible can provide a significant competitive advantage in a changing environment.
Similarly, agile methodologies are designed to respond to change, not predict it, and have the
ability to make decisions as late as possible
• The fifth rule of Lean Manufacturing and TQM is to empower workers, to
provide both the tools and the authority for people other than mangers to make
decisions.
• One of the problems with heavyweight documentation is that it attempts to make all of the
decisions for developers. However agile methodologies give developers guidance as well as
freedom to make the detailed design and programming decisions. Mary mentions, “It is
always better to tell developers what needs to be done, not how to do it”.
Follow these Rules of the Game …

15. • Want to fail at your Agile transformation? It’s easy.
• Follow these simple rules for distributed teams-
• Set up a complex geographic maze based on the economics of
resource utilization;
• Ensure a time zone difference between 7-11 hours
• Rely heavily on emails and large documents (especially detailed test
plans) for your communication
• Don’t invest in bringing people together to collaborate or train.
• Mental Co-location (and not Physical)
• Organizations in this distributed bind have essentially made deals with the
devil, trading off fundamental Agile success principles like face-to-face
collaboration (Invest in tools and technology) for the promise of speed and
lower costs (but don’t worry, it’s still Agile!)
• How many have real paid attention to con-calls (only Audio)?
• Be honest to yourself…..
How to manufacture disaster..

16. WHOLISTIC AGILE TRANSFORMATIONS
• The inherent challenges of working with offshore development team are kind of
obvious, at face value-
• time zone differences,
• cultural differences
• and a lack of face-to-face communication
• FINALLY – Management commitment (85% of all problems are from Sr.
Management)
• All the above facilitates a negative feedback loop in which misunderstandings beget
more misunderstandings and traditional Scrum-based agile development spirals out of
control.
• The most important facet of agile development in a fast-moving
workplace is communication – without it, processes can fall apart
and deadlines can fail to be met.
What are the challenges?

17. • Start customizing an agile process before you’ve done it by the book.
• Have one person share the roles of ScrumMaster (agile coach) and Product Owner. In fact,
have this person also be an individual contributor in the team.
• Replace a plan document with a plan “in your head” that only you know.
• Don’t trust the team or agile. Micromanage both your team members and the process.
• Equate self-managing with self-leading and provide no direction to the team whatsoever.
• Cavalierly move work forward from one iteration to the next. It’s good to keep the product
owner guessing about what will be delivered.
• Do not create cross-functional teams. Put all the testers on one team, all the programmers
on another, and so on.
• Convince yourself that you’ll be able to do all requested work, so the order of your work
doesn’t matter.
What are the challenges?

18. WHOLISTIC AGILE TRANSFORMATIONS
• Due to the lack of F2F communication, cultural differences & time zone issues, the developers
start to misunderstand requirements. In an attempt to close the communication gap, the
product owner starts to use more written communication, which causes more issues.
• The next thing that happens is because the team has never met one another, the onshore
developers don’t treat the offshore developers as part of the team.
• The offshore developers start to work on their tasks independently, become less likely to clarify
aspects of the project, and because they feel that they need to fend for themselves, they start
to blame each other when something goes wrong.
• In my experience, this lack of communication and teamwork leads to poor productivity and a
solution that doesn’t provide value.
What are the challenges?

19. • But more often than not, I hear of project failures that are blamed on offshoring.
People say things like: “The offshore developers just didn’t understand what we
needed” or “They developed completely the wrong thing.”
• An executive decrees is a switch to Agile delivery across offshore development, but
there’s no real follow-through: it’s simply a “check book commitment.”
• The executive demands immediate results, yet doesn’t change the metrics by which
success is measured. We still continue to measure
• Effort Variance
• Resource Utilization
• Schedule Variance
More of the some that we know

20. WHOLISTIC AGILE TRANSFORMATIONS
How do we prevent this failure?
• Leaders must accept that a successful transformation is a journey. Along this journey,
leaders seek guidance for a transformation with a broad, sustainable impact.
• As part of the transformation they make a personal commitment to their teams, and in
turn they recognize the personal commitment they are asking from their employees.
• Executives commit to measuring success differently from before, because the work is
different from before.
• Success now favours value delivery, and time for learning is built into the transformation.
Ultimately, success is celebrated across the organization and setbacks are seen not as
failures or cause for blame, but as opportunities for learning and growth.
More of the some that we know

21. • Failed Agile transformations suffer from an inability to change the existing organizational structure.
• Here’s another symptom of your crippling Agile transformation: Does your organization cling to a notion
of efficiency based on resource usage — believing that loading people to 100% capacity is the best way
to get work done, and then measuring people annually by how well they deliver in this fully-loaded
mode?
• Typical organizations have been set up for sub-optimization: that is, they measure success by
departmental performance, versus overall value delivery.
• In your effective Agile transformation, you know what the true value is, you know who needs to be
involved in order for the value to be delivered, and everyone associated with the value delivery has
visibility into the current state of the value stream, including its blocks.
• They see the goal as successful delivery of value to the customer, and they coordinate as a whole to
deliver that value.
Why do we have Failures?

22. • Lack of experience (on the part of the customer).
• The wrong developers. Note that I didn't say "bad developers".
• The wrong attitude
• Bad development process. By far the biggest cause of offshore development failures
is also the cause of many on-shore or in-house development failures: not having an
effective development process.
Why do we have Failures?

23. • Misunderstanding what Scrum is (and is not)
• Software not tested at end of sprint (Definition of Done)
• Backlog not ready at beginning of sprint (Definition of Ready)
• Lack of facilitation or bad facilitation
• Lack of management support
• Lack of client, customer, or end user support
• We do things to support and clear audits – Business value takes a back seat
Challenges in Implementing Scrum

24. • Decentralize decision making
• Define Guiding Principles in your organization for offshore engagement model
• Have Open culture and relationship based on equality
• Transparent results are only measure of progress
• Building Quality in, Results in lowest development cost
Enough of issues, let’s focus on solutions

25. • Agile transformations fail when we don’t pay attention to whether we centralize
or decentralize control.
• Due to strict, centralized control, decisions are not as informed as they could be.
Waiting for a decision because of centralized control wastes time and human
potential.
• Servant leaders don’t relinquish all control; rather, they recognize the value in
releasing control when all concerned are better served.
• Always remember, “Watch the work, not the worker.” Decentralize to move
decisions closer to the worker, the one who best knows the work. Centralize
control as a service to the flow of value.
A bias toward decentralization helps leaders and teams better converge.
Decentralize decision making

26. • “GROWTH AND PROFIT ARE A PRODUCT OF HOW PEOPLE WORK TOGETHER”
• SW development is complex and offshoring complicates this further. It takes special
effort to collaborate effectively with people in different time zones, locations and with
different culture.
• Develop the concept of “One team”.
• Team members on both the sides of the Atlantic are considered equal.
• Shared culture and personal relationships triumph over distance.
• There is NO substitute for working with “Good” people.
Guiding Principles in your organization for offshore
engagement model

27. Co-locate team as often as possible,
especially at inception and key
milestones.
Rotate members around.
Invest in (and plan for) tools that provide
a shared environment.
Plan to experiment.
Establish a single global instance of
project assets, easily accessible by all.
Try virtual team building (team wiki &
photos).
Establish known hours, with as much
overlap as possible.
Apply high cohesion and low coupling to
allocation of work to sites.
Develop a shared team vocabulary.
Apply Scrum-of-Scrums concept when
mass remote meetings are
unproductive.
Dispersed Team Recommendations

28. • Involving all the team members in the scrum ceremonies and have a right structure
for all necessary formal communication
• Remove all / any barrier that supports the “Us-Them” mentality – There is “One
Team” and there is no room separation
• The team only works on the user stories / requirements that are necessary and
agreed upon to complete the clients priorities
• The client repeats the aim and the ‘Why’ behind every ‘What’ for every sprint /
iteration to the entire team
• Personal disciplines (developer, analyst, tester …) are less important than achieving
the sprint goal together
Guiding Principles in your organization for offshore
engagement model

29. • Team members at both the locations / or multiple locations have an equal say in the
software architecture and design
• Feedback on quality and performance is open and bi-directional
• Company culture and project culture are based on the strong principles and value
system. These are more important than personal differences
• Hiring the same level of talent at both the location creates trust and respect
• Know your co-worker contests: Create a game where you describe the passions and
interests of a particular co-worker and everyone has to guess which co-worker it is.
Have Open culture and relationship based on equality

30. • Invest in common tools to be used across the borders
• Knowledge is always available at local levels, because both the sides of the team work
on the same parts of the system
• Measure the wastage incurred in the sprint / iteration. The most powerful metrics in
the Agile world
• Address the concept of “Takt time” or what we call the “Cycle time”
• Always round the velocity to the lower level and Sprint time to the higher level
• Identify and quantify the impact on velocity due to loss of time / waiting for
information and so on…
Transparent results are only measure of progress

31. Here are some changes you can embrace to deal with the distress introduced by the
distributed model:
• Engage the executive sponsor in regular visits to all locations.
• Trade or share the burden of dealing with broad time zone differences.
• Hire a coach who’s well-steeped in distributed team success.
• Ensure all team members receive the same Agile training; for maximum effectiveness, get
everyone in the same room for the training.
• Invest in high-definition, large-screen video technologies.
• Have a facilitator in each location when teams plan their dependent delivery
commitments.
• Maintain a regular cadence of visits across all geographies and all roles.
• Build working agreements that support core hours for availability, or alternative solutions
for quick turn-around feedback.
Dealing with Disasters, some ideas, & thoughts…

32. Practical processes and work aids contain enough information:
Right Level of Process (1/2)

33. Anvil Project Weekly Status Report
User Stories Completed
– As a User, I want to be able to use my anvil 24/7
– As a User (all personas), I want to be able to carry
my anvil
Lessons Learned during the sprint
– Breaking down stories into 20 points or less is a
big help
Impediments (not closed during week)
– Testers assigned to multiple projects
Risks
– User environment may not be ready on time for
final acceptance testing
Right Level of Process (2/2)

34. • Actually all concepts we review are part of the root concepts Scrum has,
Transparent, Inspect and Adapt.
• These are key factor to improve in scrum and become a more Agile team and
people in this technology world.
Some Closing thoughts ...

35. • Stop Starting and Start Finishing …
• Change Starts with you … You are the change agent
• Learn to say “No” and Learn to say “I don’t know”
Some Closing thoughts ...

36. “Xebia:
Share
Knowledge.”
The Netherlands | USA | France | UK | India
blog.xebia.in | blog.xebia.com | www.xebia.com