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.

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.

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)

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!

I want to be controversial for a moment and propose an end to IT projects, project management & project managers. I propose that the entire project process is flawed from the start for one simple reason. If you need to run a project, you've already failed.

By definition, an IT project is a temporary structure to govern and deliver a complex change (such as a new product or platform) into an organisation. However, to be truly competitive, an organisation needs to be able to deliver a continuous stream of change. Managed properly, this negates the need for a project and the associated cost overheads.

This is fundamentally what #noprojects is. The approach, structure, tactics and techniques available to successfully deliver continuous change. At its core, #noprojects is predicated on the alignment of activities to outcomes, measured by value, constrained by guiding principles and supported by continuous delivery technologies.

This presentation will introduce you to #noprojects. You will learn how to define an outcome and create an Outcome Profile. You will also learn how to manage change within the context of an outcome through the Activity Canvas.

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.

Using play to build a better beginning through Agile Chartering

Better teams create better outcomes.  A liftoff (as described in the book Liftoff by Diana Larsen and Ainsley Nies) at the outset of a new endeavour helps teams set the stage for betterness by cocreating a shared understanding of purpose, establishing alignment and understanding the context of the work they will do together.  While the activities to include in a Lift Off will vary according to team and context, the practice of Agile Chartering - collaboratively developing a lightweight yet effective roadmap for the project and the team - is key to aligning and inspiring people to do better work together.

The purpose of an Agile Chartering workshop is to give all stakeholders of a project a voice and the opportunity to co-create a common understanding of the project dynamics, its purpose and context. It creates co-ownership of the project within the project team and thereby higher commitment to the project goals.

In this workshop, we will explore the objectives of Agile Chartering and foster a playful approach to doing this work. We'll talk about what kinds of games can be used to cocreate Purpose, Alignment and Context with a team, and run at least one game that can be used for each of the elements of an Agile Charter

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.

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.

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" * 

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.  

Agile is a radical evolution in how we think about work flow – AND how we engage people’s intelligence and commitment in the process. So now we’re doing a faster, better, more engaging job of ….. What? And Why? The “What” and “Why” questions are the stuff of strategy – purpose, vision, customer value, competitive advantage and sustainable financial performance.

 OKRs (Objectives and Key Results) are the missing link between agile practices and alignment with the larger mission and purpose of your enterprise. Developed in Silicon Valley and adopted by industry leaders including Intel, Google and LinkedIn, OKRs are the framework for individuals and teams to set their own goals and align agile action with overall business strategy.

 In this workshop, we will explore

• How business strategy is evolving from a waterfall model to an agile approach
• Extending the idea of “cadence” to include ceremonies for enterprise-wide strategic conversations that create “line of sight” for individuals and teams
• The use of OKRs as goalposts for strategic alignment and agile action

Leading in an Agile environment is all about mindset and understanding what motivates people. This interactive workshop will unpack the superhero archetypes of Agile leaders with their related Agile leadership anti-patterns.

Many leaders come into an Agile environment and feel threatened by a perceived loss of control. Successful Agile leaders empower the team and acknowledge that they can choose their own work and solve their own issues, pull themselves out of the detail and focus on supporting the team, know that if the team succeeds they do too, and are emotionally mature and are not constrained by ego.

The best paradigm to frame the concept of leadership in Agile is that leadership is encouraged at all levels. As such everyone working in an Agile environment is a leader. In smaller organizations this is probably easy to encourage. In larger organizations, where the “Title” or “Position” predominates defines who is a “leader” and who is not, anti-patterns tend to emerge which do not support an Agile culture, even if it is the organisation’s stated vision to become Agile.

In this instance the physical manifestations of Agile are put in place such as physical boards, Scrum ceremonies and an attempt at co-location are put in place. The danger here is that the Agile adoption will be a shallow one and will remain superficial. When the awesome magic of implementing Agile right is not achieved then people blame Agile as being the problem. It is not Agile that makes teams, projects and adoptions fail; it is people that cherry-pick those aspects of Agile that they like and are easy to implement that put the adoption on the path to failure.

All too often leaders dismiss Agile as something the development teams do, rather than as something which affects them too, and that their role is important for its successful adoption. The role of leaders cannot be underestimated to turn a shallow adoption of Agile and make it a deep and lasting change for the organisation’s benefit. In this case, adoption in a small team or program will start the journey toward the tipping point that will make it a lasting organizational change.

This may cause confusion, manifested as cognitive dissonance, in the leader. They may be asking themselves these questions:

