May 10th, 2016 by Christian Hauschild

This is the 4th installment of our series about being a Product Owner. For the other posts, see here, here and here.

Give me information

The Gatherer mainly focuses on gathering as much information/feedback from stakeholders as he can. This helps him build a direction for the product for a specific period of time. Although he gets new requirements, features and requests, he strives to keep the direction steady and aligns new requirements to it. Together with the team, he prioritizes the backlog consequently. This helps him ensure that the direction is clear to the team.

Remember to write it down

The Gatherer keeps a personal log for all the possible long-term features that could be implemented in the product. He notes everything down regardless of whether the come from from customers, or by comparing with other similar products in the market. As soon as one of these features is barely considered valid for implementation, adds them to the product backlog and discussed it with the team.

Groomed and clean

He insists on frequent grooming sessions; they keep everyone in the team informed and mentally prepared for the forthcoming tasks. Moreover, grooming sessions keep the backlog clean and optimised, since most of the old issues would have been already solved and need to be deleted or rephrased.

 

Team, Team and Team

The Gatherer always tries to keep the team involved. At the regular meetings with customers, he usually summarises the notes and shares them with the team. Likewise, he tends to convey the feedback from stakeholders (positive or negative) about the development process, the quality of deliverables, and their expectation to the product and the team.

 

A responsible role

As a Product Owner, he believes in the role as responsible for defining the product path. That is of course after analysing requirements, business needs and use cases. He has established a strong relationship with the customers, based on mutual trust and sending a clear signal that he takes product ownership seriously.

 

This post concludes the series about different flavours of a Product Owner.

Now hiring in Dubai! - Read more

Posted in develop software, process Tagged with: , , , , ,

April 26th, 2016 by Christian Hauschild

This is the third installment of our series of blogposts about different ways to be a PO. For the previous posts see here for part 1 and here for part 2.

The Buy-in pwns

If you look up “complete ownership”, there’s likely to be a picture of this Product Owner. He identifies with the task at hand to an extent that it requires the most stern-hearted 1940’s British nanny to not be won over to his team. If he believes in something, there’s no doubt that he will run in front to get to the finish line. He has a knack for formulating visions and goals which are both ambitious and attractive.

His greatest strength is also a challenge: his own buy-in means he has to work hard to get a similar sense of ownership in the people he works with. He manages this by being really well prepared for any conversation where he suspects it might be necessary to defend a decision or align expectations.

Don’t do it if you can’t sell it

The Buy-in has a knack for selling. He’s not the traditional salesman with well-honed skills of persuasion, but rather he makes a choice. A very conscious choice to trust his own buy-in. A choice to believe in his buy-in and an admirable ability to accept that it is necessary to thoroughly understand those who don’t share his devotion before he is ever able to enjoy their support.

The moment he feels even the most subtle signals of agreement, he sets all sails and his unwavering enthusiasm becomes apparent.

You really have to talk to someone about this

When structuring the backlog, there’s calculated strategy involved. In his case, it’s the communication strategy which prevails. If he can successfully communicate his reasoning for priorities, he feels that the prioritisation is right. This forces him to consider both his customers and his peers and he must make an effort to understand their expectations and perspectives in his work.

 

In the next post, we’ll look at The Confident PO.

Now hiring in Dubai! - Read more

Posted in develop software, process Tagged with: , , , ,

April 19th, 2016 by Christian Hauschild

This is the second installment of the series about flavours of a product owner.

The Inquirer asks a lot of questions.

He does so because it helps him get closer to defining the value that a user story or an epic represents. He understands that users often create their own detailed mental model of a system, which is somewhat removed from the implemented model. Both the questions he asks and the answers he gets, help him discover the users mental model, and translate that to value described in user stories and epics.

To do this, he plays the “Why?”-game.

The “Why?”-game

When a user tries to communicate what he wants by describing his mental model of the implementation, this POs most common response is asking why the user feels he needs the feature and asking for clarification on what the user hopes to achieve.

By asking, he is be able to identify the use case behind the request, and perhaps more importantly, the real value that the user is looking for.

With a clear idea of the required value, he can author user stories which focus on the desired value.

Talking to the team

He can use this to communicate with the team without having to discuss implementation.
This empowers the team to design the implementation and deliver the required value with as few constraints as possible.

During the course of development, the team naturally encounters areas which require additional business input and decisions. The Inquirer makes an effort to return the teams questions and will aim to use their very extensive knowledge and understanding to return to the core value of a given user story. Does the team feel that one or another decision will contribute to delivering the value?

Is there any chance that this PO will also deliberately end a conversation with a question?

 

Next week we meet The Buy-in.

Now hiring in Dubai! - Read more

Posted in process Tagged with: , , , ,

April 11th, 2016 by Christian Hauschild

What makes us unique as Product Owners?

What defines and characterises each of us?

In the coming weeks, we will try to characterise how we are different as Product Owners in our organisation in order to highlight the quality of variety. By identifying our differences we can work better to support each other – something which is easy to overlook outside the traditional scrum team configuration.

No two the same

Whatever your title, I’m sure you do your job differently than anyone else with that title.

What you focus on is the result of a combination of things: varying expectations (from boss, colleagues, self) or a preference for some specific tasks – probably those where you experience success more often.

