According to the 11^th annual State of Agile report by VersionOne, one of the top five reasons for adopting Agile is to “enhance software quality”. In spite of this aspiration, a common pattern in Agile roll outs is the failure to set quality goal improvements from the outset. It is often assumed that if you implement Agile/Scrum then quality will just take care of itself. As many organizations quickly discover, you cannot just “deploy Agile” and expect it to be the silver bullet for a software organizations’ quality issues. Why is this happening so frequently? Is it due to methodical deficiencies, unrealistic expectations, fundamental misunderstanding of Agile, lack of executive support, too much existing technical debt or all of the above?

If you are questioning whether your Agile roll out is really helping you deliver higher quality software, faster, then this talk is a must to attend. I will discuss the approach I have successfully used in a number of organizations which involves; identifying the necessary building blocks to establish a quality mindset in an organization, moving the organization to a test first mindset, helping the Product Management organization become more Agile, and finally setting the right level of test automation so that you can deliver quality software faster.

If you are serious about doing Agility at scale, you cannot realistically achieve that goal without ensuring that each team individually delivers quality, and in-turn whole projects/programs that incorporate outputs from the individual teams are delivering quality software. To successfully scale quality, you will need to follow the ‘blueprint’ provided in this presentation.

Many of us work in geographically dispersed teams and struggle with the inherent challenges of such teams. In software development these challenges also impact the agile development methodology we want to use. Over time at Macadamian we have established strategies that have helped our teams get better at being both agile and dispersed. In this session we will share these practical strategies with participants followed by some of our current difficulties and what we propose so far to resolve these.

A reflective design approach to achieve software design agility by modelling change as a vector and tracking it to aid refactoring decisions.

Preface about the talk

Software design is a field that has always fascinated me and I have tried to be an obedient student trying to learn this art. Like any other design problem, software design is also a wicked problem. Horst Rittel and Melvin Webber defined a “wicked” problem as one that could be clearly defined only by solving it, or by solving part of it .This paradox implies, essentially, that you have to “solve” the problem once in order to clearly define it and then solve it again to create a solution that works.

Hence you need an architect with magical powers to get your design correct in the first go .This is the core philosophy behind emergent design in which we do not think too much about future . As Uncle Bob sarcastically points out, your customers somehow knows your design and they will come up with a requirement that will break your assumptions and thus your design. In emergent design you embrace aggressive refactoring religiously and few teams rebelliously for the good. It has also been observed that during emergent design refactoring step more focus is towards class design than higher abstract architecture elements. This creates technical debt which can go unnoticed for a long time.

In this talk I will be introducing a novel technique called change vector tracking that will address the above described problem. Change Vector Tracking is a reflective design approach to achieve software design agility by modelling change as a vector and tracking it through ceremonies like Change Vector Tracking meetings.

Change vector tracking doesn’t prevent customers from coming up with requirements that would invalidate previous design assumptions, it helps us in monitoring these changes and aids in making informed decisions of where and when to redesign. It helps us keep a check on design debt which otherwise would be overseen and not addressed at the right time .Design debt is invisible to tools initially, only when it grows beyond a scale tools can catch it. Change vector tracking is a technique to capture this design debt in a very early stage. “A stitch in time saves nine”.

The Lean Digital Marketing workshop, inspired by the principles of Lean Startup, Effectuation, Agile Project Management and user-centered value-driven philosophy, lets you discover the fundamentals of digital marketing through experimentation and collaborative work.

In this playful experience, participants alternately plan and execute specific actions to reach their goal in a real case study where they must test their assumptions. The Lean Digital Marketing game is an innovative and interactive experience that will give you the tools to better adapt to the continuous changes of today's marketing.

The Lean Digital Marketing Game participated in WAQ17, the largest French-language digital event in North America, as one of the masterclasses, and at HEC innovation workshops.

Creativity is traditionally though of as a solo activity, but many human endeavors leverage the creative power of groups. Agile uses group creativity to produce better products in shorter times. How do we support, enable and enhance the creative abilities of our teams? There are many ways to redefine the work environment for greater creativity. Many of them have been discovered through experience, experimentation and accident. Modern neuroscience suggests to us some guidelines for deliberately designing conditions to enhance creativity by explaining how our brains work, learn, integrate and create.