- How am I supposed to behave in a changing environment?

- What behaviors am I supposed show to support the values and principles of Agile?

- How do I support support the teams now?

This workshop is based on my learnings and experiences as line manager of a development team in a large organisation, and Agile coach in large organisations in how leaders can in many instances unknowingly "sabotage" Agile initiatives, as well as experiential insights on what the enabling leadership behaviours and characteristics are.

As part of this talk I will share the following:

• What are the superhero archetypes of Agile leaders.
• What are the related Agile leadership anti-patterns?
• Discover the antidote to these anti-patterns (or the good patterns to replace the anti-patterns).

“When will it be done?” That is the first question your customers ask you once you start work for them. And, for the most part, it is the only thing they are interested in until you deliver. Whether your process is predictable or not is judged by the accuracy of your answer. Think about how many times you have been asked that question and think how many times you have been wrong. Now think about how much harder it is to answer that question when practicing Agile at scale. Your customers most likely feel like they have better odds of winning the lottery than they do of your next Agile project coming in on time. That you don't know your odds of success is not necessarily your fault. You have been taught to collect the wrong metrics, implement the wrong policies, and make the wrong decisions. Until now. This session will introduce how to utilize the basic metrics of flow to more effectively manage the uncertainty associated with very large scale software development. In it, we will discuss how to leverage the power of advanced analytics like Cumulative Flow Diagrams, Cycle Time Scatterplots, and Monte Carlo Simulations to drive predictability at all levels of the organization. Your customers demand better predictability. Isn’t it time you delivered?

The metrics of flow provide a comprehensive, analytics driven methodology for agile development at scale. By capturing real-time flow metrics and by using powerful analytical tools such as the Cumulative Flow Diagram (CFD), Cycle Time Scatterplot, and Monte Carlo Simulations one is able to more effectively manage the complexity associated with very large scale software development. Better management of complexity ultimately leads to better predictability.

Further, these metrics provide transparency at all organizational layers. At the team level the metrics provide real-time information and act as a catalyst for continuous improvement; and at retrospectives the teams will always have the most accurate, critical and objective information upon which to base any action. For Scrum Masters and the team the metrics provide insight and levers to pull. This level of visibility is crucial to decision making as most organizations and teams can perform multiple types of work across varied layers of work-units.

Similarly, at the enterprise and/or program level the metrics provide the transparency required to effectively manage complex and geographically distributed development and maintenance environments. One is able to track progress, productivity and pro-actively act on systemic issues such as infrastructure concerns, resource capacity, cross-team dependencies, and integration.

Flow metrics are the most effective means to manage to predictable outcomes in an inherently uncertain field. The use of Scatterplots and Monte Carlo Simulation based on real historical metrics eliminates any need for subjective estimation. At all levels of an organization, these metrics provide much higher levels of confidence and more realistic projections.

“If a task takes 1 hour; it takes 2 hours in pair programming.”
“This fix is needed urgently; it is better done alone to save time.”
“It is good only for complicated tasks; there is no need to pair program on simple tasks.”

These are some of the statements you may be hearing around you from experienced developers to even managers. Sadly, there is lack of understanding of dynamics that make pair programming a key agile engineering practice. This, in turn, resulted in lack of its acceptance in teams adopting agile methodologies. Our mission is to dissect the myths around pair programming which brings continuous learning, productivity, quality, and the joy of collaboration to countless developers every day.

Collaboration is the foundation of Agile teams. Then why do we focus so much on the performance of individuals? Want better collaboration? Get rid of your high performer. Chris and Sean will demonstrate through a series of skits how strong personalities can get in the way of team performance, and how collaboration skills can help overcome this.

Knowing challenges and taking them over is what we preach. In reality making it happen is a true success. Agility as a practice when implemented speaks about the thresholds, we debate and blame the stake holders of the process but in reality, we are failing to deliver the essence of agility to the bottom level.  If it is just forcing on to the stake holder we call to practice, we can say we are an agile environment but is it how it is supposed to be?

When asked this question time and again, what we truly understand is we are not considering the integral value agile can offer when the bottom level leaders are the true agilist. Are we really not considering this to happen? How do we work to make this happen? Are frameworks built to fit or should we tailor them for the right fitment?

Making leaders believe that they are not shepherds but leaders of teams they work with, is essence of implementing agility all across the environment. Pragmatism is essential at every level of interaction when we decide to implement agility. If the Scrum Master is the one who has to do it, he should be giving more thought on how to make Agility a reality than keeping it to the documented success stories.