• chevron_right

      Anmol Chaudhary: GSoC 2020 Ends - Final Words

      Anmol Chaudhary · news.movim.eu / PlanetJabber · Thursday, 10 September, 2020 - 00:00 · 2 minutes

    With the rise in the usage of the internet, the need for digital communication is increasing day by day, this has only been accelerated by the current COVID-19 pandemic in 2020. More and more people are using chat applications to communicate with each other whether it is their loved ones or for discussing work with colleagues.

    This summer I was involved in implementing In-Band Real Time Text (RTT) for Dino . Real Time Text allows transmission of text instantly just as the user is typing. This allows for faster and more engaging textual conversations just as telephonic calls but at the same time keeping the discretion of text-based communication.

    To sum it up here’s what I did in order to make RTT work:

    • Message Comparision that generates the difference between two strings, in this case, used to generate a difference between the message being typed in real-time to generate necessary action elements. The algorithm is based on “Gestalt pattern matching” (Details, see here )

    • Sending and receiving real-time texts in both single and multi-user chats. The Real-Time Text has support for all action elements ( insert, erase, wait ) and events ( new, edit, reset, init, cancel ) mentioned in XEP-0301. The RTT are displayed on the conversation view along with traditional messages. In MUC at a given time, only 3 RTT are displayed in order to keep the User Interface clutter-free, the priority for which is determined by the affiliation of the member. (Details : here , here , here , here , and here )

    • RTT Setting radio toggle to toggle between Off/Receive only/Send and Receive. This is handled by using events “init” and “cancel”. (Details, see here and here )

    • Handling of stale messages that removes the RTT widget from UI if there is no update in a given time interval. This may be due to peer stopped typing or loss of sync. (Details, see here )

    • Multi-Device Support to sync input between different instances of Dino. With this, a user can start composing a message on one device and finish on another. (Details, see here )

    • Compatibility with Last Message Correction. With this, RTT is also displayed for the messages being corrected. The live correction is displayed in place of the old message received.

    The PR for which is available here .

    Overall it has been a great 3-month long journey. From working with a completely new language - Vala to fixing a ton of bugs in the process, and from discussions with mentor to the weekly meetings; I enjoyed my time with XSF.

    Although GSoC is now officially over, I look forward to contributing more to XSF and Dino in particular in the future. Next I plan on implementing message retraction and message moderation .

    Finally, I thank my mentors especially Marvin for guiding me through the summer. They have always been present to solve any problems I faced whether it was regarding discussion on how to implement something or for some bug fix. I also thank the XSF community for having me as a student developer this summer.

    • chevron_right

      Prosodical Thoughts: Prosody 0.11.6 released

      The Prosody Team · news.movim.eu / PlanetJabber · Wednesday, 9 September, 2020 - 13:46

    We are pleased to announce a new minor release from our stable branch.This release brings a collection of fixes and improvements added since the 0.11.5 release improving security, performance, usability and interoperability.This version continues the deprecation of using prosodyctl to start/stop Prosody if it is installed system-wide. You should use your init system’s appropriate commands to manage the Prosody process instead. You can silence the warnings with the ‘prosodyctl_service_warnings’ option.
    • wifi_tethering open_in_new

      This post is public

      blog.prosody.im /prosody-0.11.6-released/

    • chevron_right

      Ignite Realtime Blog: New Openfire plugin to help reduce spam!

      guus · news.movim.eu / PlanetJabber · Wednesday, 9 September, 2020 - 08:02 · 1 minute

    The Openfire community is happy to announce the immediate availability of a new plugin: the blacklist spam plugin.

    With the growing popularity of XMPP-based solutions, we’re also seeing an increase of a less desirable application of XMPP: the distribution of unsolicited messages over instant messaging (SPAM, or SPIM).

    In order to help our Openfire community combat known spam, we have now released a new plugin the “Spam blacklist” plugin . This is configured with a URL that is used to lookup addresses of known SPAM distributors and block all messages sent by these addresses.

    By default, the plugin is configured to read from a blacklist that is hosted on the igniterealtime.org website, and block all messages sent by any user on a domain listed there. The blacklist hosted by the Ignite Realtime community is a periodically updated copy of the list that is curated by the https://github.com/JabberSPAM/blacklist project. You can help combat spam by contributing to that project!

    In the next few hours, the plugin will pop up in the list of available plugins on all Openfire instances. Alternatively, you can manually download and install the plugin from its archive page .

    For other release announcements and news follow us on Twitter

    3 posts - 2 participants

    Read full topic

    • chevron_right

      Monal IM: Some usage stats for a random day

      Anu · news.movim.eu / PlanetJabber · Thursday, 3 September, 2020 - 02:04

    I don’t track users in any way but in the process of fixing a server issue I did do a count on the number of messages sent on a given day. Here they are in case anyone was curious. On the scale of modern apps, these are tiny numbers but it is nice to see lots of people using the service.

    On a random day, 8/25/20 in a 24 hr period

    • Total Users: 103,065
    • Pushes sent: 56,768
    • Server to server (s2s) connections: 1,580

    • wifi_tethering open_in_new

      This post is public

      monal.im /blog/some-usage-stats-for-a-random-day/

    • chevron_right

      Paul Schaub: PGPainless 0.1.0 released

      vanitasvitae · news.movim.eu / PlanetJabber · Tuesday, 1 September, 2020 - 08:37 · 2 minutes

    After two years and a dozen alpha versions I am very glad to announce the first stable release of PGPainless ! The release is available on maven central .

    PGPainless aims to make using OpenPGP with Bouncycastle fun again by abstracting away most of the complexity and overhead that normally comes with it. At the same time PGPainless remains configurable by making heavy use of the builder pattern for almost everything.

    Lets take a look at how to create a fresh OpenPGP key:

            PGPKeyRing keyRing = PGPainless.generateKeyRing()                .simpleEcKeyRing("alice@wonderland.lit", "password123");

    That is all it takes to generate an OpenPGP keypair that uses ECDH+ECDSA keys for encryption and signatures! You can of course also configure a more complex key pair with different algorithms and attributes:

            PGPainless.generateKeyRing()                .withSubKey(KeySpec.getBuilder(RSA_ENCRYPT.withLength(RsaLength._4096))                        .withKeyFlags(KeyFlag.ENCRYPT_COMMS, KeyFlag.ENCRYPT_STORAGE)                        .withDefaultAlgorithms())                .withSubKey(KeySpec.getBuilder(ECDH.fromCurve(EllipticCurve._P256))                        .withKeyFlags(KeyFlag.ENCRYPT_COMMS, KeyFlag.ENCRYPT_STORAGE)                        .withDefaultAlgorithms())                .withSubKey(KeySpec.getBuilder(RSA_SIGN.withLength(RsaLength._4096))                        .withKeyFlags(KeyFlag.SIGN_DATA)                        .withDefaultAlgorithms())                .withMasterKey(KeySpec.getBuilder(RSA_SIGN.withLength(RsaLength._8192))                        .withKeyFlags(KeyFlag.CERTIFY_OTHER)                        .withDetailedConfiguration()                        .withPreferredSymmetricAlgorithms(SymmetricKeyAlgorithm.AES_256)                        .withPreferredHashAlgorithms(HashAlgorithm.SHA512)                        .withPreferredCompressionAlgorithms(CompressionAlgorithm.BZIP2)                        .withFeature(Feature.MODIFICATION_DETECTION)                        .done())                .withPrimaryUserId("alice@wonderland.lit")                .withPassphrase(new Passphrase("password123".toCharArray()))                .build();

    The API is designed in a way so that the user can very hardly make mistakes. Inputs are typed, so that as an example the user cannot input a wrong key length for an RSA key. The “shortcut” methods (eg. withDefaultAlgorithms() ) uses sane, secure defaults.

    Now that we have a key, lets encrypt some data!

            byte[] secretMessage = message.getBytes(UTF8);        ByteArrayOutputStream envelope = new ByteArrayOutputStream();        EncryptionStream encryptor = PGPainless.createEncryptor()                .onOutputStream(envelope)                .toRecipients(recipientPublicKey)                .usingSecureAlgorithms()                .signWith(keyDecryptor, senderSecretKey)                .asciiArmor();        Streams.pipeAll(new ByteArrayInputStream(secretMessage), encryptor);        encryptor.close();        byte[] encryptedSecretMessage = envelope.toByteArray();

    As you can see there is almost no boilerplate code! At the same time, above code will create a stream that will encrypt and sign all the data that is passed through. In the end the envelope stream will contain an ASCII armored message that can only be decrypted by the intended recipients and that is signed using the senders secret key.

    Decrypting data and/or verifying signatures works very similar:

            ByteArrayInputStream envelopeIn = new ByteArrayInputStream(encryptedSecretMessage);        DecryptionStream decryptor = PGPainless.createDecryptor()                .onInputStream(envelopeIn)                .decryptWith(keyDecryptor, recipientSecretKey)                .verifyWith(senderPublicKey)                .ignoreMissingPublicKeys()                .build();        ByteArrayOutputStream decryptedSecretMessage = new ByteArrayOutputStream();        Streams.pipeAll(decryptor, decryptedSecretMessage);        decryptor.close();        OpenPgpMetadata metadata = decryptor.getResult();

    The decryptedSecretMessage stream now contains the decrypted message. The metadata object can be used to get information about the message, eg. which keys and algorithms were used to encrypt/sign the data and if those signatures were valid.

    In summary, PGPainless is now able to create different types of keys, read encrypted and unencrypted keys, encrypt and/or sign data streams as well as decrypt and/or verify signatures. The latest additions to the API contain support for creating and verifying detached signatures.

    PGPainless is already in use in Smacks OpenPGP module which implements XEP-0373: OpenPGP for XMPP and it has been designed primarily with the instant messaging use case in mind. So if you want to add OpenPGP support to your application, feel free to give PGPainless a try!

    • wifi_tethering open_in_new

      This post is public

      blog.jabberhead.tk /2020/09/01/pgpainless-0-1-0-released/

    • chevron_right

      Ignite Realtime Blog: Spark 2.9.2 Released

      wroot · news.movim.eu / PlanetJabber · Sunday, 30 August, 2020 - 18:26

    The Ignite Realtime community is happy to announce the availability of Spark version 2.9.2.

    This release fixes offline messages and a few other issues. Full list can be found in the changelog .

    We are thankful to all the contributors and encourage developers to get involved with Spark project by providing feedback in the forums or submitting pull requests on our GitHub page.

    You can download Spark from the Downloads page. Below are the sha1 checksums:

    44bedca5f8c49373e3a3454ae92857612a907714  spark_2_9_2.deb9b2a36cb4bc5b620f6e34d0bbe52ad57f0ff1bee  spark_2_9_2.dmg8df94552ada52a8c2a7da68ad596f4acd39d9ac4  spark_2_9_2.exeb1a81744923f4aaf3d39ced95fea233b6077f93c  spark-2.9.2.rpm4933144d2812c638effe95344dce304dbf820c0d  spark_2_9_2.tar.gz21836f86e101a7e48fcbd44fa400d5862f0840ab  spark_2_9_2-with-jre.dmg68e2ed4bd916bab17a0f963f748176d4d8514c29  spark_2_9_2-with-jre.exe

    For other release announcements and news follow us on Twitter

    1 post - 1 participant

    Read full topic

    • chevron_right

      Gajim: Development News August 2020

      Gajim · news.movim.eu / PlanetJabber · Sunday, 30 August, 2020 - 00:00 · 1 minute

    This month was all about configuration. Gajim offers a ton of configuration options, making it customizable to fit almost every users needs. The settings backend received an upgrade and a lot of code has been cleaned up, which should make it easier for you to handle all of Gajim’s configuration possiblities.

    Changes in Gajim

    A huge amount of code has been cleaned up around Gajim’s configuration backend. This was necessary in order to move from a configuration based on text files to a new settings backend powered by SQLite. Everything involving configuration (preferences, account settings, states) is now completely migrated to SQLite. Gajim is now able to store settings efficiently, and some quirks around default values have been solved. When you browse Gajim’s configuration via Advanced Configuration Editor, you’ll now only see settings which are not available in the Preferences or Accounts window. States (e.g. window size) have also been removed from ACE, which results in less clutter.

    After all these changes under the hood, it is finally the time to rework the Preferences window. The Accounts window already features ‘ListBox’ settings, enabling Gajim to display settings in a tidy and clear fashion. We plan to fully migrate the Preferences window as well, which should make it easier for you to handle all of Gajim’s configuration possiblities.

    A preview of the new Preferences window

    A preview of the new Preferences window

    What else happened

    • Linux: Gajim will now use GTK’s native Emoji chooser (with categories and recently used emojis)
    • Removed ‘Auto copy’ workaround for Ctrl+C usage in the chat window
    • Fixed a bug where dropping selected text on a chat window would fail
    • Fixed ‘Show status changes’ setting being ignored for group chats
    • Fixed a bug where removing a plugin would fail

    Plugin updates

    It is now possible to install the ‘Ayatana Appindicator integration’ plugin via Flatpak.

    Changes in python-nbxmpp

    Support for JID Escaping ( XEP-0106 ) has been added, enabling users to join group chats containing special characters (e.g. ‘&’ in IRC channels). Furthermore, bookmarks parsing has been improved (nickname validation, password element for XEP-0402 ).

    As always, feel free to join gajim@conference.gajim.org to discuss with us.

    Gajim

    • wifi_tethering open_in_new

      This post is public

      gajim.org /post/2020-08-30-development-news-august/

    • chevron_right

      Ignite Realtime Blog: Spark 2.9.1 Released

      wroot · news.movim.eu / PlanetJabber · Tuesday, 25 August, 2020 - 18:35

    The Ignite Realtime community is happy to announce the availability of Spark version 2.9.1.

    This is a small bugfix release for the recently released 2.9.0 version . A few minor issues fixed in this version can be found in the changelog .

    We are thankful to all the contributors and encourage developers to get involved with Spark project by providing feedback in the forums or submitting pull requests on our GitHub page.

    You can download Spark from the Downloads page. Below are the sha1 checksums:

    7574a4ffee89aec037ed788046975d4fd32b62f7  spark_2_9_1.deb86ee3a78e6bdfe21c18559abce70e4c7ed334f66  spark_2_9_1.dmg3196d7b5be4c24de44c9931cb099d3e073501496  spark_2_9_1.exe5e7fa73aa1fefef8e67ba81acc61be2786fce819  spark-2.9.1.rpm55e344832b37595e4fb2fc9d8749519d06f2a7c8  spark_2_9_1.tar.gzca2a4fb154601c860e959eb3c614bc760cec6334  spark_2_9_1-with-jre.dmg0906c896303cf60a07ae4208b83f9de6359e2935  spark_2_9_1-with-jre.exe

    For other release announcements and news follow us on Twitter

    1 post - 1 participant

    Read full topic

    • chevron_right

      Erlang Solutions: Applying Scrum to a system of fluid teams working on an open-source product

      Erlang Solutions · news.movim.eu / PlanetJabber · Thursday, 20 August, 2020 - 11:36 · 17 minutes

    The modern IT workplace is weird.

    You get a desk that sometimes has a chair, but often also wheels or a button that makes it go up and down. There are often bean bags involved, bosses that say they are not really bosses, complimentary fruit and candy, engagement programs, and people constantly pushing you to “self-actualise” and grow.

    Your projects often come with a lot of trust and freedom, but that also means that project structures are fluid, and there is a lot of responsibility for individuals to set up the direction. On the spectrum of freedom and security, everything serves the most important goal - adapting to change.

    A lot has been said about how Agile and Scrum differ from other approaches to organising work. They are born out of experiencing first hand how detrimental it can be to follow ill-fitting methods that work well in other industries. At their core, they are about creating effective communication channels - between team members, teams and the market, different stakeholders and the various people responsible for orchestrating the process. A culture and environment that promotes sharing, listening and taking ownership for your work is required for this approach to shine and foster dynamic progress and satisfaction of all involved.

    It would be tempting to say that following the Scrum guide verbatim is a silver bullet for running all IT projects, and many would argue it is.

    In this short article, I would like to tell you the story of how we took the spirit of Agile, measured it against our needs and then iteratively made it our own. Did we manage to reach the shore of a procedure that works for us? For now - yes. Will we stick with it? I have no idea - come back and check in with us in a few months. One thing is for sure, if we are not, it will be born out of a test and learn approach which has led us to something that fits our way working better.

    Mongoose wrangling - you have to be agile!

    MongooseIM is an open source product developed by a commercial company. 100% of the code is available to the public; everyone can use it, customise it, contribute, point out bugs, raise feature requests. At the same time, the core development team works not only on developing the product but also on assisting companies that want to create custom extensions, optimise their installations, scale or adjust their setup.This means we have two groups contributing to MongooseIM - the open source community and Erlang Solutions developers. The second group can’t really be considered a monolith, since some of them only work with the open source product while others assist the company’s customers with different projects.

    In short, what we have on our hands is a system of fluid teams . By definition a fluid team consists of “experts from disparate functions and geographies who must get a temporary project or task up and running, sometimes with completely different priorities, beliefs and values”. As challenging as it may sound, this form of organisation is typical for modern IT, it has been widely accepted that nowadays “this is how we roll”. What we have at MongooseIM goes a step further - it is not just a fluid team, it’s a system of fluid teams. We all work on MongooseIM in one way or another, but our goals, priorities and procedures are often very different, since what is important for a single client is not always a must for the entire product (and vice versa). Different projects follow different procedures; they follow different guidelines and assumptions and sometimes they even look for solutions to contradicting problems. We slip in and out of different roles and teams, and the direction of the entire system is forged somewhere in between these parallel interests.

    This also means implementing Scrum is tricky.
    You have to remember that Scrum is not only valuable, it’s also costly. You spend a lot of time and effort on inspection - meetings, analysis, discussions and syncing. It’s all an investment you make to empower your team, allow them to learn, minimize certain risks and make sure you generate value, but in order to have a return on that investment, you have to be consistent in your actions.

    For a team to be considered totally “scrummy” it has to meet a few criteria. It has to be cross-functional, self-organising, it can’t have any hierarchies, and it has to be small. Ideally it should have between 3 and 9 team members.Many of these assumptions make little sense when talking about an open source project like MongooseIM. For example - who do we consider to be a part of the team? Everyone who contributes to the project? If so, there is no way of determining how many people that is or to coordinate their efforts. So do we define it as all Erlang Solutions employees working on MongooseIM? Some of them are embedded in customer teams, making it near impossible to have them conform to Scrum ceremonies and requirements. The cost of abiding by the client’s procedure and our Scrum would make them unable to do any actual work. Perhaps we should narrow down our focus to just the core development team? Very few members will be with the team for more than 2 consecutive sprints, there will be sprints with just 2 or 3 members, followed by sprints with 9 or more, we will constantly pay the cost of onboarding new people and relearning and restructuring day-to-day work. In short - it will be very hard to let the team members do their work, learn from each other, form long term plans, and benefit from what Scrum offers.Taking all of that and more into consideration, for us, there was little sense in going “full Scrum”. To be able to progress and not lose our minds, we had to remain Agile, but also, we had to make it our own.

    Building a frame

    Let’s skip the part where we start with an eager team, an inexperienced Scrum master and a willingness to do everything just as the Scrum guide says. That was our starting point, but it is not exactly the basis of what we do now. For me that elusive basis was best expressed by Tomasz Włodarek at one of his amazing workshops. To paraphrase the thought, he encourages management to steer away from creating a workflow as a set of rules, or set pipelines with different steps and stages. You do need those to create predictability and thus stability, but at the heart of how you operate, there should be something else. Your work culture should be built on two sets of objects later filled by your self-organising teams. Those two are the frames and attractors. You build these by answering two simple questions - “what are the things we want to discourage?” and “what are the things we want to encourage?”. The answers will never be complete and might change over time, but they need to be communicated to the team.

    For our team, there were a few things we did not want. We did not like it when we were swamped with ad hoc requests. We did not like it when people started a lot of tasks and never finished any. We did not like external factors interfering with our goals. We did however, and still do, love our product.

    Working with Erlang, XMPP and MongooseIM is something the team is genuinely excited about. We love to learn, explore, come up with new ideas, we love the open source culture and commercial projects we get to work with. It is exciting to get to work with customers who have massive, running installations and then assist a hobbyist writing his own MongooseIM module for fun. It is great seeing in action how people use and build upon our work.

    Luckily this state of mind aligned perfectly with what our management wanted - a highly professional, efficient team always growing their capabilities, ready to tackle any task.

    The initial attractors and frames we’ve set reflected that:
    We wanted to encourage knowledge sharing - so we created channels to share the lessons we’ve learnt and award people who actively engage in assisting others.
    We wanted the team to have agency - so we made sure that both our backlog and pipeline of commercial projects is transparent (everyone can volunteer, contribute or comment) and that everyone is encouraged to submit their ideas on what to do next. This also eliminated many of the bottlenecks we have run into in the past.
    We wanted the team to have the comfort of working on their goals without interruptions - so we’ve introduced work iterations and separated the development team from other teams.

    The process that crystallized around those assumptions gets more and more refined over time, but these add up to an agreed-upon basis of all the changes we introduce.

    What does that mean in practice?

    Let’s perhaps start with what we have in common with Scrum. We have sprints with all the prescribed Scrum ceremonies that produce potentially shippable increments. We do Daily Scrum, Sprint Planning, and Sprint Retrospectives. Our backlog is always growing, and the Release Owner orders it based on their best judgement and value calls.Have you noticed that? The first difference?

    We do not have a Product Owner. We tried and we are very grateful to our past Product Owners for all their contributions, passion and the great ideas they brought to inspire the team. What became apparent after working with these talented individuals is that if your product is an open source project with an elaborate business model built around it, traditional POs do not get enough space to shine. What has worked for us is actually an expression of the self-organising principle of Scrum - we put things up for a vote.

    Every release ends with a small “political” campaign where members of the development team present their ideas about what the focus of the next release should be. We have a few meetings discussing the ideas, some people contribute to the existing proposals, others form their own. We’ve had elections with multiple candidates and elections where one candidate asked us to vote on release themes and priorities to create guiding principles for the upcoming months. The result is a vision everyone understands and an uncanny level of transparency and insight into the plan.

    And, since everyone has contributed to it, we all feel responsible, engaged and encouraged to take ownership of the work that needs to be done.The Release Owner has extra powers (they decide on priorities and can overrule a tied vote) but also extra responsibilities (managing external stakeholders including the marketing team, gathering extra information, attending many meetings that the other team members can skip). As they say - with great power comes little time to do some actual coding yourself.The Backlog Grooming is of course an ongoing process. Everyone can add stuff to the backlog at any point, but it is the Release Owner who decides the order. We do hold backlog grooming meetings to which the team should bring their ideas, preferably in the form of PBIs we can all see, discuss and ask questions about. Top priority, groomed items get placed on the top of the list and are likely to be included in the next sprint’s backlog.

    So far we are not that far from a traditional Scrum with a PO who is part of the team. Where is the key difference?

    Let’s switch the perspective and ask - if you happen to be an Erlang solutions employee and part of the MongooseIM core team: does this mean you are on the sprint? Not always. Does it mean that you are a part of the sprint work? Most yes, no, maybe, kinda, can you clarify what you mean?

    We have people who join the sprint. At Sprint Planning they state their availability and we populate the sprint backlog based on their estimates and capacity. There are people who know they will have some availability but have no idea how much. For them, we have a neat Kanban board with community support items, research, occasional marketing requests, side projects that can bear fruit in the form of estimable PBIs for the Scrum team. There are people on commercial projects who are invaluable to us and the way we plan. They have hands-on experience with live implementations of MongooseIM, they have battle stories, insights, ideas, they know the pain points and have a unique perspective on the work. It is critical for them to know what is happening on the open source product and it is critical for the Scrum team to know what’s up with them. The two latter groups are not included in the sprint capacity and we make sure we do not depend on them to complete the sprint work, but their feedback is welcome and assistance is invaluable.

    Another important thing is that the division between the groups is strict only from the single sprint perspective and in no way permanent. There are commercial projects that last months and others that are completed within days. People who technically are not on the sprint are still invited to join our meetings, listen in and join slack conversations - they are much more than external stakeholders.

    The result of all this?
    We are still “scrummy” (all the roles, rules, ceremonies and artifacts are there and we get to benefit from them).
    We are inclusive and responsive to specific needs of team members, external stakeholders and projects.
    We are highly communicative and flexible.
    We have a structure that gives us predictability but also the capacity to change.

    Cool tricks

    There are many supplementary techniques we use in our work to make sure the attractor/frame setup is something we actually live and breath and not just sometimes brag about. Here are some examples that can inspire you to come up with ideas to introduce to your own project/team/organization.

    Feedback.

    Creating a culture of feedback is not just a way to inspect and adapt but also to provide people with a sense of agency. We’ve introduced many tools team members can use to share their thoughts with different levels of formality. Let’s, for example, explore Pigeon Post - a form where you can send a short note and a cookie (or not) to people who did something notable. The person not only gets to enjoy the cookie but can also include these notes in their appraisal process as evidence of what a great teammate they are. It’s a fun way to express appreciation to your colleagues and point out specific behaviours we value (or not - it’s not just for praise and positive feedback). Other systems we have, allow people to explicitly raise points and introduce ideas that are then included in the office-wide processes and day-to-day work. Most of the mechanisms we use in the project pipeline or for knowledge sharing purposes, stem from suggestions from the team. One important rule to keep in mind, is that when you ask for feedback or ideas, it’s on you to act on the response. Whether it’s a suggestion box, a retrospective action point, informal conversation or an official request, you have to have a timely reply. If nothing else, make a short presentation listing what you’ve done to address the ideas, preferably no later than 3 months after they have landed on your desk. If you don’t, you are not really encouraging your team to engage, rather just proving that what they say does not matter.

    Knowledge sharing.

    That is the number one reason for most of the Pigeon post cookies. “I loved your report on Helm - you get a cookie”, “I really enjoyed your Lessons Learned - here’s a cookie”, “Your workshop was awesome - One cookie coming right up!”. Developers love learning, love exploring new ideas, sharing the knowledge, discussing stuff. If your team members are afraid to speak up, unwilling to share or reluctant to talk, something has gone terribly wrong and needs to be addressed right now. Perhaps they are afraid of ridicule? Work on how safe they feel. Perhaps they feel they don’t have enough time to “waste” on knowledge sharing? There’s something wrong with the workflow. Perhaps they do not see how, where or when to let people know they have something to share? Create a Lessons Learned series! The format that worked for us is a company-wide library of presentations from different people and teams sharing stuff they find interesting. It ranges from project post-mortems, lessons learned from different projects, panel discussions to presenting a pet project or favourite technology. Whatever it is, it is welcomed, encouraged and rewarded. Not by a “knowledge-sharing bonus” or an official letter of praise but by attention and appreciation from the rest of the team. This is not only how we build expertise, but also ourselves as teachers and experts.

    Candy.

    How do you make people actually follow up on all these values and ideas? A lot has been said about what drives us , how to build or destroy motivation. My favourite tool is humour, empathy and showing people you actually like them (the prerequisite here is that you actually do).
    Let’s explore an example. MongooseIM Scrum Team has daily standups, but other teams and standalone consultants have separate, internal meetings to worry about. We would like them to write short standup notes every morning to let us in on what they’re doing, but we do not want to enforce it or annoy them with the request (they are very busy people!).
    The solution? Candy. Everyone who shares what they are doing on a given day, gets a personal visit from the Scrum Master carrying a bag of candy. They get to pick one. Ridiculous, right? No one would change their behaviour for such a small bribe. “If you want me to write standups, just make it part of my job description, we are all adults here, do not insult my intellect!” But it’s not a bribe. It’s a nice gesture, an occasion to talk for a minute without big disruptions, to quickly see how the other person is doing. It’s small and it’s fun. After a while everyone sees the benefit of the standups and they write it regardless of the reward, but the candy stays. You get to learn everyone’s favourite flavour, you get people requesting different types of chocolate, finally you get a petition asking for a “Healthy jar” with nuts as an alternative to candy. Some people choose either the candy or nuts depending on how their day went - what a great conversation starter you just earned! Your team gets closer, gets friendlier, gets engaged. Of course this technique will not work for every team, and I am not advocating for getting everyone off their healthy and balanced diet. The tool you choose for this type of exercises can be whatever you see fit, but it should:

    1. Not be too valuable or attached to salary/bonuses/promotions (or it will provoke people to try to cheat the system, see if they can break it - they are developers afterall)
    2. Be easily accessible and of similar value (we use candy for all kinds of exercises and mini-procedures)
    3. Not cause too much formality or fuss (it should be a nice gesture, a conversation starter not a potential black market currency).

    Want some other great ideas on how to engage people and make them enjoy their work more? Ask your team!

    The takeaway?

    The modern IT workplace is weird. It makes you think of things, observe the nature and craziness that is life. All of a sudden you see how complex systems emerge from simple rules and how trying to design or foresee something can sometimes only make things worse.

    Before working in IT, you might think that being proactive is better than being reactive, that defending against failure, planning for all possible cases is the smart way to go. The more you observe nature, Erlang or self-organizing teams, the more certain you will be that that’s wrong. Evolution is smarter than revolution or any sort of planning, it’s more mature, natural, it allows order to emerge painlessly. Embracing your team’s potential, allowing mistakes and experimentation helps expose their strength, building an environment that fosters creativity where traditionally it was limited and curbed. No one person can design a perfect system or process for a diverse team facing challenges that are hard to foresee. What you can do is listen, encourage and adapt.
    It’s more fun that way.

    • wifi_tethering open_in_new

      This post is public

      erlang-solutions.com /blog/applying-scrum-to-a-system-of-fluid-teams-working-on-an-open-source-product.html