With newer trends in the mobile world, there are plethora of apps that every user downloads on their mobile phone. However not every app is an ‘Instagram’  or ‘Snapchat’. The science behind what appeals to a user vs what doesn’t, has been an emerging field of research. There are multiple aspects when it comes to the question ‘What makes your app successful?’. From the core loop of the product to user experience, there are many parameters that decide the fate of an app.

In this workshop, I would focus on the usability and user experience testing, which helps in product discovery/development. We would discuss briefly about the structure and stages of usability tests. Later we will focus particularly on conducting user tests through hands-on exercises. The session will give you a dip-stick experience into running usability or user tests.

How much do we care about the emotional well-being of our team members?

Do we understand what it means to build a culture infected with love, care and intimacy?  

Most importantly do we care enough to 'take-care' of our employees when we talk about appraisals?

 Here in this proposal I would like to re-visit the fundamentals of giving, receiving and accepting feedback in a safe, secure and healthy environment. I will introduce the classic 'Stroke Economy' model and the injunctions to emphasise the need for building a team which is not 'stroke' deprived. This model could be used for individual/organisation profiling and its an excellent tool for self-introspection.

stroke - A unit of recognition

Having worked with multiple Agile teams, I realize that most problems the teams have to deal with are often related to issues that are beyond the scope of any Agile framework. These issues are often related to people and the surrounding eco-system. The success of any Agile implementation is largely dependent on this H(uman)-factor which is intrinsic to any team/organization. This H-factor has always been a pandora's box, that we would like to avoid owing to  the amount of complexity and the uncertainty involved.

Here is my humble effort to try and identify few common traits that I have observed with people across Agile teams and organizations. The idea here is not to stereotype people, but to present an approach/strategy to accommodate different kinds of people in an Agile eco-system.

The objective of the session is to have some scientific vigour to our people processes and be aware of our current status quo.

Most Agile teams learn the ceremonies and other Agile jargons sooner than we could imagine.They add few meetings to their project execution and talk in a fancy language that would make us believe in Agile utopia. Everything seems fine and happy, until one day their happy bubble bursts and they realize that they are just 'doing' Agile and not 'being' Agile. One primary culprit here is that the teams often neglect their core technical practices and don't challenge their status quo. Which means they don't change anything about the way they design, code or test but just modify their management processes and await a miracle. There are three primary reason why we observe this Agile smell in most teams. It is believed that there are no immediate results in modifying these practices, its is hard to change the existing practice because of umpteen man-made reasons and finally no one knows where to begin their journey.

Here in this talk I would like to address the third challenge and explain how a (non-technical) coach could pair with the team members on their day-to-day activities and help them initiate this journey. The focus of this presentation is on the do's and don'ts while pairing with the team members. It will also explain the benefits of this exercise.

Having worked with multiple Agile teams, I realize that most problems the teams have to deal with are often related to issues that are beyond the scope of any Agile framework. These issues are often related to people and the surrounding eco-system. The success of any Agile implementation is largely dependent on this H(uman)-factor which is intrinsic to any team/organization. This H-factor has always been a pandora's box, that we would like to avoid owing to  the amount of complexity and the uncertainty involved.

Here is my humble effort to try and identify few common traits that I have observed with people across Agile teams and organizations. The idea here is not to stereotype people, but to present an approach/strategy to accommodate different kinds of people in an Agile eco-system.

In this talk, I would like to present 5 characters in a fictional story and the various strategies I have adopted to coach them.

After all one size doesn't fit all!

With the increasing number of Indo-Chinese collaborations in the technology space, it is important for us to identify new paradigms to coach cross-cultural teams. From a simple 'NiHao' to a more complex 'Chop-Sticks', everything comes our way when we coach these teams. It is important for us coaches, to be sensitive to the cultural needs of these teams and re-visit our coaching strategies accordingly. It's true that every team has a flavour and our strategies as coaches are almost always situational. However in this particular talk, I would like to highlight few salient cultural differences which we could harness positively for the team's benefit. I would also like to discuss few tools and practices, which the coaches could adopt while they coach their Chinese counter-parts.

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.

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.

What does it mean by a ‘Self-Organizing team’?  Or it’s just an euphemism for something else? Or even worse-it’s just a fancy term?

This particular entry is a result of my relentless pursuit in search of a ‘Self Organizing’ team. I have always doubted the existence of such mythical teams, however my perseverance made me search for them whatsoever. In this short presentation, I would like to present the experience of my journey and observations on the anatomy of such teams. However reluctant I was, I decided to add some data points to my personal journey to make it more sellable. Fortunately, few of the observations are not very different from the accepted reference points. Hence I would also refer to the group behaviors explained by various psychologists like Sigmund Freud, Eric Berne etc in this short talk.