Timeboxed

self Asim

After years of aspiration, I finally have the opportunity to share that I am now a Certified Scrum Master (CSM) and Certified Scrum Product Owner (CSPO). My journey, supported by the outstanding leadership of SJVAPCD and the encouragement of my management team, has just begun. This post aims to share my insights into the world of Scrum, detailing key takeaways such as timeboxing, Scrum teams, trust, self-management, ceremonies, the importance of separation of concerns, empirical process, and more.

It is important to note that the the content within this post is a brief overview of some of my favorite aspects of what I learned in both classes and not a detailed exploration on all attributes of Scrum. Over time and with more experience I certainly intend to delve deeper into the individual elements of this framework.


Key Takeaways

šŸ‘EVERYTHINGšŸ‘

Itā€™s all good, just do it. No, seriously.

Okay, so thereā€™s going to be some stuff that resonates more with me than with you and vise versa, thatā€™s just how things are. In addition to that, some concepts are just not as impactful on a personal level but take time to brewā€¦ more often experience itself brings out these lessons that we didnā€™t really notice all that well before. Having said that, hereā€™s what stuck to me right away.


Timeboxing

Time management technique that limits an activity to a fixed timeline. Depending on the task the timeline may be minutes, hours, days, or weeks.


Scrum Team

  • Cross-functional
  • Self-managing
  • Typically 10 or fewer people
  • Developers/people doing the work: kind of self-explanatory with the whole "people doing the work" thing I added there. Another way of putting it is "skilled individuals who are needed to add value and complete increments toward the overall product/project goal". This group manages the Sprint Backlog.
  • Product Owner: maximizes the value of the product, manages the Product Backlog.
  • Scrum Master: establishes Scrum as defined in the Scrum Guide; Coaches the team in self-management, helps keep focus, removes impediments to team's progress, facilitates Scrum events (ceremonies); Serves the organization in leading, training and coaching Scrum, planning and advising, removes barriers between stakeholders and the team.

Trust

Out of all Scrum values trust is just so damn huge. Iā€™d argue that everything falls apart without trust, itā€™s just such a basic and foundational need upon which everything else is built.


Self-Management & Accountability

When people have ownership of their work, specifically deciding what and how to do it, you will always get a better product. Through self-management emerges accountability, and that right there is the prerequisite for a transparent team built on trust and self-inspection.


Ceremonies

Iā€™m a big fan of structured meetings. When meetings have undisputed definitions that everyone understands and agree on, everyone knows what to expect. When everyone knows what to expect, anxiety and fear is minimized so that the entire process becomes routine and focused. In other words, build a staging environment to better extract value from these meetings. Now itā€™s important to have someone keep everyone in check and on task, just having the definition of a meeting is not enough. That someone is the Scrum Master, facilitating meetings is just one of the tasks this role takes on.

Scrum ceremonies include:

  • Sprint planning
  • Daily stand-up
  • Sprint review
  • Sprint retrospective

Each one of these serve specific and integral purposes in the process of moving from idea, self-organization, focus, presentation and feedback, and self-reflection.


Separation of Concerns

This subject is a little bit tricky for folks who are not used to relinquishing responsibility and letting teams guide their own progress. Nevertheless it is essential for production of top notch work and quality/shipable products.

Much like the organizational importance of different Scrum ceremonies their purpose and who attends is equally (if not more) important.

Many folks might be surprised to know that majority of these events are attended by devs, or simply people who do the work, rather than supervisors and management. In fact Sprint Review is the only time the entire Scrum team and stakeholders (customers, management, etc.) are invited.

I can definitely see how this structure can shift anxiety from the core/dev team to management but in reality, if you remember, Scrum heavily relies on empirical process.

An Empirical Process is an Agile-driven process where the team expects the unexpected. In a defined process the team would plan every detail of the product with the assumption that this is required for the product to become successful.


Empiricism in Scrum and Reducing Risk

To calm some nerves about what is said above: every single time an issue arises in an organization the root of contention is almost always wrapped up in reducing risk.

Scrum is founded on empiricism and lean thinking. Empiricism asserts that knowledge comes from experience and making decisions based on what is observed. Lean thinking reduces waste and focuses on the essentials.


So while separation of concerns and process exists the transparency and openness does too. After all, remember, this is all built on trust.

Ok but what about risk reduction? Keep reading. šŸ‘‡


Reduce Risk

Scrum employs an iterative, incremental approach to optimize predictability and to control risk. Scrum engages groups of people who collectively have all the skills and expertise to do the work and share or acquire such skills as needed.


Incremental Release Strategy

