Pull versus Push in the Software Enterprise
One of the most misunderstood facets of Agile and Lean Software Development is "Pull versus Push". Many practitioners take a naive and global approach: "Pull is always better". Push models are associated with old and stodgy command and control companies. I think it depends on the context.
Pull versus Push with regards to Tasks
One context for "Pull versus Push" is how to assign tasks to team members. In the push model an authority, a manager or lead, assigns the tasks to team members. In the pull model each team member decides which tasks to take on. The key to the pull model is sprint planning where the product owner and team jointly decides which stories and tasks to put in the sprint. After that it's up to the team to self-organize and execute.
I have a hard time finding scenarios where the push model of task assignment is better for knowledge work. Perhaps in times of crisis it can be necessary, but I still lean towards empowering and trusting team members.
"Pull versus Push" with regards to Software Development
"Pull versus Push" is also used in a completely different context: software development. And this is the crux of my argument: optimizing for empowerment and trust in this context favors a push model!
Open Source Software Development
Open source software is typically maintained and owned by a small number of trusted people that have committer rights to the open source code base. The owners are part of a community of contributors, who again are part of a larger community of users. New features and even bug fixes go through a lengthy process of discussion and voting by the community, approval by the owners, design, and finally implementation. Implementation is not even the end, next comes another potentially lengthy process of review, merging, and release engineering: the pull request.
The open source software development model is purposefully methodical, gated, and slow. Individuals are put into circles of trust, with the inner circle holding most or all of the power. Releases are typically infrequent and large batch, although how infrequent and large depends on the project. Control is favored over speed.
The Lean Enterprise
At LinkedIn, in contrast to open source software development, everyone is a committer to every code base. All of our developers are trusted members of the inner circle. This enables us to move fast in small batches and experiment cheaply. Given this, we default to a push based model for software development.
Even in a trusted group it's important to trade off quality, craftsmanship, and consistency with speed. At LinkedIn we have the concept of code ownership at the file level, and in the general case one of these owners must review the code before it is pushed. However, overrides are available. We trust and empower all our developers.
There are cases, for example our flagship application, and revenue and security critical code bases, where more control is favored. In these cases the workflow moves more towards a pull model.
Conclusion
"Push versus Pull" is a continuum, not discrete extremes. For open source development it makes sense to favor the pull model. In an enterprise context it makes sense to favor the push model. However, push models have proven to be effective for open systems (e.g. Wikipedia) given a strong enough community that self-polices. And inside an enterprise some systems need to favor centralized control for trust, safety, privacy, or business reasons. There is no once size fits all. The best of all worlds is a platform that supports both extremes, and is flexible enough to customize workflows on a continuum between them. That's what we're looking to build at LinkedIn.
VP of Software Engineering | Integration, Legacy System Replacement
1yWe discussed this article with our team this morning and it's quite insightful with loads of revelations just in the first paragraph. We'll be studying this some more and discussing it further next week. Thanks Jens, your work is making an impact here at Absa.
Scrum Master at Fidelity Investments assisting in Personal Investing's Virtual Assistant Platform providing insights to our customers. Enable Employee Resource Group Co-Chair for Enable NH.
1yThank you! New Scrum Master here and still learning so this was a really helpful article.
Sr. Datacenter Architect at Insight, IT Systems Engineering and IT Strategy
6yPictures remind me of the funny cartoon titled "midvale school for the gifted" showing a little boy struggling to get thru a door
Engineering Leadership at Airbnb. Scaling developer productivity and designing commit-to-production pipelines. Creator of @mockito. Core eng of @gradle 1.x and 2.x.
6yIn an active OSS, pulls and pushes are frequently used interchangeably: core developer pulls occasional contributor change. Other core developer pushes his own pull request after getting approval in the code review. I cannot even tell if OSS development is push or pull based :) Good article, concise and to the point.
Just some guy... ;-)
6yInteresting article. I would have to argue that the Push model also works well when it comes to Open Source. Those projects with a small set of committers who have a strong vision and passion for their project tend to be more successful. The Pull model may cause issues down the road when certain ideas are not fully baked (thought out) and can cause headaches when it comes time to correct these mistakes. Software development isn't a democracy. Ever seen a Duck Billed Platypus? ;-)