My Scrum Journey – In the Beginning

Context

A couple of years ago, I attended a Scrum training that was so kindly sponsored by a previous employer. At that time, I have already been practicing Scrum (which I now know actually wasn’t) in some form or another for seven or so years. So, understandably, I was excited (despite my bias against classroom-type training) to finally learn the fundamentals I felt I was lacking. Unfortunately, instead of laying a foundation, the training ended up getting me even more confused. And this sense wasn’t exactly isolated. As a former colleague humorously put it, many felt they knew less about Scrum after the training than before.

Here are some claims the trainer made that I found questionable:

- The Scrum Master and Product Owner are not part of Scrum Team (he probably meant the Development Team)

- Sprint 0 is a good/useful practice

- QA is done outside the development team

- UX involvement is only needed at the end of the Sprint

Looking back, as bad as that training was, it turned out to be the best training I attended in a long time (if not, ever). Not because of the delivery and definitely not because of the content but because of what it awakened in me, a desire to go back to the basics, to take it upon myself to answer the question “What is Scrum?” and to practice Scrum as faithfully as its creators intended; not because I think they are infallible but because of a sincere desire to really learn, master and ultimately adapt it (nobody wants dogma or to be dogmatic – to follow blindly – but Shu-Ha-Ri: follow the rule, “break” the rule, be the rule). So, in a very real sense, it set me on my Scrum journey.

(And, who’s to say that that wasn’t in fact the intent of the trainer. Perhaps, he really is a Scrum Master!)

What follows are some of my notes in the beginning of that journey (which I wrote some days after the training); mostly taken from the Scrum Guide and some articles and videos I have encountered online (that I unfortunately failed to note down). Those in italics I have added more recently.

(I have since moved on from the Scrum Guide to Scrum Patterns and I feel I have barely scratched the surface in gaining that depth of understanding that true masters possess.)

Brief History of Scrum

- more than 20 years old; created around the 90s, has evolved since -- latest incarnation is defined by the Scrum Guide

- created by Ken Schwaber, Jeff Sutherland; Mike Beedle also a pioneer, all three are among the 17 original signatories of the Agile Manifesto

- actually predated the agile manifesto; but conceptually based on it (but more so -- both historically and conceptually -- on Lean or more accurately, the Toyota Production Systems)

Side Topic: Agile Manifesto

- around the time the manifesto was written, waterfall was still the dominant software development methodology

- but there was a growing movement away from it; there were already distinct agile "ways" e.g. XP, DSDM, Crystal, Scrum

- basically, these "new ways" of doing software development was a reaction to waterfall and its perceived shortcomings:

--> big upfront planning + big release at the end of a long (several months long, even years) development phase resulted in delays, cost overruns and outright failures

--> traditional project management's focus on standard/stringent/heavy-weight processes and treatment of people as interchangeable/replaceable "resources"

- founders/creators/thought leaders on these "new ways" gathered and realized that though they have differences, they agree on a lot of things and have come to strikingly similar conclusions on how to do software development better

- the result was the agile manifesto - a distillation to the essence of these "ways" -- a set of values and principles that elaborate the values; so in way, agile is a mindset

- in many ways, agile is the polar opposite of waterfall:

--> people are the most essential; each one is unique and brings a unique value to the table -- they're not replaceable (in the sense that say servers are)

Side Comment: Agile for me is all about tightening feedback loops and continuous learning and experimentation. 

Back to Scrum: So What is Scrum?

A framework...

- it is a FRAMEWORK, not a methodology, not a technique

- analogy: building construction: foundation (agile manifesto values) + framework/structure (scrum) + exterior/interior design/details (methodology + practices + techniques)

- a methodology is more prescriptive with specific processes/practices/instructions; a framework can be built upon, filled in, though it also identifies boundaries/limits/restrictions such that when you go beyond them you are already outside of the framework

--> this will be made clearer later on

...for addressing problems and delivering solutions/value

- but a framework for what? a framework for addressing complex ADAPTIVE problems (such as developing software) and productively and creatively delivering the highest possible VALUE (i.e. value-optimizing)

- it is iterative and incremental; iterative pertains to the "process" and means repetition of activities (paulit-ulit), incremental pertains to the result and means building on top of past results (paunti-unti)

- what does iterative and incremental development enable? agility, flexibility, adaptation, changing course..why? (explain -- see pillars)

The Scrum Team

- the essence of Scrum is a small, stable and autonomous team of people -- the individual team is highly FLEXIBLE and ADAPTIVE

- they collaborate and interoperate

What is Development?