Creativity can manifest in several ways: creation of something new, refinement of something that exists and problem solving. We will present a summary of the literature that describes and demonstrates how creativity can be enhanced by providing a safe, nurturing environment, enhancing group interactions, pacing activities that utilize different sensory modes and trusting in the power of subconscious integration.

Portfolio management is a key aspect of organizational performance. The ability to visualize upcoming projects, projects in progress, the process of value creation, the dependencies, the ability to share a common vision and to throttle the work in progress based on organizational capacity are all contributing elements to the effectiveness of an organization.

Unfortunately, the shared vision of a portfolio is too often buried in a tool shared with too few people and does not help the organization build a global and cohesive plan of action.

But when we think about it... Value chain, limiting work in progress, transparency, flow... have you ever thought about using Kanban for portfolio management? Seems like a great idea!

Create alignment around what delivers value to your end-users, use cadence to move forward, help shape a new organizational culture, support innovation, continuous improvement, and leadership and unite people around a shared mission, that is what Kanban at the strategic level can bring.

In the federal public service there is an air gap between the performance evaluation criteria applied to business leaders and the criteria applied to service providers.

As a consequence, even in situations where both the business and the service provider enjoy optimal relationships, the goals are not the same and may even be contradictory.

In a climate centered on Results and Delivery, leaders cannot expect results if they do not tackle this conflict.

The approaches proposed in this discussion align the service organization to the business. They promote mutual accountability by insisting on mutual performance alignment between the business and its services provider.

When you learn about agile practices, one of the most challenging concepts to grasp is Story Point Estimation. This is particularly true for service companies that normally bill clients by the hour.

On the one hand, they need to submit project proposals that are based on concrete time estimates.

Story points, on the other hand, are an abstract concept by design. They were born out of the needs of product companies with the purpose of having a better assessment of the amount of work involved in developing software units, regardless of how long each unit takes. This makes people struggle between using points and hours. You want to reap the benefits of point estimates, but you still want to keep things tied to time.

In this session, I will introduce the notion of point estimates, highlighting its advantages over hour estimation. Then I will explain one approach to doing point estimation in a professional services company. I will address common concern from various stakeholders from Project Management to Business Development, COOs and CEOs.

Over the past few years, I’ve found incredible flexibility in building my technical coaching practice around the "Four Rules of Simple Design", originally penned by Kent Beck back in the ‘90s.

The Four "Rules" have resonated with many developers over the years, and have a wonderful lack of specificity. These tiny pearls of wisdom are so simple and flexible that they have caused many an argument. They have even been called generative – that is we can derive many of our practices and small-scale architecture by extrapolating on them.

As such, they provide fertile grounds for growing consensus on the thousands of decisions your team should be making together.

1. Tests Pass – How does your team test the code you deliver, and at what level(s) of abstraction will you decide to test?
2. Express Intent – How does your team arrive and socialize common understanding so that the intent in your code is always clear to every team member?
3. Don’t Repeat Yourself – What strategies do you use to ensure your team knows what behaviour is present in your code, and how to leverage it without duplication?
4. Small - What dimensions will you measure so that you continue to derive the maximum level of value from a minimal amount of code?

Code that follows these rules has a natural agility. Tests give us confidence to make change. Clear intent helps us find what needs to change. No duplication means we make the change only once. Small means we aren't getting lost on our way to making the change, and allows us to make more meaningful change with less effort.

More asking, less telling. As an agile leader, adopt the approach of humble enquiry to build relationships, increase trust and collaboration, and deal with the challenges of organizational transformations.

"Humble enquiry is the fine art of drawing someone out, of asking questions to which you do not already know the answer, of building a relationship based on curiosity and interest in the other person." - Edgar H. Schein

Working in an agile way asks us to rethink how we relate to each other as we tackle complex problems and challenge the traditional structures of our organizations. Humble enquiry - the art of asking instead of telling - is a critical skill for agilists who seek to improve collaboration and address difficult problems head on. Inspired by Edgar H. Schein's book 'Humble Enquiry, this workshop will teach you the fundamentals of how to do more asking and less telling. Through mini-lectures and interactive exercises, we'll discuss the different types of questioning, consider the forces around and within us that inhibit our ability to ask instead of tell, and examine how this powerful technique can improve collaboration within agile teams as well as help to address some of the challenges of agile transformations.

