By Erik Gfesser — Mar 6, 2017

Pyntail CEO Taps Erik for Consultation

This past week, I chatted with Kamran Qamar, founder and CEO of Los Angeles based Pyntail, which markets itself as the fastest growing mobile app and game development studio. Since its founding in 2010, Pyntail has delivered over 175 unique apps and produced 17 game titles. During our conversation, Kamran mentioned that their growth has led to doubling their workforce year over year.

Emily Piwowarczyk had initially reached out to me on behalf of Kamran after reading my blog. She had stated that they were implementing agile / Kanban practices, ended up having a number of questions during the implementation, and wanted to reach out to a couple people like me to chat.

The initial sample questions Emily had emailed me revolved around educating customers, addressing and overcoming objections, prioritizing work, and developers working on more than one product at a time:

When applying this process how did you educate your customers?
What were their main objections, how did you overcome them?
Once they bought into this how did you keep them involved. Do you regularly involve them in prioritization meetings?
From the internal team perspective, I imagine that one of your team members might be working on more than one project at a time e.g. an iOS developer might be primarily working on a new project but also supporting some previous app that he worked on, Correct? In this situation, how do you create that visualization and how do you perform capacity planning?

Kamran explained that he had incorporated Kanban into Pyntail processes about 4 or 5 months ago, earlier starting what he had referred to as "Scrum". However, he ended up having a number of challenges with external / end customers (defined as entrepreneurs and the Pyntail marketing team). We also talked about a number of other areas, such as his "project manager" also serving as Product Owner, as he said that this dual role has been a challenge.

(If you are wondering why I have the term Scrum enclosed in quotes, refer to an earlier post of mine from last year, which I closed with the following statement. "Remember: 'Agile' is not synonymous with Scrum, and unfortunately, 'Scrum' is not always Scrum. If you want to adopt processes that deviate from the framework outlined by the Scrum Guide, that's fine – just don't call them 'Scrum'.")

For additional context, Kamran explained that Pyntail is building a product for some entrepreneurs that is intended to be a competitor to a well-known platform that makes use of crowdsourced reviews of local businesses. Kamran had previously started 3 other firms, but the relatively new services / consulting offering at Pyntail is the first time he has delved into this area of business.

While Kamran did not initially use the term "Product Owner" in his explanation to me, he described the project manager as also having responsibilities around requirements gathering and the cataloging and prioritization of user stories or feature statements. And the Development Team was increasingly running into situations where members were not clear as to what was needed to be built and when.

More specifically, customers were complaining that the team was not implementing what they were looking for them to do around functionality, quality, and change requests. One particular area in which customers sought frequent changes was the user interface. Kamran explained that they had added agile ceremonies around backlog grooming to help alleviate these challenges, but he felt that grooming was not an agile practice.

The main takeaway that I provided during our discussion is that he really needs to organize around the application platform as a product, with a single person serving as Product Owner for this product, and to have stakeholders working through this person. Additionally, it might provide benefit to include stakeholders in Sprint Review meetings as long as these are limited to a few people, since it would be best not to risk overwhelming the Scrum Team.

For posterity, the following were my thoughts around the initial provided sample questions:

When applying this process how did you educate your customers?

To date, Scrum education has been internal, as my clients have been new to Scrum. As a starting point, what I typically do is create custom presentations to walk clients through Scrum guidelines, based on the Scrum Guide.

In every case, a Product Owner needs to be established. It is the Product Owner who coordinates with end customers. The main responsibility of the Product Owner is to manage the Product Backlog: driving product vision, determining priorities, and enabling Development Team understanding. It is important to understand that the Product Owner is a single person: no committees, multiple Product Owners etc. While committees can exist and can be beneficial to the product, these need to work through the Product Owner as a central point of contact.

What were their main objections, how did you overcome them?

The main objections that I have seen from past clients are often related to PMO-related concerns, as PMO representatives tend to want detailed plans. Planning is important with Scrum, but not detailed plans, as this tends to detract from its benefits. Timeboxing is inevitable because Scrum is viable for the life of the product, and determining lifespan is not realistic. Individuals going directly to the Development Team to make requests is also another issue that tends to arise, as this practice bypasses the Product Owner.

The interesting aspect here is that people tend to work in an agile manner even if they don't think they're doing agile. And every team has a process even if they do not have one formally documented. Scrum is not right for every team. If the organization fails at implementing Scrum, it should reevaluate what it should do in its stead. Just don't call it Scrum if it doesn't follow the core tenants of Scrum, as this tends to cause confusion. There are plenty of different processes out there.

For example, going directly to Developers can be seen as an agile move, but team structure needs to be respected due to priorities etc and so the team does not get derailed. Stories can be reevaluated etc in a Sprint, but significant changes that derail the purpose of the Sprint should not be made. Use Sprint Planning wisely.

One of the main ways to overcome objections is to focus on what the Product Owner wants. In most cases that I have seen, time to market was the driving factor. Being able to present the product at the end of each Sprint rather than waiting months and / or putting the team through unnecessary stress etc helps ensure team success.

Once they bought into this how did you keep them involved. Do you regularly involve them in prioritization meetings?

The Product Owner is the individual who prioritizes stories. Depending on what is being built, the Product Owner either has a sense of direction as to where things need to go, or they are regularly meeting with end customers. The Sprint Review is where discussions take place as to expected direction and where to go next (as a preview to Sprint Planning).

The Scrum process framework includes these events for a reason. These events help ensure that what is being built is what end customers want. Note that stories might have infrastructure related dependencies. Depending on the situation, there are various ways that this work can be handled. What is important to know is that the team should not be waiting. The team should have what it needs to progress with Sprint work.

From the internal team perspective, I imagine that one of your team members might be working on more than one project at a time e.g. an iOS developer might be primarily working on a new project but also supporting some previous app that he worked on, Correct? In this situation, how do you create that visualization and how do you perform capacity planning?

Ideally, a developer is only working on one Development Team. What is likely going to work best in each situation is going to come down to Sprint Planning, and Sprint Planning takes team velocity into account. The total number of story points for this individual should be equivalent to what they can do in one Sprint. The Sprint Backlog comes from the Product Backlog, and these artifacts only address one product. Merging Product Backlogs creates noise and team conflicts. More than one Development Team can support a single product, with one non-feature team supporting another team, potentially for specialized skills, but they need to work closely together.

Subscribe to Erik on Software