If you can run a solid, clean usability test, you have the foundation for almost any UX research method out there. In this rapid-fire session, we'll cover the basics of usability testing, including Who, What, When, Where, and Why, (not necessarily in that order) plus top Dos and Don'ts. Attendees will leave with just enough information to get them past "dangerous". Issues addressed will include:
The future is now!
Artificial Intelligence is the new hotness, and it's time that you and your big enterprise get onto it. Although, it might seem like science fiction, integrating AI solutions into your applications isn't as far off as it seems. You just need to know how to start, and where it can provide value.
In this session, we will prime you up with foundational knowledge about current AI solutions available from the vendor and breakdown the service catalogue. Then we'll talk the challenges of delivering an AI solution, from defining requirements, goals, and differences in development.
What makes you different makes you wonderful. The differences that make us unique and special whether they be our race, ethnicity,cultural traditions, religion, gender, sexual orientation, and/or personalities types can also be a source of contention.
How do you handle talking to those who are different and not your typical crowd at work? Do your day to day conversations leave room for others or can they only be understood by a small group of fellow coworkers? Are you willing to find the person most unlike you and strike up a conversation? Â Most importantly how can you make an impact on fostering a more welcoming workplace?
During this talk we will walk through these questions together by defining what diversity is and how it impacts an organization, describing what it means to be an inclusive workplace, provide detailed steps on how to best evaluate to what level your workplace promotes diversity and inclusion and last but surely not least provide guidance on steps you can take to influence your workplace culture from the ground up.
Participants of this talk will walk away with a greater understanding of what it means to be a diverse and inclusive workplace. Participants will also step away with individual steps they can take to become advocates of change to create a more welcoming work environment.
Too much design up front and you are bumping into the design all of the time (and losing time). Not enough design and your system can crumble in reality. How do you blend architecture so you have the right decisions at the right time, and give them enough due dilligence? How do you embrace cloud and microservices and not risk getting into different failure scenarios or overly complicated maintenance and ripple effects?
In this session we will walk through visualizations that help teams blend product thinking with architecture. Along the way, we will look at microservices and domain modeling as well as chaos engineering and fault tolerance - blending all of these into a context that is consumable by all and gives the right emphasis at the right time.
Leave this session with simple visualizations and approaches that you can apply immediately to start blending product with architecture, especially if you are looking to run in a cloud world.
Have you ever been so excited about building something to only find out much later itâ€™s not working as expected? Well, after building your exciting new thing did you try to break it, use it in an unexpected way? ensure beyond a doubt that your application is safeguarded against all possible unintended functionalities?
In an ideal world users would use applications we build in specific predefined ways allowing us to build for the happiest of happy path scenarios. Though in reality, that doesn't always happen. This talk will dive deep into how testing your application in Â unexpected ways at different points of the development process can allow you to discover bugs and hidden vulnerabilities and will conclude with a live demo inviting members from the audience to try and test some applications in the wild. It will be exciting, it will be daring, and most importantly it will highlight the true joys of quality engineering.
Chances are good that your organization produces data, maybe even a lot of data. But do you consume it effectively? Is it worth using? What can you do to make it better? In this session we’ll look at data (with a focus on the Microsoft tools) and how you can produce it with quality, and what techniques and processes you can use to make it into a complete and balanced diet.
Data Science is an emerging field that draws from Mathematics, Statistics, Computer Science, and Information Science. Its subdomains include machine learning, classification, cluster analysis, data mining, databases, and visualization.
Python is the fastest growing well-known general purpose programming language, and along with R is one of the two most popular languages for Data Science.
In the first half of this session we’ll explain what Data Science is, why it’s in such high demand, why Python is so popular with Data Scientists, and how an interpreted language such as Python can be fast enough for them.
The second half will be a demo and hands-on tutorial showing you how to use Python, Pandas, and Jupyter Notebook for data exploration and analytics of one or more data sets.
For the hands-on tutorial participants should prepare their laptop (Windows, Mac, or Linux) before coming to the conference by installing the latest Anaconda Python 3 distribution from http://Anaconda.com/downloads, then installing Jupyter by opening the Anaconda Prompt, typing "conda install jupyter", and following the default prompts.
It has been 18 years since Martin Fowler published Refactoring which codified an initial catalog of code smells. But in that time, have our noses been able to sniff them out? What have we done to develop our sense of smell?
We will do a series of Sparrow Decks to increase our sense of code smell by building the pattern recognition part of our brain. This way we can more easily know if there is something wrong with the code. Remember smelling you have a problem is always the first step.
(Note: this technique works for non-programmers as well as programmers so even if you're not a programmer, come and develop your sense of code smell!)
Developers are 'makers'. We like to get things done. The more productive we are, the happier we are. This connection between productivity and happiness has been researched in the field of positive psychology as flow: the theory that people are happiest when they are in a state of absorption with an activity, or in the zone (credit: M. Csiksgentmihalyi). Through the exploration of specific practices such as personal Kanban, the Pomodoro technique, and Test Driven Development, this session will present how to effectively harness the power of flow to improve happiness while also producing high-quality deliverables.
The opposite of ambiguity is certainty. In the absence of certainty, organizations often settle for standardization i.e. getting everyone “on the same page” and “speaking with one voice.” However, successful organizations realize the capacity for understanding, appreciating, and fostering difference is critical for evolution and meeting the needs of diverse markets.
Is the secret to effective and lasting organizational change getting everyone on the same page and speaking with one voice? While coherence is important, successful organizations understand, appreciate, and foster difference. This session provides attendees with some tools to avoid the the siren song of standardization and make peace with the diversity and ambiguity that are necessary for evolution.
While the GetKanban game is a great way to learn some of the foundational concepts about Kanban, the game just takes too long to play. Mike Burrows created a version that can be played in a much shorter time, and allows for teams to create their own flow of work - this is Featureban. Through this activity, we'll explore the benefits of WIP limits, how we track our work using Lead Time Charts and a Cumulative Flow Diagram. And, we'll cover many of the elements of the Kanban Method, such as creating explicit policies.
When the Phoenix Pay system was released in April 2016, it had severe problems affecting some 70% of the people who the system was intended to pay. It has been fraught with issues ever since resulting in under and overpayments of those employees, and in some cases no payments at all. Hundreds of millions of dollars have been and will be spent to correct the pay issues and update the system. The people working in the pay centre in Miramichi, NB, have been overwhelmed to the point that retired compensation workers have been recalled to deal with the crisis. This was yet another example of the ineffectiveness of the antiquated approach that the government used to deliver Phoenix.
When the 2018 budget was tabled, nearly half a BILLION dollars was allocated to fixing Phoenix! What seemed like a footnote to that was $16 million over two years to _study_ how to build the replacement system.
Study. That's what finally broke me. I had been grumbling at the stories of Phoenix for years, but this finally triggered me to do something. I began tweeting to government officials, and Justin Trudeau himself, that they were going to end up taking the same approach and making the same mistakes again. I wrote a series of blog posts detailing the approach that I'd take, and given my 30 years of experience, 15 of which were building systems small & large in the federal government, this was anything but armchair quarterbacking.
This session is about what I believe the government should actually do to replace Phoenix, and what has happened since my Budget Day tweetstorm and subsequent blog posts. I will also welcome ideas from the audience and we'll discuss how we would leverage the collective experiences of the group to deal with building a system as large and complicated as one that needed to pay some 300,000 people from 40 departments and agencies and a number of unions.
Organizations that are accustomed to developing software in a particular way often struggle with change, and typically reach a tipping point where change is required in order to survive. Moving from a software development process and an organizational structure that focused on large, adjusted estimates in order to handle contingencies and unknowns when delivering projects, to an Agile organization capable of absorbing change and delivering value to the customer while minimizing time to market, has been a very interesting process for RAPID RTC. We will walk you through our process for making the change, getting buy in from the required stakeholders, and converting SDLC processes from waterfall approaches to an agile methodology.
CEO of the Product. Product "owner". "The Business". With terms like these, it is no wonder that the relationship between Product Managers and Engineers can be contentious at times.
Better products get built when teams are collaborating and working together across disciplines. Product managers and engineers provide needed balance to each other. But too often the balance gets shifted and an "us vs them" mentality emerges. The lack of trust erodes collaboration and keeps teams from operating at a high-performance level. This talk aims to address some common misconceptions about product managers, and discuss how product managers and engineers can work better together to reach a common goal - building products people love.
As Artificial Intelligence (AI) becomes more accessible, software engineers will be more apt to incorporate these algorithms into the systems they build. While many of these algorithms can make software systems safer and more efficient, there can also be a downside. Human error can increase with too much automation.
In this thought-provoking presentation, the positive and negative impacts of AI on human performance will be presented. You will be equipped with a working understanding of these impacts and leave with a framework for determining the right amount of AI to mix into your system that will truly help your users. The goal for practitioners is to find, identify, and implement the â€œjust-rightâ€ amount of artificial intelligence - the Goldilocks AI."
Does your organization rely on heroes to complete your products and projects? Fuelled by pizza, coffee and who knows what else, they work all hours, flat out, giving 110% (even Mathies agree) to meet that critical release date. Sometimes they do it week after week. It isn't pretty. It isn't smart. And it isn't agile.
This session will offer ideas that aim to stop or prevent that unsustainable and costly scenario.
In her work as a trainer of agile practitioners, Sue has a view of Scrum life through the eyes of Scrum Masters, Team Leads and other technical professionals here and around the world. She sees a pattern - make that an anti-pattern - that gets in the way of team productivity, effective work and project success. It's the gap between the expectations organizational leaders hold or were sold (twice the work in half the time, anyone?) and what's possible under the circumstances.
Changing those circumstances is the role of agile leaders. While few believe, ""install Scrum, fill up Jira and you're agile,"" there's an apparent belief that Scrum and other aspects of agility are the responsibility of the teams, alone. For everyone else, it's business as usual and that leads organizations to to demand and reward heroic behaviour, which leads to quality slips, burnout and interpersonal drama.
In this session, you'll examine this challenge and explore what we might do about it. We'll create some realistic expectations, based on the patterns of effective teamwork.
We interact with others on a regular basis, and help each other all the time. We rarely take time to analyze how we're interacting with others. This activity allows us to become more aware of how we interact with others, and expose us to other ways we might want to consider incorporating in our approach.
As a Chapter Leader of Girl Develop It (GDI) I have had numerous companies ask me why can't they get women to apply to any of their openings. They want to diversify but have a "pipeline" problem. My experience as a woman in tech and helping women enter the tech field through GDI tells me otherwise.
In this discussion we'll consider the some of the common reasons women might not apply to certain companies and or job postings, examine some of the â€œred flagsâ€ you might not realize you are waving, explore ways to make the hiring process more inclusive and discuss how to determine where the breakdown may be occurring.
For each of the RESTful actions we'll identify the typical messages that flow across the team boundary and identify specific methods that can be adopted to respond, ease communication stress and promote a common understanding of the state of the team and its work.
We seldom place these practices in the context and language of development teams and show the connection between the mental models of the team, work and the organization. When ideas or practices appear and sound foreign or extraneous to daily experience they tend to become an extra burden rather than a useful tool.
So let's talk about helpful methods in familiar language.
Feedback has the power to transform your team. Effective feedback is one that motivates, informs and empowers team members to do their best work. Ineffective feedback poisons a team with contempt and dismay. This session provides you with a framework so you can collaborate more effectively.
If you work with people, this session is for you. This presentation is part lecture, part hands on. You will have the opportunity to put the framework to the test - and even receive some feedback on your feedback (so meta). This session will:
As knowledge workers, we are tasked with exploring and solving problems. Complexity theory can give us a helpful way to think about a wide variety of problems and potential countermeasures in context, addressing everything from architecture to organizational design to technology strategy.
Participants will leave with a basic understanding of complexity theory including some increasingly common frameworks (Cynefin, Wardley Maps) for making sense of knowledge work.
In 2011 we embarked on a journey to turn TFS into a cloud-hosted SaaS product – now called Azure DevOps. This session will focus on the architectural challenges we faced, how we evolved and refined the architecture over the past 7 years, and lessons learned along the way. Should we re-architect first then move to the cloud, or just get it up there ASAP and re-architect afterwards? How did we address multi-tenancy? How do we take advantage of the benefits of cloud, without sacrificing the ability to deploy on-premise also? How do we optimize the costs of cloud hosting (yes, even we have to pay azure bills!). What does the future look like in terms of architecture (hint: containers everywhere!).
Want to watch some kung-fu movies?
Ok, now that we have your attention, do you ever feel like other people are getting in the way of building great software? Like you are trying to do what is right, and nobody understands you, or worse, others have it out for you? Have no fear, you are not the first! Believe it or not, we can learn how to face this adversity with grace and come out on top by studying the cinematic kung-fu masters - spoiler alert - it's really about understanding the people around you.
Wuxia, or "martial hero" stories, like the Kung-Fu classics made by the Shaw Brothers in the 1960-70s, told tales of heroes rising from humble beginnings to right the wrongs of their times. The secret to their success was often right before their eyes, such as the town drunk who was really a kung-fu master, or a woman posing as a man to get the respect she deserved. Although we may not get to have epic kung-fu battles in the streets (cubicles), we can learn empathy from these movies which will allow us to create our own hero story. This talk will explore the common themes and tropes of the Wuxia genre and how they can teach us to take a more humane perspective with our colleagues and the people challenges we face every day. You'll walk away with some lessons learned and a deeper connection to co-workers and kung-fu movies.
Co-creating drawings helps teams enhance their systems thinking abilities by really seeing the big picture. A group of people talking around a whiteboard is an effective way to share ideas across a team. Imagine how much richer the conversation is when everyone on the team has a marker in their hand and is actively contributing! Graphic visualization is an important tool for talking about new ideas, generating insights and developing shared understanding. In a team context, drawing is a thinking tool rather than an artistic endeavour. When everyone participates in creating drawings, all team members can see how things fit together and what mental models are at play in defining the situation. And, by drawing together, the team is collaboratively creating meaningful records that are being validated and updated.
Join Sue for a visual adventure into how teams can collaboratively visualize ideas and make sure that everyone at the table has a voice. In this workshop, we'll warm up with some basic doodling skills practice. No drawing experience is required to take part in this session: if you can hold a marker, you can learn the skills needed to put your ideas on paper. Together we'll consider the ways that collaborative drawing can be used to enhance group work, and we will share practical activities that you can take back to use with your team for setting the stage, gathering information, and sharing stories.
Roadmaps can be a somewhat controversial topic in Agile software development. In this talk, we will discuss how user experience plays a vital role in the validation and prioritization of a roadmap. Taking inspiration from the cartographers of the Age of Discovery, we will discuss the ins-and-outs of maps and walk through centuries of maps to understand what maps are good at (and not so good at).
After our historic tour, we will circle back to a form of Story Mapping based on a data-driven approach, leveraging design thinking and user validation. This technique has been used to help companies from startups to Fortune 50 companies to identify and prioritize opportunities for innovation based on the needs of their users.
In addition, there will be a collection of historic and modern maps on display, demonstrating a number of the elements discussed in the talk.
Metrics are the bane of many organizations, getting fascinated on measurements that don't matter or can drive improper behaviours. In this session, we walk through a simple grouping for metrics where the groupings not only call out the metrics, but their limits, and help guide to better metrics.
In general, we are leading transformations where the standard questions around metrics (velocity, bug, mttr,) come up - and we use these groupings to help organizations to get some answers for questions they want, but also understand their limits. I.e. if code coverage goes up, that might be good directionaly but does not say we are getting code coverage of the important code paths. We wrap up the session giving examples of more impactful measurements and walk through process behavior charts to help separate signal from noise in data.
All of us multitask, and some of us may even be great at it. Is that a good thing? Whether you are proud of your multitasking skills, or are frustrated by working when you are asked to work on more than one thing, are you able to articulate why this is good or bad and what options you may have to use your time more effectively? Join us for an exercise and discussion on the pros/cons of multitasking using the Hands/Numbers/Song game. You will gain insights into the costs of task switching and have answers the next time you are asked to take on one more thing.
A "happy" team is an "Efficient" team. The intended audience are developers, leads, managers and any individual part of a group or aspiring to lead a group.
This talk discusses how eBay embraced Agile methodology and as part of this effort, how we formed a new team to manage Identity Infrastructure. This talk takes the audience through the journey of how a group of individuals got together and transformed to an efficient and highly productive group. The journey is wrought with hurdles, battles and conquests and this talk bares the details of how a team rallies together against a common enemy. This talk identifies the key points of what keeps the team cohesive, motivated and challenged and the lessons learnt on how to keep a team "Happy" and always in the pursuit of its "Happiness"
We will discussing some of the ground rules, how to centralize the right things, how to breed a culture of learning, need for a safe space etc., How high levels of automation help achieve better quality of life. We would be talking about how everyone acts as everybody and flexible to take up any role and much more."
At CBC we define service design as a human-centred approach to creating and delivering holistic, seamless audience experiences across the CBC ecosystem. As we change and adapt, we have to strategically think about the public services we provide to our current and future audiences. These need to be intentionally designed, thoughtfully structured, and systematically executed. Canadians connect with CBC in multiple ways, and build a relationship with us over time. We can develop and deepen this relationship by helping them seamlessly experience the CBC ecosystem. This careful orchestration requires: a problem solving mindset, collaboration across all aspects of the organization, and a toolbox to practice this approach within the reality of the organization. This talk will focus on the increasing adoption of the service design discipline, and CBC's adventures in embracing this approach.
On the TFS/VSTS team at Microsoft we moved away from a waterfall-ish process to a more agile process. We started with scrum (ish) and have evolved over the years into something that works for us across 800+ people, and 40+ feature teams. We believe that changing the culture among the teams is by far the most effective way to effect change, also the hardest. We'll look at what we did to change our culture, our agile practices that focus a lot on providing alignment and autonomy, our various planning horizons (yearly business strategy, planning seasons, feature chats, etc), and the changing roles and team structures over the years. We've made some mistakes along the way and learned a lot of lessons.
When it about converting business requirements to code, there are hundreds of best practices and frameworks available for developers to refer to. However, when it is about security for APIs, it is a well guarded secret on how does internet giants tackle their API security. What are there best practices. There are very few in this space who can ascertain to the credibility of their API and Identity assertion systems. This talk targets the uncertainty around the functioning and utility of tokens in an API security landscape. It addresses the basic needs of a token infrastructure and what would it take to build one. This talk aims to help developers embrace security and identity as part of their tool chain and remove the skepticism around building their own API security. The developers should be able to use this discussion as a launchpad for building their own API authentication systems. This is a unique talk as many companies closely guard the secret of how their token infrastructure functions.
This session will present and discuss simple visualization techniques to structure useful conversations about evolving role changes for organizations in the midst of adopting agile principles and practices.
Part experience report, part presentation, this session is intended to explore how to have better conversations about where the work goes and who does what when adopting agile approaches and methods in project-oriented enterprises. You'll learn the value of identifying skills needed and available in teams and how to reduce the risk of blocked work and how to improve the delivery flow through teams.
Does your organization DevOps?
It's a challenge no matter what you do, and it is especially difficult to get things moving when you have years of technical debt and a culture of accepted manual processes, but it's not impossible.
This session talks about getting DevOps practices setup in an legacy technology environment, and talk about the journey David has experienced starting the DevOps movement at the University of Manitoba, including the wins, the blockers, and some of the mistake he's seen (and made) along the way.
Come join us to learn about the Agendashift approach to learning organizational health and exploring obstacles to desired outcomes to achieving meaningful strategic improvement.
We'll explore Agendashift with a brief introduction to the survey tool and a debrief followed by a 15 minute FOTO (From Obstacles to Outcomes) game wherein we can learn to explore clean language and improve our coaching toward the strategic application of Lean flow.
The agendashift survey is a framework agnostic tool for exploring existing organizational systems and making a plan for improving them.
Most dev teams "own" some code that they don't really want to work with. However it got there, the code is scary but pretty stable but now requires updates. Perhaps your team draws straws to each time to figure out who is going to have to put on the metaphorical hazmat suit and deal with the problem. Or worse yet, your team relies on one developer to always do it and he or she is getting burned out and could leave at any minute.
Mike will share some techniques that will help you modify the code with confidence using a few core refactorings and characterization test.
This talk reviews the ups and downs, trials and tribulations of my time as a manager, with advice of mine that I took, advice that I threw away, and advice that I modified.
In this talk you'll learn that even Agile Coaches are fallible! We examine common coaching topics and how well (or not!) the advice I had given others had worked for me when I had to actually apply it. The primary goal is to determine how to take what I learned and apply it in your organizations and business domain.
Come learn Kanban by engaging in activities such as demand analysis and board design. We'll talk about flow and Kanban Principles while doing some Kanban ourselves. Should be a fun time playing games and doing some Kanban.
Depending on the product in question, good experiences reduce development and support costs, generate revenue, increase word of mouth marketing, improve employee efficiency, or any combination of these. Good experiences don't happen by accident, though - they are intentional, iterative, and egoless. Creating them requires multiple touchpoints with end users during all stages of design and development (regardless of the development method used - and yes, you can do it with Agile).
In this session, we'll cover four major ways good experiences provide business value.
Rubber, meet road. IaC is the process of source-controlling your runbooks. It's Dev and Ops collaborating to drive results greater than the sum. Using Ansible and AWS CloudFormation, but generic understanding, this session aims to accelerate your DevOps journey and power value into production.
User experiences are multi-dimensional. Some aspects are very concrete and easy to measure, whereas some aspects are very abstract in nature. A holistic system of measurement is needed to capture both, the concrete and the abstract. A meaningful system of measurement should not only be diagnostic in nature, but it should also also help teams aspire to a higher level of product experience. Experiential maturity of a product refers to the growth of a product’s user experience beyond the basics. Hira will discuss a framework for measuring a product’s experiential growth, and how it impacts users’ relationship with it.
Tech is one of THE MOST exciting industries to work in. Besides that literally, ANYTHING IS POSSIBLE, and we are solving the worlds' most interesting problems, tech companies are driving innovation in terms of employee culture and engagement. Every day in tech is new and exciting.
On paper, working in Tech is my dream job.
Why then, did I subconsciously remove myself from coding, advocating for women in IT, my awesome and well-paying corporate career, an opportunity to work for Google (literally my dream job) and nearly walk away from the industry altogether? How had the first academic subject that actually challenged me, become so uncomfortable that I couldn't waste any more of my precious hours with it? And how many other brilliant women (and men) has the industry lost to a similar story?
Long story short, it was how I *felt* in my daily activities that encouraged me to kick into fight-or-flight.
As I moved away from development, I moved towards coaching and personal growth. I strengthened my emotional intelligence by becoming aware of my thoughts and feelings and how I was being affected by my environment. I questioned and rebelled against my "todo" list and my relationship to *efficiency*. And eventually, I even found my way back to an appreciation for the technology in my life, what it allows me to do every day, and that it really is a force for positive impact in the world.
Let's end the pattern of good people leaving development by appreciating what we each have to offer. Learn about my story and what facilitated in my leaving tech so you can recognize your own career trends, find more satisfaction in your work week and help others stay on course.
Men, you have it easier than women when it comes to working in tech.
If this statement makes you angry good! Hopefully it makes you angry because you want to be a part of an industry that works for everyone. Do you read all the news reports about the diversity problems in tech and think someone should do something about that? Maybe that someone should be you!
You might be thinking how can I help fix this problem as a guy? Will the women around me think I'm sincere? Yes, you can be a big part of the solution. And, yes they might question your sincerity at first, but with time and effort you can show everyone that diversity is important to you too!
There will be mistakes along the way and that's ok. We make mistakes too. But by learning from those mistakes and continuing to try, we can make tech a better place for everyone.
Some of the topics we'll cover are: