Customer collaboration is essential to every Agile business. To create and collaborate to keep a customer is the purpose of an organisation. But still lots of companies try to make bad profits, i.e. profits earned at the expense of customer relationships. The Net Promoter System (NPS) is a renowned open-source system which addresses and measures customer collaboration. And did you know that you not only can use it to get feedback on your products and services, but also on your employees and your personal performance?

NPS is a perfect fit for Agile companies - and those who want to be. Most of the companies I worked with (Agile coaching, training, consulting) had not heard about it, and far less were actually using it. This really surprises me, since NPS integrates like a charm with Agile, e.g. within product development via Scrum.

In this session I'll explain the basics of NPS, i.e. promoters and detractors, satisfied and delighted customers, bad profits (how to deal with bad feedback?) and good profits, and why and how to measure these. Several stories from companies like Apple Retail, Zappos, Southwest Airlines, and others will help to make my point. I’ll further show why NPS is a very good fit with Agile regarding products, employees, and personal performance. Dos and Don’ts regarding NPS (also from personal experience) will close this session. Related to the Don'ts, I also cover some of the negative critiques out there.

I love being around awesome people, who build great products customers desire. 
I love learning from and together with these amazing minds. 
I love creating the right environment for teams to flourish. 
I love change, and learning from new experiences. 
I love working in Agile environments.

How about you? 
I bet there are some elements of this list why you're in Agile, too. And you can probably add even more elements to it.

The Agile Manifesto states amongst others individuals and interactions, customer collaboration and responding to change.

In our everyday life doing Agile we already respect these aspects in many ways. 
But do we practice what we preach as best we can?

I'd like to challenge your current way of thinking about people and processes. 
I'd like to challenge you to focus on you, before you focus on others. 
I'd like to challenge your current way of reflecting. 
I'd like to inspire you to go different ways. 
I'd like to inspire you to inspire others.

In Agile we're already good in improving our processes and creating well performing teams and hence building the right things in the right way. And in the Agile Manifesto's communication and collaboration piece we can even get better.
"You have not yet reached the limit of what you're capable of!" means we can always further improve. And we do follow this idea in our Agile processes, too, through continuous feedback (Retrospectives) and improvement.

And why not take it even further? Why not go "Beyond Agile"?!

Here's where aspects of Life Coaching come in handy: through also understanding and improving ourselves (how do we interact with people due to how we perceive our environment) we will even further improve communication and collaboration.

Life Coaches believe our clients know the answer. And even if Agile Coaching is slightly different than Life Coaching, I see it as very relevant in Agile Coaching, too. If we apply this in Agile, instead of giving our clients (team, colleagues) the answers, asking them powerful questions to help them be more aware of what's happening at the moment, they will find their answer for it and will have a much better commitment to making the change for themselves, their teams and the company. It's not for us to TELL them what to do, but to ASK them what's going on for themselves. Here's where I see a huge chance for improvement.

In my session I give lots of examples on how to link Life Coaching ideas to our Agile work environments. I've given the session at LAST Conference Melbourne and at the Agile Coaching Circles Meetup Melbourne. The audience was engaged and the attendees were very happy about having some new ideas on how to improve their daily work life.

Come along to be inspired by Life Coaching and thus to benefit our Agile Thinking!

In the software world we have been looking for “The Methodology” to solve our software development sorrows for quite a while. We started with Waterfall, then Spiral, Evo, RUP and, more recently with XP, Scrum, Kanban, DAD, SAFe (there are many others, but, their impact, so far, has been limited).

In this tutorial, I'll show why this search for the holy grail is bound to fail--each methodology has strenghts and weaknesses that make it suitable only in some contexts--and I'll describe a different approach based on patterns and pattern languages, that teams can use to create their own methodologies to suit their specific needs, which, in my experience, has a higher chance of success. 

The approach is based on the observation that all the practices used in all modern methodologies--e.g., user stories, use cases, team self organization, TDD, unit testing, acceptance testing, continuous integration, iterative and incremental development, etc.--come from the same set. Different methodologies just mix and match them differently. All those practices can (and many have already been) described as patterns whose relationships with each other form a set of pattern languages.

"Release Early, Release Often" is a proven mantra and many companies have taken this one step further by releasing products to real users with every commit a.k.a Continuous Deployment (CD).

Over the years, I've built many web/infrastructure products, where we've effectively practiced CD. However at Edventure Labs, when we started building iPad games, we realized there was no easy was to practice CD, esp. given the fact that Apple review takes a few days.

