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.

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 🙂

Me & my colleague basically decided to attend Agile Greece and Agile Turkey, and then exchange opinions and knowledge gathered there. Big advantage of my trip was Dave Snowden’s keynote, whom I wanted to catch after the speech and bore to death with silly questions 🙂

Agile Turkey Itself

The conference (1-day conference, october 19th) kind of frustrated me, as 2/3rds of speeches were in Turkish, so I had to ditch my plan to attend certain events, and half of the time was roaming around the conference floor.

Dear people who stand behind this huge event, Agile Turkey team, please make a note next to the speech, that it may be in Turkish next time 🙂 That would be awesome!

The awesome part of that was that English-speaking crowd (mostly invited speakers) were roaming around the vortex (as Kurt Bittner joked) as well. Noone occupied their attention (possibly because of the language barrier), so I’ve turned that into 2-3-hour-long interrogations!

The Bag ‘Shift Happens. Be Agile’ has a nice slogan, but poor quality 🙂 Lots of spam from sponsors and small notebook with the pen. Felt like I’m on my local UfaDevConf conference.

Snowden’s Keynote

I’m so glad that I’ve attended to one of Dave Snowden’s speeches! He’s an amazing guy, I love his approach to not treat metholodogies and frameworks as silver bullets, I love how he merges anthropology with IT – and I share this approach wholeheatedly (given my specialization in Applied IT in Psychology).

Keynote was called COMPLEXITY, CULTURE AND CONFUSION. Snowden described cynefin model, which I find as an universally applicable framework for sense-making. My experience with cynefin emerged when we were trying to find an already-existing model of describing various projects we had at SkuVault with Ksenia. And guess what: it fits and describes how we firefight, develop new features, research/migrate/stuff bumps as a sequence of cause-effect perfectly (and I’ll write about that soon).

Key points:

Perception over mindset: I’m so agreeing with him, that mindset cannot be changed after it’s declared to be agile: you start with slow process and transparency improvement – and over the time the team becomes more agile. And only then the inner understanding of the business agility is fulfilled.

As soon as the company declares it’s now agile – it’s definitely the opposite (which is derived from the first bullet).

There’s a thin line between simple and chaotic systems in cynefin, and you may even not see if you’re already in chaos: it may be calm on the outside.

Work on company’s perception among the clients. Clients remember all past negative events you had. Interview the clients / market, and make sure you address the question: ‘what can we do so that clients don’t say this the next time’, instead of justificating your actions.

Company’s culture is to be inherited. There should be a knowledge sharing, when the creators transmit their values to the others, share both good and bad experiences over the course of the work.

Waterfall is not bad (thank god finally more and more people start telling that).

And yes, finally, SAFe and NEXUS stop being dynamic, when they scale up! And that’s the disconnection from the original Agility idea!

The latter part of me interacting torturing Snowden with questions on remote distributed teams with huge timezone difference, processes and estimations was indeed very satisfying! Lesson learned from almost every speaker I had time to chat with: SkuVault’s case is unique and you empirically find your own path of comfortable pace, workflow and communication.

Mr. Snowden also shed some light on asynchronous conference calls they had back at IBM, which seems like a very interesting idea to try now.

Kurt Bittner of Scrum.org

Later on, I sneaked out to him while he was listening to some old Van Halen stuff, and started to ask tricky questions:

How does Scrum work, when the team is distributed, when there’s a language barrier, when timezone difference is 9-10 hours? (>> scrum works, but that depends on how comfortable the team is overall with scrum and everyone’s got own approach, mixed with constraints that every organization has).

We recently worked on migrating a huge chunk of SkuVault to a new architecture and it was chaotic, is Scrum a good way to handle such? (>> R&D projects may work with Scrum pretty good, however in our case there’s no clear answer because using micro-sprints for 1 day and have a whole retro for that seems obscurely inefficient and redundant).

Politics (eww)… Skiing & Hiking in Colorado and generally in the world.. Does iPad Pro 12″ really allow you to do general work without bringing your laptop (for mail and notes yup).

