Happiness at Work Matters. When we achieve greater job satisfaction it has a huge impact on the productivity of our workers. The Happy Melly Business Network brings together videos, podcast, blogs, work life balance tips, and other valuable resources for entrepreneurs, managers and individuals who want to inspire happiness in their organization. So hopefully “I love my job” will become the new normal.
Happy Working Resource Hub
Happy Melly is a collection of people hands-on resources to help you learn how to be happy at work and to empower you to help others achieve job satisfaction. The Happy Melly blog is where our Funders, Supporters and an occasional guest sound off on this topic. It’s filled with work-life balance tips, small business resources, how to motivate employees and find out what makes people happy, and how social entrepreneurship is allowing people finally to say “I Love My Job!”
Last week an interesting debate was sparked on the very active #agile channel in our exclusive Happy Melly Slack community. So interesting that I asked all the passionate participants if I could share their points with the greater public interested in spreading happiness at work, while still having success at their jobs. They agreed so today we start to answer the age-old question (that we hope you’ll continue to answer in the comments below):
How can you measure the success of a project?
Since agile coaches and managers in general are managing unquantifiable human beings, this is a particularly challenging question to answer even though, in the end, at the vast majority of companies, we have to do just that, quantify the work of fellow knowledge workers and creatives.
Member Paul Harding re-asked our community this question one of his product owners posed, who it seems was asking looking for her or his own feedback, to discover ways to improve.
Paul kicked off the solutions brainstorming session with three ways he has tried to measure project success, by asking:
Are they creating small and consistent user stories?
How many stories have to be broken down into smaller chunks during a sprint? (as the team many not have had a good understanding of them at the start)
Are the stories independent? (i.e. no cross dependencies)
Perhaps this was how Paul kicked it off or perhaps it’s because our community sees the value of questions, what immediately followed were more members offering more questions.
Marjan Venema offered the following quantifiers of project success:
How clear is the product vision to the development team? (going by the prioritization of stories in the backlog)
Would they make decisions with regard to the product in the same vein as the product owner, in his/her absence? (For example with regard to the user interface and user experience, the reliability, sustainability of development speed etc.)
Immediately responded to by numerous heart reactions, Tomas Kejzlar then posed:
What about measuring it together with rest of the team by the success of the product & reaction of users?
Koen van der Pasch, agreeing with Tomas, then pointed out, “In the end things like user stories, slicing, independency are only far, far proxies for the success. The only measure of the success of the product owner is the success of the product.”
But then I guess that opens a whole other can of worms as to identifying how you can even measure the success of a product? In sales? In users? In usability? The list goes on…
Sarah Baca argued that, yes, the success of the product is important, but “I think that it’s fair to know what behaviors have been helpful for others in the past to have a successful bottom line.” She said it’s all about measuring success for the whole team, but that “each member has different behaviors to get there.”
Should the qualifiable aspects of a project be measured? Or should it only be quantified?
This led us into a bit of a semantics debate. Should success be only the quantifiable measurements or perhaps should it include qualifiable measurements too? Now this might not be what upper level management wants to hear but the consensus seemed to be to avoid the quantified at all and only hit the qualified.
Or as Koen said, “I don’t think you should have quantitative measures of the success of a P.O. I think you can definitely have quantitative measure of the success of a ‘hired help’ [or] consultant.”
There was some going back and forth over these semantics, but Marjan interjected some valuable advice:
Be careful what you measure, as it gets magnified. Looking for quantifiable measures in work that’s largely unquantifiable, like creative work, adds unnecessary pressure that can stifle that creativity. The quantifiable targets become the goals instead of desired behavior.
Seeking quantifiable measures at a very granular level, like team-level, leads to “local” optimizations that can be sub-optimal for the organization as a whole.
Marjan continued that “You may want quantifiable measures, because they are so nicely… quantifiable, and so easy to compare. I’m more and more inclined to use measurements only within the group or team that has control over these values, so they stay in control of how these measurements are used for their own improvement wishes. [This way they] don’t suffer from varying interpretations or hijacking for other — subversive or not — purposes.
She went onto suggest that to quantify the unquantifiable, it’s good to come up with survey questions — while staying aware of our own cognitive biases — using something like a Likert scale to compare resulting opinions.
How would you answer these project management doubts?
In the end, Paul’s product owner clarified what she or he was looking for, asking “How do I ensure I am improving and doing a good job? Also for HR purposes, like objectives, then I thought that in my opinion I can say I am good or not based on the following:
Does the team genuinely like me?
Does the team understand my user stories and my thought behind them?
Is the product and any new feature we develop of good quality? If the P.O.’s user stories were lacking, it could result in bugs and a poor user interface.
Are users happy with the product/new features?
Is my manager happy?
Does the board feel we’re achieving their vision?
It sounds like this P.O. has the doubts in how valued her or his role is, just like many of us, and is looking for validation and ways to measure that value. Perhaps Paul from his leadership position could work to create some sort of peer-to-peer recognition program that facilitates confidence and motivation.
So in the end did we come up with metrics for success? Well, as Tomas put it, “Depends on your definition of ‘metric’… just that there is no quantifier — a number — does not mean it is not a metric.”
What the community did come up with is a lot more open-ended questions each of us should be asking in feedback conversations with our teammates. And perhaps questioning is the most valuable communication tool there is.
Of course, Sarah may have summed the debate up best, it isn’t about coming up with an exact answer but enjoying the journey to possibly many answers. “I love this about agile coaching — it’s a skill that you can use to peel back layers and recognize different opinions and experiences.”
How would you measure success in a project? Offer us your advice, experience and tools below!
And this isn’t the first time we talk about measuring the unmeasurable. Want another glimpse at what it’s like to be a member of the Happy Melly global business network dedicated to happiness at work? Listen in on one of our Happy Melly Coffees, where we discuss and debate experiments in the workplace.
Get tips and tricks to support happiness at work by signing up for our biweekly newsletter. Sign up now to get Kudos Cards you can print out to start encouraging gratitude and recognition on your team!