Lean UX research is essential to guide and validate what exactly is the 'Minimum Viable' to launch a Minimum Viable Product, especially in government.

In this talk, I'll describe how user research insights helped us understand, design and launch Canada's first online open-source regulatory consultation. The first research participant identified a significant hole in our assumptions - and predicted that we could miss the minimum viable mark. It helped us course-correct, and plan ahead for the next development iteration.

The other customer group was the government. We applied lean UX research techniques to understand the government analyst team's journey and needs, and then to co-design with them as the analysis site MVP was developed, and as the commenter data flowed in.

I'll describe how the insights from the research helped us meet the Minimum Viable mark for the government customers, understand how and why we missed the mark with the specialist customers and how you can apply lean UX research techniques to ensure you don't iterate your way to a useless product.

Everyone is doing it! Not very good at it though. If you ask them, every single one of them tells you they are great at it. I am talking about Facilitation!

Everyone is thinking they are doing it. Many of them have an idea about it, maybe through word of mouth. The funny thing is that everyone is claiming to be great at it. This time, I am talking about Coaching!

Facilitation is what we do on a daily basis, no matter what our roles are. If we are talking to more than one person, we are probably using some facilitation techniques. People that are working with teams use that more often. Facilitation is a human centric activity. It gets more complicated and more complex by the number of people involved, and that's not the only factor. There are many factors involved in that.

Coaching is not something we necessarily do on a daily basis unless you are a coach; and a coach by heart. It is very easy to call yourself one and not be one. It is hard to be a coach. Coaching is a deliberate stance we take. In coaching, depending on your client's situation, you use different tools and techniques.

In their core, Coaching and Facilitation are not very different. One is mostly focused at a person's personal level, and one at a group's personal level. When you look at the group as one entity, you can apply techniques and tools for both. Similar to the scaling challenges you might have encountered, you can not necessarily apply the exact same techniques and tools to the bigger picture. However, you can rely back on the pillars of Coaching, Facilitation and vice versa.

Shahin is a passionate Coach and an enthusiast Facilitator. Please join him for a session to talk about Coaching and Facilitation; the techniques that we can use and apply no matter who and how many people are we interacting with. Let him share with you his personal coaching & facilitation experiences, and through that to help you identify your own unique charismatic stance of Coaching and Facilitation.

When Agile first came on the scene it was premised around putting the customer first. But, over the years its focus has evolved and the general perception of Agile today is that it’s mostly a tool for delivering software. Agile’s original focus was mainly on developers and testers, but it never really contemplated design thinking as a discipline. Design thinking, which has been around for decades but is only recently having its ‘moment in the sun’, compliments agile beautifully in that it focuses on trying to solve the right problems for the right people. Design thinking allows us to iterate and test assumptions before too much coding and production-readiness is done, which helps ensure the team is investing in the right things at every stage. It really provides a focus on innovating rather than simply burning down a backlog. In this talk we will discuss different ways to incorporate design thinking into the agile process. You will learn how to yield benefits from bringing these two practices together – most importantly how to best serve the users of the product or service you are delivering. At Scotiabank, we’ve been using these fantastic tools in combination for over a year. It is a journey, and although we haven’t completely solved everything yet, there are a lot of lessons we have learned that can be applied elsewhere.

Confused about Continuous Integration vs Delivery vs Deployment? Not sure how to take the next step towards Continuous Deployment?

In this session, Nayan will remove the confusion around the "Continuous" terms. He'll then show you how to go from Commit to Production with no manual steps, while remaining confident that your production system remains stable. We will do this with a variety of open source tools -- from traditional build & integration tools to modern deployment environments & monitoring. You'll leave the session inspired and ready to build your own Continuous Deployment Pipeline when you get back to work.

Qlik is on a journey evolving from a monolithic enterprise product released three times per year, to a cloud first microservices based product deployed multiple times per day.