Estimates – what does he think of them, do we even need them fully in scrum? (>> Kurt is not a fan of estimates. If you got a timerange – better give it (doing this myself all the time), and estimate is really needed only in times when you have to understand project phase length).

Overcertification, and is there really a problem with Scrum Master certification and poor performance of fresh certified practitioners, which devalues overall CSM / PSM badges? (>> gosh, this is a painful topic to discuss with scrum.org rep, right? 🙂 So the consensus was that SCM certification really only shows that you know the basics, it doesn’t tell anyone about your experience on the battlefield and definitely not something to rely on when forcing scrum 😉 So in a way, yes, certified people quality in scrum and process building may devalue certification perks… kinda…)

Kurt was not just helpful, he’s been my savior in the middle of turkish-only-speaking crowd 🙂 I thank him greatly for expanded answers, references to his experience and knowledge sharing!

Initial meeting consisted of Me, Nur (from modulbank.ru – online bank for small businesses) and Oleg (from smena.io – various crms / solutions for partners). Both work as analysts at cool and interesting teams.

So thank you, @Nur and @Oleg 🙂 First meeting went nicely, at my favourite coffe place Chat House. Meetup went as expected: we’ve shared experience and discussed who works via which workflow, how we formalize requirements and what are the places we store them.

Last year guys from SkuVault offered me an amazing opportunity to help the company manage a growing development team, create organized schedule, establish workflow that reflects the company goals .

For those who don’t know – SkuVault is a Warehouse Management System (WMS). Like a swiss army knife, SkuVault manages and syncs your inventory across e-Commerce platforms, POS, Logistics and Warehouses, providing accurate quantities in order to prevent out of stocks. Headquartered in Louisville, KY – SkuVault helps to manage the inventory for hundreds of clients all across the globe.

It’s time to list some of the achievements we accomplished during this year.

Observational Research and Optimization Scenarios

For the first 2 weeks, I was examining the flow within the project, and getting to know the team. Each couple of days I published blog posts on my findings with ideas on how to improve and optimize the workflow. Some things in my new team were completely different from my previous experience:

No teamleads. That meant that developers split up into Code Review teams, and reviewed each other.

Technology stack (.NET at SkuVault vs Scala / Riak / react.js at Storia). With all the pros and cons, .NET development teams don’t have that clear BE / FE differentiation: backend developers can work on frontend tasks via ASP.NET MVC, so our devs are more like (..universal soldiers).

No UX / UI design step in the workflow. This particular part makes every decision much faster. The product itself (SkuVault Warehouse Management App) uses Bootstrap, and is very utilitarian from design perspective. Key factor here is ease of use (as much as it can relate to industrial application).

Distributed team on both sides of the Atlantic, covering almost 24 hour period.

SkuVault is used by hundreds of customers around the world, bugfixing happens daily, and there are different bug priorities. This particular moment doesn’t work well with typical “sprint->release” cycles (because the priorities may change quite fast, or something needs to be urgently released).

With all those differences in mind, I started to streamline the workflow in JIRA.

Statuses, Transitions, Workflow

I managed to decrease the number of statuses.

Used to be: 23 (with any transitions allowed between any statuses)

Became: 9 (with clear status sequence that reflects state of a bug / new feature).

Most statuses were redundant, I’ve changed some of them with combination of “labels + status”, some were eliminated and substituted by generalized statuses (for example statuses “Design Holds”, “Client Clarification” changed to status: Hold + label “IncompleteDescription”).

The Workflow is constantly being refactored and improved per developers’ suggestions and whole team feedback. Last week I’ve released the 7th version of the workflow in a year.

Flow in general, and for every team member (BA / PM / Dev / QA) is described in our wiki, as well as terminology, list of labels to apply (there is a special glossary for labels). I explain the workflow as a sequence of steps, so that there is an instruction in case of emergency, or a new person onboarding.

On Duty Teams

