Agile Coach, Trainer, Improvement Leader
Member since 3 years
Specialises In (based on submitted proposals)
I’m a coach, trainer and leader with over 20 years experience delivering complex projects successfully.
I have a proven ability to train, coach and mentor teams to improve predictability and quality in their projects, by employing Agile techniques and other best practices in practical and innovative ways. I have a strong track record in building and leading highly effective teams that consistently exceed their objectives.
I'm a Certified Scrum Master, Certified Scrum Product Owner and Certified Scrum Professional. I've trained and coached hundreds of people in Scrum and Kanban practices internally at BlackBerry and have co-delivered several Certified ScrumMaster and Certified Scrum Product Owner courses. Feedback from those who have attended my courses include comments like “Melanie is an amazing instructor, she was able to answer all questions / issues I had with Agile in a way that left zero doubt of its effectiveness” and “The instructor was an expert and shared experiences and made the course very interesting.” As a coach, I have worked with dozens of internal teams to implement Scrum and Kanban effectively, where I have “far exceeded expectations” both when coaching teams new to Scrum and when helping experienced teams to further improve their Agile practices.
I've presented on Scaling Scrum at Agile 2010 and Agile Development Practices East 2010 and served as a panel member on Agile Adoption at Rally Agile Café.
Scrum, Agile, Kanban
Training development and delivery
Process definition and deployment
Metrics program definition
You're just not doing it right -- an agile coach's crisis of faithMelanie PaquetteAgile Coach, Trainer, Improvement LeaderIrdeto
schedule 1 year agoSold Out!
One of the most common responses to problems and failures in implementing agile practices is "you're just not doing it right." I've heard it from many, many coaches, and I'm ashamed to admit that I've said it myself. While "you're just not doing it right" is probably true, it's also not helpful. For the past year, the question I've been asking myself is: "Is it actually possible to 'do it right' in most organizations?
A little bit of background on what started my crisis of faith: One day, a little over a year ago, a question was brought for discussion at our company's agile guild meeting: "Is agile right for all types of development work? It seems like some work simply can't be broken down into 2 week pieces." Of course in 15+ years of using agile practices and 9 or so years as an agile coach, it's a question I've heard many times. Obviously, no one process is completely right for all situations, and the people who ask this question already know that -- they're usually just looking for an opening to tell you why Scrum is no good for them. I could have repeated the easy to find information about when to use Scrum or other agile practices and when not to, but instead I decided to see what others had to say on the subject -- so I did what every good coach would do: I googled it.
I found Michael O'Church's 2015 article about the evils of agile, and especially Scrum, and thus began my crisis. Mr. O'Church's article was somewhat unique in its passionate hatred of Scrum, but that's not what made me question everything I believed. The real kicker was this: it had 777 comments (at the time of my initial read of the article in mid-2016; it now has over 1300). And by my rough count, over half of them agreed with everything in the article.
It was a real eye opener to see how much the article's premise that Scrum was actually damaging to companies resonated with so many people, and how most of those who thought Scrum was a good thing had nothing to offer other than "what you're writing about isn't Scrum" (I agree, it isn't) and "your company wasn't doing it right" (right again, they weren't). But apparently hundreds of other companies aren't doing it right.
We've gotten really good at telling people that they aren't doing it right, but we still aren't all that great at telling people how to do it right. Most of the advice I've seen (and frankly given) fails to take into account the complexities of organizational culture and history, and the long entrenched fears, behaviours and motivations of the people who work in an often volatile industry.
In this session, I want to explore what stops companies from being able to do it right, and what can realistically be done to help an organization move closer to being able to "do it right". We spend too much time "trying harder". In this session, I want to come up with ways to "try different".
Accidental Agility: A tale of unintentional agile practices in a non-profit organizationMelanie PaquetteAgile Coach, Trainer, Improvement LeaderIrdeto
schedule 1 year agoSold Out!
This summer I had the opportunity to participate on the board of directors for a market in a small community in rural Ottawa. The amount of work required to organize a regularly occurring market is staggering. We were entirely staffed by volunteers with varying skills sets, work experience, age, and availability. Within the first few weeks of the market season, I realized that we were actually operating in an agile fashion - by accident! This talk will explore how a diverse group of people, most with no software development background, organically adopted agile practices in planning and running this community market. We'll also take a look at how some of the lessons learned could be applied in other contexts.
Adopting Scrum: Incremental or all-in?Melanie PaquetteAgile Coach, Trainer, Improvement LeaderIrdetoAnthony Weicker--Sean McFeePrincipal Scrum MasterIrdeto
schedule 3 years agoSold Out!
When a team decides to adopt Scrum, is it best for them to go all-in, adopting all of the practices, to the best of their ability, at once? Or is an incremental adoption, picking the practices that the team thinks will help them meet their, a better approach.
During this moderated panel discussion, four panelists who have worked on a number of different agile teams in a variety of roles will answer questions about Scrum adoption, covering the relative merits of the all-in vs. incremental approach, when one approach might be preferred over the other. The panelists will provide examples of both success and failures from their own teams.
We will take questions (and answers) from the audience throughout the session.
Using team kickoffs as a tool to make Scrum more effective
Scrum is a team sport. We ask people to work closely together in small teams to achieve a common goal. A significant failing in many Scrum teams I've worked with has been the team's inability to function as team -- they tend to function as a collection of individuals, focused on their individual goals first, and the team's goals second.
We have a tendency to put people together in teams and expect them to figure out how to work together and become effective very quickly, but we don't give them the tools to get started as a team, and move towards working together as team. In this session, we'll explore how to use a team kickoff to accelerate the process of team formation.
A Scrum Makeover - An experience report
Many teams think they are doing Scrum, when they really aren't. They are doing something that they think is Scrum-like, but not getting great results. In this experience report, I'll explore a team that thought they were doing Scrum, but really needed a makeover to get on the right track. We'll take a look at where they were before the makeover, what they changed, what sort of results they experienced as a result of this change and what actions and changes were key to making Scrum work (better) for this team.
What does agility feel like -- a new approach to goal setting
If we examine traditional goal setting methods, like SMART, we see that we've been encouraged for over 30 years to make sure that our goals are Specific, Measurable, Achievable, Realistic and Time Based. The theory being that if our goals meet these criteria, we will be more like to actually achieve them. From there, we take the actions necessary, we measure, and ta-da! we achieve our goals.
Only, in a large number of cases, we don't quite get there. A few things can end up happening:
- We get tired of pursuing the goal and give up
- We pursue the goal, but can't quite seem to achieve it, even though we know what we want and how to get it
- We achieve the goal, but find that somehow, the results are not what we thought they would be
Examples abound both in our personal lives and in organizations. We work hard to get a promotion, only to find that we aren't satisfied with the new role. We commit to a healthy lifestyle, only to give up on it after a couple of weeks. Organizations set goals for improvement, and don't achieve them, even though everyone did the right thing.
What if we are actually motivated by how we think achieving a goal will make us feel, rather than by the achievement itself? So really, when we were working for that promotion, what we actually wanted was to feel powerful and capable (even if we weren't conscious of it). We thought that the promotion would make us feel that way, but it didn't.
Human beings are uniquely motivated by feelings -- we do things that we think will make us feel good, and avoid things that we think will make us feel bad.
What does this have to do with agile development you ask? Well, in my experience as a coach and a ScrumMaster, I've watched teams struggle to adopt agile practices (even though they seemed to really want to) and I've watched team members resist implementing practices that have obvious, undeniable benefits, and wondered what the barriers were. The common thread in all of these teams seems to be the lack of understanding of how they want to feel on an agile team -- ultimately the "what's in it for me?" is missing for them. It's like leaving the "so that" off of the user story.
It's not enough to just want to "be agile". We have to know why we want to be agile, and specifically, what we as individuals will get out of an agile transition.
In this workshop, we will use user stories as a basis for setting goals, with a particular focus on using the "so that" to identify how we as team members, want to feel when work on an agile team.
I don't feel like it syndrome: overcoming resistance 15 minutes at a time
I suffer from a (sometimes debilitating) condition called "I don't feel like it" syndrome. I know what I need to do to, or what I should do, but I just don't feel like it. So I don't do it. The list of things I know I need to do but just don't do is long and varied, and ranges from things like tracking my spending, to exercise, to meal planning, to cleaning my house. I understand why I should do these things, I'd like to reap the benefits of doing these things, and yet, fairly often, I choose not to do these things, because "I don't feel like it". I'd rather drink wine.
Does that sound at all familiar? If so, I think you'll enjoy this session.
I'll discuss what's behind the "I don't feel like it" syndrome, and how I've used agile practices to overcome it. I'll provide specific examples from my own life that can be generalized and used by anyone to get over "I don't feel like it" syndrome. And you can still drink wine if you want to!
No more submissions exist.
No more submissions exist.