With each sprint a usable piece of value, increment, or collection of increments that meet the criteria of Definition of Done is/are added to the product goal. Now this sounds too deterministic, obviously you can and likely at some point will have failed sprints that produce little to nothingā€¦ but the ultimate goal of a sprint is to further the Product Goal.

Bit by bit the product is built, and with every sprint cycle reviewed, inspected, and received feedback on by the stakeholders. The crucial part that makes Scrum click for most people is this final step. Once you realize that the timeline for these events is relatively short (up to 4 weeks) you begin to see the importance of partial and incremental product releases. It is this exact process that uncovers:

  • Is the product on the right track?
  • Is this what we even wanted to begin with?
  • Unforeseen issues are exposed.
  • Value may be found in places once misunderstood or not even looked at.
  • Etc

Commitment & Definition of Done

The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.

The Definition of Done creates transparency by providing everyone a shared understanding of what work was completed as part of the Increment. If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review. Instead, it returns to the Product Backlog for future consideration.


Now this is a commitment for the increment. For the Product Backlog it is the Product goal and for the Sprint Backlog it is the Sprint Goal. Expanding on the principle of commitment would take a whole new post so Iā€™ll save that for later.


Scrum Pillars (TIA)

My simplified take on the pillars of Scrum:

  1. Transparency - all work must be visible to those doing the work and those who are receiving the work.
  2. Inspection - "check-in" process that teams often do to make sure that progress is being made toward the agreed goals.
  3. Adaptation - if at any moment the process or progress falters resulting in undesirable outcomes the team must adjust immediately to prevent further deviation.

Each of these pillars lean on one another and provide guide rails for teams to function at their very best and most efficient versions of themselves.

Most importantly teams who are not empowered to self-manage and lack overarching principle of trust will see the last pillar crumble and the framework invalidate itself.

Boy that sounds a bit doom-and-gloomy doesnā€™t it!? šŸ˜± Yes, it does, and thatā€™s why it is so important to understand these pillars and establish trust early and reinforce it often.


General Class Notes

One of my favorite aspects of both classes, even if they were run a little bit differently, was the fact that we were there to learn and do the work for the full 16 hours per training. Iā€™m sure just about everyone who takes these courses are sacrificing important time from somewhere else so getting down to business and holding pedal to the metal the entire time is greatly appreciated.

Aaron Sanders ran his CSM course with a traditional approach to breaks, every couple hours or so weā€™d take a 10/15 minute break. Steve Martin on the other hand ran his CSPO course using shorter but more frequent breaks, about 6 to 9 minutes every hour. Now personally I donā€™t have a dog in this race and any ratio of instruction/break works fine for meā€¦ but having said that, thereā€™s something to more frequent but shorter breaks. During particularly longer and heavier lecture stretches losing focus after about an hour is pretty darn easy. I found that allowing for a short break after an hour and then back to lecture creates a reset for focus and attention.


Breakout Sessions and Activities

Both courses utilize plenty of interactive activities. In fact, all of the activities are built on interacting with others in the class. I meanā€¦ weā€™re learning about a framework built for working better with others after all. I felt that CSPO course was a little more intense in this department but the CSM course wasnā€™t too far off, besides there is no test for CSPO so a more involved participation program makes sense.

I have to admit that Iā€™m not necessarily the most chatty or eager to join in the funā€¦ right away at least. I usually take a little bit to warm up, Iā€™m sure Iā€™m not special in any way about this. What helped the most here, in both classes, was that I wanted to be there and learn. If youā€™re doing any of this stuff just to check a box, think about spending your time doing something else.


The CSM Test

Anyone wondering about this test: if youā€™re interested in Scrum and want a CSM this test isnā€™t going to be a problem. Just stop right there, relax, calm down, too many people were entirely too nervous about it during the training. Having said that, just remember this: most of the questions on the test are not about right or wrong answer but the most correct answer. If thatā€™s too much, donā€™t even attempt to study for PMP.


Burndown Chart

I almost forgot! During the CSPO class Steve Martin used a burndown chart to track his/our progress throughout each day given what was on the course backlog. This was the first time Iā€™ve learned about sizing tasks rather than estimating time it would take to complete each one. After sizing everything the chart was fitted for a full work day. Then, as time progressed, we checked back and reviewed where we stood on the chart (burning down, burning up, etc.). Steve, if youā€™re reading this could you please send me a copy of that spreadsheet? šŸ™ Thanks!


In conclusion

Speaking of reading, if you made it this farā€¦ THANK YOU SO MUCH! This post was timeboxed for a 15 minute read (average reading speed). I am beyond grateful that you took the time out of your day to let me share my CSM and CSPO experience with you. Take care and checkout the links below if you want to learn about some cool people, organizations, and, just in general, maybe learn something new.šŸ‘


Acknowledgements