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.