Minsk AUG Hosted!

1c0346c5-3d86-4f3d-a3c7-6e301876a15e-original

Hey guys, good news – Minsk has it’s own Atlassian User Group now, me & StiltSoft kicked out the first event, gathered 60 RSVP’s in just one week, and had an amazing time in the beautiful city of Minsk, Belarus!

Hosted an event in an awesome Eventspace.by at the old factory!

  • AUG Minsk, SkuVault-Jiraย – Speech on how we organized processes and workflows in Jira, and helped SkuVault become more transparent in development;
  • AUG Minsk, Stride – our experience in migration from Telegram to Atlassian Stride.

https://www.linkedin.com/embed/feed/update/urn:li:activity:6396021858935861248

And of course, a pub pic.

2018-04-29 18.10.07

Telegram -> Stride Migration Experience

Recently I hosted Minsk Atlassian User Group, where I shared our experience on migrating to Strideย and gave the analogy between Stride, and Russian word ‘Stradai’ (-> eng.: ‘Suffer’). I’ll explain the analogy later. Hence the ‘Napalm Death’ song ‘Suffer’ joke on the first slide ๐Ÿ™‚

Given that a lot of people use Telegram as a corporate messenger, and given all of the telegram-blocking happening in Russia currently, it’s pretty relevant to write about alternatives. We at SkuVault migrated due to the need of user control, but migration experience is relevant to many other teams.

Atlassian launched Stride as a HipChat Cloud replacement (so we can call it hipchat 2.0). Main competition is Slack, which is currently de-facto corporate messaging standard, as we know. I’ll compare Stride to Telegram and Slack in areas they are strong.

Pros

Atlassian Ecosystem

Biggest point of Stride is that it connects to your atlassian ecosystem. Typically you got single account for Atlassian User, from which you can manage entirety of Atlassian Permissions. Now, Stride is added as an application to the very same account, and access / admin rights are easily managed from the very same place. If you want to have control over the users and the ecosystem that is locked to Atlassian (as we do) -> this is an ideal scenario.

admin_unified

In Telegram we had personal accounts, which you don’t have control of (sure you can create virtual / work phone numbers and link them to telegram to make it corporate-friendly, but that is kind of a crappy way to maintain users ecosystem).

In Slack – you have to pay more than $3/user and it’s a separate account management system.

Users Control

User Control means removing a person, when she no longer works at the company, visibility for messages in order for infosec to not be compromised.

Audio and Video Group Calls

It may not be something you’d count as a pro, but given that we previously used Telegram + Skype for calls (with hangouts as a fallback in case of skype outage), it’s nice to have same app doing everything.

Jira / Confluence Integration via bots

z0ogiy1zqdssa9zywvco-ccwoii

Integration with Jira and Confluence (not out-of-the-box-though) gives you a glimpse of the ticket in the chatroom (ticket card that reflects priority, assigne and editable layout), ability to create tickets as a command to chat-bot (create new bug Fix spacing on signup page in SV project), bitbucket PR review poking, and a lot of neat other things you’d expect inside the Atlassian ecosystem).

bz_ruco5zorq8lnv3cnme3tpjvq

Basics

Mentions, citation, styles for text. NO HASHTAGS THOUGH – giant bummer!

Cons

suffer_stride.png

And here’s my analogy of ‘Stride’ to russian word ‘Suffer’: you can use Stride, but it’s still raw, and a lot of features you’d expect to be basic in messaging, are half-baked in Stride.

Video Calls

Let’s admit, that Slack sucks at group video calls as well. But Stride is much worse ๐Ÿ™‚

stride_kianu.png

  • Issues include showing bad internet connection, when connection is good.
  • People may suddenly leave the call, although didn’t click on leaving or anything
  • Stride’s animations are smooth, so when it switches to another person, it fades in / fades out. And sometimes crashes during that animation!
  • Video lags a lot, sound doesn’t though
  • Video freezes a lot, and doesn’t resume until you restart the call
  • RAM consumption (400mb), CPU consumtion 70% on core i5 2014. This is a lot.
  • When you share the screen, and stride catches a glimpse of itself (stride window), it falls into the infinite glitch of Stride fractal windows.

Ok, done with the video calls!