- when the words "develop" and "development" are used in the Scrum Guide, they refer to complex work and pertains to all activities needed to deliver a product increment (i.e. requirements analysis, design, coding, testing, docs, packaging, release, etc.)

Scrum Theory

- based on empiricism -- rooted in experience, encounter with reality, observation, experimentation

- pillars: Transparency, Inspection and Adaptation

--> inspect and adapt is a feedback loop, a cycle and is basically iterating the scientific method (there is a problem, you make observations, you come up with some hypothesis, you test it by experimenting i.e. trying out your hypothesis, you make conclusions, recommendations for future research/investigation, repeat)

--> inspect and adapt is only effective with transparency

--> every Scrum event is an opportunity to inspect and adapt

Side comment: I think these points are very important but are seldom emphasized in trainings. This is basically the Scrum thesis applied to software development: software development is a complex and adaptive process (as opposed to predictive; it is a blackbox/fundamentally uncertain because it is a creative process rather than well-defined/well-known; its first principles are unknown); to manage it and the risks that comes with it, we need an adaptive process, we need to constantly inspect and adapt, thus we need transparency, we need iterative and incremental development and not only that, we need the iterations to be short (to minimize risk); the product increment is basically an experiment and we learn, make conclusions, make adjustments, launch new experiments based on the stakeholders’, customers’ and market’s feedback).

Scrum Values

- commitment, courage, focus, openness and respect

- for you to reflect on; very important since as always values are the foundation where awesome things are built-on

(This was me attempting to relate/map Scrum values to Company values.)

--> build for the long term (commitment, courage, focus)

--> wear the customer's shoes (commitment, focus)

--> our employees and their families matter (respect)

--> humble (respect, openness)

--> hungry (commitment, courage)

--> have a point of view (courage, openness)

- values + pillars build trust; as we know, trust is very important -- organizational health rests on it

Scrum Team

- Product Owner

--> maximizes the value of the work done by the development team by clarifying and prioritizing product backlog items by value to the customer

--> can delegate but is ultimately accountable for the product backlog

--> there is only one PO per product backlog; the ultimate authority on "what" (but not "how") to do

- Development Team

--> self-organizing, self-managing; decides on the "how", how to turn product backlog into RELEASABLE increments

--> releasable is "DONE"; Scrum Team defines "DONE"

--> cross-functional; has all the skills (requirements analysis, designing/architecting, coding, testing, documenting, etc.) to create a product increment

---> does that mean every team member must have all the skills? No, but broad competencies are desirable and acquiring those competencies/skills are encouraged since it promotes collaboration, mitigates risks among others (T-shaped developer)

--> no titles, sub-teams regardless of work being performed, regardless of domains

--> development team members can have specializations, areas of expertise/focus; gaining deep skills/mastery over a specific area is also desirable and is encouraged

--> members may work on specific tasks but accountability belongs to the team as a whole; every team member is accountable for ensuring that the sprint goal is achieved

Scrum Master

--> helps team understand and practice Scrum; to follow its rules, stay within the framework

--> serves development team by removing impediments

--> facilitates decision-making, coaches development team on self-organization and cross-functionality

--> helps find techniques to help team be more effective

===

"Final" Words

Some weeks after I gave a "talk" to the team based on these notes, we decided to go over the Scrum Guide as a team. We spent an hour a week (or was it every two weeks) over several weeks going over the Scrum Guide, reading and re-reading it, discussing and reflecting on passages in it. We were conscious of how similar the format we adopted was to that of a Bible study (and we laughed at ourselves for it -- but we took the process and the learnings seriously nonetheless). Indeed, during those sessions, we took the Scrum Guide as our (Scrum) Bible. We also spent time, individually, taking and re-taking Scrum.org's open assessment. It did not take long until we were consistently getting 100% (the set of questions in the open assessment is quite limited) so a teammate asked me, "What's the next step?". I did not have a ready answer for her at the time but I did come back with one a few sessions later: "Scrum Patterns".

(I hope to add more links to resources in the notes above at some future date.)

Hello, Refactoring!

We often hear software developers use the word refactor when talking about changing existing code. The word is used so loosely that doing just about any change is considered, incorrectly, a refactoring. Yes, to refactor means to change but not just any change; rather, refactoring entails a specific kind change to achieve a specific purpose.

..so what is refactoring exactly?

"Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure. It is a disciplined way to clean up code that minimizes the chances of introducing bugs. In essence when you refactor you are improving the design of the code after it has been written." -Martin Fowler

Or operationally, "refactoring is the process of turning dirty code into clean code while keeping unit tests passing." - Idj

But why refactor?

