On Agile teams, collaboration is the way of life. Our leaders want their team members to work closely with each other, have shared goals and even think as one entity. Why? Because we believe that collaboration leads to happier, more productive teams that can build innovative products/services.

It's strange that companies use the word collaboration very tightly with innovation. Collaboration is based on consensus building, which rarely leads to visionary or revolutionary products/services. Innovative/disruptive concepts require people to independently test out divergent ideas without getting caught up in collaborative boardroom meetings.

In this presentation, Naresh Jain explores the scary, unspoken side of collaboration and explains in what context, collaboration can be extremely important; and when it can get in the way or be a total waste of time.

What started off as a trial-and-error approach to improve the state of software development by a bunch of tinkerers, is today dominated by management consultants, "Thou-Shall" codified frameworks and rigid, expensive tools. Over the last 20 years, we've gone from, "I'm not sure, let's try this in a small-safe environment" to "you/your-team sucks; you guys have a very poor agile maturity because you are not doing _x_y_z_ (not conforming to the standards)." Along the way, we've lost the purpose of being agile .i.e. to embrace uncertainty via simplicity. Instead we've been forced to believe that consistency via top-down standardisation and predictability by increasing the rigour on process is our eternal quest. Anything that sounds simple and works 80% of the cases is discarded as being naive. What once drove thought-leader into agile, is now driving them insane. This is the unfortunate fate of Agile.

Luckily there has been some fresh perspectives from Nassim Taleb, author of Antifragile. His work explains how some things benefit from shocks; they thrive and grow when exposed to volatility, randomness, disorder, and stressors and love adventure, risk, and uncertainty. More importantly why antifragility is beyond resilience or robustness.

In this talk, I'll use some of Nassim's thoughts (and some of my own) to explain what is wrong with our current approach to Agile and how we can bring life back into Agile. Particularly how we can leverage Volatility, Uncertainty, Complexity, and Ambiguity to make product development more antifragile.

The role of Leadership in organisation's Agile transformation is a critical piece. Yet many organisations struggle to find the right balance between top-down vs. grass-root transformation. I would like to share an experience where we were able to achieve fairly good grass-root movement, but had serious challenges building the agile mindset at the leadership level. While the leadership was trying to help with the best of their intentions, certain actions, behaviours and patterns did affect the spirit of agility. If you are keen to hear about typical leadership anti-patterns during agile transformation and some pointers on how to avoid them, this session is for you.

You’re probably here at this conference because you want to become a better developer, but I’m here to tell you that that you’re focusing on the wrong area. The difference between a good programmer and a great one isn’t the ability to write a kernel module in LISP, but the ability to communicate with your colleagues and customers. Skills sharing, collaboration and functional communication are critical for the success of any software project, and yet usually overlooked and undervalued.

Developers who strive to be great, cannot afford to neglect their professional development in these areas. You don’t to reinforce the dreadful stereotype of the shy, stuttering, geek, do you?

This interactive presentation will examine a few of the critical “soft skills” that are needed to thrive in corporate team environments. For example, how you can:

• write effectively and speak clearly; i.e. get to the point,
• move beyond your technical silo to work effectively as a team,
• build trust and rapport with your project customers,
• mentor, motivate and encourage others,
• mediate or negotiate between competing points of view,
• lead others and manage vendors

This is about agile “anti-patterns”: “something that looks like a good idea, but which backfires badly when applied” (Coplien). Todd has been around agile development from before it was called agile.  In that time, he’s seen teams fall into the trap of many of these anti-patterns, becoming stuck without ever realizing it. Frequently, this is due to a dogmatic understanding of what is right and wrong about Scrum and agile development. The first step to getting unstuck is to be able to detect these “sins.” The presentation aims to expose teams to these common pitfalls and then also provide a vision for a virtuous path to take them to the Promised Land.

In this highly engaging workshop attendees will experience estimating, planning and delivering a new product and product features. The uncertainty in value and costs will be resolved through rolling dice based on the stories that the team selects and prioritizes.   The teams will run through 3 iterations of story cost, value estimation, and product feature delivery. Points will be scored for delivering product features and meeting release and iteration commitments.

Dealing with uncertainty is one of the largest challenges that teams face. The simulation aims to have levels of uncertainty in value and delivery that are commensurate with those found in software development. Some of the key tools for dealing with uncertainty are integrated into the simulation.

Attendees will come away with a better understanding of the challenges of working with uncertainty in software projects, and will learn some of the tools that are at their disposal for managing this uncertainty.

About the company

Philips is a healthcare multinational company that focuses on building complete health care products and solutions for emerging markets, in addition to developing solutions and products for global markets, across the three sectors Healthcare, Lighting and Lifestyle. Using the expertise of its nearly 2000 engineers in Bangalore and aligning the marketing and sales teams the campus is responsible for creating and rolling out a complete set of products that include a whole host of solutions for global customers. It also contributes to global solutions in critical health care component development for connected consumer devices and renewable energy.

Executive Summary

Beginning of 2014, an external survey brought out the issues wrt time to market and code quality. Taking the survey results positively, the Leadership embarked on an Agile/SAFe journey with pilot projects. The results were amazing and with the currently learning from the pilots, the organization is running 25+ deployments within. The journey has started and Agile release trains are delivering periodic value to our customers at defined frequencies.

Background Objective/Challenge

Product quality, consistent & predictive delivery and quicker time to market are the key challenges the organization is trying to address today. Continuous Innovation is constrained due to the above issues and hence there is need to find a new way of product development which can meet the dynamic business needs, foster people engagement and deliver meaningful products to the world.

Target

ScaledAgile has been used as a framework for product development across the organization global. The whole organization is undergoing a transformation from waterfall way of working to the SAFe agile way of working and roadmap is till 2019.

Agile Initiative

The Framework used for the transformation can be summarized into 4 major steps

1. Develop products in the Agile way with focus on Basic Agile practices (Scrum)
2. Establish Product Ownership with focus on Enabling Scaling aspects (SAFe practices)
3. Establish a release pipeline with continuous integration (supported by Automation)
4. Adopt a DevOps Culture with focus on Continuous delivery (to production environment)

This includes a comprehensive diagnosis of the various business processes, agile practices and behavior, engineering practices, delivery maturity and recommendations for the transition. A coaching and tooling plan is also an outcome of the diagnostics.

 Measurable Impact

• Predictable Releases to customers (hitting the market with features every three months with features and business criticial bugs with less than 2 weeks with all the regulatory compliance)
• Capitalization
• Feature planned vs Feature delivered per program increment > 80%lose
• Defect reduction co t 45%
• Team velocity – Baseline vs actual.
• Very high sense of ownership and high levels of engagement

Transformation team Profile

Global team

• Agile Capability program manager -1 FTE
• Agile Deployment Program Management – 1 FTE
• Communication expert – 1 FTE (Today we are 0/1)
• Coordination - 1 FTE
• Enterprise Agile Coaches – 16 (Today we are 9 /16)

We have been discussing a lot regarding Agile transformations and how such transformations can help organizations. The key is to base such a transformation on the concepts of agility such as self-organization, intrinsic motivation, collaboration, etc. But still the puzzle of how those can be used in practice is less discussed. This is where the emerging concept of "Learning Organization" from Peter Senge can help a lot.

The five disciplines of a Learning Organization lies in the heart of an agile organization. Therefore, exploring the learning organization within agile organization aids us find the "truly" agile organization.

This is an experience report of a journey where a mid-size offshore software development organization moving towards to become a learning organization.  

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.

Large-Scale Scrum (LeSS) is a framework for scaling agile development to multiple teams. LeSS builds on top of the Scrum principles such as empiricism, cross-functional self-managing teams and provides a framework for applying that at scale. It provides simple basic rules and guidelines on how to adopt Scrum in large product development.

In this tutorial, we focus on LeSS framework and see how you can scale Agile development to big organizations. We will start by looking at basic assumptions behind scaling and what different approaches there. Then we learn how LeSS deals with scaling in big groups and finally how LeSS can be adopted for existing organizations and what changes it bring in.

