My TL;DR style notes from articles I read today.
The failure of Agile
- Agile suggests embracing change, using an ‘inspect and adapt’ approach. This is possible only for experienced and skilled team members who have the mental models to handle the real world abstraction of these concepts in play.
- For beginners, it is easier to follow simple, context-free rules. Agile methods have some concrete practices to start with and new teams latch on to those and get stuck there.
- Andy Hunt, one of 17 founders/authors of the Agile Manifesto, along with Jared Richardson, proposed a solution to this a few years ago that combats these problems of agile.
- It is the GROWS Method where GROWS stands for GRowing Real-World Oriented Working Systems. This aims for evidence-based inspection of real-world feedback.
- A notable quote by Andy that explains his thinking behind GROWS:
“Software is not designed and built; that’s far too a deterministic, linear model that doesn’t work here. Growing is a better metaphor because with growth comes change. Real-world oriented is a nod to the idea that we need to base all our decisions and direction on actual evidence: feedback from the real world, under actual conditions. Anything else is just some unfortunate combination of fantasy and wishful thinking.”
Full post here, 5 mins read
How we write an incident postmortem
- Record the impact of the incident, steps taken to mitigate it, learnings from it and follow-up tasks identified.
- Make postmortem a team effort, led by the on-call engineer and compile a timeline of the incident.
- Keep the conversation free of blame.
- Ask how the mistake was allowed to happen, whether automation could have prevented it in the first place and whether wrong assumptions were behind the mistake(s).
- Check whether alerts for the problem came fast enough and whether they could be improved or added to.
- Consider whether the initial assessment of an incident’s impact was accurate and whether the impact could have been worse than it was.
Full post here, 10 mins read
Perspectives on issue tracking
Some fundamental capabilities of issue tracking we should pay attention to:
- It helps in enlisting unique tasks to be done.
- It helps identify ownership of an issue, sometimes extending to multiple roles.
- It allows for the organization of issues into components, hotlists, sprints, releases, backlogs, etc.
- It can establish hierarchy and interrelationships between issues.
- It helps to aggregate discussions around an issue by supporting comments.
- Issue trackers make for excellent knowledge repositories for postmortems.
Full post here, 8 mins read
I share these TL;DR versions of articles on software engineering that I read every weekday through my newsletter - in.snippets(). Sign up here if you liked what you just read.
Top comments (0)