Software development culture has been dominated by the hero. Rock stars, ninjas, and 10Xers have been the center of attention, giving the skewed perception that great software is the result of a single amazing developer. But this couldn't be further from the truth.

In this talk, Andrea Goulet, the CEO of Corgibytes, will share her experiences using vulnerability and empathy as drivers for Agile adoption and culture building. 

As timelines on application development and delivery continue to shorten, it’s no longer enough just to ask folks to work faster. Many managers are stuck between missing deadlines or burning out their people.

This was just one of the challenges for Promontory Interfinancial Network when it chose to implement Agile Portfolio Management over three years ago to speed the deployment of new financial technology software in an IT division of over 80 employees. Since its implementation, the number successful projects has more than doubled and late-stage overload has essentially been eliminated. Along with improving productivity, project visibility, resource allocation, and clarity of prioritization, the process has also been a highlight in audits and examinations as it demonstrates management oversight and risk mitigation.

In this session, Simon Storm, Senior Director of Enterprise Applications at Promontory, and the project lead in implementing Agile Portfolio Management, shares learnings from the implementation by the IT Management Team. He discusses how to get management buy-in, tips for customizing the Agile process for your institution, and his insights of how spearheading the Agile process can significantly advance your career by putting yourself in the driver’s seat of improving your organization’s productivity and collaboration.

Scrum is a project management framework and does not specify a set of how-tos or checklists that some other development processes define. Since Scrum can be implemented in various ways, it is easy—and often common—to misinterpret Scrum’s guidelines and make mistakes while implementing it. A new team, in their eagerness to “go agile” and adopt Scrum, often succumb to common pitfalls. Being aware of these mistakes is the first step toward avoiding or resolving them. Sumedha Ganjoo discusses and shares examples of some common mistakes that she notices new teams making. Examples include shared and unclear Scrum roles, excessive estimation, accumulating technical debt, failing to capture non-functional requirements including quality, and not having an effective retrospective. Scrum offers the opportunity to incorporate feedback iteratively, and watching out for these mistakes enables us to deal with them sooner. Learn about these mistakes, review your processes, and determine if you can improve the way your team does Scrum.

We've all heard it; the only constant is change. When an organization begins a journey for Agile Transformation, the changes piles up... Unfortunately most change management approaches focus on creating a project-oriented plan for this. Other approaches like Lean Change are more emergent, but aren't specifically designed to help people to cope with change itself, only to help make the steps smaller. Let's explore some complementary people-centric approaches:

• Transition Management to help people make the journey through the wilderness
• Appreciative Inquiry to build on the current strengths, and
• The Power of Habit, to help people unlearn what is unwittingly holding them back

As we talk through each of these, we'll focus on the role of leadership and how these techniques can help people become willing, as opposed to being coerced, partners. We'll close with a brief discussion on how to engage people creatively with storytelling and such approaches as Open Space, World Café, and other workshops. In thinking on techniques that complement change management approaches, we can improve the effectiveness and willingness of the people in the organization to join in.

Organizations in the midst of a bottoms-up agile transformation can find themselves in a quandary. Even though some (or even all) teams may have adopted agile at the developer / program level, PMOs are often still required to plan, resource, and report on progress with almost no consideration given to the methodologies of the underlying work. 

As organizations embark on agile transformation, many traditional project managers or business and technical leads are thrown into the Product Owner role after reading a book or two and, perhaps a few days of CSPO training. In the midst of changing environments, conflicting mindsets, and other change-related issues, they are expected to start operating within a Scrum team. Alicia Cyrus compares the responsibilities of product ownership and traditional project management—similar roles, with the same goal of achieving working software (or services) and productive teams, but very different approaches. Alicia explores how product owners should focus on the “means to the end”—organizing a strong backlog and eliciting solid requirements while assuming ownership of the relationship with their team. Product Owners need to help their team build trust and find their best approach to achieve successful delivery. Alicia offers experience-based techniques for positively influencing the team’s continuous improvement and taking collaboration to the next level, identifying obstacles, and managing them head-on to prevent roadblocks to the team’s motivation and performance.

Have you ever imagined how our ancestors built Stonehenge, the Great Wall of China and the Pyramids without the tools and technology that are available to us today? Now imagine today’s world without the internet, smart phones and technology. What do you see? I see that there have been generations before us and there will be generations after us which will develop ways to survive, excel, and perish. One thing that is constant is change. Most of the organizations today acknowledge that change is good and have discussed it in great detail; however, but fall short in realizing the change.

Change is an absolute truth. No one can agree with this more than organizations in today’s cut-throat competition, where constant change is the norm for their survival. Organizations which are slow to respond to change or resist change are on the verge of being obsolete. They need to change for various reasons such as external competition, market pressure, performance issues, changing workplace demographics, globalization etc. Organizations which invest in proactively responding to change are more likely to not only survive or but also emerge as leaders, creating new markets which never existed before. When organizations are successful, they become complacent and continue to do what worked, but in doing so you keep getting what you were getting; where is the growth in that? The main reason for organizations to resist change is in their mindset; change is perceived as negative or with skepticism. How many times have we heard the phrase “if it ain't broke, don't fix it.” Many organizations have fallen victim to this mindset and have become extinct.

Product owner provide requirements and its business value to IT which in turn works on building a solution. Usually the focus is geared towards building the correct solution based on customer’s requirements. But can we guarantee if the requirement and the business value provided by the customer is right? Does the product owner really know if their requirement adds value? We propose a shift in how the requirements should be processed. Instead of accepting requirements based on business value and customer’s need, we suggest a scientific method of evaluating a requirement to see if it really does add any value prior to adding it to the backlog. Most of us in our early school years might have studied in science the scientific method for asking and solving a scientific question.

We all know how paramount collaboration and communication is among members for success in the Agile world. People, Process and Tools are the three pillars of any organization. This session will focus on the people aspect of Agile. Teams are made of people who come together to work on a project from their diverse backgrounds - each of whom bring with them their respective personalities which has developed and evolved over time. According to the Myers-Briggs indicator, there are 16 personality types and each personality type has its own pros and cons. An organization’s success is largely dependent on its team’s personality which in turn is driven by the personality of each and every team member. In this session we will explore questions like – What has personalities to do with Agile? Why do we care? What is the impact of personalities on an organization’s success? Which type of personalities promotes team members to thrive? Which personalities create bully behavior in the team and toxicity in the organization? Can personalities evolve over time?