The role of “Architect” is sometimes frowned upon in the Agile community as a central command-and-control authority who bottlenecks decisions and limits team empowerment. Or at least, that is what we thought. Follow the real-life journey of our teams as we discovered how the role of an architect is compatible with Agile principles. We will explore our failures, and how we learned that an Architect can bring immense value to the organization through a focus on transformational leadership. In this presentation you can see how an Architect as Leader can help a project scale and can help create a truly self-sustaining organization.

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.

Great teams make great products, but what fuels this greatness? It's the common understanding and passion for the product but more importantly the singularity of purpose and the feedback loop and how the users are responding to the teams work. 

The new world of product development is no longer about scope management and delivering the project on time and within budget but it's now more about hypothesis validation and learning from the users and their behaviors.

The dynamics of product development is changing.  As more and more organizations are moving towards maturing their agile software development approach the traditional barriers of roles are being broken creating new opportunities and fostering a shift in the mindset. Instead of being tied down to scope management and delivering the project on time, Agile teams are focused and inspired by hypothesis validation and learning from the users and their behaviors.

In this case study we will go over how a portfolio of 12 SCRUM Teams adopted a more outcome approach and how they shifted their mindset from project delivery in Agile way to adopting the Experiment-Measure-Learn-Repeat loop which plays a crucial role in teams overall motivation, performance and moved from being SCRUM Teams to "Product Teams".

We will also see how we experimented with different team formats and how exposing the team members to different events and user research changed the way they perceived the information of the problem they were solving via features and user stories.

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.

In Hugo’s workshop, participants will create a best practice board in teams of 5-6 people. The teams go through each block of ‘The Bridge Canvas’. The goal is to share best practices, ideas and experiences. Per block, each team selects the ‘best best practice’. At the end of the workshop, each team will present the best best practices for each block.

At the start of the workshop, Hugo shares a few best practices (personal ones + from other distributed agile experts). Each person gets a handout with clear instructions. This includes some questions to stimulate thinking within the team + some best practice examples per block.

Language is the medium by which individuals interact. Our language expresses our values -- what we care about (and what we don't). Language defines our relationships with our team. What can our language tell us about whether we are "self-organizing team" or not? In this talk, Sean explores how the subtle ways in which our words influence team dynamics and how we, as team members, can influence team values and collective ownership through deliberate use of language.

The team's use of language is important to ScrumMasters, Agile manager sand leaders as it provides us an insight into the values our team members. By being attentive to the team's the use of language, we can identify where the teams' values align or diverge with Agile principles. More importantly, ScrumMasters and leaders can guide the team towards Agile values and principles by deliberately influencing the team's language. 

 Sean will relate this through common, recognizable speech patterns -- the familiar phases we routinely hear in standups, planning meetings, retrospectives or day-to-day development. These common speech patterns (or anti-patterns).  Through examples of alternative phrasing, Sean will provide tangible tools ScrumMasters can use to challenge the team to think in new ways. 

* Note that slides are early draft that are being adapted from other presentation. There will be a de-emphasis on "structure" and focus more on "language" * 

This session will be a combination of both devops concepts and a case study of a practical implementation of deployment pipeline. Karma teaches us how each action leads to good or bad repercussions based on the nature of the action.  If we build the deployment pipeline in a way that we are allowed to push only the good deeds through, We will be achieving good repercussions. But if we are not ? 

With business agility being the new watchword in senior management circles, many enterprises are looking for ways to adopt this into their technology practices. However, it is imperative for such an initiative to go beyond the mere adoption of agile in a few projects.

To run an effective enterprise there are different  systems and applications in every value streams.  There is no one size fit for all. There could be a broad pattern/ classification  like 'Money making applications' 'Applications which bring efficiencies to their operation' and 'Applications which are critical from a regulation and compliance perspective'.

My session is going to focus on experience and patterns that helped in  achieving Agility in the above categories of applications   with respect to  key 'Movers & Shakers' in the system.