(or what exactly does "improves internal structure" mean?)
We refactor to:

• to keep code readable, modifiable and easy to reason about
• to pay technical debt
• to reduce accidental complexity
• to go fast (by making change easy)

That's all well and good but how do we know when to refactor?

Easy, train and use your sense of code smell. The more you use it, the better it gets. Here are two common code smells:

• Long method
• Feature envy

Find more here.

Okay, seems legit. We want to learn. What do we do? 

Good. Start with two of the most common refactoring techniques:

• Extract method
• Move method

Check out more here. Do exercises like this.
But most importantly, read the bible. Practice what you've read. Spread the word.

Journey to Mastery

The following is the resignation letter I am going to send to my manager in the next couple of days.

Hi ***,

Please consider this as my formal notice of resignation effective July 31, 2019. My last day of work will be July 30, 2019.

I have been with [company] for over two years now and for the most part, it was a rewarding experience -- especially my stint as the lead of the [team] and for this, I am grateful.

In my years as a developer, I have seen and been with teams in many organizations and I can say with pride and confidence that this team embodies the spirit of agile the closest -- self-organizing, cross-functional and always seeking to improve. Of course, the journey to mastery never ends (or as Kent Beck puts it, perfect is a verb, not an adjective). It's non-linear and context-dependent. The struggle to overcome our weaknesses and reinforce our strengths is constant. It is real. To get side-tracked, make mistakes, fall behind or fail is inevitable. At the end of the day, it's the motivation of the people in the team that carries them through the errors and failures into the next level. And from what I've seen, I have no doubt that the [team] has what it takes. It will do well with or without me.

Regards,

Ronald

---------------------------------------------------------------------------

I decided the above was too dramatic. So, here's what I actually sent.

Please consider this as my formal notice of resignation effective July 31, 2019. My last day of work will be July 30, 2019.

I have been with [company] for over two years now and as a whole, it was a rewarding experience; especially my stint as the lead of the [team], for which I am most grateful.

In my years as a developer, I have seen and been with teams in many organizations and it is not too much of a stretch for me to say that the [team] is the best (if not in actual, then definitely, in potential). It strives to be agile and lean. It is self-organizing, autonomous and cross-functional. The journey to mastery is a struggle but given time and opportunity, I have no doubt that the Collection team will get there with or without me. I hope I get the chance to work with such a team again in the future.

Building a Culture of Organizational Excellence

The following is an e-mail I wrote to my managers about 4 years ago when they asked for feedback/ideas on the "cross-pollination" initiative they were planning to launch.

Hi Scott, Joel, Alona, Jenny,

This is several weeks late but I hope it could still be of some value. I have considered going directly to my suggestions/recommendations but I thought it may be worthwhile to also share how I got to them. (This is as much an attempt to organize my thoughts on "cross pollination", learning and knowledge-sharing as it is an attempt to synthesize and share ideas from books and articles I've read recently and not so recently so I hope its tone and length don't turn you off.)

Personally, I think "cross pollination" is a great idea but, as is probably obvious to everyone, doing it effectively is quite daunting because there isn't a simple, straight-forward formula or a sure-fire method to guarantee its success (i.e. that the desired outcome is realized -- a high number of engineers with sufficient retained knowledge to competently work on multiple products.) This, I believe, is because it all boils down to the people or the engineers involved who have varying skills, motivations and capabilities. (The variance is of such magnitude that, according to this study which is the basis of this article, the traditional normal or bell curve, which SeaChange continue to use, is ill-suited for characterizing performance distributions in organizations and that the so called power law or curve, which seems to pop up in various areas in human dynamics, is more appropriate.) As such, I consider the following to be key to doing "cross pollination" in our context effectively:

1. Willingness of engineers to learn 

2. Their ability to learn quickly

3. Their problem-solving, analytical & critical thinking skills

4. Their sense of (collective) ownership i.e. doing whatever it takes to get the tasks done

5. Hiring the right people to begin with 

6. Keeping them motivated to excel

