Not all team decisions need to be made by the entire team. There. Someone said it. In some cases, we can trust a single individual to make the decision because they have the most experience and insight. In other situations, we want a variety of interests and perspectives included to ensure a well-considered, unbiased decision. But how do we decide who and what and when?

Put down the RACI chart - there's a better way! A Collaboration Contract is a simple tool that allows team members to opt into conversations and decisions. With a Collaboration Contract, teams identify the decision makers, and through an open selection process, establish their desired level of autonomy. This is a not a decision-making tool, but a tool for assembling the decision making team with clear expectations and agreements.

Join Diane and Doc in this hands-on workshop where you will learn what it takes to run your own Collaboration Contract. Learn this powerful technique today and establish clearer decision making for your team tomorrow.

Useless \ˈyüs-ləs\

use·less: not fulfilling or not expected to achieve the intended purpose or desired outcome.

[Synonyms: futile, to no avail, (in) vain, pointless, to no purpose, hopeless, ineffectual, ineffective, to no effect, fruitless, unprofitable, profitless, unproductive]

If you want to stop building useless software, then you have to start understanding your customers. Unfortunately, there’s no magic trick for reading their minds. But there is a simple technique that can help you gain insights and build empathy for them.

Empathy mapping is a simple activity for your team, stakeholders and anyone else who is responsible for delivering products and services. It allows you to collectively 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 which are the keys to building more useful software.

In this session, Diane guides you through building an empathy map, showing you how to use silent brainstorming to encourage everyone to contribute. You will see, first-hand, how easy it is to work collaboratively to create a shared understanding of the customer. And that is the first step to start building software that customers find useful.

If your team uses velocity for planning but you don't find it very useful, this workshop is for you.

If your manager or scrum master or other pseudo-authority figure keeps obsessing over your velocity, this workshop is for you.

If you want to know about better ways to forecast when a piece of work will be done or how to gather data that actually helps your team, this workshop is for you.

In this interactive workshop, Doc and Diane share insights into metrics and how they can be used to improve your team's performance. From cumulative flow diagrams to lead time distribution charts to forecasting using Monte Carlo simulation and more, you'll come away with the ability to better forecast when work will be done and better diagnose issues with your process.

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 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 and facilitation skills of an experienced BA. She goes on to highlight some 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.

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.