There is a level of "assumptions" that each one of us work with, while we deal with any system. Here in this case the system could be a team member, the manager, the management, or the entire organization. While we work with assumptions, the conversations or the discussions or the work we do, can seem like getting nowhere because of the conflicts, and a sense of frustration piles on .This is a common situation and a very common feeling amongst Coaches/Scrum masters/Project Managers or anyone dealing with project management scenarios. That is where "contracting" helps us get our way through!

Contracting is a concept of "Transactional Analysis" school of psychology. Eric Berne defines it as "an explicit bilateral commitment to a well-defined course of action". Sometimes contracts will be multi-handed - all parties to the contract will have their own expectations. In the unusual event that these are all congruent, then fine. However, if not, then discussing everyone's expectations will lead to greater understanding and therefore to a clear contract. The risk in not doing this is that problems in completing the contract will emerge at some stage.

3 Categories of contracts are administrative, professional and psychological.

Administrative contracts deals with the operational agreements- like fees, who has to do what, time, frequency, attendees etc.

Professional contracts deals with the expectations from each role and clarifies the essential setup required to achieve the same

Psychological contracts talks about how we work as people and help to understand how we express our comforts/ discomforts       

Amongst the three contracts psychological contracts are very essential and often ignored in projects. This type of contract will help us co-create any assignment and it’s a powerful tool for Agile coaches while they work with their teams, managers, organization etc.

Further to agree with any contract, both the parties should operate from a space where there is mutual trust and concern (I am Ok , You are Ok).

This report will discuss in detail about these contracts with examples from Agile projects, in an activity based sessions. We will also discuss the life positions based on 'I am OK, You are OK' theory.

Note: Please note that this presentation is not about the business/financial contracts that most of us are aware of. However, the framework of contracts could be applied in any situation including the business/financial contracts.

Agile methodologies are gaining wider acceptance in Software Development and Testing due to its inherent values like Accelerate Time to Market, Eliminate Waste and flexible to adapt changes quickly. Agile practices emphasis on effective communication, collaboration and customer involvement for addressing the challenges in developing the product in dynamic business environment due to fast changing requirements. The co-location of project teams and high customer interaction throughout the project helps in achieving effective communication, team and customer collaboration.

 In an outsourced or offshore Software development, teams are geographically distributed to develop products in a collaborative and cost-effective manner by better utilization of global talents. Adopting agile methodologies helps in better ROI by developing quality products as per changing market needs in short span. Adopting Agile in global software development shall pose few challenges due to wider geographical distance, time zone differences, and cultural aspects and so on.

This paper presents 3Cs – Communication, Collaboration and Customer Involvement as Critical Success Factors that need to be considered while implementing Agile for Global Software Development. It also details proven practices to address the challenges due to distributed agile software development. This paper is based on Author’s experience in executing Outsourced Product Development engagements using Distributed Agile Methodologies for co-creating Telecom products

Many product companies struggle with a big challenge: how to identify a Minimal Viable Product that will let them quickly validate their product hypothesis?

Teams that share the product vision and agree on priorities for features are able to move faster and more effectively.

During this workshop, we’ll take a hypothetical product and coach you on how to effectively come up with an evolutionary roadmap for your product.

This 90 mins workshop teaches you how to collaborate on the vision of the product and create a Product Backlog, a User Story map and a pragmatic Release Plan.

This is a sample proposal to demonstrate how your proposal can look on this submission system.

In her theory of cycles of development, Pam Levin talks about 7 stages a human being goes through from birth to becoming an adult. Each of these stages have unique requrements for any individual. The way the environment responds to the individual in each of these stages will determine how the individual will make sense of themselves with respect to their environment.

Interestingly an individual goes through these stages when they enter a new situation. This could be as simple as walking into a roomful of new people or when they join a new team, or an organisation. Each one has their own own pace. While this is very logical for an individual how is this related to Agile?

I have seen that teams also go through stages in their development. This is not just the forming, norming, storming and performing stages which is the internal process of a team. This is about the team being identified as an entity and being supported in their journey of becoming a high performing team. In understanding the cycles of development, we get some clues of what needs a team may have at different points in their journey to becoming self-organised.

I would like to discuss Dr.Pam Levin's model in the context of a team and propose do's and don'ts that can support the journey of a team

The seven stages:

This report is based on the analysis of the epidemic called ‘Agile-But-Teams’ in services organization. The presentation would cover the following 7 anti-patterns in such teams,

 #1 Fix ‘everything’ in your contract (definitely no breathing space) 

Sign contracts with fixed scope and penalties. Ensure you include at least 30 metrics with fixed targets without accounting for team’s capability.

  #2 Don’t groom your requirements, make them look beardy and scruffy 

 Ensure your product backlog grooming is either not taken seriously or not done until the first day of the sprint.

 #3 Be a salary thief and never change a thing 

Freeze your process steps in the beginning of the project and create checklists that would ensure compliance on a monthly basis. If possible, include mechanisms for tailoring and deviation, but never change the process.

 #4 Be loyal to the law of averages 

Set organizational baselines for Agile teams and measure them periodically. Also, get RCA’s and reasons for missing the organisation targets.

 #5 Trust the pyramid and mummies 

Adhere to the team pyramid structure and give the product responsibility to the identified leads.

 #6 Never Tell, Only Ask 

Never change your product development/testing practices empirically instead implement industry ‘best’ practices based on case studies from other projects.

 #7 Make Self-fulfilling prophecies 

Constantly discuss about, how Agile is not the right model for your project. Ensure your prophecies are fulfilled and there is no redemption whatsoever

 The presentation would also cover the possible antidotes for the scenarios and explain in detail about the behavioral sciences behind such patterns.

Scaling agile practices across thousands of people around the globe is challenging on many dimensions, yet it can be done!

Besides the usual problems with timezones, languages, colocation and cultural friction, what are the key issues that make or break agile at scale?

The answers may surprise you, since they may not be obvious unless you have already been down this path before.  There is surprisingly little literature and precious little practical experience being shared from people who have successfully flipped large organizations to become more agile.