Observation created over 5 years agoFeaturing:Ethan M.Joseph A.Joshua A.Waseem D.We ask clarifying questionsWe get agreementsWe inspire others to do better workCommunityDesign CollaborationBack-end engineerFront-end engineerDiscovery engineerEpic shaperStory shaperI am grateful for how these 4 have been communicating on this project. This is a complex project for a variety of reasons. We are splitting up the frontend and the backend. Linking elements in our app is a difficult endeavor. The way these four have communicated to one another and to me has been such a joy. Whether it be Waseem posting killer updates in the channel, Joshua and Joseph presenting their findings on technical deep dives, or Ethan walking me through expectations on epic breakdown, everyone has chipped in to really get this off the ground.
I have been inspired to bring the level of clarity I have found here in other aspects of my job.
Observation created over 5 years agoFeaturing:Alec R.Ethan M.Waseem D.We share before we're readyDecomposition & SequencingEpic shaperFront-end architectBack-end architectThis thread speaks to it: https://lessonly.slack.com/archives/CPHPVJSTH/p1574698910011200
This is a great discussion and approach to taking on what could be a larger project in Linked Elements. The team was able to work together to identify and slice up the work in order to get value into the hands of customer faster. Alec said it in his summary here:
We are going to structure the epics so at the end of each element the element is fully implemented. This means that at the end of epic two the paragraph element will have all of the linked element functionality. Then epic three will be the photo element fully implemented.
- This will mirror how the platform team rolled out a role management, a fully functional piece of a larger whole. This means we can learn more about the entire linked element process earlier.
- It gets to value quickly. We have been hearing for years from clients about the linked element functionality. With this plan, we will allow admins to do this whole process faster!
- It will make the delivery manager role more smooth. Because of this plan, each epic will look similar technically speaking. The first element will take the longest because we have to implement all of Linked elements but after we will be able to determine with reasonable accuracy how long each element takes to build start to finish.
As a result...
- This enables the squad in efforts of successful decomposition of ideas into shippable units of work to deliver customer value, validate P&E assumptions, or both
- Developing right-size slices of work that fit into the checkpoint and quarterly goals
- Thinking through the stack in a way that promotes flexible story creation (e.g. model/database, API, routes, react components, UI).
- Your squad consistently gets slices of work into customers hands for testing as early as possible in the lifespan of a project
Observation created over 5 years agoThe PR Waseem wrote for https://github.com/lessonly/lessonly/pull/7197 is just fantastic, even by his own high standard. The context, problem, mechanics of the solution (including diagrams!), and even performance data are included. He's showing a deep understanding of the issue and the PR is educational as it explains itself. Everyone should check it out!
Observation created over 5 years agoFeaturing:Waseem D.We don't wait to be told what to do, we take initiativeFront-end engineerDevX Enablement LeadSince we didn't have a team meeting yesterday, I wanted to shout about Waseem's recent PR to enable some accessibility checks in eslint: https://github.com/lessonly/lessonly/pull/7075 This is the culmination of months of work upgrading eslint and its dependencies. The benefits of up-to-date software are many (security, performance, reliability) but in this particular case it allowed us to enable some accessibility checks. Sure, linters like eslint help us keep our whitespace consistent, but this is an example of how they can really shine: as teaching tools. As a result of Waseem's work, now when we accidentally write UI code with accessibility flaws that make it harder for some folks to use Lessonly, we'll get a warning that "Hey, we can do better!" (And we'll have to fix it before that code can be merged.) Automation like this scales with our team, and it doesn't just make our code better over time, it makes us better. This gives me confidence that as we grow, we won't be one forgotten Lesson or hurried code review away from falling short on accessibility, but that, at least in these examples, it's guaranteed to be a part of how we build software. Finally, I'm reminded of Nassim Nicholas Taleb's Antifragile (which makes an appearance in Do Better Work), which is about building systems that aren't just resilient to failure, but that get stronger from failure. Here is an example where when we make certain accessibility mistakes, we're guaranteed to learn and grow, getting stronger and smarter as we do. Heck yeah!