With the increasing integration of Yammer into SharePoint, there will be a lot to learn for SharePoint practitioners from a technical perspective. How to bring Yammer feeds into existing sites or replacing the newsfeed? What social interactions should be done in Yammer or SharePoint? What about search? The list keeps getting longer. What might be overlooked however is what SharePoint project teams can learn from how Yammer work, not the product they produce.
Yammer’s development practice revolves around a few core principles. In this blog post, I’m going to discuss two in particular:
- Data Driven Development
- Time Limited Development
Yammer’s Data Driven Development
In simple terms, the Yammer development cycle follows the basic structure of the scientific method.
1. First, a theory is proposed- if we do X to the product then the outcome will be Y for our users.
2. A test, or tests, are defined that will prove or disprove whether the theory is true.
3. An experiment is run within the confines of the test. In this context, some development is done and the code released to some users. Crucially it is not released to all users- an equal proportion remain on the old code as a “control group”.
4. Data is analysed from the control group and the test group. If the outcomes are more successful in the test group, then the code is implemented for all users. If the control group is more successful, then the code is not implemented but our understanding of the user base has increased.
This approach allows a truly informed decision making process. Rather than rely on the preconceptions of a project team, business stakeholders, or a vocal minority of users in a focus group, Yammer choose to follow the data- even if it disagrees with their assumptions.
Even a failed experiment is a long term success if it’s backed by data. It increases understanding of the problem at hand and informs the next iteration of development theories.
What Can SharePoint Teams Learn from Data Driven Development?
SharePoint is a complex thing to implement. This is why project teams tend to be made of people who’ve been involved with SharePoint before- they’ve already got to grips with some of the quirks of the platform.
The problem is, this can frequently lead to work being done based only on “experience”- in other words, assumptions. Business problems and user’s expectations are not all equal, and could vary dramatically between projects.
Teams should have the confidence to run pilots, testing their recommendations to validate the effort (and ultimately money) that is being spent. The real value of their experience is knowing the right question to ask, not all of the answers.
Yammer’s Time Limited Development
As Yammer’s development efforts are based on testing theories (with the risk that the test will give a negative result), it’s important to limit the scope of works. Yammer chooses to limit all development projects to 2-3 weeks. If the proposed development is longer than this, it’s broken down in distinct pieces.
By following this limitation, it’s much safer for tests (or projects) to fail, as fewer resources have been committed to it. A “safe to fail” environment like this is much more likely to encourage innovation, as the risk to a project team is minimized.
What Can SharePoint Teams Learn from Time Limited Development?
In more lengthy development processes, the fundamental needs of users can change dramatically from the beginning of the project to the end. Smaller projects also yield results quicker, giving a clearer indication of where to move in the future.
Taking this in mind, the traditional SharePoint project of building “the intranet” is potentially misguided.
Despite being present in most businesses, an intranet is a very difficult thing to define as a whole. The scale of a complete intranet project makes it very likely that by the time you deliver, you’ll be solving yesterday’s problem.
By breaking apart a project, you can incrementally move towards project goals, while maintaining the agility to respond to change. As said by Adam Pisoni (Yammer CTO) at last year’s SharePoint Conference in a session about the development process- “Icrementalism isn’t breaking apart a big project, it’s not knowing the end state”.
Although this is a very superficial summary of Yammer’s development principles, I hope it’s provoked you think more closely about how you plan to implement your next SharePoint project. More information on Yammer’s development practices can be found on the Yammer site.