Since its founding, Google has created six products that each have at least a billion monthly users. Google continues to innovate rapidly, and in many new areas. The organizing principles and cultural elements that drive this monster of innovation are a hot topic among designers. So what are they? Find out in this engaging talk by Google’s Chief Evangelist, Brand Marketing.

The digitalization calls for rapid organizational flexibility and adaptability. This has an impact on all dimensions of a company: its strategy, structure, and the processes. Agile will help implementing some of this flexibility and adaptability yet mainly in terms of processes. Thus, the digital transformation needs companies to change beyond Agile. Beyond Budgeting, Open Space, and Sociocracy provide the missing links for a company to fully embrace digitalization. The combination of these concepts enables a company not only to survive but also to thrive (digital) disruptions.

You have tried Scrum, Kanban, XP, Crystal and other even less known frameworks and methods that claim to help you to become Agile. You have applied them pure, you have tried to tweak them, and even you have made some homemade cocktails out of them. So yet you still can't say your company is Agile. Your Cxx-s are willing to change the company, and themselves. Your employees on all levels genuinely want to step into the Agile journey. Yet there is nearly no progress toward a real organizational agility.

What is the secret? Why is it so hard? Why there are so many crashes on this way in our industry? Why most of the companies will still fail to become Agile, and yours will most probably too.

I'm going to answer all these questions during this talk. We will figure out what aspects of a large-scale agile transformation have a mission-critical impact and how they influence each other. Where to put your efforts? How to cut corners? And moreover, how to survive on this journey.

First came agile, then came DevOps and Continuous Delivery, now comes Continuous Testing. Managing the balance between speed and quality is a difficult decision for many organizations. In this new reality of rapid releases, incremental changes, and short QA cycles, testing is becoming a bottleneck. The adoption of DevOps has brought this more into the forefront as testers find their place in this emerging area. Continuous Testing is a major opportunity for QA leaders to redefine the strategic role in the organization, specifically as drivers of quality within Continuous Delivery.

We will have an overview of the upcoming challenges that you will face as QA leaders and how Continuous Testing will bring you through these changes on top. We will discuss real time experiences as a tester bringing quality into the DevOps process, with key strategies used to ensure quality is infused in every step of your process. Also we would discuss about the different cases where CI, CT & CD are in practice.

Session name - Outcome based agile coaching

We all want to become good agile coach. But what does that mean? How do you get better outcome from your agile coaching sessions? In this session, participants will experience how to improve outcome of your coaching session. Some areas we will focus in this session are output Vs outcome, why, what, how of coaching, how to make coaching outcome etc.

This will be a hands on workshop with very minimal guidance from facilitator. Participants will have experiential learning through the activities to understand how to align agile coaching to deliver maximum impact on business outcome.

The benefits of a high performing team are endless. They are autonomous, empowered, responsible and effective.

At Atlassian, we've pioneered the Team Playbook, which is our way of scaling teams by getting smarter, not bigger, and driving a culture of continual improvement. Utilised by hundreds of teams within Atlassian, we've made our secret sauce not so secret. Don't come to this session for a lesson on theory...come to this session to hear the philosophies and principles of the Team Playbook from Peter Scobie, Program Manager/Team Doctor. You'll leave this session invigorated, engaged and ready to take action.

T-shirt sizing. Fruit Sizing. Planning pokers. You might be familiar with any or all of these estimation (relative sizing) techniques. Story points based estimations (along with velocity mapping) is touted as a predictable method to plan for software delivery. Teams are expected to get a good sense of the effort needed to deliver a piece of work by comparing estimates with references of similarly complex work they have delivered in the past.

The accuracy of point based estimates fares more or less in the same range as sheer gut feel. So, the natural inclination for software teams is to try and make it more accurate than gut feel. Thereby, we obsess with breaking functionality into smaller byte sized stories. We freak out when there is "scope creep". We debate endlessly about ideal days vs. person days. We fuss over the specific visual representation for the burn-up or burn-down.

Does it matter anymore how many days the team spent chipping hard at a feature that added no value to the business? Have we made agile teams into mini waterfall teams by focussing on the wrong metrics? Can product companies afford this?

Process heaviness in product companies can cost a lot. We need to find better ways to invest in success metrics. We need to change the conversation from productivity to value add.

My talk intends to challenge prevalent estimation practices and contest their validity in product companies. I will also introduce ideas around capturing relevant business metrics and sizing stories using business value.

In Software Development, Agile is a way of developing code. It is essentially an unspoken promise of new functions, fixed bugs, automated tests etc delivered in a short period of time. Agile has became the reference approach for modern product development in the last few decades. However, we still see a lot of misinterpretation and abuse of its core values. This is so common and I would like to call this unwanted byproduct as fragile. If you don’t handle it with care, it is sure to shatter your product and loudly crash your entire team.Companies worldwide have faced many issues adopting Agile, a lot of the struggles and challenges are shared across different regions.

