How #SCRUM tweet began

Historical anchor: April 2012. Written as a present-day reconstruction on August 29, 2026.

#SCRUM tweet began years before it became a published book.

The surviving evidence takes me back to April 2012. A working spreadsheet identifies #SCRUMtweet Book 01, calls itself Draft 0.1, and records April 15, 2012 as its last-updated date. A publisher questionnaire from the following day carries the title that stayed with the project: 140 Thought-Lenses to Build Better Software Using Scrum.

The book was published in 2016. Its origin belongs to 2012.

What I was trying to understand

Project management was already an important part of my work and writing. I had been practicing Scrum since 2008, and I wrote regularly about project management, software delivery, teams, and professional responsibility.

Scrum caught my attention because it disturbed a familiar assumption about how work moves.

The manager does not have to remain at the center, dividing work, assigning it, and pushing people toward the plan. A capable team can pull bounded work, make its commitment visible, and take responsibility for turning that commitment into evidence.

That was more than a change in procedure. It changed the relationship between responsibility and action.

I read Scrum, practiced it, and blogged about it. I started ScrumZen to think in public about what happened when teams tried to use the framework in real work.

On May 3, 2012, I submitted an article to Scrum Alliance as Seven Things I Wish I Had Known When Starting Out as a ScrumMaster. The editor accepted it that day. During editing, she asked me to identify and link the people and resources I had cited. On May 16, Scrum Alliance confirmed that the article was live under the edited title Seven Things I Wish I'd Known When I Started Out as a ScrumMaster.

The original page no longer survives at its old address, but the Internet Archive preserves a May 23, 2012 snapshot of the published article. I have also preserved the article in the Almanac with a present-day note rather than silently rewriting it. A 2015 public reply of mine on the Scrum.org forum also points back to it and records something else I remember clearly: the article attracted comments and criticism. I valued both because I was not trying to repeat a manual. I was testing what I believed I had learned.

The book grew from the same impulse.

Why 140 thought-lenses

I did not want to write a long explanation that a reader would understand once and forget.

The THiNKaha format offered a different constraint: 140 short thought-lenses, each compact enough to remember and practical enough to affect behavior. The eventual book had 3 movements: build the right mindset, build great software, and inspect and adapt.

Rajesh Setty had a profound influence on this work. He became my mentor, helped me understand the form, and served as the book's editor. His THINKtweet and the publishing structure that became THiNKaha made this kind of book possible.

Tanmay Vora's #QUALITYtweet was an important nearby example of what the format could become. I had reviewed its manuscript. Mitchell Levy helped the book move through the THiNKaha publishing process. Jesse Fewell wrote the foreword.

I remain grateful to each of them, and especially to Rajesh, from whom I learned far more than the structure of a book.

The format forced a useful question: if I had only a few lines, what did I actually want a practitioner to notice?

The 2012 proposal used the difference between a map and a compass. A map assumes enough of the terrain is known. A compass helps when the route must change but direction still matters. Scrum, as I saw it then, could give a software team that kind of orientation.

I believed strongly in the framework. Some of my language from that period gave Scrum more power than I would give any process today. But the manuscript also contained its own qualification. Methodologies were a means to deliver. Working software had to justify the methodology. Pushing work onto team members was the wrong use of Scrum.

The tension was present from the beginning.

The manuscript I lost

On November 1, 2013, on Dhan Teras, thieves broke the glass of my Honda City and took a Mac, a BlackBerry, and a hard disk from the car.

The manuscript was on the stolen devices.

I remember the loss through the physical scene: the broken glass, the empty space where the devices had been, and the realization that work I believed I had completed was no longer available to me.

Hardware could be replaced. The manuscript had to be reconstructed.

So I wrote the book again.

I cannot recover every sentence that disappeared that night. I can say that the thinking survived the theft. It had already passed through reading, practice, blogging, argument, and revision. Recreating the manuscript was not the same as retrieving a file, but it was not beginning from nothing.

The published book eventually appeared in 2016.

What survived publication

#SCRUM tweet contains the confidence of the practitioner I was and the early signs of the position I later reached.

Scrum mattered because it helped me see pull, ownership, visible work, feedback, and adaptation. It gave teams a language for inspecting how they worked, not only what they produced.

My Scrum blog then said, “Scrum is a vehicle, not the destination.” It also argued that Scrum exposes problems but does not solve them. People still have to solve them.

That distinction became more important to me with experience.

Any process is not a solution. A solution is a solution.

This does not make the earlier work embarrassing or irrelevant. It places it in its proper role. A framework can improve how people see, decide, coordinate, and learn. It cannot substitute for judgment. It cannot make an unwanted product valuable. It cannot rescue a weak solution by making the delivery process look disciplined.

The durable lesson was never loyalty to Scrum. It was the movement from being pushed through activity to pulling responsibility for an outcome.

That movement still shapes how I think about project leadership under uncertainty and the Forward Professional. The vocabulary has changed. The question underneath it has not:

What will you take responsibility for moving, even when no plan can tell you everything?

Source note

This is a present-day reconstruction, not an article written or published in 2012. The April 2012 origin is supported by surviving book-project files. The May 2012 Scrum Alliance milestone is supported by the submitted manuscript and surviving editorial correspondence. The November 1, 2013 theft and reconstruction are my recollection. The published book records 2016 as its publication year.

Related: When Scrum Mattered and the published book record on Amazon.