I’ve work in product management for a decade now. Over that course of time, I’ve watched the company change software development philosophies several times. Not all of these changes resulted in positive improvements, but the impact of these changes on the software development lifecycle and engineering culture is fascinating. For this blog, I discuss the four different approaches taken during my time with the company and the results of those approaches. Note that not everything in here is typical of these processes. In many cases, we implemented the approach in an ineffective way, which lead to some process failure. These are my experiences, and your mileage may vary.
Stage 1: Kanban
When I first joined the product team, many moons ago, the young company had only a single team of engineers. Back then, software development used Kanban, including a Kanban board that listed the various tasks needed. Under this form of Kanban, sprints do not exist. Instead engineers accept new tasks immediately after finishing a prior task. Product managers were required to constantly groom new tasks to keep up with the engineers.
One of Kanban’s focuses is on constant deployment. This frequent deployment and change in tasks made software evolve at lightning speed. Customer requested features were often implemented within days or weeks of getting the requests. Everyone delighted in the constant smorgasbord of new features. Of course, no one was very happy when a new feature broke something. However, we could repair any outage within hours or rollback with minimal effect. The product was fun to work on, even if keeping up with the constant change was taxing. UX and marketing experienced the most hardships. The fast timelines left UX little room for testing designs and the impact of new features. Marketing also struggled to keep up with engineering and complained that the constant deployment meant they lacked a big press announcement about new features. Note that Kanban can accommodate bigger changes with proper notice to marketing and UX of what projects are coming up. However, in this case, planning that far in advance never happened.
Kanban was super fun and, for me, the upsides of speed and agility outweighed the negative aspects. The teams were forced into a tight-knit group in order to meet the need for speed and constant change. This made going to work very pleasant and rewarding.
Stage 2: Classic Scrum
As the company grew, Kanban became increasingly difficult to manage. With additional engineers and new teams, conflicts arose both in work and in code. In turn, the conflicts increased the number of outages and rollbacks. I believe Kanban can work with large teams and comprehensive unit tests, but the discipline required from engineering proved too much. We switched to classic scrum.
Using classic scrum, the teams switched to two-week sprints, daily standups, and a dedicated scrum master who held the members of the team accountable for their performance. Each product manager was assigned as specific area of the project, allowing the engineers on that team to focus their skills .In addition, we added true cross-functional stakeholder meetings and sprint demos. These meetings were a relief to both UX and marketing as the heads-up gave those teams room to plan.
The primary downside of scrum was the noticeable loss of speed compared to Kanban. With sprint planning and team coordination, fixes that used to take a day could take up to three weeks. One week of planning plus two weeks of waiting for the change to reach the top of the priority list. The other perceived downside was the leadership team felt a lack of control over the planning process. Roadmaps in scrum are ordered lists of priorities. This mean that the executive team was never sure when a project would complete. Combined with the lack of immediate changes, the use of scrum led to frustrated business leaders.
Of the various approaches, I thought classic scrum worked the best. Although we operated slightly slower, the total amount of product produced over all teams was significantly higher. I also liked having slightly more time to plan and the focus of product on future changes rather than the immediate tasks.
Stage 3: Large Scale Scrum (LeSS)
The engineering teams expanded with additional company growth. Eventually, we reached a critical mass where, once again, the engineering teams were stepping on each other. With six teams working on one project, each with their own product manager, conflicts became common. The PM releasing first usually ended up owning that particular part of the product.
To fix the conflicts, the company pivoted to large scale scrum (LeSS). LeSS is similar to traditional scrum but is designed to deal with multiple engineering teams working on the same system. LeSS features a main product manager that coordinates between the product owners, each of which has responsibility for certain areas of the product. The product manager decides which stories are a priority based on the the customer impact and completeness of the specification.
The main issue with LeSS is political. With one person deciding priorities, the different product owners felt more like advocates for particular agendas than dedicated to a single team. The lack of embedment with engineering corroded the relationship between product and engineering, leading to less trust in the product plans. On top of that, the UX team could never be sure which product owner had the most important task. Sometimes UX would end up working on a part of the product that never received prioritization. With LeSS, if the product manager is constantly diligent, the whole process breaks down. LeSS also didn’t solve the management oversight problem.
I liked LeSS slightly less than Kanban. LeSS ended up feeling too political. The product manager simply didn’t have the time to review all of the proposals and sort out the presentations effectively. I think LeSS would have been more successful if the engineering teams aligned more closely with the product owners rather than the product manager at the top.
Stage 4: Waterfall
The final, and current, evolution of software development approaches was a retreat to waterfall. Despite the CTO trying to pivot towards a more agile framework, the CEO and current SVP of product really like the theoretical oversight waterfall provides. The waterfall approach features a beautiful project plan. Managers and sales can share this project plan, pointing to what the future holds. When the project plan came out, everyone was excited about the end-state product. Customers especially appreciated the long notice of what we planned to release and the end-state specifications.
Unfortunately, we ended up experiencing every classic waterfall pitfall. The project has significantly deviated rom the project plan. All parts of the project are late. That big fancy document that the SVP touts around? No one reads it. Everyone still likes the end-state, but the actual plan is more of a marketing and sales tool rather than a product specification. This causes friction between the business and engineering.
Although the waterfall process appears super organized on paper, the reality is chaos. Despite being happy about the documentation, the management team is more frustrated than ever because of the missed timelines. I personally have found the decline to waterfall fascinating. It’s a textbook case about the pitfalls listed in every article on agile.
Summary
My recommendation, based on experience, is to stick with agile. There are lots of agile methods available, and every single one worked better than waterfall. I loved Kanban, but I definitely experienced issues in scaling Kanban to large organizations. If I could change one thing, I’d go back to classic scrum.