Basics

  • No hashtags (sucks)
  • Sending messages is painful (it’s slow).
  • Sending messages with attachment is a torture (Stride waits until image is uploaded (slow), and only then allows you to click on send message (which is slow as well)
  • No forwarding between chatrooms -> leads to isolation of discussions to room-only.

Notifications

They are horrible (not Rocky-Horror-Show or Dr. Horrible way, and not even Troma-way. They are as bad as most coffee in US (ha-ha)). The sound of notification is bleak and unnoticable. You can’t change it, even if you rip apart the guts of app package and assemble it again ๐Ÿ˜ฆ That results in people not reacting on urgent messages.

2018-05-04 11-51-23

There is no mute for chat rooms, which results in information overload and renders the whole notifications system pointless.

There is no indication that your message was read by your counterpart. You don’t know whether to poke your colleague or he already read this.

Phone gets 2/3rds of all notifications. But when it does – mac app doesn’t show any of those! This is a typical failure, I’m writing this post on the train from Brest to Minsk where I ride to host AUG Minsk, and our team notified me with long message on my phone, but i see no new messages in my mac app. I have to restart it to get those messages.

Jira Bot

Although integration with jira bot is neat (hey, slack does that even better, actually), it crowds chat room’s vertical space like a giant worm that digs Jasinto in Gears of War 2. If you dump number of tickets to dicsuss in the chatroom, you can’t read any message because card previews will occupy the whole 2-3 screens of vertical space.

xetwzcbgzz5vqnfapjf4ab5il5a

JSON parsing

As per our admins, Stride doesn’t parse JSON on itself, so basically you have to parse and feed parsed JSON to the API yourself. Not the case with telegram.

Nutshell

Stride is not-horrible-beyond-anything, it’s ok. You can use it and adjust to it. Especially if you’re locked to Atlassian Ecosystem (and I love and use jira, even after the latest interface update). But if you’re already on slack – there’s no point, it will work better for now.

There are a lot of things to improve, and the guys at Stride work on making their product better. It took 5 years to telegram to become the best and neatest messaging platform, it took same number of years for Slack.

Parking Lot

References – Submitted Issues

Ufa AUG #1. Wrap Up

So we’ve survived Ufa Atlassian User Group, the very first meetup, with 17 people visiting our office to hear about jira, confluence, bitbucket and other atlassian products ๐Ÿ™‚

 

We’ve discussed how Jira helped us in reflecting SkuVault development processes, and how do we keep documentation on the feature in Confluence, until it’s released, and what info do we store there.

Panel consisted of Smena.io, modulbank, MEGI, and a couple other teams ๐Ÿ™‚ Presentation is available in Russianย via this link:ย UfaAUG_1.

Stay tuned atย https://aug.atlassian.com/ufa/ for more events in Ufa ๐Ÿ™‚

 

Agile Communication in Distributed Teams (with no overlapping hours)

So as you know my speciality is distributed teams ๐Ÿ™‚ This post is about what changes does the agile communication face (and scrum in particular), when it’s adjusted to the distributed teams. This is my experience, I don’t assume this is a silver bullet, but such approach works for me for the last 5 years and proved itself to be proficient.

Let’s divide communication by types:

  1. stragetic meetings (plannning, retrospective)
  2. daily huddles (e.g. daily standup in scrum)
  3. day-to-day clarifications.
2018-01-18 11.12.16
by Text I mean Instant Messaging

Let’s add another dimension: geographical distribution:

Collocated teams – everything’s perfectly fine for all three types of communication events. Teams, working in scrum, that are collocated face no issues with any of those.

Distributed teams with little difference in timezones, but still with overlapping hours. Great examples are US – Chile / Mexico. Netherlands / India.

  • Daily syncup can be handled with almost no pain, as well as planning and retrospective (if you incorporate scrum in your company).
  • Instantness of clarification on work tasks is lost (when overlapping hours end), however given that skype / hangouts / whatever you use is just a click away – no significant impediments are to be found.
  • No matter what you think about focused team, and that it processes everything faster due to unitedness, whenever team member is outside of her overlapping hours with the rest of the team – communication lag happens.

 

Distributed teams with no overlapping hours (8+ hours difference).

Approaches here are:

  • 3.1 Team liason. When someone from the team in one part of the world is having a meeting during his time off work, to sync up with other part of the team in different timezone. Usually, team liason is someone from product team, however there are different examples of who syncs up with dev team in the industry. It can be simply a representative from one part of the team that syncs up on the progress with the other part (just like in scrum of scrums)

 

  • 3.2 Timezone Compromise approach. Teams change their work schedule, to have a compromise in at least 1 overlapping hour, in order to sync properly. For example, start of working day for one part of the team in western hemisphere moved from 10am to 9am, and eastern hemisphere team changes their working day to start from 10am to 9am. Thus, you got at least 1-2 hours overlapping. Whoa, problem solved -> we can get back to bullet 2, on how teams with overlapping hours work together! But remember, everything depends on team configuration, whether the team is comfy with selected approach, and development tasks specifics.

 

  • 3.3 And finally, you can set up communication process in a way it’s comfortable for everyone in the distributed team. My personal beliefs is that redundant communication is always less efficient than on-demand-clear-bulleted-discussion, thus I’d prefer clear agenda and clarification when needed.

— 3.3.1 First of all, that means that people still are participating in retrospectives and planning sessions, cause those events happen once per 2-3 weeks (thus distraction or working off-time is tolerable). However, those meetings / scrum rituals are to be performed with clear goals, and well-prepared bullets. Try to not allow offtop conversations (when someone gets into topic not relevant to current discussion). Remember, team values personal time, and no team member should suffer from poorly planned meetings.

— 3.3.2 Second, it means that daily sync (or daily standup, if you follow scrum) can be done via text, at the end of team’s working day. In order to reach more visibility, developer can share a link to the branch, that he worked on. But main goal is to have an exceprt of what team member has done during the day, that is visible for everyone (e.g. special channel on updates in telegram). Some people also propose asynchronous video messages (Dave Snowden of cognitive edge shared this experience of his with me, referring to the times he worked at IBM) – you record video message for the team, and even share the screen, if you want some visual material on your work.

— 3.3.3 Third, clarificational communication (meaning day-to-day clarification communication type) is done on demand. Meeting for such batch of clarifications is done in a compromise time, so that noone’s felt left out). The good part of that is since you don’t have to get explanations on critical and extremely complex clarifications every day – you don’t need to torture your colleagues with evening / early morning calls each day. Usually, most of the impediments are resolved via instant messaging. Please keep in mind, that requirements standardisation is a key role in these clarifications, as properly structured requirements save a lot of time while developing a feature.