During the first week we started to ask developers to fill a small questionnaire to find out how often they are distracted from new feature development by urgent client requests or bugfixes requiring immediate attention. It turned out that significant time (up to 80%) had been taken by Urgent Tasks, which distracted devs and made their work less efficient.

So the management team (well, actually it’s more like PMs, CEO, CTO and Support Lead) decided to establish teams of on call devs. These teams (2 devs: Frontend and Backend) would work only on urgent tickets, which allowed the rest of the team to work on regular tasks, ideally, without distraction.

On duty team concept has been rethought a couple of times, and currently we’re aiming at having 3 devs on call each shift, as client base grew significantly, and so have the requests, tasks and points of attention. Some of developers still get pulled to urgent tasks, because SkuVault heavily relies on integrations with other SaaS / eCommerce / Shipping systems, that change their APIs, improve their products, and may occasionally alter the way they interact with our system. And on duty devs may have questions for the developer who built the integration originally.

However, the concept itself proved to be extremely helpful, and overall the issue is resolved.

Mentorship

It’s a common thing to establish, when you have senior and junior devs 🙂 In order to clarify overall system architecture questions, seniors mentor other developers and code review.

Ticket Description Standards

Creating a clear guidance on filling out the fields and required info on a bug / new feature / or any other issue type is essential to streamline development.

Changing Kanban approach to Hybrid Scrumban

In a nutshell, a year ago development boards (one for planning, one for development) included lots of statuses, was extremely heavy (as you gotta display ~1k tickets), and hard to manage. Kudos to Tim Jannace and the team , who managed to bravely (and successfully) operate and maintain this board!

However, an agile board should focus on one goal: to show a piece of flow relevant for particular scenario / area. So those two boards were split up, so that each board reflects a single scenario:

Development Board, where the tickets transition from ToDo to Ready to Release: Scrum Board;

Urgent Board, which is used by on duty teams, and includes only Critical and Blocker tickets: Kanban Board;

Quality Control Board, where developers and test managers can to see the scope of tickets they need to review: Kanban Board;

Release Board, for the release manager to overview and manage the tickets that should be merged to master: Kanban Board.

There are boards for DevOps tasks, of course, as well as for other projects, but developers mostly have to check 2 boards maximum. And both of the boards are easy to use and lightweight.

On the other hand, pure sprint -> release cycles do not reflect how SkuVault operates, because of the Urgent bits that need to be released almost daily. So sprints are more like folders here, which allow us to forecast approximate or particular start / release dates for the tickets, and limit feature scope in a given time period. That’s why it’s called ScrumBan 🙂

Notifications, Due Dates, etc

I’ve also established automated email notifications on Pull Requests or Tasks are not Reviewed / Tested for more than 2 days.

We started to use labels trigger notifications for tickets that will soon miss due date, or for ones that shouldn’t be rescheduled.

There are a lot of other specifics, changes, undergoing improvements – over the year team grew significantly, as well as number of clients – and we adjust the company flows accordingly. Developers look motivated, and I couldn’t be happier to work in such an environment.

Key findings this year:

Don’t make a release the goal itself. Quality product is the goal. So you can skip a release or two, but deliver something good. Even if there are lots of clients,they would understand the importance of stability, not the feature they want firsthand;

Write up retrospectives on problematic moments, so that you solidify foundation of your experience for yourself and others. Try to gather additional data and opinions inside the team, in order to provide a broader angle to the problem;

Make everything possible to have a good human relationship with developers and other team members. You are colleagues, and a good person will always try to do her best, if she’s motivated (see motivation reference article);

Horizontal hierarchy and a little bit of dev anarchy is always good. Every team member should have his voice at least heard;

Always update team feedback on how things are, this is essential to keep the flow up to date and address concerns that devs may have. Cause you know, in IT, team is what defines success, and good manager’s work is to facilitate work and motivate the people;

Maintain comfortable release pace for the team and the clients;

Read professional literature, but don’t forget to check how this works in reality 🙂

