With business agility the new watchword in senior management circles, more and more enterprises are looking for ways to adopt ‘agile’ into their technology practices. However, such an initiative needs to go beyond the mere adoption of agile in a few projects. To successfully implement enterprise IT agility, organizations need to understand the impact of agile across functions and groups, develop frameworks to sustain agile, empower teams across the board to work in an agile fashion, and invest in the right infrastructure. A strategic roadmap based on these considerations can help organizations infuse agile into their practices, processes and systems, thereby achieving true benefits of agile – faster returns, better quality and quicker time-to-market.

This session  discusses the critical factors for an effective roadmap to implementing enterprise IT agility. It also outlines how these factors contribute to a successful enterprise IT agility strategy.

This is a workshop to introduce the concept of Value and cost based prioritization. The speaker will facilitate a short game for participants to learn how to prioritize the backlong using value and cost. 

Agile Product development with Scrum is based on completing a set of User Stories within a time-box called a sprint. Stories describing user functionality. Conversatin with customer is the means of elaborating requirement. looks simple, right?

Only User Stories are enough for product development? If not, what all other documents are necessary and how these are progressively elaborated? 

What's required before agile team start sprinting? What are the challenges while transitioning from waterfall to agile related to product requirement?

What's the role of Business Analyst in agile? BA moving into an agile team, moving to Product Owner? Can Business Analyst and Product Owner co-exist?

In this session, we discuss about the few facilitation techniques that a servant leader need to have to promote self-organization.

We also focus on Evolution of an Agile team, the traits of an agile leader and various of pit falls that do not lead to self organization.

How do you really make a team being controlled by a manager to become self- coordinating team?

We also look at key behaviours that helps changes stick.

What came first - Lean or Agile? It's a chicken-and-egg question for many. And then, there are beliefs that these two are separated twins.

If you think that Lean software development and Agile are the same, think again!

There are both difference and similarities in the Lean and Agile principles and practices.

During this talk, we will discuss on how Agile and Lean are related or different. Or are they two different names of the same thing? how the principles of Lean and Agile can be leveraged in order to create complex software solutions at enterprise level.

Why do we need team agreements?

Scrum teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team. To become self-organized, a team has to go through various stages of team development.

Tuckman's stages of team development The "forming, storming, norming, performing" model of team development was first proposed by Bruce Tuckman in 1965. He maintained that these phases are all necessary and inevitable in order for a team to grow, to face up to challenges, to tackle problems, to find solutions, to plan work, and to deliver results.

A Scrum team does not have the luxury to be in each of these stages for much time, as it is expected to deliver right from the first sprint. Thus the need for formulating team agreements arises at an early stage. Sprint Zero is the ideal time for a Scrum team to go through all of these stages within a very short period. As Scrum is iterative and incremental, a Scrum team goes through Tuckman's stages in each sprint and improves its performance in every new sprint.

Knowing what kind team agreement a Scrum team might need is useful for the team members. It helps avoid conflicts. This knowledge can help them set the team agreements in advance during Sprint Zero rather than deciding what should be done at the last moment, in the middle of working sprints. Team agreements can be defined and agreed upon in a meeting facilitated by the ScrumMaster. Various steps that can performed in this meeting are: prepare, brainstorm, sort, categorize, agree, and refine

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.