— 3.3.4 And fourth, but equally important, more standards and documenting. The more info necessary you prepare for your colleagues overseas, for the questions that may rise during your off-time, the less he will be stuck. Please use common sense in how much you need to prepare. When team gets to know each other, such planning becomes much easier. And finally, efficient process always means that person doesn’t get stuck ๐Ÿ™‚

Finally, we’re getting to my favourite ever part!

Distributed teams with no overlapping hours + language barrier! I’ve been working with those for the last three year, and here are the additional steps to make it all work efficiently.

The three common baseline rules to follow are:

  1. Prepare meeting agenda prior to the meeting. I’m talking about writing down basic points, explanations, and maybe even branching when presenting solutions (depending on meeting complexity). It’s obvious, that people not fluent in english can’t properly communicate during the meeting – everything starts to require much more time, which isn’t efficient (and quite heavy, when it comes to hourly payrates ๐Ÿ˜‰
  2. More documenting. You may say that Agile says “working software over comprehensive documentation”, however when dealing with distributed teams + no overlapping hours + language barrier, I can’t stress enough how much documentation means. There are key principles better to be described, as the team grows: communication standards (what type of communication is done via which tool, working time, speed of response), requirements acceptance, visual standards for documentation. All three principles affect how developer understands the task he’s supposed to work on. Requirements should have only one way of interpreting, should include clear pre-and-post-conditions; bugs are to be described in reproducible steps.
  3. And finally, it’s essential to have a bi-lingual person (team liason), who helps with english (he comes up with translation of complex bits, moderates the discussion). This person is better to be a developer or someone who gets the technical part well, as she often helps with syncing two development parts of the team. She may also add meeting notes on technical details agreed once meeting is over. That person most likely will sacrifice some of her time off, since hours don’t overlap.

At the end of the day, there are plenty examples across my experience, and blogs, how people manage to work with just on demand meetings, and create complex projects together. Those are git, atlassian and, among others – SkuVault.

Let me add an additional rule to common sense manifesto – process over redundancy. Greatly established process, understandable and rational for all parts of the team, makes it easy to track progress through transparency, keep team motivation high (for being productive) and time off undistracted.

References:

  1. http://www.disciplinedagiledelivery.com
  2. http://snowdolphin.com/blog/2009/2/16/adventures-in-distributed-agile.html
  3. http://agilemodeling.com/essays/communication.htm
  4. https://www.atlassian.com/blog/confluence/4-simple-collaboration-strategies-distributed-teams
  5. https://www.atlassian.com/team-playbook
  6. https://www.atlassian.com/company/events/summit-europe/watch-sessions/2017/scale-extend/a-brave-journey-in-merge-waters-how-paysafe-consolidated-their-atlassian-tools
  7. https://msdn.microsoft.com/en-us/magazine/hh771057.aspx
  8. https://pdfs.semanticscholar.org/cde9/6fed7d2e2591bc8f697814ab1f33e3a84160.pdf
  9. https://www.scrumalliance.org/community/articles/2013/july/managing-distributed-teams
  10. medium.com/@MentorMate/what-i-learned-managing-a-remote-agile-software-team-fd2db22e22b1
  11. https://www.researchgate.net/publication/263398659MoonlightingScrumAnAgileMethodforDistributedTeamswithPart-TimeDevelopersWorkingduringNon-Overlapping_Hours
  12. https://www.agileconnection.com/article/five-agile-challenges-distributed-teams
  13. https://www.agilealliance.org/wp-content/uploads/2016/01/Distributed-Agile-in-the-Enterprise-and-Virtual-Spaces-2012-08-16.pdf
  14. http://www.research.ibm.com/pdfs/scrum/Chapter6Pearson20090706.pdf
  15. https://www.thoughtworks.com/mingle/scaled-agile/2016/06/13/visualizing-time-zones.html
  16. http://reqtest.com/general/working-efficiently-with-distributed-teams/
  17. http://www.methodsandtools.com/archive/archive.php?id=109
  18. https://books.google.ru/books?id=jBsVrWbIhYUC&pg=PA112&lpg=PA112&dq=distributed+teams+agile+communication+no+overlapping+hours&source=bl&ots=0kdQw5RQo9&sig=SMVuHCrX0oH4dWq1KDn2lQ8-1fk&hl=ru&sa=X&ved=0ahUKEwis5tDGvOHXAhXGQZoKHWzRCqE4ChDoAQhMMAU#v=onepage&q=distributed%20teams%20agile%20communication%20no%20overlapping%20hours&f=false

Ufa Atlassian User Group

UPD: Rescheduled Jan. 30th -> to Feb. 6th.

Recently buddies from Moscow recommended me to join Atlassian User Group Leaders,to host Atlassian events in Ufa, so here I am (after an interview with Atassian)!

First ever-ever Atlassian User Group with special Atlassian swag will be happening January 30 2018, 7pm ๐Ÿ™‚ Meetup related to all things atlassian and related!ย Follow the link and save the date ๐Ÿ™‚ https://aug.atlassian.com/events/details/atlassian-ufa-presents-ufa-atlassian-user-group-1#/

2017-12-29 10-12-57

  • # I’ll be talking about how we adapted our development workflow in JIRA
  • # Documentation lifecycle in confluence at SkuVault

More topics to come, from our local Atlassian Users ๐Ÿ™‚

Ufa IT Management Meetup #4

This time it was all about requirements. And we hosted the event at our cozy SkuVault office:

IMG_1550

  • Eliciting and preparing requirements from gathering data till development:
    • Oleg Gumerov (PO at SMENA – solutions provider for a big delivery service) shared his experience on how they do it in SMENA.io;
    • Nur Ibragimov (Head Analyst at modulbank) shared their way of processing requirements;
    • Us (me and Ksenia – also PM/ BA at SkuVault) shared how we do it in SkuVault, as well as how we used to work on requirements at Storia.me back in the days.
  • Formalizing and Structuring the requirements, by our own Ksenia of SkuVault
  • Tracking changes in Requirements by Ksenia (lightning talk)
  • Tracking time and Estimations by me (lightning talk)
  • Documentation Lifecycle when developing a feature (by me)

And that was my first-time experience of stitching video and audio ๐Ÿ™‚

Meetup is in Russian, links are: VK / Meetup / Telegram Channel

Ufa IT Management Meetup (24.10.17)

2 weeks after we had the actual meetup, here’s the follow-up post ๐Ÿ™‚

Topics this time:

  • Keynote by me on cynefin and how it fits our company projects. Had some discussion & arguing on applicacy of cynefin when it comes to rough development times, migrations, firefighting-based development. Overall, model was introduced, and the fact-and-experience-based arguments are always the best. Cause we all keep it harsh, true and ironic, when it comes to sharing something you’ve been stuffing bumps on!
  • Afterwards beer-session was a 3-hour-rant on headhunting of employees by Moscow, Saint-Petersburgh, Europe and States, and that Ufa developers became much more audacious, over the past crisis-driven years (given that there was no crisis in Moscow and the rest of the world). Seems like the raises are imminent, if you want to keep the developer. Headhunting becomes more brutal and sneaky at the same time!
  • Yet another topic was keeping the valuable professional, when he reaches the limites of intra-company growth, and what is best to offer in those cases.

KXD01nqfom8

Overall, meetup gathers momentum and creates a community. We already got bigger guys from the enterprisey-yet-more-or-less-tolerable-sector, few startups on mobile/IoT/PaaS, Banking, Digital ๐Ÿ™‚

our links are: VK / Meetup / Telegram Channel