This presentation describes our approach to Agile, Continuous Delivery and DevOps on Qlik Sense Cloud. It discusses some of the impacts Continuous Delivery and DevOps have had on our Agile processes and shares some of what we’ve learned over the past two years developing Qlik Sense Cloud.

As Agile continues to scale among organizations of all types (including governement agencies), challenges are now not only at teams or projects level but are more and more encountered at the portfolio management level. To significantly improve end-to-end global delivery model and to inject effective responsiveness into strategic and operational programs, organizations need to reinvent governance by shifting organizational KPIs from variance surveillance to real business value creation. Horizontal business processes (such as planning, reporting and budgeting) must be cohesive with this shift as their influence and impacts go far beyond scrum/kanban floor-team execution mechanisms. How should we organize and manage such a transformation? Where should we start? How should we deal with existing processes and management paradigms that are far from being Agile?

This conference will provide numerous references and pointers from a successful large scale Agile government transformation. The two speakers are senior agile coaches passionated for real change and for long lasting improvement. All together Jean-René and Richard combine more than 20 years of Agile experience and have helped many organizations improve their performance with agile principles and practices.

It is intended for executives, managers and everyone leading and applying changes in the organization.

Are you struggling to implement change in your organization? Is your team resisting your influence? Does your team believe they are a high-performing, mature team, therefore do not need to change? Are you actively trying to bring about improvements without results?

If this is you, then you need to stop what you're doing. Yes, stop everything and do 'nothing'. This means stop pushing against the resistance, stop driving people onto the Agile bandwagon. Instead, influence your environment by telling stories, model the behaviours that you would like to see, and most importantly be real.

This talk illustrates a different approach to initiate change. Attendees will walk away with a list of pragmatic techniques to influence teams.

Have you ever found yourself saying, “Estimating is HARD”, “These estimates are WAY off”, or “Who estimated THIS??!?” These reactions are all too common. Ever wonder why?

This workshop will take you on a journey through your brain where you will discover some of the cognitive biases that behavioral psychologists have found to affect our ability to estimate. We will look at 3 different estimation techniques and examine the factors that make each more/less successful. Practice sessions will highlight pitfalls you need to be aware of in your next estimating session.

Come prepared to have fun participating in revealing interactive exercises. Learn practical techniques for effective estimating that will help you choose the best approach for your team/project.

CFOs in today's digital economy are looking to invest significant capital on data driven initiatives to deliver strategic analysis to business partners. However this is often reprioritized due to regulatory requirements.

This session is about a large European Bank successfully delivering a large regulatory transformation program using an agile approach. Driven by Finance & Risk groups and enabled by technology, incremental business value was delivered to Finance and Risk stakeholders.

The key challenges faced required an approach to handle evolving regulatory requirements, integration of new technology assets to automate business requirements and an aggressive timeline enforced by the regulator.

The successful delivery was largely due to business foresight to maneuver around typical IT challenges and instead adopt an approach using agile principles that put delivering business value over fixed scope. Through this approach, the clients were able to deliver the solution that addressed the immediate needs but this also position them to leverage for future regulations.

This talk will elucidate the backdrop, challenges that posed the business, the agile approach, culture and mindset that was adopted, and the resulting outcomes.

If you have thought of or thinking of adopting Agile mindset in a non-IT environment, this is the session for you. In this session we will share some techniques we developed and hiccups that we managed along the way.

By the end of this session, you will likely have gained some valuable insights that you can take back to your Organization and adopt agile principles and practices in areas outside of IT.

“Are we agile yet?”, “Can you get me some metrics on our agile adoption?”, “I want to measure the effectiveness of our agile teams, get me some metrics to do that.”!!!

These are scary questions that can get asked of you from your executives. We’ve all been there. What are you supposed to do? How do you (politely) tell them no, yet still provide your teams with information that will help them? Most importantly, how can we actually help a large set of teams understand their own journey towards adopting agile practices?

Chris and Lee have worked with over 70 agile teams and created an approach that allowed the individual teams to understand where they were on their agile journey while maneuvering through the minefield of executives that wanted performance metrics to hold teams accountable.

This session will be a review of what the challenges were during this process, how they were accepted and mitigated and how the teams were able to get good insight into their agile adoption and performance.