Adapting Scrum in an Organization with Tailored Processes

Adapting Scrum in an organisation with tailored processes

Ajay Kabra16th July 2016

Hope, everyone's paying attention

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.

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.

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.

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%

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%

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%

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%

1. Too heavy / Non value added processes defined2. Lack of management support3. Different understandings of mission and goals4. Process adoption not well planned5. Process and procedure definition forced on staff6. Pilots of process too limited

Other contributors to failures

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

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

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

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

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


• 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 apartand deadlines can fail to be met.

What are the challenges?

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



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


• 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


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

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

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

http://www.zdnet.com/article/outsourcing-exec-urges-stop-outsourcing-your-software-development/

• 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

• 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

• 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

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

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

• 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

• 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

• 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

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…

Practical processes and work aids contain enough information:

Right Level of Process (1/2)

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)

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

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

Adapting Scrum in an Organization with Tailored Processes

Technology

Transcript of Adapting Scrum in an Organization with Tailored Processes