To a significant degree, items 1 - 4, particularly 2 & 3, are pre-determined (which is why I think the importance of 5 & 6 cannot be over emphasized). Some are just innately predisposed, while others are not. (Furthermore, they are hard to measure. How can an engineer's willingness to learn or whether or not he/she has good problem-solving skills be measured. I doubt if any single metric can accurately capture any of these "competencies" but my hope is that there is an identifiable set of KPIs that can effectively measure, if not the "competencies" directly then, the results they are expected to produce.)

However, regardless of innate predispositions, I believe that all four can also be acquired or learned, at least to a certain extent, and that the right organizational culture (shared values, beliefs, mindset & norms) is key to acquiring them (over, say, formal training or rigid processes because these "competencies" like many others require tacit knowledge that by nature is difficult, if not impossible, to codify.)

Thus, to be successful (with "cross pollination"), I believe we need to create a culture where 1) excellence and learning are valued, 2) collaboration and knowledge-sharing are the norm, 3) challenging/questioning the status quo is encouraged, if not expected, and 4) every team member feels collectively responsible for each of the team's deliverables (or more generally, for the success or failure of the entire organization.) Moreover, I believe that if we are to succeed (in creating such a culture), we ought to expect the process/journey to be messy, difficult, protracted and iterative, fraught with errors and failed experiments (that we nonetheless have to make) 

I realize that 1) although these are lofty ideals, they are rather abstract -- what we need are concrete practices; 2) they cannot be achieved overnight or at all, without focused, coordinated effort and constant follow-through; and 3) ultimately, it is the "plumbing" and not the "poetry" that counts -- it's going to be the nitty-gritty, day-to-day implementation that determines our success or failure.

So in this vein, here's my attempt at some raw but concrete (-enough, I hope) recommendations:

1. Institutionalize knowledge sharing

 A. Regular (monthly?) half-a-day(?) sessions where engineers share:

a. What their teams are currently doing and why to other teams

b. Challenging problems solved recently and how

c. Demo new product features or share lessons learned from last sprint

e. Other interesting topics they found useful and think will be useful or at least, of interest to other teams (e.g. Java GC, Cassandra internals, performance tuning tools, etc.)

- As introduction/first topic, engineers could discuss/refresh the overview/architecture of products they sustain/develop and how these various products fit together.

- I envision this to be relaxed and informal (more akin to a discussion over dinner rather than a formal training) where engineers can freely discuss and ask questions even remotely tangential to the topic at hand.

- The point being to create linkages or open channels where knowledge can diffuse across teams and product "silos" as well as reduce the learning curve for engineers that will be "cross-pollinated"

- Can't be called "knowlegde-sharing sessions"; catchy name needed 

 B. Augmented Scrum

- Augment or even just re-focus the 3 traditional scrum questions of "what did i do yesterday?", "what will i do today?", "what issues are blocking me?" with "who did i help yesterday?", "what new concept or technique did i learn yesterday?", "who will i help today?" and "what do i need/want to learn today?"

- The point is for engineers to be always conscious of learning and knowledge-sharing/collaboration as well as recognize their value in relation to their tasks. 

- I see cross-pollinated members (or "cross-pollinees") as primary players and beneficiaries of all these "learning and helping".

 C. Re-vitalize the Wiki

- I believe our wiki has some very valuable content but is poorly organized. There ought to be a conscious effort at improving its structure and links (between articles/entries even beyond product "silos") and that effort should be considered a "real" task (i.e. managers should recognize/promote that it's worth allocating putting hours into) rather than just a side-task or a filler. Perhaps, techpubs can also help out or even lead this undertaking (i.e. improving organization and linkages of wiki pages).

- Creating wiki pages should be made an essential/integral part of an engineer's workflow, again, rather than just being an after-though or an add-on task or worse a distraction e.g. make it an expected artifact or better, another channel where engineers discuss ideas.

- Managers should start using the wiki too; for meeting minutes, documenting plans, updates, ideas or whatnot  

- Naturally, "cross-pollinees" will once again be primary drivers here since they will be doing a lot of learning and should utilize the wiki to take note and organize what they've learned. 

 D. Debriefing "Cross-pollinees"

- When cross-pollinated members return to his/her original team or transfer to a new team, there must a mechanism/venue/expectation for him/her to share what he/she learned from the team prior, even if it's just an overview of the other team's product or the detailed design of a some very specific component.

2. Encourage, or even force, collaboration

- Design/create user stories in a way that encourage collaboration or even manufacture, instead of avoiding, inter-dependent stories that force engineers within and across teams to collaborate so engineers could learn from each other

- Move away from the mindset that individual engineers are allocated to specific stories/tasks as it naturally fragments the team (with individual engineers pre-occupied with his and only his tasks), instead "assigned" engineers should be seen as leads or primary movers of stories that are collectively owned by the team; the entire team is expected or even required to contribute. Naturally, this implies that a team can't have too many members or too diverse or too many stories at once (if this is the case, then, despite appearances, there isn't actually one but multiple teams.) 

