Is the scaling framework your organization is on helping you to Be Agile or pretend to be Agile? How about drafting one that stays true to Agile principles and helps with what your organization needs most while scaling?

While there are many frameworks available to scale Agile it is important to discern if these prescriptions address the real problems that an organization encounters while scaling up.  Does one size fits all? Is it worth adopting a framework and then retrofitting the organization into it or it is a better proposition to understand the dynamics of the organization, the existing challenges and business objectives first and then carve out a scaling approach, keeping Agile principles intact, that suits the organization's needs best.

This interactive workshop is about discovering the best approach to create your own scaling framework, one that is custom made to respond to your organization’s needs. 

Is the scaling framework your organization is on helping you to be Agile or pretend to be Agile? How about drafting one that stays true to Agile principles and helps with what your organization needs most while scaling

While there are a many frameworks available to scale Agile it is important to see if these prescriptions address the real problems that an organization have while scaling up.  Does one size fits all? Is it worth adopting a framework and then retrofitting your organization into it or it makes more sense to understand the dynamics of your organization, the existing challenges and business objectives and carve out a scaling approach, keeping Agile principles intact, that suits the organizations needs best.

This interactive workshop is about discovering the best approach to create your own scaling framework, one that is custom made to respond to your organization’s needs. 

One of the biggest challenges in achieving agility is the way contracts are written. More often than not, these contracts prove to be a deterrent to realize the ultimate benefits of Agile. The way contracts have done traditionally usually go well with the traditional way of building software where scope / time / cost are fixed. However when the focus is on delivering business value early to the customer for his competitive advantage, to reduce risk, cost by not building what is not needed, gain and retain users, traditional contracting does not help the cause. Agile is something that the entire organization has to embrace. It has to start with the sales team. It has to reflect in the contract. It has to start with the right mindset. It has to start with an Agile contract.

Third value of Agile manifesto is Customer collaboration over contract negotiation. Not only should this collaboration be expressed during project development, it should be expressed in the contract language as well.

In this talk + workshop session, I will be sharing various types of contracts that can be leveraged / customized for an Agile project, some good practices surrounding them and will be involving the participants into a small workshop of writing Statement Of Work (SOW) for Agile contracts related to a few real world scenarios.

Principles behind traditional performance management system are utterly opposite to that of Agile. While traditional one focuses on Individual ratings, surprises, one sided evaluation, Agile is built on the foundation of trust, transparency, respect and courage. Whole is greater than sum of its parts and individual ratings and outdated performance management processes may prove to defeat the bigger purpose. While aspiring for Agility both at team and organization level, it is important to ensure all the wheels are moving in tandem in the same direction. Technology has changed the way our people engage, work and communicate and the need for frequent and less formal points of progress reviews is in demand.

Agile performance management is an attempt to plug the hole by providing an approach that compliments Agile values and proves to be a catalyst than detractor for a high performing team and organization.

In our Agile journey, while it is great we focus on mastering various Agile practices, understanding Agile principles and internalizing Agile values at times small yet an  important aspect like Visualization does not get the required attention.   

My presentation will be about various Visualization examples for teams to improve collaboration and communication.  It is going to be an interactive session stuffed with a lot of discussions around the various practical Visualization techniques an Agile coach / Scrum Master / Agile team member should have in his toolbox.

These techniques enable communication and aid knowledge sharing by making information visible to the team members. There is no prescription but the suggestions that one can experiment, evaluate and evolve as per team's need.

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.

-The Sprint Planning meeting is just too long and never finishes on time.

-I finished my tasks on time, the story couldn’t be completed as there was a dependency on him. I just didn’t have time to follow it up. Not my fault.

-Yet again, there are left over items in the sprint. We couldn’t finish all the committed stories as some of them were too complex for their correct effort complexity estimation.

-Ohh Gosh, once again the priority of the tasks have changed in the middle of the sprint, there are new urgent items that have to be done. My sprint commitments have gone for a toss.

-We moved to Agile from waterfall and it has been few sprints into it, though even here vision is unclear, requirements are evolving and our sprint commitments are failing. Velocity is just been a number, Burn down graphs conclude nothing concrete and useful.

-How do we cater support/maintenance work with Scrum?

Does any of the above statement sound familiar to you, if yes probably it is the time to evolve and adopt KanScrumBan wrapped around XP practices.

KanScrumBan is the combination of Kanban and Scrum and uses the best features of both. While Scrum framework helps the software development teams to self-organize, collaborate, improve efficiency constantly, work in small iterations, and avoid management overhead, applying lean methods like Kanban , flavored with XP practices can extend these benefits.