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.

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.

Agile is not about doing scrum, kanban, lean or any other flavour of the process. An organization cannot be “doing” agile, they must “be” agile. They must believe in and understand the agile principles. After going through a successful agile transformation and running scrum for 3 years we realized that it’s just not working for us anymore. The team was suffering from scrum fatigue. It felt like there was a sprint planning, stand up or retrospective meeting happening all the time. We decided to take a hard look at how we were working and turn it on its head. We looked at all the different agile options such as scrum, kanban, lean, xp, etc and decided to take the best part from all of these instead of sticking with one approach. This session will take you through our journey and share what worked for us that could also work in your organization

This is a new presentation with the goal of sharing our lessons learned in the adoption of an agile project management approach, with a focus on Scrum, within our web development (Drupal) agency.

The rules and practices for Scrum - a simple process for managing complex projects - are few, straightforward, and easy to learn. But Scrum’s simplicity itself - its lack of prescription - can be disarming, and new practitioners often find themselves reverting to old project management habits and tools and yielding lesser results.

There is a very real misconception that people believe....just because they have a daily stand up once in a while or because they only plan work for the next week at a time that they are being agile. This simply could not be farther from the truth.

Doing agile does not mean you are being agile!

Just because you have a stand-up, does not mean you are being agile. Just because you only plan work for the next week, does not mean you are being agile.

There is a lot more needed for a company or a team to be agile and it is a lot harder than you think....but understanding the difference is half the battle.