So far, we have concentrated solely on agile development. But there are other practices out there that emphasize many of the same techniques and ultimate benefits, including lean and design thinking. Jeff Gothelf believes that these different practices were productized by trainers and coaches eager to sell their services to company teams. And ironically, rather than ultimately deliver efficiency and collaboration, the bevy of practices to choose from has only made it harder for different teams in a company to work together. The answer is to identify the common components and find unique ways to use them together across your organization, including short development cycles and putting your customer at the center of everything.
Getting comfortable with the components of an agile program is crucial for a Product Manager. These are the jigsaw pieces that define what is being built when things will be delivered, how the team is performing and will also enforce discipline in estimations. This article from the folks at Atlassian gives a nice overview of each of the components.
Scrum is central to an agile process. In it, the role of a Product Owner is defined as a person who has “final authority representing the customer’s interest in backlog prioritization and requirements questions”. However, it’s important to note that the duties of a Product Owner are only a subset of the duties of a Product Manager. The Owner definition stems from a highly technical environment where that person is responsible for making development decisions based on customer feedback, priorities or other factors. Whereas the Manager role involves broader company activities including strategy, marketing, and sales.
This is a good question to start with. In his answer, Roman Pichler summarizes the differences between old school and agile product management. The agile product manager you’ll see is directly involved in development, is constantly refining requirements and regularly speaking with customers.
Is the Product Owner allowed to be at the Daily Scrum event?
A big question, as a product person, is whether you are even allowed to participate in a Stand-up. Some argue, as you’ll see in this discussion, that Stand-ups are the domain of the engineers and a product person will not contribute positively to the group. But others argue that it’s essential that the product person participates. How much they should participate is another question — perhaps it’s enough to be a fly on the wall to learn how a project is progressing.
Looking at worst case scenarios will help you recognize Stand-up killers quickly. According to Jared Carroll, there are many common pitfalls including overcomplicating the discussion, delving into problem-solving (which should be done ‘offline’ after), starting too late and over-relying on software tools.
There are also several tools you can use to make your Stand-ups more efficient. Thomas Schranz names a few, the first of which may be the most important — the use of a Kanban Board. This board will often visually answer the three questions above allowing the individual updates to move along quicker. Not in the same room (or maybe country) as your team? Not a problem these days with services like Slack and video conferencing.
5 Scrum Meeting Best Practices: Master the Daily Stand-Up
Stand-ups, alternatively known in agile development as Scrum Meetings, can be powerful if done properly. Fortunately, there are relatively simple rules for being successful. Michael Lun outlines these which include sticking to three questions — what has been accomplished, what will be worked on and what is blocking you from doing your job. He also lists some common pitfalls including letting people ramble and allowing the Stand-Up become a planning session.