The world as we know it is growing more complex. As we automate away those things that can be easily repeated, we leave ourselves with ever more challenging work. The way we’ve worked in the past won’t necessarily work for today’s problems… or will it? Join Diane and Doc as they explore dimensions of complexity in software development and look at how teams and leaders might adjust their behaviors (and the software they create) based on the complexity of the problem at hand.

This hands-on, interactive workshop will provide a practical introduction to Cynefin (a sense-making framework for complexity) and show how it applies to the work we do every day as creators of software. You’ll map your own work to Cynefin and learn about applicable management styles and optimal team interactions for each of the Cynefin contexts.

“Success is not delivering a feature; success is learning how to solve a customer’s problem.”  ~ Scott Cook, founder of Intuit*

If this is true, then the next question is: what is your customer’s problem? Unfortunately there’s no magic trick to figure out what customers need. But there is a simple technique that can help you gain insights and build empathy for them.

Empathy mapping is a simple activity that you can facilitate with stakeholders (or anyone responsible for delivering products and services) to build empathy for your end users. It allows you to explore what your customers see, hear, say & do, as well as consider what they think and feel. This leads to insights about their pain and potential wants.

Because this is done collaboratively, using silent brainstorming, everyone on the team contributes to a shared understanding of the customer. So not only do you build empathy, but you also create alignment within the team and among stakeholders. And that can only help you be more successful. 

*as quoted in The Lean Startup, page 66

As companies introduce agile practices, the Business Analyst role is often left by the wayside. The title does not even exist in Scrum or other specific agile implementations, leaving many Business Analysts wondering where they fit in. But fear not! The skills of a good BA are even more valuable in an agile environment!

Join Diane Zajac-Woodie as she tells the tale of a new agile team, struggling with no formal training, a resistant corporate culture and unwilling team members. She shares how this team benefited from the communication, collaboration & facilitation skills of an experienced BA. She then highlights specific shifts that Business Analysts can make in order to help their own team’s transition. These include using story maps and writing executable requirements, just in time.

Embracing their new roles, BAs can also encourage team members to cross role boundaries. This leads to new skill acquisition and a more cohesive team, which ultimately leads to higher quality software.

It’s time to dial in for your daily scrum and your team is distributed. You punch in the number and sit on hold until “the host has joined the conference.” Patiently, you wait another few minutes while the electronic board loads on the screen sharing tool. Once everyone else has joined in, and after a handful of miscellaneous “technical difficulties” you’re finally ready to start being agile! Does it have to be this painful?

In our zest to be agile and collaborative, many distributed teams are struggling. We know that face-to-face communication is ideal, but it’s just not possible for some teams. This presents challenges such as a lack of engagement, frequent miscommunication, delays due to scheduling needs, and bloated invite lists for conference calls.

Graham and Diane have felt your pain. And there is no silver bullet. Together let’s explore some of the causes of these pain points and discover ways that we can still achieve high quality communication. You will leave with our recommendations for tools and techniques, as well as renewed hope that remote collaboration really is possible!

As a business analyst on an agile team, do you spend your time gathering decisions from product owners and passing them on to development teams? Are you tired of simply being a “proxy without power?” As a product manager, do you feel like you are just collecting stakeholder opinions and filtering them for the team? What can you do to boost your impact to your team?

Be more than a proxy.

By definition, a proxy means doing a thing “by the authority to represent someone else.” That job can be important, especially when stakeholders and customers have limited available. But teams need more.

In this workshop, Diane Zajac-Woodie demonstrates how you can be more than a proxy. Through some experiential exercises, you will learn what impact collaboration has on results and why requirements are just as important as ever. Diane also teaches you how to document requirements so people will actually read them. Using acceptance tests, you will practice writing requirements that describe the exact behaviors that you expect in a format that everyone understands.

Be inspired to embrace your role in an agile environment and leave with new techniques that ensure that you will be more than a proxy when you head back to work.

Scrum suggests that business analysts, testers and developers shed their old job titles and don the badge of “team member.” And current trends like mob programming further encourage team members to abandon their individual goals in the interest of team achievements. It seems there really is no “I” on some teams...but should there be?

In this session, Diane evaluates the pros and cons of eliminating job titles and examines the concept of becoming a generalizing specialist. What does that really mean? What are the impacts to the team? Can you maintain your individual skills while your contributions to the team are getting blurred?

Come and join in the discussion!

As a business analyst on an agile team, do you spend your time gathering decisions from Product Owners (or stakeholders) and passing them on to development teams? Are you tired of simply being a “proxy without power?” What can you do to boost your impact and become invaluable to your team?

In this workshop, Diane Zajac-Woodie demonstrates how any team can benefit from the communication and facilitation skills of an experienced BA. Through some experiential exercises, you will learn what impact collaboration has on results and why requirements are just as important as ever. Diane also teaches you how to document requirements so people will actually read them. Using Acceptance Test Driven Development (ATDD), you will practice writing requirements that describe the exact behaviors that you expect in a format that everyone understands.

Be inspired to embrace your role in an agile environment and leave with new techniques that encourage more cohesive teams and ultimately lead to higher quality software.