Our main question was: As mobile app developers, how should we architect/design our apps for CD?

We were a young startup, learning new behavior about our users (kids aged 5-8) everyday. We could not afford any delay in releasing latest, greatest features to our users. To solve this problem, I believe we've built an innovative solution to enable any mobile app developer to achieve CD.

If you are building real products, which have platform/3rd-party dependencies and you want to practice CD, this session is for you.

Traditional models of management and corporate governance are failing to keep up with the needs of the modern economy. Change, both technological and cultural, is occurring at faster rates than ever before. In this climate, modern enterprises will live or die on their ability to adapt. This is where Agile, and Agile Business Management, come in. Agile is change; changing how you think, changing how you work and changing the way you interact. This is important whether you are a software developer or a CEO.

In this presentation, Evan will provide engaging and enlightening case studies of Agile beyond IT; from lean startups to large enterprises. These will be reinforced with practical approaches for the leadership of teams, divisions and businesses. 

Taking the successful concepts and methods from the Agile movement and Evan's new book, Agile Business Management is a framework for the day-to-day management of organisations regardless of industry, size or location. We will discuss processes, techniques, and case studies for the 4 key domains from Agile Business Management;

1. You, the Agile Manager - What makes a good manager and how do their responsibilities change?
2. Integrated Customer Engagement - Collaboration and communication techniques to build trust and deliver Customer needs efficiently, with minimal waste, and to everyone's satisfaction.
3. The Structure of an Agile Organisation - Efficient, transparent and collaborative techniques to manage empowered staff.
4. Work, the Agile Way - Managing all types of business functions, from software, HR, finance to legal, by using Just-In-Time planning and Incremental or Continuous Delivery processes.

Ultimately, the goal of this presentation is to make you think about your role as a leader. 

On Agile projects we estimate user stories in order to allow team to

1. 1. Track velocity
2. 2. Decide scope for the Iteration
3. 3. Help Prioritize stories
4. 4. Help Release planning

But most of the time we faced issues with estimation. It takes lot of time in estimating user stories, managers tend to relate estimate to number of days it will take to complete the story, in some teams estimate is equal to deadline. Most of the teams which use story points to estimate the work face these issues. This results in lack of confidence on development team when stories are taking more time to complete.

Here I am going to talk about better alternative for both the suppliers of software products (financially and ethically) and their customers (internal and external). This alternative is being used in real companies delivering to real customers with great effect where team uses count of stories completed in an Iteration as measure of progress. Will talk about how this alternative can be used to track velocity, prioritize stories, planning Iteration and for release planning.

I will share some exmples from my past projects where team did not use story points/velocty but used count of stories completed in Iteration to measure progress and also as best indicator of future performance.

Other talks and games will teach you how to run a successful Agile project. Only this one will teach you how to ruin an Agile project*. In this game we will break every Agile rule, disregard the manifesto and ignore common sense in the singular pursuit of failure (and fun).

Each of you will be part of an Agile team with a dis-engaged Customer and micro-managing boss. Being Agile, there will be daily stand-ups, planning sessions, retrospectives, and kanban boards but nothing will go as you expect.

* More importantly, this activity will teach you "how" Agile projects can fail and the reason behind many common Agile practices.

We (at Nokia Maps Division) began our Agile Journey in 2009, with a Top Down approach for Agile Transformation. The formation of an Agile Working Group (with members having Agile experience behind them) at two major sites was instrumental in shaping the transformation and scaling and also overcoming the challenges from time to time.

The challenges were huge, but our spirit was bigger, and the high level strategy was decided. Interestingly, the Agile Working Group itself ran the whole Transformation and Scaling program using Agile values and Scrum frame work. Scrum was also used as the preferred framework for the agile projects (after success in our pilots), except where Scrum would not work. Kanban or hybrid methods were used in those few teams.

What were the challenges faced, and how did we overcome them? What values helped us in our transformation journey?

How did we migrate to the Scaling phase? What helped us in scaling and stabilizing?

Can we rest easy now? Of course not!

What are the next steps? And of course, the challenges ahead?

Let us share our Nokia Agile journey with you, and help you all be successful too, in your Agile journey!

Willpower is the force that is between the brain activity (I want to do this or I need to do this) and the action itself (start coding). If there is not enough willpower, people find it difficult to start any activity (especially that involves
decision making).

