Emotional intelligence (EQ/EI) by definition is the capacity to be aware of, control, and express one's emotions, and to handle interpersonal relationships judiciously and empathetically. Emotional intelligence is the key to both personal and professional growth.

The world is highly competitive and lot of importance is attached to being highly intellect in order to succeed in professional and student life. But researchers have shown that our success at work or in life depends on Emotional Intelligence 80% and only 20% of intellect.

Studies have shown that people with high EQ perform better at work place, they have strong leadership skills, and are better at mental health. These are the qualities every project manager, execs of organization, individuals aspire for. Intellectual Intelligence on its own is not sufficient to be successful at work or in life.

EQ is often an ignored angle when focusing on building self organizing teams. It is unimaginable how amazing results can be acheived if people focus on EQ. In this session, we will look at why EQ matters in building high performing teams.

Every organization aspire for faster time to market, release of features on demand, reducing the time between concept to cash and better quality of products. Agile has been a popular choice to achieve this objective. While agile was becoming a streamline approach, software industry saw the advent of DevOps. By adopting DevOps practices, organizations were trying to bridge the gap that existed between different groups within the organization, such as business, delivery, QA, Operations, Infra, etc. In spite of adopting agile practices, organizations were not fast enough to respond to changes. And one of the major reasons was the misalignment of purpose and processes withing these groups, hence while features were dev ready but it would still take the same amount of time to release to market as it was before. That's where organizations found the missing piece in DevOps in the entire delivery process.

Everyone started hoping on it without realizing the complexity involved in its adoption. It is now a big buzzword in the industry. DevOps involves bringing changes not just in the delivery but also in the operations. with greenfield projects its a bit easier than doing it with legacy systems because greenfield projects have the opportunity to start from scratch which legacy systems lack.

The purpose of this proposed talk is to share experience of devops implementation on such legacy systems which are complex and not just on its own but a web of multiple systems working together. How scaling devops practices becomes a necessity when working with enterprise applications.

Everyone is creative. Creativity exists in each one of us. It is there to experience in our day to day life, right from how we want to buy vegetables, commute to office to how we can solve that complex customer issue. The quest for finding solutions to our everyday problems stimulates the innovator in us. And there are innumerable examples of this.

Who, What, Why, How are such powerful words that if thought sensitively, we are able to create products/services/processes that can exceed consumer expectations. Delivering an ecstatic experience is a matter of answering these questions, being more creative and sensitive to user behavior. Nobody wants to create a bad experience. If we are failing to deliver a wow experience, then the problem lies with the process or approach taken to understand customer behavior, his/her surrounding, socio/economic fabric, etc. An approach that involves empathy with the user, acknowledgment of the problem and working collaboratively and iteratively backed by technology through the entire process works wonders in designing and developing fit for purpose products/services/processes. New opportunity area or solution to existing problems are the main drivers for innovations. Digital disruption or software driven business mindset is one of the best examples of this.

This case study is about such experience. The case study will cover approach adopted for creating product and the stages involved in designing the product, implementing value generating cycle, encouraging diverse thinking and convergent decision making.

Design Thinking has been a revolutionary approach to build products that help solve users 'REAL' problem. It introduces a whole new approach of thinking towards the needs and problems of users. It challenges a designer's thinking and assumptions made about users behaviour in using a product or service. It is not about designing just another jazzy user interface but an approach to create end user experience that makes them happy and productive using your products and services. 

Thinking about design thinking, while it is mostly endorsed by product development companies, it is a concept which can be applied just anywhere, be it schools, government offices/schemes, social enterprises, public utility services, organization structure, anything and everything that deals with a common person. It is not just another new entrant in the software world, but its a blank and vast canvas that can be used in any difficult situation that needs user-centric solution. 

Agile philosophy puts a lot of emphasis on self-organized teams that can build great quality products and services.  Self-organization is one of the core attributes of agile teams or if I dare to say, is at the heart of agile project management.  Self-organized teams are supposed to be self-contained and have required skills that works towards a shared vision. They don't need directions (read command and control) and can figure out on their how to best deliver results. A lot of literature can be found around self-organization.

