Scaling Agile across the enterprise can also scale up or create new organizational conflicts: groups that are accustomed to working in their own silos struggle to find ways to identify their shared interests and collaborate effectively.  Equipping team members with effective conflict resolution skills is important in helping everyone navigate change successfully.

Conflict isn’t inherently a bad thing – it’s inevitable when people are working closely together on things that they care about. In fact, diverging viewpoints can bring new insights to help teams move forward and create something new. Dealing with conflict head-on is challenging for many people, yet few organizations and teams spend time explicitly considering “how will we work together when things get rocky?” Teams need to build the skills to be able to navigate through rough times together and come out with win-win solutions.

This workshop will present useful models for considering conflict supported by games teams can use to develop and practice conflict resolution skills. The models address underlying drivers of conflict, modes for responding to conflict, assessing conflict severity to determine appropriate interventions, and the patterns of principled negotiation. The games build on the concepts to help participants gain insight and develop important skills in a non-intimidating and memorable way.

How much does one story point cost? Is Sprint 0 an expense or an asset? Can you run Scrum with a fixed-cost contract? Agile challenges the existing approach to financial aspects of running projects: i.e. budgeting, forecasting, financial planning and vendor contracts.

Applying new financial models becomes increasingly important for larger organisations adopting Agile. While they are going through an Agile transformation, they also need to maintain transparent financial governance and reporting. Shareholders would not be too excited about messy Annual Financial Statements.

Join me if you would like to know more about Agile Economics. No financial degree is required and all the content explained in plain English with plenty of pictures!

Whether a team is brand-new or seasoned veterans at working together, explicitly defining and/or refining a team working agreement will help the team to align on how they will work together effectively to meet their common goal. In this fast-paced hands-on session, participants will go through the process of building a team working agreement using LEGO Serious Play (LSP).

Creating a team working agreement helps team members set the stage for effective communication and high performance by making assumptions about ‘what really matters to us’ and ‘how we will work together?’ explicit and negotiable.  Great working agreements address some difficult topics - what values do we share? how do we want to deal with conflict when it comes up? how will we handle problems within the team? - which are often challenging to discuss openly and honestly, especially when a team is first assembled.  

This session will show you how to use LEGO Serious Play to encourage a frank and fearless discussion in order to kickstart these discussions so that a team can quickly create a powerful set of simple guiding principles for working together.  Participants will learn about the importance of team working agreements in creating team cohesion and common understanding of shared values and operational guidelines, and experience hands-on how to use the LEGO Serious Play cycle of build-share-reflect to have a participatory discussion to identify shared values, explore reactions to conflict, and build a set of simple guiding principles.

The #NoEstmates twitter hashtag was intended by Woody Zuill "..for the topic of exploring alternatives to estimates [of time, effort, cost] for making decisions in software development. That is, ways to make decisions with ‘No Estimates’."  Based on twitter traffic it has been successful at generating activity.  It's a bit debatable as to whether it has really spawned much exploration.  In this talk Todd will actually do some exploration using real data from over 50 projects at companies ranging from startups to large enterprises.  In addition to the analysis of the data, Todd was able to build a simulation model of the software development process to both replicate the data to and explore the conditions under which estimates add value and when they do not.  Based on the findings from the data and the simulations, along with an analysis of the types of business decisions that organizations need to make, Todd will provide some pragmatic advice for estimators and #NoEstimators alike.

From 2 person Company that worked on the other side of the Globe,  to a 30+ company, thats spread across,  BigBinary has grown gradually.

Since its completely remote as well as Service based, it has its own unique way of growing, and adheres to its own set of problems.

There are things ranging from, how do you hire, when do you hire? To how does your client get comfortable with your Company being remote.

As a team that can hire remotely, and pay good salary, does salary even account for a person to 

join the company, when there is a looming reality that, there is NO Office, to this Company. 

This is further exaggerated in an employer market like India, which is still fairly conservative.

Or does a better work-life balance, no time wasted on commute, and being able to spend more time with Family, trump these concerns?

Then, when new developers do join, how do you make sure that you are working in a sync, 

as a team. Following the same Code conventions. Following the same process that has been in place 

to ensure faster and better delivery.

Since its remote, a 9-5 timeline is not a realistic or expected commitment. When should people work? 

Does everyone need to be online and work at the same time? Not everyone is going to work on the same project or team.

Does this apply to such teams in that case?

How does the Company manage projects. Does it micro-manage the Developers? Because lets face it, 

you are not sitting next to the person as in a office, you are not witnessing how the developers work. 

How do you measure and build trust, in such a setup.

How do you bring a developer up to speed, with exciting conventions and processes your company uses. 

Things that are going to be alien to them.

How do you pick concepts from the best, and then move forward as single team, functioning as a single unit, 

instead of a bunch of freelancers scattered around.

Lets discuss, some unique set of problems Remote Consulting teams face, and how to make most of it.