Sometimes, you place your focus where you feel the need to improve.

Most important of all, you contribute where you feel your contribution is valuable. If there’s an unoccupied space that you think it would make sense for you to step into, you do it. You claim ownership of that space and do your best with it because you feel it’s the right thing to do at that time.

The choices of an Agile Product Owner

As a Product Owner in a truly agile organisation, you get to make a choice about where you want to place your focus at any given time and provide value to someone. One minute you are working within a development team and the next you are aligning with a customer, trying to make more sense of what value they are actually looking for. To build a useful network and gain more understanding of the product in full, you spend time in the server room with an admin installing hardware and deploying software.
The above tasks are all vastly different aspects of crafting software. All of those things need to be done to make it in our game, but nobody expects anyone to do all of it. That’s why we work in teams.

A team of Product Owners

We are currently 5 Product Owners working with each our product. Some products have overlaps and collaborative opportunities. Others don’t. Regardless, we can use each other and our differences to become better at our jobs and create better products.
Working in a team doesn’t apply only to developers, testers and devops:

That is why we are trying to be a team of Product Owners.
In forming ourselves as a team, we have discovered that we have vastly different interests, skills, experience and focus, which we can use to help each other and deliver more value, faster. Just like a team.
To get an idea of how we complement each other, we are working with identifying what makes us unique as Product Owners; what defines and characterises each of us. In addition, it’s also an attempt to show that none of those unique qualities are better or worse than any other. Rather, it’s to encourage that everybody benefits from us working as a team.

Product Owner Flavour No. 1: The Visual

The Visual Product Owner has an ability to put himself in the users’ place. He thinks visually and spends time generating ideas and designing an experience for the user. This makes it easier for him to communicate the value to the team.

He has a challenge: suggestions for implementation can easily be construed as dictating a solution to the team, so he has to ensure that the experience he designed in his mockups are perceived as suggestions from someone who cares intimately about the product.

Time well spent

He spends a lot of time producing social glue and listening to what the team says about priority and product. As a positive side-effect, he is included in the team to a great extent.
To ensure there’s no doubt about responsibilities, both he and the team sometimes address him explicitly as “PO” when a Product Owner decision or opinion is required. His personal opinion is not always the same as his professional Product Owner opinion, particularly when it comes to prioritisation.

Working with the backlog

When working on the backlog, he looks through what is in the top third-ish and make sure that each user story has a clear description of value using the syntax:

In order to <value>
As a <stakeholder>
I want <feature>

He looks only as far in time, as he can couple with events in “real life”, with the reasoning that: “If I don’t know what I am doing in my spare time 3 weeks hence, it’s likely to change anyway”. It’s the same with the product backlog. Things beyond the structured top of the backlog are constantly subject to change.

Epics are used as a tool for grouping. The groups can be prioritised and the priority of the epics help when working on the backlog. User stories from different epics can easily be worked on at the same time. The epics are more a tool for managing stakeholder expectations to when delivery of specific work is planned.

 

Next week, we’ll look at another flavour: The Inquirer.

Now hiring in Dubai! - Read more

Posted in process Tagged with: , , , , ,

March 7th, 2016 by Jonas Mellquist

Say hi to Ben.

benBen likes taking things apart and trying to break stuff.

Ben is a software tester at Teletronics. He spends a lot of his time troubleshooting errors and eliminating bugs together with his colleagues.

By taking the users’ perspective he helps the team make sure the common thread is maintained. Voicing his opinions and giving input about new features and upcoming changes to the software comes naturally.

Often, he takes a different viewpoint because he believes a healthy discussion gives a better end result.

Ben really enjoys the many different aspects of software development where he can help out his team. In a day, Ben could spend his time:

  • Setting up different test-systems
  • Using his terminal to get things done
  • Playing table tennis with his colleagues during breaks or after work to loosen up
  • Helping others
  • Coming up with test scenarios together with the developers
  • Taking charge of the release process by making sure everything is sorted before handover to the client

Not many days look the same for Ben who is always helping his team out where he is needed.

It’s important for Ben to feel like he’s contributing to something he can be proud of.
He often takes the initiative to organize and participate in various social happenings with his colleagues.

We need more people like Ben. If you’re it get in touch. We’d love to hear from you.

 

Now hiring in Dubai! - Read more

Posted in develop software Tagged with: , , , , ,

February 18th, 2016 by Christian Hauschild

This is Khalid.

Khalid says: "Join our team"

Khalid says: “Join our team”

He would like to expand his team.

Khalid is curious about how things work. He has always been curious about that and has so much experience with figuring stuff out, that he fairly quickly can gain overview of complex systems and understand how they are put together. This helps him to find creative solutions to seemingly impossible problems.

Khalid is keen to enable others to experience the same kick as he gets when a new system is fired up for the first time and works, when approaching a new interesting and unforeseen challenge with confidence, when resolving a bug in a production-critical system and when helping design a system by providing important operational details that others had not yet thought of.

He is a modest yay-sayer and his surroundings appreciate his willingness to share and his ability to include. As the technical go-to guy, that goes a really long way when you are part of a team.

Khalid is hoping that more can join his team so they can build even better products together.

Now hiring in Dubai! - Read more

Posted in develop software, Uncategorized Tagged with: , , , ,