If you have witnessed enough Agile transformations, you have probably experienced a plateau in the journey; or worse, you have experienced “the great dip”.

Agile Transformations frequently start with a lot of fanfare, see a fast-paced adoption laced with early successes, and then settle into a plateau where we experience little to no improvement OR begin a slow, painful slide into a trough where behaviors start regressing to old ways.

What keeps us stuck on the plateau of change? What might drag us into this great dip?

There are the usual suspects – management has found the next shiny object, coaches and transformation agents only know how to help us get this far, all the easy stuff is done, the frozen middle (management) never really unthawed and so on.

People with a lot of experience in helping with transformations will know to watch out for these and would have developed ways to navigate these obstacles – we know what they look like and we have developed a reliable range of responses to them.

What really blindsides us are the watermelons! Stuff that looks green on the outside but is a dangerous shade of red on the inside. Surprising traits that are superficially positive but can real drag a transformation effort down.

Through this talk I will draw upon my experience of over a decade in Transformation roles to share what these Watermelons are, telltale signs that these are lurking in your system  and ideas to tackle them.

Individuals, their interactions and communication are highly valued in Agile.

These values frequently find application in the form of big visible charts or information radiators.

Yet, in a lot of large, traditional organizations who have started their journey in Agile, the public display of information, uniformly accessible to all, is unsettling.

Through a “scary” analysis of the impact of the lack of transparency, I aim to build a really strong case for more transparency at the workplace.

Product Owners and others responsible for creating and maintaining the Product Backlog often focus on functional items.

With good engagement in the Backlog Management process from the Development Team and Architects, technical and architectural items also find their way into the Product Backlog.

But what about the human-centric items related to accessibility, inclusivity, internationalization and sustainability?

Through the talk and with the help of several supporting examples and a short exercise, I would like to highlight the importance of addressing these aspects in the Product Backlog. The examples will include examples of good and bad backlog items and design decisions.

I will also share some tips on how Product Owners and supporting roles can work these aspects into the Backlog Management process. These will include some ideas from Design Thinking but will not be limited to that.

Change is tough! Big changes are tougher!

As people initiating change as well as people experiencing change, there are some attitudes and stances that will help us ride the wave of change rather than falter and drown.

Some of these, amongst others, that have helped us immensely in our experiences are The Principle of Heliotropism and Ubuntu!

We would love to share our experiences so other can learn from our failures, successes and more.

Expect a lot of anecdotes!

Collaboration spaces, agile floor-plans, open office plans....love it or hate it, you can't ignore it.

From our experience across various companies - some with 6 feet high cubicles walls to some with completely modern collab workspaces - we would like to share what seems to work and what doesn't.

We would also link it to underlying mindsets and cultures and when and why some spaces seem to work better than others.

We would also give examples of very high collaboration in very silo-ed workspaces - and when and why that works!

Change is tough! Big changes are tougher!

As people initiating change as well as people experiencing change, there are some attitudes and stances that will help us ride the wave of change rather than falter and drown.

Some of these, amongst others, that have helped us immensely in our experiences are The Principle of Heliotropism and Ubuntu!

We would love to share our experiences so other can learn from our failures, successes and more.

Expect a lot of anecdotes!

Do we always point all the reasons of failure in transformations to mindset change. Is it our one go to whenever we face a wall or failures and is it true? In this session we will look at what is mindset change, and how sometimes it could be insecurities and territorial dominance.

1. We will talk about a few examples of areas and people where it was thought to be a mindset problem, but how not always that aspect is the key player
2. Ways to identify the problems that seem like mindset - and create a cloud over the actual problem and how it deviates us from solving the real issue, this is why most organizations feel that we cannot make a mindset change
3. What can we do to overcome them to make the change

Presentation of a few real life examples to support the findings

We usually have variety of opinions and suggestions on what and how a coach is expected to do or the kind of people and attitude they need to adopt. Sometimes it is a box, that everyone tries to fit into until you feel you have an identity crisis. In this session we want to look at the myths, the pitfalls and the perceptions that we need to break. Some examples/case studies showing the challenges, the confidence breaks and finally the awakening of a new coach or the burial of an existing one. We would also have a small workshop on identifying your one strength as a coach and how it can be mapped with the needs of the team and leaders – looking within. All of us have that one strength we don’t need to find it in others.

To support the above myths and challenges, we would also share a case study outlining the scenarios for certain situations where coaches have self doubt and how we either overcome it and many times just give up and go back to status quo

What would a dream Agile team look like? A small, collocated, cross-functional, self-organizing feature team?

Not always. There are several considerations that go into forming a team and there is no one-size-fits-all solution.

While the above described team attributes may help us be agile, there may be other conflicting goals which may nudge us in a different direction.

For anyone trying to design and set up a team, it is important to be aware of the many possibilities and the many goals that may influence team configurations.

Through this talk and with the aid of some hands-on exercises, we will aim to throw light on various aspects of team formation and the pros and cons of the choices we make.

Product Owners and others responsible for creating and maintaining the Product Backlog often focus on functional items.

With good engagement in the Backlog Management process from the Development Team and Architects, technical and architectural items also find their way into the Product Backlog.

But what about the human-centric items related to accessibility, inclusivity, internationalization and sustainability?

Through the talk and with the help of several supporting examples and a short exercise, I would like to highlight the importance of addressing these aspects in the Product Backlog. The examples will include examples of good and bad backlog items and design decisions.

I will also share some tips on how Product Owners and supporting roles can work these aspects into the Backlog Management process. These will include some ideas from Design Thinking but will not be limited to that.

