Hey everyone, here’s my list of resources and literature for getting prepped for the PSM II examination. I would be tremendously happy if you share yours 🙂
Sidenote: if you are “certificates are overvalued” type of person – I’d agree. This is especially true when it comes to CSM / PSM I – because that certification only mentions that you have been introduced to the basics. However, when it comes to PSM II you need to rely on your experience as a Scrum Master. No more “shu” (of shu-ha-ri), just your experience and daily understanding of agile values.
By the time I write this post, there are 6793 PSM II holders.
PSPO open – because there are questions related to an understanding on how to coach PO and how to work with value. (might I say that you can easily pass PSPO exam in case you’ll pass PSM II)
PSM I – since you MUST know everything in it by heart. Values, roles, events, artifacts.
PAL-E – so that through coaching you could understand higher management, metrics, organizational maturity.
PSK open – foundations of working with the flow.
Nexus open – foundations of official scrum.org scaling solution, although not the most popular one.
Other tests should be treated with the grain of salt. The internets provide you with a wide variety of preparational test suites: some of them are more oriented for passing PMI-ACP (and are overall PMBoK-skewed); other ones should be avoided at all costs as they mutilate the very basic principles of scrum and sabotage your preparation – stay aware.
Coaching, books, training
Lyssa Adkins: Coaching Agile Teams – rather easy-to-read and universal cookbook for Scrum Master’s stances of an agile coach, facilitator, teacher. It perfectly complements your personal experience.
There’s a small section on conflicts, which I find useful (in case you don’t want to dive deep into the science of conflicts). By the way, the book in my experience is greatly enhanced by ICAgile: ATF (Agile Team Facilitator), ICAgile ACC (Certified Agile Coaching) training courses.
So we’ve been measuring story points estimate and throughput through the last 5 sprints, and they really do show approximately similar results 🙂 makes you think why do have an additional story points layer on top of the simple throughput? 🙂
I spoke with Ben Linders of InfoQ (thrilled to be published at that website!) about challenges and communication patterns for Distributed Teams, uncovering bits of my Atlassian Summit 2018 speech.
The biggest challenge of distributed teams is communication, which is essential for establishing ground rules on collaboration. Shifting working hours to accommodate each other and team liaisons help to communicate and synchronize work. Teams based on trust, respect, and openness will thenselves to help people throughout the organization and foster a culture that keeps teams in sync.
InfoQ spoke with Kiniabulatov about the challenges of distributed teams, how product owners and stakeholders collaborate at SkuVault and how the workflow is managed, how distributed teams communicate effectively and synchronize their work, and how SkuVault nurtures a culture that keeps teams in sync.
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:
stragetic meetings (plannning, retrospective)
daily huddles (e.g. daily standup in scrum)
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:
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 😉
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.
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.
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!