Debriefing in the era of Agile Software Development

Software Development has been traditionally managed in the Waterfall model or spiral/iterative models. In the Waterfall model, each stage of the development had to be completed before the next stage could be initiated.
First Design, then development, then testing. At the end of each stage, an evaluation process had been conducted. If needed, the process would go back to previous stage to fix the issues.
These evaluation points were kind of debriefings and reviews for what happened up to that point.
However,  the lengthy stages were met with dissatisfaction from stakeholders. When the first products of development arrive, after months, the stakeholders would have had opinions for re-design.

With the spread of other iterative methods, the Agile method got its grasp on the high-tech industry. The idea behind the Agile development process is that "control points" are set and fixed all along the process in short-time periods.
This way, stakeholders can provide feedback and the developers or the people who work on the product can respond more quickly, with more agility. One of the most popular implementations of Agile is the Scrum method.
I won't go into full detail of  the Scrum method but I'll focus on the ceremonies. Each team that implements Scrum conducts some ceremonies that assist with planning, daily review of status and retrospective meetings.
At the end of each development sprint, which usually takes 2 weeks and includes design, planning, developing and testing of small subset of the product specs, the retrospective ceremony takes place. In this ceremony, the team members perform a debriefing of the past 2 weeks:
- What went well?
- What went wrong?

The major focus is on the team's work, The review does take into account external influences ("the deign team made a lot of errors, the DevOps didn't give us enough servers"). But, the real deal is reviewing the team's internal work, co-workers communication, adherence to procedures, etc.
Team members are asked to raise problems and solutions.

The retrospective is a crucial part of the process and without it, same issues and problem re-occur again and again. In IBM XIV GUI team, at stressful times, such as prior to product launch, some of the scrum ceremonies were postponed in order to give people all the time they need to work.
However, we would have never skipped the retrospective, especially in stressful times. This debrief is important in keeping the team's work efficient and to allow quick solutions for one-time and recurring issues.

Communities in Practice and Meet Ups

The latest topic of out course, Communities of Practice got me to think on the influence of social media, and the internet as a whole, on the way communities may interact.

One would expect that with the growth of social media and social networks, people will use those platforms to collaborate more, rather than actually meeting and socializing.

Facebook, Twitter, form platforms and other platforms promoted creation and fortification of communities of practice. In recent year, several websites that specialize in promoting community gatherings popped up: mainly meetup.com, everbrite, Facebook events and more.

Those meetings and gatherings complement the online platform in ways that let individuals to communicate directly without any means. One can converse with many other people easily by speaking, as opposed to typing and reading which is a heavier cognitive task.

So even though online social platforms play a major role in bridging different people from different geo-locations, face-to-face meetings are here to stay and both "platforms" can benefit from one another.

Designing Social Spaces - Reputation and Gamification

One of the challenges in creating a successful and lively social platforms, is the question of continuously engaging users.

It is obvious today that knowledge management is based on the social atmosphere of companies and organizations. Do we want to hand out bonuses? Maybe deduct salary from users that don't contribute?

One approach is to use reputation. As human beings, we have a strong sense of community hierarchy and respect towards one another. People that have higher reputation are honored with higher respect and taken more seriously. For Jewish religious people, there are different levels of Rabbais. Same thing goes for professors or other high ranked personas.

Stack overflow, the most popular software development Q&A platform, has a sophisticated reputation system. Every action a user performs or interaction they're involved in produces an increase in reputation: answering questions, being up-voted on your answer, leaving a reply, up-voting answer etc.
This methodology proves to work because many users invest a lot of time in maintaining their reputation by being active on the platform. People with high reputation are considered to have better answers. It is so successful that companies who seek to hire employees look into their candidates ranking in Stack Overflow. Some candidates even include it in their CV!

Gamification is a bit more advanced approach. While it is kind of reputation ranking, since there's an explicit or implicit ranking, it is mainly focuses on adding fun to the intended task.
We can look at Waze or Moovit as socially-powered apps. At their begging, both apps relied on crowd-sourced updates for fixing map data, road data, incidents report, real-time reports and more. Both companies used games to encourage users to report. Waze encouraged users to drive through certain locations to improve their database by adding virtual tokens to their balance if they pass there.

These tools can encourage users to share knowledge and insights, but they have to be crafted carefully to be successful (Waze & Moovit dropped their gamification incentives as time went by...)

Has Wiki transformed the Knowledge Management Culture in Organizations?

Until 2010, the most common way of managing knowledge in enterprise organizations was Microsoft Sharepoint websites.
Users would create documents and upload them to the Sharepoint. The novelty of the Sharepoint was a useful and convenient way to share documents between users with versioning. If once had to have shared volumes with folders inside where one user might overwrite changes, now Sharepoint allows version control and recovery.
However, Sharepoint still consists of documents as the smallest component of knowledge. The user has to checkout the entire document, edit it, and check in again. Other users can't edit it simultaneously and if the document wasn't check out, merge conflicts occur.
These are exactly the kind of issues that prevent user from documenting and contributing their knowledge to the organization.

Then, came Wiki. Mainly by popular spread of Atalassian Wiki, users can now contribute their knowledge by directly editing articles in their browsers. The knowledge and data aren't stored in documents, but in online editable articles that in later versions, user can even edit collaboratively.

So, Wiki tools do make it easier for users to contribute data and edit articles. Nonetheless, as with all tech tools, the ease of updating wiki resources still need to be governed by KM policy. Companies always have to get their employees the easiest and best KM tools, but to enforce KM policies by compulsory, guidelines, bonuses etc.