The puffin (puffin in English) is a profile that, leading a team of developers, has endless software functions with little or no impact on the business, customers or other employees.
A PUFFIN —( Plans unending feature factory initiatives), in Spanish would be equivalent to endless plans of feature initiatives.
This term of profiles suppose cost and no benefit, in addition to a great frustration of the teams that do not have any visibility in the organization.
The term Feature Factory came about when a software developer friend of mine complained that he was "just sitting in the factory, building features and shipping them out to other developers."
How to know if you are working in a function factory? There are clear symptoms that allow these structures to be identified.
- Shipping Costs metrics. Teams don't have to measure the impact of their work. Or, if measurement is done, it is done in isolation by the product management team and selectively shared. It is not known if the work performed worked correctly.
- Quick mix of teams and projects (also known as Team Tetris). Instead of sensible and understandable missions or initiatives, teams deal with role assignments and projects without knowing why or who should be responsible for what. Multitasking in all operations and overuse of resources.
- Theater of success around “shipping” with little discussion of impact. A lot can be said about an organization by the questions it celebrates.
- Infrequent (recognized) failures and scrapped work. Without eliminating or significantly improving previous functions. The primary measure of success is the features delivered, not the results delivered. Work is rarely dismissed in light of data and learning. The equipment lacks the necessary measure to admit production failures.
- No link to business metrics. Conversations about customer or business results do not exist or are infrequent. The team is unable to relate the work to key business and customer satisfaction metrics. Can't connect work with lor substantial business.
- No impact analysis. Product managers do not periodically review the quality of product decisions and therefore do not compare expected benefits with actual benefits achieved. The developers have "approved requirements," but product managers have no goals of business. Only speed and production are taken into account as a key performance indicator
- Obsession with prioritization. Discrepancies appear between the rigor of prioritization (deciding what to work on) and the rigor of validation (deciding if, in fact, it was the right thing to work on). The rigor of prioritization is uniquely designed to temper internal agendas so that people "feel safe." A lot of work goes into determining which ideas to work on, leaving little room for results-based adjustments and improvisations. Roadmaps, plans, show a list of features, not focus areas and/or deliverables.
- no adjustments. Once the work is "done" (according to the principles of development managers), the team immediately moves on to the next "project", leaving no time to iterate with qualitative and quantitative data that lead to improvement and improvement plans. quality.
- Culture of transfer of the deliverable. The team is not directly involved in the research, exploration of the problems/challenges to be faced or experimentation and subsequent validation. Once the job is done, the developer has little contact with support, customer satisfaction, and business results.
- Great Package Sets. Without the mandate to experiment, features are delivered in large feature packages, rather than incremental releases. If methodology is applied agile, it may be the case that, still working in sprints, but nothing new reaches customers at the end of each delivery.
- Search for income in advance. Functions are implemented to close new one-off deals. While this approach is not inherently wrong, the economic justifications are often weak (at best) and do not take into account the non-linear increase in product complexity (short-term benefits that accrue later). ) . Again, the idea that characteristics are the unit of measurement of value is reinforced. Product decisions lack sound economic vision and strategy.
- "star" projects. The constant delivery of new features overshadows other types of necessary initiatives. Reengineering, cost reduction and value delivery work have low visibility. Focusing on those star features detracts from tasks about the impact of new features on usability, maintainability, scalability, and so on.