As organizations embark on agile transformation, many traditional project managers or business and technical leads are thrown into the Scrum Master/Product Owner role after reading a book or two and, perhaps a few days of training. In the midst of changing environments, conflicting mindsets, and other change-related issues, they are expected to start operating within a Scrum team. The main problem I see these days with agile methodologies is that it has become a branding term, many organizations want to "do agile" not because they appreciate or even understand the benefits of doing so, but just because they want to get a sticker that says I'm Agile. You bring a team together, give them some work, and yet they don't meet the organization's or manager's expectations. At the end they fail to jell, fail to perform and fail to deliver.

Why do so many organizations struggle to put in place mature Agile teams that can apply proper Agile principles and deliver awesome products? Some people will say, “Agile is hard” as an excuse to not do Agile or to become frAgile. Here we shall discuss the secrets to reboot any Agile team. Let's discuss why this happens and how we can overcome these to bring in a new cultural shift which will boost the team productivity ?

This talk consist of a series of stories that hopefully can illustrate a different approach of implementing change in the right way. We shall also analyse if what you think of agile is exactly what it is or else what tweak you need to bring in to make it work for you.

Everything we do we believe in our startup founders and their new vision of the world. The way we show this belief is by joining them on the journey of challenging every assumption we know, making a difference for one individual person and always being focused on user, no matter the cost. Let me share with you my stories of how to build products by shifting the focus from scalable, technical solutions to addressing single user needs and challenges first. How to impact culture and inspire a distributed, rapidly growing company and how to collaborate and treat your customers and your colleagues like “you believe in what they believe”.

Everything we do starts with WHY and a single user need.

The session is for anyone who in their daily job needs a helping hand, a bit of inspiration and a useful set of practical experiments to challenge status quo, move the needle in their organisation and build delightful products that people really want. I also want to show they they are not alone in their failures and defeats. The lessons will apply to executives changing organisations, scrum masters coaching the teams and product owners wanting to build delightful products

For me this new talk is about constantly evolving set of ideas, thoughts and values that always puts the user first and allows our employees and founders to have the time of our life.

I had a great pleasure to speak at SUGSA 2017, the biggest Scrum Gathering in Africa, where i presented this talk and I want to share our story and challenge “we have always done it that way!” point of view.

My objective is to shift the way you think about your current situation, your team, your organisation and your customers by refocusing you on user needs and always starting with “WHY?”. I am going to show you how to apply design thinking, theory of constraints and cynefin framework to situations in your daily job and see how they could be improved. This talk is about sharing what worked in our context and what made all the difference to our products delivery.

I have been working as a Scrum Master with a team for a few months. In one of the releases we encountered a bug in our production release. Technically it was a small check missing, but when the team started discussing it then everybody was pointing at other team members as a source of issue. No one was willing to accept responsibility or creatively consider what went wrong and how to stop this from happening again. It was all about finding someone to blame. This situation changed my focus to explore the aspects of teamwork from the perspective of blame and to look into best possible ways to build a team that never use blame to find out solutions to team challenges.

I will try to share a few examples of how our organisation with #noblame culture tries to behave in moments of crisis and how we never considered blame to be an option or a solution.

I am also very confident that this problem is present in more than just our organisation and it impacts our ability to deliver great value to our customers and build great teams.

As we all know our agile teams should be accountable to each other first but i believe many teams and Scrum Masters often confuse accountability with blame. There is usually an underlying set of issues with people using blame as a solution to their problems. For one it feels good, not to be responsible for team problems. Usually there could be a deeper reasons why a person would play a blame game. Those reason vary from unhappy either in personal or professional life or trying to protect herself due to insecurity. Also in modern society people are so much stressed and obsessed with their desire to be successful they feel happy by blaming others they remove spotlight and pressure from themselves. All those behaviours are very dangerous and impact the team ability to deliver value to users.

During the session we will discuss how we try to create no blame culture, what we do and how you can apply those lessons in your context. I will share some practical examples, theory to back them up and aspects that worked for us. I will also share some failures and mistakes we made on our way.

Business agility is all about getting results out in an agile pace. Self organized teams would seem like an answer here.

An honest look into why self organization is a buzz word now. Why is it so important, why are companies shifting gears now. Is something terribly wrong with the normal top-down organizations?

Takeaways:

1. An answer to an important question - Do you need this shift?
2. The bare necessities to get you started towards self organization
3. How you should kill the boss in you
4. From coding to finalizing a new office space