In spite of wide knowledge and information around this topic, it would be interesting to know how many organizations have actually managed to create such teams. How many 'Spotify' case studies are around? In my opinion and experience, I think building self-organizing teams is easier said than done. While it’s a very good intent but there are lot of challenges that drags creation of such teams. For creating a mouthwatering dish, just like you will need right ingredients and in right quantity, same goes for creating a self-organized team.  Unless you have all ingredients, such as, management commitment, an individual's willingness & attitude, infrastructure and operations, supporting groups, an organization's culture, etc. in place, it is difficult to have self-organized teams that can run like a well-oiled machine.

In this session, I will share some of my experiences with such teams, their behavior pattern, how such teams can be nurtured, some successful and some not so successful attempts.

Impediments are one of the major hurdles for successful agile adoption and implementation, and more so when scaling to multiple agile teams. While everyone acknowledge that impediments should be raised and resolved in a timely manner, the reality is far from what people say. Time and again, teams have not met their sprint commitments because of improper handling of impediments. It is my experience that organizations and agile teams don't realize the urgency of identifying, highlighting and escalating impediments while they focus a lot on following sprint cadence and other agile practices. Lack of effective management of impediments is one of the silent killers of running successful agile teams.

As designed for use, Scrum works well for small co-located teams, cross functional teams. As the popularity of Scrum starting growing, more and more companies started adopting Scrum with mixed results. But overall, the trend has been increasing. Off late, big enterprises have also started adopting agile for their business needs and building complex products. In a recent study, the number of enterprise customers adopting scrum has doubled in last 2 years and they have used distributed scrum on large programs. So, the question is, can agile scale beyond small and co-located teams and what challenges could be there?

This presentation talks about our experience of implementing scrum on a large program, the challenges of scaling scrum and how to overcome these challenges.

Innovation and faster turnaround of ideas from concept to realization is one of the primary drivers for organizations to stay competative in the market. Risk reduction, cost optimization, faster time to market, managing changing business priorities, focusing on delivering high business value are some of the key considerations for organizations when transitioning to agile. The transition journey will not be very smooth. It needs continous inspection while taking informed decisions as this change can have long term implications on several fronts within the organization. The change could be delicate and hence a well thought approach backed by strong senior management support is very crucial to the success of this journey. Here we propose a 5 stage framework for agile transformation called as ADAPT which also gels very well with the adapt philosophy of agile. The ADAPT acronym stands for Assess, Define, Adopt, Perform and Transform. Each stage is linked to some benefits that that can be derived from that stage.

A distributed Scrum team is a necessity than a choice in many cases. Often customers and their suppliers struggle to put up a team model that will work effectively and provide maximum value. The customer wants to be absolutely sure how the entire engagement will be executed so that there are no surprises later.

So, what are the different ways of forming teams in a distributed environment, what is the impact on the execution, how do you execute different engagement models, what challenges do you see and so on? These are the questions the customers are interested in.

This talk will focus on answering the above questions. We have defined 3 types of distributed team models and implemented in few of the projects in an onshore-offshore scenario. We have also tailored scrum meetings like planning, DSM, etc. so that these meetings are more effective in distributed model. While some of the changes have worked, some still needs to be enhanced further.

The 12 agile principles lay the foundation for a successful agile team and deliver a product that meets customer satisfaction. Every principle is an absolute necessity to build great software and great teams. While these principles have stood the testimony of time over a decade now, much has changed the way we build and deliver software, especially from an offshore perspective. Adoption of agile methods does not simply imply a framework or a process implementation, but it goes beyond that.

In this talk, I share the experience of a Scrum Master, who in hindsight, look at the challenges such as lack of trust, micro management, lack of technical excellence, managing stakeholder’s expectations etc. and the impact on team’s performance. This is the result of ignoring agile values and principles which could have been avoided. Lastly, we look at the actions taken by the team and Scrum Master to turn on the challenges into a win-win situation for both onshore and offshore teams and become one of the successful agile teams.