- Mentoring/coaching others should not be treated just as a side task to be undertaken when one's schedule allows (and thus something unaccounted and hence, seen as a burden), but a task and a goal in itself with its "cost" (in hours or whatever) and "returns" fully recognized by managers and the team. In other words, it must be made (or made known explicitly to the team that it is) an expected activity/task worth putting hours into and a value in itself.

- A "cross-pollinee" should be assigned, together with an experienced engineer, to an important story in the current sprint, preferably one that requires learning a significant breadth of product knowledge. This setup, especially because the story is important, makes collaboration imperative and in the interest not just of the "cross-pollinee" but of the entire team (because it can potentially make or break the sprint). It is therefore imperative to clarify and constantly re-iterate that though only two engineers are assigned to the story, it is the collective responsibility of the entire team.

3. Supplement story planning/commit meetings with design and strategy meetings

- In practice, the "formal" story planning has been reduced to identifying stories/tasks, high-level estimation and resource allocation i.e. assigning the stories and scheduling release dates.

- A deeper-level discussion doesn't really happen and understandably so, because the information to facilitate such discussions are, more often than not,  not yet available at that time and also because during commit meetings coming up with dates and schedules are the primary focus/pre-occupation. (I'm not looking for implementation-level detailed discussion but definitely something deeper than the usual high-level discussion during planning.)

- I believe the best time for such discussions to happen is during follow-on meetings at the point when an engineer is ready to design a solution or come up with a testing strategy.

- This should also provide a venue for analytical/critical discussions that are too long to be accommodated during scrums but too valuable to let slip.

- (And, even as I write this, it seems off to me or it seems to me that the order is somehow backwards -- that estimates and commits come ahead of these more "deeper-level" discussions.)

4. Reward excellence

- Make the process of selecting awardees more objective & transparent; to be truly fair, reward base on merit, instead of trying to spread bonuses "to be fair."

- Identify KPIs and track individual and team performance based on these KPIs; the KPIs themselves need to be carefully selected and under constant review; also, extreme care must be taken so the identified KPIs do not result to the opposite of the desired behavior i.e. engineers becoming too cautious or taking too much risk (and cutting corners as a result) or worse, "gaming" the system (to get high marks on KPIs without actually delivering or even eroding value.)

- Move away from the normal-curve based annual raises; treat performance evaluations as a re-hiring process (e.g. instead of "engineer X got a rating of Y, that puts him/her on the top so-and-so % and so he/she gets Z percent increase", why not "engineer X adds this much value to the team, losing him/her would be a pain; in our industry's job market, he/she would probably get, and so deserves a salary of, A (and not some percentage value based on his current pay.)"

- Come-up with team-centric incentives to reward excellent,highly-collaborative teams; perhaps instead of, or better, on top of individual bonuses, there could be team bonuses; there ought to be some level of "rationalization" or "normalization" though, since not all teams get equal opportunities to "shine". 

Thank you for reading all the way through.

-Ronald

Effectivity of Selection Methods as Predictor of Job Performance

Most of the articles I've read that compare selection methods as predictor of job performance eventually (because some articles cite articles that then cite the study) cites this study. Looking it up in Google Scholar reveals that it has been cited by over 4500 studies (note not merely articles but studies published in scientific journals). This tells me that the study is credible.

The study itself is a meta-analysis of research studies conducted in the past 85 years (until 1998). The study and its findings is not without its critics. For instance, this study questions the validity of its conclusions given the uncertain quality of the original data of some studies included in the meta-analysis. However, I find that the criticisms (of that particular study) apply equally to the different selection methods. So, as far as the organizations' practical problem of choosing selection methods is concerned, I believe the conclusions in this (and a recent version) are still the best we've got (in terms of being backed by empirical data and scientific rigor.) 

A working paper that updates the study was made available in 2016. It expands the meta-analysis to cover 100 years (until 2016) of research findings. The main findings and their practical implications remain the same but some findings differ.

Both the original and the updated paper found tests of general mental ability (GMA) to be a better predictor of job performance than either structured and unstructured interviews. In fact, in the updated paper it was found to be the single most effective predictor of job performance (in the original it was a close second to work sample tests). Moreover, in both paper, GMA was also found to be the single most effective predictor of job-related learning (i.e. amount learned on-the-job and in trainings).

Both papers also found that when combined with GMA, integrity tests yielded the highest incremental improvement over GMA alone as predictor of job performance followed closely by structured interviews.

My take on these is pretty clear. Let's do GMA tests. Doing away with interviews altogether is not unjustified. If we must do interviews, let's do structured interviews. The rest of the selection methods are either too costly (in terms of effort and resources required like work samples) or just really poor predictors (reference checks, years of job experience, person-organization fit, personality tests).