There is always room for optimization. You just don’t have enough time! You can spend days micromanaging things, to extrapolate optimization on global flow later. Neverending exciting job.

Maintain work/ life balance. Don’t let team overwork.

Aside of your professionalism, key things to stay motivated are team spirit and ability to apply and improve your skills. For the past year we became mature, overcame challenges, and continue to create awesome WMS for our clients. Looking forward for the next adventurous year at SkuVault 🙂

Thanks to Ksenia, Slav and Kim for the review, and SkuVault team for the support.

I’ve recently been to Vienna, and visited local Austrian Startups Stammtisch. It went by the number #31, so quite a consistent event going on for more than a year now. The event took place in Sektor5 co-working space (which I have to recommend, because it’s a really cool place with only eur 18 per day! You can feel the international vibe and all that kinds of stuff).

Bureacracy. In order to open a traditional gmbh company, you may need to be patient and get a lot of papers and formalities. It can take up to 120 days.

Government support. However, the good side, is that the process of bureacracy is not that painful, as the govt. is on your side and supports businesses will to change the country to innovation-driven economy. Grant system is strong here (http://www.austrianstartups.com/grants/)

Hard to notice, when you’re from Russia, but Vienna is quite close to strongest european mainland startup hub: Berlin. An hour-flight only 🙂

English is embraced throughout the IT startups. So yaay!- Expats! However, you’re more welcomed, if you speak deutsch. And because socialistic mindset, a good Austrian professional is mostly more preferable, than a great expat 😉 And there are loads of cool pros in Austria.

Tons of sessions and meetups happen in Vienna, Salzburg and Graz. May keep you busy almost 100% of your time. There was a great atlassian event in Graz, that I wanted to attend, but didn’t. Sad.

Great startup (and established IT companies) scene! Some of the big startups from Austria include: Runtastic (surely you’ve heard about it), bikemap (great stuff, more route-oriented than strava), Shpock (my facebook is overloaded with it’s ads now), mySugr (basically an ecosystem of apps made for people with diabetes, by people with diabetes) and lots of others.

Vienna is extremely lovely!

Met great ppl from Austria, Ireland and Eastern Europe 😉

Hey to Odessa guys, who created a venture find and were searching for partners (Crop Inc),

Product is crafted by people. It is not a sum of collaborative work. It’s usually a combination of work, excitement, collaborative ideas, feedback loop inside the team throughout the whole project lifecycle.

Passion is right at the heart of every person, and if environment tends to motivate – a person will work hard to achieve a good result (appreciated by the team and himself). Moreover, working with passionate team amplifies the overall product, makes it bigger than sum of efforts.

I approach to motivation as to a three-factor equation.

Excitement about the project (and willingness to work on it)

Ability to apply your skills (and improve them)

Compensational part

Let’s leave out compensational part. Let’s also make a note, that such approach doesn’t work on lousy boring projects.

The rest two points are extremely transparent, if you work in a smaller companies with more or less ‘flat’ hierarchy and informal communication.

Excitement about the project comes from inspiration. It could be something cool, that brings value to the market. Aspirational team, that challenges you, while you challenge them. This makes it extremely easy to go & do your job day by day. Such teams later stick together, even working on different products, to exchange ideas and share experience (as we did with Ufa42 Conference).

Once the project is exciting, challenging – person starts to work hard in order to bring his valuable contribution. Developer, manager, designer, analyst – everyone is involved into general decisions, everyone is able to improve the product from the inside. Which means he can apply his skills in a good way, practice fresh approaches and technics, learn on mistakes, tune the workflow.

However, lack of involvement in product creation (aside from simply doing your job), vertical hierarchy and formal chain of command – it all kills the motivation. This brings us back to our equation: team is unhappy, not motivated = product not exciting. World doesn’t need boring products. Don’t forget: awesome pros won’t stick with something dull for a long time, they will leave as soon as they can. And we all know, that finding great teams is something almost impossible 🙂