The Organization have rules, standards, and procedures on how work is done and should have the control to delegate and prioritize the work assigned, this was what I was told and programmed few years back in the traditional organizational structure I was working for. Still, there we were asked to percolate Self–Organizing behavior in our teams, and that to under a fully constrained and micro-controlled environment. And what we use to get a few responsible individuals organizing tasks in a way to make their managers happy but never a team who can perform together.

Whereas, it is well understood that trained responsible individuals are the core of any Self-Organized team and who take responsibility to manage their own tasks and don’t rely on a manger to tell them what to do. At uCreate I am following Agile setup that is propagating a self-organizing team and implementing Agile manifesto: “The best architectures, requirements, and designs emerge from self-organising teams”

Scrum team’s job is to self-organize around the challenges, and within the boundaries and constraints, put in place by management. In Self-Organizing Scrum team each member is responsible for determining what work he or she will be doing.

Now, creating a self-organizing team is a continuous challenge in today's dynamic world, where the focus of building a team can get sidelined due to changing business demands. Another uphill task is whose real duty is to create a Self-Organizing, is it the management, or Scrum Master or Scrum team itself.

So my today’s session is to discuss with you on how we can continuously pursue towards getting a Self Organizing team since this a continuous process like an organism grows towards maturity.

We at uCreate are also facing this challenge to change the mindset of individuals who were used to traditional approach and mentoring them or training them or coaching them to be responsible individuals in order to have real Scrum Teams delivering agility on its own.

There have been various ways it’s been practiced at ucreate but major two focus strategies are:

1. Review Tool.
2. Spare Time for Learning.

The above methods have sure imbibed responsible behaviour in our Scrum Teams but the lot has to be improvised to get responsible Self-Organizing Scrum teams.

Today’s agenda will be elaborating on above methods and also on few examples on how real-time facilitation is all about being a Scrum Master, rather than using command & control and what can be done to instil self-organizing culture among the Scrum Team members.

So, Creating a self-organizing team in Agile is not an easy task and takes a reasonable amount of time to form. ucreate has been adding deleting ingredients to help fast-track the formation of such self-organizing Agile teams but still a lot to be achieved in this regard. What as a team we learnt is that process of forming Self-organizing teams is that we should develop individuals who are

• Responsible
• Trained and Competent
• Motivated
• Respect talent and individuality
• Goal oriented

An organism grows from infancy to maturity and then delivers results but the process of development is long and learning all the way similarly Self-Organizing Scrum team is a long and continuous process. The Scrum Master should dwell on creating a team which can buy-in and share ownership, Motivation, which leads to an enhanced performance level of the team and Facilitate innovative and creative environment conducive to growth.

A few weeks ago i took part in an agile meetup where i met managers and leader from other organisations discussing their need to transition into Agile way of working. They came to the conference to learn a little bit more about “Agile”, but they’d already made the decision to adopt it. They shared their assumptions that the transition will be relatively smooth and they were expecting the increase in team performance almost immediately. They expected Agile to be all about being cheaper and faster. As much as in principle agile want to be faster to market with value to users and cheaper in not doing the wrong things, at the same time the journey requires the whole organisation to change its values, behaviours, investing in people and trusting them. Those activities are rarely cheap and fast. The benefits are 100% worth it but the journey is not as easy as a day of scrum master training and changing of mindset based on motivation talk by organisation leader.

As a Scrum Master, I’m getting really tired of talking to managers and teams whose sole drive to adopt agile is due to cheaper and faster delivery. Ignoring all other aspects of agility cause the organisations to not really see the benefits of transformation and also neglect crucial aspect of any change: people.

It's hard for me to accept this way of thinking. During our sessions I will try to explain short and long term agile goals and try to establish the expectations of any agile change. I will be fair and honest and present much more real transformation model, so that everyone can understand why certain things work and others don't. I will also address aspects of speed of delivery based on our experiences at ucreate and consider the “cheapness” of agile based on daily decisions we make. I hope after this session it will be much easier for You to understand where you are in your agile journey and enable you to be able to explain reasonably what is going wrong within your team and organisation.

In this talk i will present biases about agility and agile methodologies when it comes what can be expected and how long does it really take to achieve expected results.

We will consider multiple aspects of agile software development and look at it from different perspectives. Quality engineers with their focus on Quality Software, DevOps and developers with Continual Refactoring and Continuous delivery and whole team ability to pay down technical debt. We will always look at benefits of those activities vs the speed and cost applied to them. We will honestly judge multiple agile activities vs value they really deliver. My hypothesis is that Agile can actually be slower to deliver individual features but we should always consider long term view of the project.

In this session you will learn how to start and explain agile to your team members and management team. You will learn practical knowledge how to manage expectations of any agile transformation and show the real value of organisation agility. You will discover benefits of agile and XP practices and how they measure against the metric of speed and cost. You will never consider agile as fast and cheap again but you will understand the value it delivers to organisations, users and team members.