What is the standard approach when you feel tired and find it difficult to concentrate? Take some coffee (but latest research shows that coffee depletes the brain activity, even when body has more energy), take some sweets (but sugar ends quickly and gives even more exhaustion to the body)? These widely used strategies generally do not work, and in long-term even add harm to the body and brain.

The willpower is not endless (so-called muscle theory of willpower), it can be saved, it can be trained, there are approaches how to keep the willpower level high. To keep the willpower (and thus, productivity) on the high level, people should know and use different approaches that lay in the field on the social and cognitive science.

There are a lot of evidences that SCRUM improves the developer’s productivity in terms of speed of development, code quality, and accuracy of design. Unfortunately mainly all recommendations from SCRUM coaches look like “believe me, if you do this, you will have better velocity”. Yes, it works. But why does it work?

Sometimes SCRUM does not give such great results even when main elements are in place. The question “Why” and “What makes the difference” is here again.

I will describe the model of relationship between the willpower related brain metabolism on very low level (specific amino acid cycle) and the SCRUM practices. I can prove that SCRUM addresses the productivity of the people’s brain using 3 different flows simultaneously. There are several tips that make these productivity flows working or not. You can make Agile productive, you can have non-productive Agile. I will show you where the difference is.

Overall there are 10 productivity tips that can be put into 3 flows.

As the outcome of this session, Agile coaches, and all people who can change the process (in fact that is any team member) will review their SCRUM: does the way they have it improve the productivity or they are losing all the power? The changes are cheap, the outcome can be huge.

In lot of agile teams, often times, all the team members will be doing the grooming and planning exercise as a team. Often times, defining the behaviors is either ignored, overlooked, skimped or done by individuals on their own without a common understanding as a team.

To solve this problem, I have used this hands-on time-boxed activity for all of my teams to define behaviors as they move along in the sprint. This will help all the team members to have a shared understanding on their users and their behaviors as it relates to their user story. This is an activity that any agile team member can take and implement the next day at work.

As more and more organizations are transitioning to agile, it’s inevitable that Agile testing is not just a concept any more. It is also not just about placing a tester in every team. What is so radically different now? How to be successful at agile testing? How to be an effective cross-functional team that embeds and honors all specialties including testing?

In this presentation, I am going to share my teams’ success with Agile testing and how we incorporated these 3 aspects – people, process and tools/techniques. This talk will benefit any members in an organization who has a stake in the product quality. It is also highly beneficial for those agile testers (from aspiring to veteran) to understand the 3 main aspects as it relates to testing and why we need to embrace- not just one, not two, but all these 3 aspects to be successful in Agile testing. 

Learning Objective:

The intention of this Model is to help organization / individuals to measure and improve the effectiveness of ScrumMasters in their role.

For the Existing ScrumMasters:

1. Helps the existing ScrumMasters to evaluate their current position in terms of their role maturity
2. Helps the organization by providing the range of maturity level and helps the ScrumMasters to improve in their role maturity

For Agile / Scrum Coaches:

1. Helps the ScrumMasters to understand the position where he / she stands and what that really mean by providing the necessary insight
2. Helps to find out the action items and coaching technique so that the ScrumMasters can move to the next level of maturity

Expected Business Impact:

1. This model can be used in a single Business Unit / across multiple business units as it will be generic.
2. This model helps the ScrumMaster community in a single BU or across BU or across product lines to evaluate their position. It provides the path for ScrumMasters to improve and perform their work better

Credits:

