Technology and digital product companies today focus on developing winning strategies in the areas of products and markets. These strategies center around branding, creative design, advertising, marketing, customer service, sales, public relations, financial management, audience engagement and others. In most digital product companies, you’ll also find an underlying operational “triangle,” made up of Product Management, Engineering and Project/Process Management. Being strategic around these disciplines is no less important. The intersection of Technology, Product and Process is the heartbeat of successful organizations of these kinds. Without efficiency and optimization at this level to enable execution, the ability for an organization to fully achieve its mission is at risk.
Product development strategies should be based on outcome, not output. The execution strategy should include how an idea moves through the organization, starting with ideation, and if it makes it, until the day it launches as a product and beyond. Organizations that wish to achieve greater resiliency, reduced complexity and improved efficiency need to be willing to examine their ways of working and make certain that the process itself sets the company up for success.
Changing or fixing a process is not only difficult and potentially complex, it also isn’t very sexy. It takes forethought and planning and then getting groups of people to change their ways (and stop saying, “but that’s how we’ve always done it!”) Process changes also usually lack a spotlight or individual recognition and seldom receive attribution once products are out the door — irrespective of how the process contributed to good outcome. Regardless, leaders must recognize the significance and necessity of a well-understood and adhered-to set of rules-of-the-road in order to have the best chances of success.
The benefits here, though, are more than just creating a better way of herding cats. A great process should not only account for workflow creation and the shepherding of individual projects forward. It also needs to create and maintain effective channels of communication, transparency and key performance indicators (KPI’s). With the ubiquitous adoption of Agile methodologies, many of these mechanisms have greatly improved. But I’ve met with many companies who, when asked if they are using Agile, respond with, “yes…we’re doing Agile-ish Development. We have stories and sprints and standups but: [we’re understaffed/people don’t have time for all that extra work/our guidelines are wishy-washy/there isn’t enough enforcement/we only look at velocity and burndown/or you can fill in the blank].”
Companies that practice Agile-ish usually have good intentions. They want their development to be iterative and for their teams to be cross-functional and for status to be transparent. However, it’s usually these companies that also resort to shortcuts and workarounds in order to save time or energy. Again, with the best of intentions, they try to reduce the number of meetings on people’s calendars, meet deadlines, or rush a new product or feature to market. The effects of this are usually evident in the quality of the released product, but may also have detrimental impacts on employee morale, motivation, reputation and company culture.
Besides process, the other parts of the operational “triangle” are Technology and Product. When considering all three together, tech, product and project, it’s easy to see how the interpersonal functioning of the teams themselves is critically important. As I’ve mentioned in a previous post, highly effective teams, which are characterized by repeated adherence to and demonstration of “team norms,” along with the capacities of individual team members to practice these norms regularly and reliably, is critical. These norms sit at a layer above the foundational process and rely on good communication and the EQ of the team and team members to fulfill their purpose. According to Agile principles, the leading facilitators of project success are the individuals working on it and their opportunity and ability to communicate face-to-face.
A great process, motivated and balanced teams, project artifacts (stories, testing criteria, etc.), communication, and team norms are all important. But even so, there are still some “gotchas” worth noting that even the most proficient Agile teams should take note of.
Sharing resources: Mostly every company has people that perform specialized functions or are subject-matter experts in specific areas. Some examples of these are DBA’s, DevOps Engineers, Marketers, Advertisers, QA Engineers and Business Intelligence/Data Analysts. Most every project has one or more elements that fall in at least a few of these areas. It is impractical to have a dedicated representative from each of these disciplines on every Agile team, but their input is critical and, if it is missing, could end up being costly. Many companies get around the limitations of not having endless staff by assigning these experts to multiple teams where they are expected to participate whenever needed at various points during the epic.
I’m not advocating completely against this strategy. I’ve admittedly needed to set things up this way, usually because of resource constraints. I raise the issue here for two reasons.
First, to caution against ignoring the need to maintain tight control over these resources’ availability and the most appropriate ways to request their participation and/or attendance. (In other words, how to best “protect” them?) Some companies maintain a master chart of these folks’ availability overlaid with the Agile team’s regular ceremonies to avoid conflicts or the need for the expert to spend all of their time juggling meetings.
Second, to remind companies that hiring more developers and/or product managers in order to “move faster” will not be successful unless there is proportional attention paid to the pool of specialists. Adding more to the top of the funnel will only help if there is a wide enough opening at the bottom – and that means having enough resources to catch what falls through. A bottleneck in one part of the process impacts overall efficiency, but can be avoided by planning properly and ensuring that the staffing is properly balanced.
Sometimes a hybrid or adapted method can work well: Agile is not a set of methodologies but rather a set of principle and values. By recognizing this, we can conclude that there is no one “method” of executing that is better than any other, nor a necessity to be considered Agile. So a possible solution to our shared resource issue might be to adapt the process to accommodate the specific ways of working of the shared group. To illustrate, think about a situation where requests typically are one-off’s or without predictable order (such as QA, DevOps or server engineering) and task priorities can change with the wind. Under such circumstances, we’d want the capability for tasks to be reordered easily and for there always to be a top-priority task for someone to pick up and work on. Utilizing a Kanban board for this group can enable them to view status at a glance, efficiently assign work and reduce the complexities around story-writing, estimating work and managing stories across sprints, typical activities when using Scrum as the methodology.
Agile creates a matrix: Companies strive to create and keep organizational hierarchies that are logical and orderly. Within most organizations, every employee is grouped with counterparts that perform similar activities or have similar skill sets. Enter Agile, and now employees belong to (at least) two teams with possibly two or more “bosses” – their HR/Org-Chart manager, the scrum master or project manager of their Agile team, the product manager (or product “owner”) and even possibly overly pushy project stakeholders. A company should address this unintentional matrix structure by clearly delineating roles and ensuring that everyone understands their place at the table. Coaching employees on both the process and effective communication strategies will help them clarify who should be answering to whom and can reduce the matrix effects.
Agile KPI’s are built-in, so don’t disregard them: Is it enough for a company to “think” that their process is working because products are making it out the door? A common talking point about the success of an Agile process is to refer to “velocity.” But velocity is just one measure among many that a well-run Agile program can reveal. Are we opening more bugs than we are closing? Are customer support calls increasing or decreasing? Are estimates accurate? And just what precisely does a “story point” represent? These questions and others can be answered by Agile KPI’s and the ones to choose and focus on depend on company needs. A good introduction to some Agile KPI’s to consider is here. If the numbers are there (or could be there), why not make intelligent use of them?
Skipping Agile ceremonies is a no-no: Does your company run regular retrospectives? Are sprint planning or story writing meetings mandatory for all? What about backlog grooming? Is burndown calculated at regular and appropriate intervals during each sprint? Agile teams are meant to start, stop and continue together and if members miss meetings or these meetings or ceremonies don’t happen at all, then there’s likely something wrong. Lesson: don’t skimp on ceremonies.
Not recognizing that Agile methodologies create more work and are slower: Does Agile create more or less work? I maintain that Agile creates more work and usually slows development rather than speeding it up. But the reward for all of this when all is said and done is higher quality products with fewer defects and more robust features, obviating the expenditures associated with problems in production. Despite this, many leaders still need to be convinced of the benefits of Agile. If matters like speed-to-market or reduced short-term costs are higher priorities for you or your company, perhaps you should either question whether you’re using the right methodology or if you are focused on the right priorities.
There have been volumes written about Agile principles and iterative development in general. The “Agile Manifesto” was penned in 2001, so we are nearly 20 years in. The basic principles of Agile go even farther back than this formal codification to 1970. Yet even with the great utility that Agile can provide, it also requires forethought, planning and appreciation for both its simplicity and complexities. Above all, it needs to remain resilient and adaptable to accommodate any company that wishes to adopt it. While it’s important for companies to invest in consumer-facing expenditures like branding and public relations, it is equally vital that they consistently shine a light on the way things work under the hood and always strive to improve it.
