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.
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.
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).
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.
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!
Small and duct-tapey resolution for the time, when you have an All -> [statusName] JIRA workflow transition.
By default, it results in the following: Default Ticket Screen shows transition from current to current status, among others. So e.g., you have an In Progress ticket, you have the transition to the very same In Progress. To avoid that, use simple conditioning for the transition:
Go to transition Conditions
Click Add New
Select ‘Value Field’ from the given list
Select logical operator ‘doesn’t equal’ / ‘!=’
And put a value in it (name of current status, and the value to be handled as string)
This works in the following way:
Perform Transition (if (Status doesn't equal string('currentStatus') condition is met).
@AtlassianTeam! A good UX would be something like a checkbox, checked by default, and labelled “Don’t show transition option to same status”.
И делаем это без необходимости прилета в РФ американского гендира.
Последние полгода я набивал шишки, ходя по инстанциям, собственно, поделюсь опытом 🙂 Задача: открыть 100-процентную дочку в России (материнская SkuVault.com находится в Луисвилле, Кентукки). Наш случай несколько уникален: CEO не мог посетить РФ, так что заверять и пересылать идентификационные документы приходилось туда-сюда меж двух контитентов.
На практике, все делается достаточно просто. Всего-то придется столкнуться с бюрократической машиной Mother Russia (которая за последние годы стала неимоверно удобнее), проблемами с межведомственной коммуникацией, ну да беготней с документами.
In order to let developer work as productive as possible, management should ensure the following bits related to her work are tackled:
Requirements Fallback – whom to ask
Issue Description & Decomposition
We moved closer to ‘no interruption’ bullet by creating on call teams, that are reacting to whatever urgent issues arise. (hållo to Kniberg’s Scrum from the Trenches 2nd edition – our own way of ‘firefighting teams’!).
However, there was no requirements preparation workflow a while back, so as the features grew more complex, more dependencies were discovered, we faced the inevitable given our product size: scope creeps, miscommunication, conclicting scenarios and inconsistency.
In order to bring all departments that were related to requirements eliciting and approval, we’ve created Product Management flow, which had to be highway to hell to better requirements.
Product Management Flow
We aimed to tackle the following areas by creating a formalized workflow:
Easy to understand sequence of steps
Each step has an accountable person, visible to all participants
Workflow encourages Argumentation and Discussion -> no misinterpreted suggestions and details are hashed out collaboratively
Each step ensures higher quality requirements, by providing criterias to be met on the output
Workflow consists of sequential steps: New Issue -> Discovery -> Sign Off -> Analysis
Ticket is created by trigger from multiple sources (marketing, services, tech, customer support forums,..). During this state, the ticket is relatively empty, providing only the request and source of the request.
Transition: In order to move the issue to the next stage, Product Owner reviews whether we’ll ever do this feature. If no – he closes it. Yes, sometime – he moves the ticket to Backlog. Yes, near-future – he moves it to Preliminary Analysis.
Preliminary Analysis (Discovery)
Step Goal: Product owner should outline Feature goal (what we need to achieve, benefits for our company and customers); describe basic business process (general 1-2 sentenses on how it works among the warehouse, since we’re a warehousing solutions company); and add that to wiki-page for that feature.
Brief feature description
Shipments are a way to track sale items that have been shipped to the customer of the Sale. A Shipment exists in SkuVault once a Tracking Number is assigned by the carrier.We want to provide an ability to connect and save tracking numbers, so that our users can have more visibility and editing right inside the app.
What do we want to achieve
Allow people that use shipping providers that don’t integrate with marketplaces as SkuVault How it works on the warehouse
Goal: Allow clients to label products with tracking number, and see shipments in relation to Sale they are attached to
Picker gets to the QC table
QC performing person takes the product, QCs it and labels the product with shipping label and tracking number
The tracking number is added to the system and can be visible in relation to the sale
User tracks the product via tracking number
Stakeholder Sign Off
Since there’s quite a stream of tickets, we let Stakeholders approve bunch of tickets at a time. Someone might say ‘Hey, isn’t that Product Owner’s responsibility, to approve?’. Well, first of all our product is big and includes different areas and domains: services, marketing, tech, operations – all having their own pursuits respectively, even if we’re moving towards the same goal.
Step Goal: approve the idea, general process and timeline for the feature to be developed.
The next step would be to gather related parties and start..
Analysis is biggest, most collaborative and complex part of the workflow. It involves:
[Business Analysts (creating User Stories)] => [collaborative efforts between BAs / UX / Developers (Wireframing)] <=> [BA / Developers (requirements adjustments, brainstorms, decomposition and clarification)].
Outcome: clear and atomized User Stories with Backend Subtasks with estimates, that give you ability to grasp and plan the feature for development. By you I mean us, Project Managers 🙂
Example: User Story – formalized and easy to grasp description, representing user activity and ability to interact with it.
Precondition: user is on Sale Info page
Before the user clicks a Shipment Tab in the Sale Info page, the hint at the top says “Click a Shipment for Detailed Information”
When the user clicks a Shipment line they see complete Shipment details at the top.
list of fields for Shipments can be seen in Shipments – Plans / Technical Requirements
They can click a button for Shipped Items or Total Cost to see detail for the items.
If a Tracking URL exists for a shipment the user can click it to open the URL in a new tab.
After new tab opens, user is navigated to shipping carrier website with tracking url info
If there is not a tracking url user simple sees “Unknown” instead of the url.
If a Label (ie: PDF) is present, the user can view it in a new tab, or download it by clicking on ‘Download’ button
Post-condition: user is able to see related Shipments info
We got strict rules for creating user stories, technical tasks, support requests and bug reports. This ensures same standards across out task-tracking system (Jira, and properly used Kanban magic) for different issue types, and allows to interpret requirements with the single possible way (which is extremely helpful :).
Right, so in a nutshell, this dramatically increased our requirements quality, and gave us ability to start analysing scope creeps properly, visibility for similar projects and better prognosis. There are things to improve, such as redundancy removal from the requirements, optimizing time spent on the workflow, better communication when estimating client requests – we’re getting closed to that!
one more thing: “oh, author, your flow is redundant for smaller features!”. You’re right, just remove sign off phase and ease analysis to accomodate simple story description for that feature / improvement ;).
Warning: don’t misinterpret scrum for agile as a whole 🙂
Around a year ago I wrote a yearly retrospect on how the workflow at SkuVault is organized, and how we set up our jira boards to work in sprints.
sprints and their goals
There was no Kanban backlog at the moment, and we used Scrum board as an improvized scrumban tool: we had the sprints, which were treated as folders to fit tickets in some time period. Classical sprints were not suitable for our workflow, I mentioned the reasons in Year Retrospective @ SkuVault. So that sprint-folder system was great, visible and allowed us to predict.
Yet, in a year period the signal that our approach (sprints as folders) doesn’t quite work appeared – there was a number of tickets migrating from sprint to sprint being rescheduled over and over.
Allow me to add a small note here on SkuVault specifics: There are different categories of work, and planning a common roadmap doesn’t quite work either: we get different priorities from different departments (QA, Product Management, Services and Angry Clients, Services and Happy and Willing to Pay clients) – so the urgent ticket scope inflates. Urgent tickets may require distraction of a developer working on some client request, which shifts the timeline for delivery. So, in a nutshell: there is no unified roadmap between different categories or depts – there is a near-term plan only, with each category having it’s own stack of priorities. Now add to this a remote team that works in collaboration across atlantic and with the timezone difference of 9-10 hours 🙂
So a question is: how to remodel the workflow to reflect the specifics?
Buckets and Kanban
We came up with the idea of buckets: basically those are categories of work, originating from different departments with separate product owner responsible for stack of priorities.
Last year Atlassian finally realised the scenarios teams use their product for. So, Backlog for Kanban was born out of desperate cry of thousands of PMs, Teamleads and other people who cannot develop themselves and just drag and drop tickets on the boards (/sarcasm).
The feature came out quite handy and we were able to merge our workflow with our development process IRL.
Backlog Kanban allowed us to re-evaluate a lot of backburners that were hanging out there, never getting into the sprints. It also gives us a cleaner board – cause you can store current workload apart from near-term plans, yet in the same board. It’s something you already get with scrum boards, just without sprint management.
We attacked backburners and development scope from two fronts:
created a separate IDEAS project, where tickets were getting fully fleshed out prior to development;
moved all of the backlog tickets that were on the shelf in development projects back to the IDEAS, to re-evaluate;
This + we’ve added Buckets System, with the support of limited number of devs in the pool for each bucket. I’ll try to write a separate post on how Buckets work in our company later (spoiler alert: they work only as indicators of ticket origins, otherwise – they are kind of not really helping, as of the current state, after some teams shuffling 🙂
Boards, Workflows, and two Backlogs
We’ve got two workflows – one for preparing the ticket for ready-to-be-developed state, the second is for development itself.
Each workflow has it’s own board – as you know, boards are the best ever unicorn rainbow tool to show state of the project from a particular angle.
So two boards reflect those workflows.
(Also called pre-development), managed by Product Management. Includes it’s own backlog for backburners, that we put in the shelf for some time (or close to forever); Sign Off, Detalization and Formalization, Architecture Review and finally Ready to Schedule states. Each step has a description and a format of how it should look.
The point of this board is to reflect status of every single idea that we decided to evolve into a feature, and to see the bottlenecks in Product Management workflow.
Establishing that IDEAS board was also a result of creating full Workflow for Product Management, without letting the ticket out of the IDEAS project and into main SkuVault development project, until all the details and edge cases are fleshed out (well, you caught me – there is no chance you get all 100% of edge cases, but you should try as hard as you can).
By creating standards for each step of formalizing the ticket, we’ve ensured the consistent quality of ready-for-development tickets, which ensured that they won’t be put on hold until clarification from API partner / Client / Product Management. You don’t get big stream of tasks pouring into development, but the quality of such tickets lets developers be distracted less and be more motivated, because who wants to switch context and work on something unfinished.
As I pointed out in previous posts – development board is pretty much untouched -> if it works, don’t break it 🙂
But the utilization of Kanban Backlog in JIRA came quite handy for both of the boards: you are able to have a set of tickets in the backburner, still in same project, but not wasting ginormous amounts of space on the board -> you just access all backlog via a special planning view.
While IDEAS board has a backlog with things, that should sit on the shelf for some time, Development board utilizes kanban backlog in a slightly different manner: I store optimization tickets that we need to check every couple of weeks / months there; as well as User Stories for Epics, that are still in IDEAS, that we didn’t get into development yet; or it’s a very handy way to form a pool of tasks for upcoming developers.
JIRA also support swimlanes for boards, which is utilizied by us in a manner of separating projects one from other:
..in a nutshell
We’ve ditched sprints, in favor of Kanban. It’s much easier to not pointlessly drag and drop tickets from one sprint to another, if they’re not ready. As I wrote, Urgent tasks needing on call devs contradicts with uninterrupted scrum approach for developing concrete chunks of functionality in a given timebox (mind the fact that scrum and agile as a whole deals with deadlines badly, while we have deadlines most of the time);
Kanban gave us differentiation by projects on one board, without making the board too crowded. Scrum boards give that too, but count the hassle of moving unfinished tickets from one sprint to another, which doubles the maintenance work;
Kanban Backlog is a great feature, allowing us to manage all tickets in the project. We could have done this in two boards (one for new tickets to be moved to agenda or closed, and another for development / formalization itself) – but now we can manage all tickets in one. Neat.
We had an Urgent Board (Kanban Workflow), and Development in Sprints (Scrum) -> now that we moved Development itself to Kanban, we were able to unify the boards, and everything, from minor to blocker tasks, is visible on the same Board! This is great!
Never use scrum rituals just for the sake of rituals. We didn’t use sprints for the sake of sprints, we approached sprints as folders and timeboxes. However it’s a common mistake, while management or teams create a cargo-cult for scrum. Most likely you’ll use different practices and methodologies over the time, and finally will come to a hybrid approach that makes you efficient.
There are different companies, and certainly there’s no silver workflow bullet for all. So given the maturity / infrastructure / tech. stack / staff – you should model the workflow related and reflecting the flows inside that particular company. SkuVault is changing, growing, scaling – and so is the workflow. Different depts can have different workflows – and we reflect that.