ScrumMaster Maturity Model is developed by Mr. Brian M. Rabon, CST, PMP, President, The Braintrust Consulting Group, USA (http://braintrustgroup.com/). I have started working with him from this year beginning and tried this model as a case study with 8 scrum teams across 3 product groups in my organization (EMC Corporation, Bangalore).

I have the first cut ppt readily available with data's and interpretation.

Project management as we know is a science that is evolving and maturing. Agile provides the next step of advancement in this arena. The topic will discuss how Agile practices have now reached a level of maturity and can be an agent of organizational transformation. These practices can now be applied to other fields and the same benefits can be reaped as we experienced in Software Development.

There are two ways to learn. From books and trainers; and by experiencing life. Life is a great teacher.

We are always pressed for time; that is a reality. But we can’t do anything till we have enough time; that is a myth. Because we can.

For learning skills and acquiring knowledge we need time. We can beg borrow or steal. Beg & borrow doesn’t work. Learn interesting ways to steal time.

Once we take care of time for skills & knowledge, we are ready to handle learning by experiencing. That doesn’t need extra time; if we know how. Through discussions and exercises, master innovative ways like maneuvering attention, watching exceptions and seeking interactions.

Being at conferences is fine, but we need something while at work where we belong. Use a few simple yet powerful tips to keep learning.

Humans are creatures of habit and agile is really challenging that part of our existence everyday. I have seen many teams thinking they now get agile and they take what they learned and just practice it everyday without really reflecting on where they are at or the fact that they are not really moving forward. So in order to say your teams and organisation are really becoming more and more agile everyday you need some metrix to measure against.

The collection of the metrix are 2 fold:

1. Metrix are tracked through the agile project management tools teams use. We have defined the below set of metrix to interrogate our data to tell us how we doing.
2. Some of the metrixs are done by getting feedback from teams and clients through surveys.

Some of the metrix include:

1. Measurement of quality
2. Measuring customer satisfaction
3. Measuring team happiness
4. Measuring continuous improvement in process and technical practices
5. Measuring time to market
6. Measuring ROI
7. Measuring productivity
8. Measuring overall project progress
9. Measuring change and improvement

In the session two processes will be explained viz. Release Planning and the Release Level Retro. Step by Step approach will be discussed so that the same can be readily used in your Agile Projects.

I have created these approaches of conducting effective Release Planning and Release Retrospectives in Agile projects. I have used these processes in various successful Agile projects.

Note: Please refer to the Links section below to see the steps invoved in both of these processes.

In the global village, some talks inEnglish the others in their own local langauge, when it comes to the global websites with international users, their users should be able to interact with the website with their own language.

The process of internationalization for a large-scale application (website) is usually time consuming; I'll show you how to split the internationalization process into different sprints and implement a successful internationalized application.

This session is a coding sessiont that takes a problem and shows clearly what is the difference between TDD, ATDD and BDD. Ths session uses code for the server layer as well as UI layer.

This session is not for you if you do not code. If you do code, please bring your laptop as we delve into the details of all these styles of programming techniques.

We will rotate between ATTD, TDD and BDD periodically and show it at use in different layers. This session will be using Java , Rails, Scala and C# together so that you can see how you can benefit do these techniques even when coding in different languages.

We look at common pitfalls and wrong beliefs that programmers have when it comes to these concepts

This session is purely keyboard and you will have to bring a laptop.

“Fixed price, fixed deliverables, and fixed schedule” contracts are just about the worst way to write contracts involving software, yet they are the most popular – so what are some techniques to use to fix that?

Organizations that perform professional services for software development or develop software on a work for hire basis are usually engaged bound by extensive contracts.  These contracts are typically characterized as “fixed price, fixed deliverables, and fixed schedule.”  These, of course, are the vertices of the “Iron Triangle of Software Development” and foreshadow a poor outcome due to issues that make the requirements gathering and project estimation phases that precede contract negotiation so prone to error.

Given this, the question becomes one of “how can I engage clients in a way that allows us each to achieve our goals?”  If Agile and Lean methods are the status quo for good development practices, how can I write contracts for development services that embrace this mindset and let each side achieve it’s goals better?  This lecture and roundtable explores the many facets of this question and provides the attendee answers that they can use going forward.

For many, the idea that you can transform an organization from the PMO outwards seems odd, if not impossible.  But my experience says that this is becoming a trend that more and more clients are asking advice for. 

We know that for an Agile transformation to work, we need to engage not just the Delivery Teams to approach work differently, but we need a change agent high in the organization to support that change in mindset.  I’ve always found it difficult to find that right person in an executive leadership role who is willing to have the courage to “bet the company” on a new and unproven approach such as Agile and Scrum.  As coaches, we tend to start “pilot” projects, and hope that traction will occur “once everyone sees the great results that we get.”  But I think that this approach is fraught with peril of not getting the right project to start with, not getting the right results immediately, and not motivating people by seeing results from a process that they are not comfortable with.

I think I’ve come upon a new approach that works better.  Instead of trying to “sell” Agile at an Enterprise level, embrace pure Lean principles high in the organization and work with the PMO leader at the organization.  Once they are comfortable with ideas such as “more leadership and less management”, “shorter concept to cash cycles”, “enabling Lean Startup mentality for disruptive product development”, “always looking for the elimination of waste”, “exploiting variability through appropriate cadence control and appropriate utilization rates”, “delegated authority”, “continuous improvement”, and “rolling planning”, the PMO becomes a terrific agent for instituting change, because they are usually already endowed with the right responsibilities and accountabilities that can push the organization forward.