Lies, damned lies and Statistics!

(the phrase is frequently attributed to the British Prime Minister Benjamin Disraeli).

Many of us work in environments that value Agility or are at least attempting to be more Agile.

We frequently turn to data, metrics, reports to help us navigate through our complex software environments, to help make sense of what's happening, to support subjective information we see around us and gain insights about the way we work.

But with the myriad of reports and metrics available to us, it is easy to misinterpret, over-analyze, overlook and generally make a big mess of things.

Through this talk, I will present some of the popular Agile reports and metrics and how they can be misread.

I will also share tips of how to counter some of these "lies".

Product Owners and others responsible for creating and maintaining the Product Backlog often focus on functional items.

With good engagement in the Backlog Management process from the Development Team and Architects, technical and architectural items also find their way into the Product Backlog.

But what about the human-centric items related to accessibility, inclusivity, internationalization and sustainability?

Through the talk and with the help of several supporting examples and a short exercise, I would like to highlight the importance of addressing these aspects in the Product Backlog. The examples will include examples of good and bad backlog items and design decisions.

I will also share some tips on how Product Owners and supporting roles can work these aspects into the Backlog Management process. These will include some ideas from Design Thinking but will not be limited to that.

As organizations start their Agile journey, very soon the question of “What’s to become of the Managers?” comes up.

Yesterday’s heroes and firefighters find themselves without a clear space or role.

But surely there is a better way of handling these managers and the expertise and experience that they bring with them.

Our managers can be re-imagined and flourish as mentors, as experts, as change agents.

We would like to share the new avatar that our erstwhile managers can adopt in the new world while continuing with some of their existing responsibilities.

Also a few tips and tricks to make managers our allies in the quest for Agility.

For large enterprises starting their Agile journey, the first step towards Agility is Transparency - the foundation for building a high-trust environment.

Yet, in a lot of large, traditional organizations, the public display of information, uniformly accessible to all, is unsettling.

Through a “scary” analysis of the impact of the lack of transparency, we aim to build a really strong case for why Transparency is the new Green! 

To make the leap into Transparency easy, we will also share some tools which have come in handy and worked beautifully for us.

Our pursuit of transparency is dotted with failed attempts – we would love to share those so that others can make fresh mistakes and not repeat our mistakes.

As organizations start their Agile journey, very soon the question of “What’s to become of the Managers?” comes up.

Yesterday’s heroes and firefighters find themselves without a clear space or role.

But surely there is a better way of handling these managers and the expertise and experience that they bring with them.

Our managers can be re-imagined and flourish as mentors, as experts, as change agents.

We would like to share some of the new roles and responsibilities that our erstwhile managers can adopt in the new world.

Also a few tips and tricks to make managers our allies in the quest for Agility.

For large enterprises starting their Agile journey, the first step towards Agility is Transparency.

Yet, in a lot of large, traditional organizations, the public display of information, uniformly accessible to all, is unsettling.

Through a “scary” analysis of the impact of the lack of transparency, we aim to build a really strong case for why Transparency is the new Green!

To make the leap into Transparency easy, we will also share some tools which have come in handy and worked beautifully for us.

Our pursuit of transparency is dotted with failed attempts – we would love to share those so that others can make fresh mistakes and not repeat our mistakes.

Imagine ... that you had a personal coach who has your best interests in mind, helps you discover your strengths and weaknesses, helps you identify your next steps, celebrates your wins with you along the way, helps you learn from your experiences and is with you every step of the way.

Imagine ... that this is how you manage your career!

We would like to share with you our "Inspect and Adapt" Career Development model and a real-life case study of the model in action.

About two years ago, we embarked on our journey towards Agility and Kanban was our vehicle.

But Kanban had people worried.

How can we not have detailed plans?! How can we limit WIP when we have so many things to work on?!

We have due dates to meet! And so on.

We would like to share one of the approaches that we adopted to help move the change along.

In addition to focusing on the Kanban implementation at the project levels, we adopted another route – to work through the individuals and the teams – a grounds up approach. We encouraged people and teams to use Kanban boards to manage their daily tasks.

You have difficulty in managing personal stuff? We’ll help you manage better!

You have issues in managing team level priority? Look what we did within our team- we have a Team Kanban and we are now much better organized!

One by one we saw people getting interested. The movement gathered steam - we worked directly with a handful of people and they in turn got their peers onboard. And we saw various flavors like Personal Kanban, Team Kanban cropping up all over the place – even in our Travel Office and Corporate Office. What this did was give people a safe, controlled environment to experiment and learn in.

As they got used to the ideas of limiting WIP, pulling work, visualizing work and “stop starting, start finishing”, it gave them the confidence to work this way at the project level too. And it made our lives as change agents just a wee-bit easier!

We welcome you to come hear our story about nurturing the change towards Agility by making it a grass roots movement.

A brief introduction to Amdocs - Amdocs is a leading provider of Customer Experience systems and services in the telecommunications domain, typically doing large scale transformation projects.

Our talk will focus on the evolution of the Agile implementation in Amdocs.

While Kanban is widely implemented in the Amdocs Delivery unit, recently we have started experimenting with Scrum in pockets.

Taking it a step further, not wanting to lose out on our learning from Kanban, we are trying ScrumBan in a large scale project.

We will share the approach, the challenges and what we have adopted from Scrum and Kanban in this implementation.

A brief introduction to Amdocs - Amdocs is a leading provider of Customer Experience systems and services in the telecommunications domain, typically doing large scale transformation projects.