We are engineers and we know how to write code.

We are QA engineers and we know how to test an application or product.

There are so many roles and so many perspective about the product / application team is building. Everybody is right in their perspective. Then the question is....are we/they missing something?

This session is going to explore the perspective beyond the perspective of an individual in team. We will try to move from individual perspective to a common perspective which is so much critical for each individual. We will talk about the user perspective and how it is important to get the 'out of box' picuture over a 'in side box' picture.

The simplicity of agile frameworks makes many of us believe that agile is simple. However, it’s actually extremely hard to make it working in a non-agile environment. By non-agile environment, I mean organizations which are fundamentally driven by heavy controls and governance; systems which are legacy large, complex & tightly coupled; multiple stakeholders with conflicting priorities and list goes on.  

This paper is share my experiences of one such journey of implementing agile in such non-agile world. It was quite a bumpy ride but in the end, we got a recipe with perfect blend of scrum, XP and Kanban practices – something which was generating visible value and truly in line with agile principles.

When we introduce Agile in any organisation, it gives impression of working in a way which will do wonders to productivity of the teams. But at the time of implementation , lot of problems and challenges pop up , which were never understood at the time when agile implementation is thought of. So what are these problems and challenges and why they are not thought through !

In traditional risk management process, a complete list of potential risks with their priority and a plan to mitigate them is prepared upfront. A lot of time and effort is spent towards these hypothetical risks both in upfront planning and in ongoing monitoring and discussion.

While in Agile, the process is rather emergent in nature. The realization of risk occurs quickly and abruptly. Team gets a sense of it at the earliest possible stage, delay time is less as the risk gets highlighted in the daily stand up, review, retrospectives or release/sprint planning meetings. It is more a real time thing in Agile. But are an application of these Agile practices enough to manage risks in an Agile bound project? Or with little adjustments can the traditional risk management be more powerful with Agile methods?

The session will contain a comparative analysis of risk management in both the methodologies, some real life examples, case studies and how the traditional risk management process can be tailored fit for Agile. It will be a talk cum open discussion session.

a combination of 3 games which demonstrate the importance and efficacy of a self organising small team.

The session also explains the "Law of Diminishing Marginal Productivity" along with other agile concepts.