I was very pleased with Exadel's performance in a recent Forrester Wave™.
We participated in the Midsize Agile Software Development Service Providers, Q2 2019 Wave from Forrester. We were named a Leader in the report and given the highest score in the Current Offering category.
It was really great to work with all of our Agile experts here at Exadel. We worked hard to put together our response and talk about the exciting Agile software development work that we do for our clients and ourselves.
Exadel has been doing Agile development for a number of years and it was great to get to talk about our Agile capabilities. Our Scrum Masters really know their stuff, and it was cool to get recognition for this.
The most effective Product Owner I have ever worked with did not have that title. I mention this at the outset of the post merely to say that titles don't really matter that much. What matters is the role itself and organizational empowerment to do the job right.
You have a Product Owner because you want to go fast and develop great software. If you don't have one you are making the choice to go slow, which is always a bad idea. You may develop great software anyway, but it will take longer than it needs to.
The product owner is a critical role in modern software development. The Product Owner’s role is to supply the following to the development team:
Product Vision
Release Vision
Feature Backlog
Prioritization
Decision Making
Effective Product Owners work with stakeholders (usually customers, executives, business decision makers, and visionaries) to supply an effective workstream for their projects. Very often good Product Owners are neither the visionary nor an executive, but are someone with the ability to manage those people and the guts to make decisions about the product.
Ineffective product owners are too busy doing other things to be bothered with the day-to-day decision making of the team and leave questions unanswered for long periods of time, delaying the work.
Effective product owners manage and participate effectively in two work cycles:
The Development Sprint Cycle (usually 2–3 weeks) A good Product Owner makes time to attend important meetings and answer questions for the team doing the work.
The Product Development Backlog Cycle – A good product owner is constantly working with business stakeholders and customers (end-user customers) to understand what is working and what isn’t.
Ineffective Product Owners don’t spend the time necessary to get their product backlog prepared. This leaves their teams unable to plan or estimate work – delaying progress, de-motivating their teams, and creating blind spots in cost and timeline for their projects.
Effective product owners work hard to understand their competitors and customers, they know their place in the industry and where they are trying to go. Being an effective Product Owner is typically a full-time position, I seldom sees a product owner that can handle owning more than 1 product, and I have never seen one able to effectively handle more than 3.
I just completed my Scrum Certified Product Owner training and certification class here in Boulder. It was a really excellent class taught by scrum guru Mike Cohn.
I learned a lot about how to do the expectations for the role of product ownership, and lots of techniques and processes for how to do the job effectively. The class was very engaging with a good mix of instructor-led content and group activities.
One of the most significant aspects of being a Product Owner in scrum is making decisions and prioritizing work.
Here are some things that will make it difficult to do the job effectively:
You aren't given the authority by your organization to make decisions for the product.
You don't give yourself the authority to make those decisions.
You have a hard time making any decisions.
Number 1 on the list is something that you can do something about, and we spent time in the class discussing it.
If you are undercut by superiors or colleagues, you need to address that with the superiors and colleagues. Often times they may not be aware of it, in which case simply brining it up is enough to make a difference.
In other situations you may need to understand the why of the situation and seek to improve your understanding of the business or your boss vision. Then when you are on the same page you will have less conflict and less decisions that have to be revisited.
If the your boss, colleagues, or team leadership fundamentally doesn't trust you or anyone to make those decisions - seek alternative employment.
Similar things apply here. If you believe that you can be an effective product owner and make the necessary decisions based solely on data, abstract principles, and rational thinking, you will run into problems. You will never have enough data to make all the decisions you have to make NOW.
You can have the data in 3 months, but the world may have passed you by then.
An effective Product Owner is going to Know a Lot - they will know the domain, they will know the analytics, they will know the users (some of them personally). They will use all of these things to make decisions.
But they won't (and can't) know everything. Even if you could know everything today, you wouldn't know everything tomorrow.
And when you don't know everything, you will have to make decisions in the absence of data. In these situations, you need to know your instincts and trust your insight to guide you.
And trusting your gut means listening to and understanding emotions - and being able to defend that decision. Whether you call it trusting your gut or rapid cognition you will need some of it to be an effective product owner.
If you aren't used to working this way, then you can choose to focus on the activities that will make your insights and intuitions more informed - learn things, focus on data, know as much as you possibly can.
Then when you need to make a judgement call, you will have a solid foundation that you have built upon to get there.
But when the time comes, you will need to decide in the absence of data, and you may have to argue your point, so be ready to put some feeling into the discussion and push for what you think is the right answer.
When you find yourself in such a situation, the best and easiest way to handle this is to recognize that this is the situation are in: You don't have enough data, you will need to make a recommendation and push for what you think is right.
I find that simply acknowledging the situation as such - whether externally, internally, or both - is very helpful.
It is also helpful to remember in these situations that most bosses want someone who will make a strong recommendation and push for what they think is the right answer.
They will see you as providing decisive leadership and be able to back you up in your recommendation, without needing to get deeply involved in the data, details, or weeds. You are smart and well-informed, it's your decision to make as the product owner.
If you run into headwinds here then the same recommendation applies as above: seek to understand those headwinds, adjust if necessary, continue making recommendations based on the best data available.
You may be wrong.
We're all wrong sometimes.
Being wrong is an opportunity for further introspection and learning. Accept it as such, make further adjustments and move on.
Software and technology are bringing a lot of changes to our lives - just think of the things in the news set to make waves in the near future - robots, AI, blockchain, and self-driving vehicles.
If only part of the revolutionary claims for this tech comes true, the world will look very different.
It's exciting.
This cocktail of technologies brings a lot of opportunity as well a great deal of upheaval.
One thing I've noticed about this digitally transformed world: every technical requirement of a project is also a business requirement.
I've often heard these words spoken: "That's just technical detail."
But I agree with less and less as time goes on.
It sounds wrong now. Just a technical detail? What product are we building here?
Yet it's true, in a way. It is a technical detail. But that doesn't mean that it isn't important or you can just ignore it or you can pretend to ignore it until it becomes a problem.
So how do we deal with this?
Over time we'll all benefit from current changes in eduction - more focus on reasoning, outcomes, and learning code will help. More people who know what code is and who have written a line or two will help demystify the whole thing a bit.
Business people: You need technical awareness and patience and you need to ask the good questions. Again, eduction will help.
Technical people: You also need patience and improved listening and communication skills. I've written before about the pain of the unasked question. Ignoring hard questions because you don't like the answer isn't OK. Ask the question you know is there.
We all need to get better at explaining trade-offs in non-technical ways. This really shouldn't be that hard.
But what is the quickest fix? What can happen now? Where do I see people stumble?
The answer is more agile adoption and commitment to great product owners.
Needed to spend half their time talking to people buying the product (getting their thoughts on the latest incremental release and how it delivered value) and half their time with the team creating the Backlog (showing them what the customers valued and what they didn't).
That would definitely help a team move fast and understand the right technical/business requirements very quickly.
It's why I believe so strongly that Agile is the right methodology and that following as closely as possible to the recommendations makes sense. I've seen a lot of product owners who did a lot of the first or a lot of the second, but only a few who did a great job of balancing both (and who were given the organizational bandwidth and charter to do it).
Today everything - every part of an application - is a business requirement. Waiting around for business experts to answer questions, when they have many other responsibilities, is a delay that almost no one can afford any more.
We all have to go fast.
And we all need the business expertise and customer awareness built into our teams.
I bring this up because it's something that I've heard a few times over the years (including recently) and I think it's worth examining the hidden anxiety behind this statement.
On one level, agile is not anything like communism. Agile practices extend some of the decision making in business to people close to the problem, people who will do the work. In this way, it's much more like a capitalist/democratic system than a communist/authoritarian model. In democracies individuals have agency/a vote/influence in the system (just like agile) and in capitalism individuals/businesses control the means of production and what work gets done, not a central authority (just like agile).
Looked at in this way, the answer to the question above is clearly 'No'. Agile equates to democracy and looks nothing like communist/authoritarian systems. But this doesn't get at the anxiety, which I think is important.
Why the comparison? Why do people say "Agile = Communism"
I think it's because in traditional businesses (a key feature of capitalism) the democratic principles of society don't extend inside the business. Inside the business the business owner and their appointed managers run the business and make key decisions. The businesses themselves demonstrate the authoritarian characteristics that the rest of society does not.
Looking at in this light, I think the anxiety could be expressed thus, "Agile is not like traditional business management and that makes me nervous. So, I will express my fear by equating it to something that also doesn't look like traditional business/capitalism, which is communism."
This fear is not unreasonable. Agile is different. It does distribute decision making differently. I think that it is hard to relinquish control and you should expect this type of reaction to change, as you should expect this reaction to ANY change at all. It's just one more manifestation of anxiety around change.
So, where does that leave you?
Understanding doesn't mean accepting. You understand the anxiety to facilitate the change, not give in to the resistors.
We've seen that the pace of change in life and business is accelerating. Predict and control structures become outdated too quickly. Your prediction will now almost certainly wrong because the assumptions that underlie your prediction lose their currency quite quickly.
Why rely on the assumptions of one person? Why not have a high functioning team working together? In this way, agile can be part of the antidote to the anxiety.
You (and your leadership team) need smart people working on effective teams with the ability to execute. Whether you call it Agile Management Practices or Holocracy or something else, it makes sense when the world changes quickly.
Of course, individual business owners and leaders are free to make decisions to run their companies in whatever way they see fit, that is capitalism.
But, as a leader, don't you want to hire the best people and get the most out of them? Empowering them is one way to do that. It does require you to let go of some control. And it does require you to have enough governance to ensure people don't bet the farm or the business without oversight.
But after that, you WANT people to feel ownership and make decisions. It's going to make them more loyal, successful employees, and it is going to help your business be more effective in the long run.
Jonathan Fries on .