TL Diaries | Page 3 | Agile Anti Patterns and Antidotes

Photo by timJ on Unsplash

Estimates provided by Tech Lead or a Single Person

Estimates are used for multiple purposes like planning, budgeting, tracking, measuring team velocity and more. It is one of the important aspect which can have impact in many areas. If timelines of project deliverables are tight and you plan can’t be flexible then the accuracy of estimates become even more critical. Estimations done by one person would not cover the thinking from multiple dimensions. There are many assumptions made which can later turn out be complex and adds pressure during development. There is limitation to which a single person can think as well.

Estimations are team sport. Different roles in a team like UI Designers, Developers, QA and BA participate in this activity. Designer might think of adding a button should be straight forward without having knowledge of the underlying systems. QA adds the points that are not thought by developers like multi device compatibility etc. Every person in different roles brings their perspective to table that other person not able to think.This helps to achieve estimates with high quality compared to the estimates provided by a single person.

Not clearing off the Tech Debt in time

Working in pressure environments with tight deadlines, it might often happen that Tech debt takes backseat over features. As the code grows ,if tech debt is not actively paid off, the cost of new change keeps growing over period. and Code becomes difficult to manage at one point time when making a small change can impact large area of code.. The old code becomes difficult to extend and new codes needs lot of refactoring to fit in. Bugs are hidden if tech debt is not paid off often.

Tech debt can be maintained against cost vs value. This helps in prioritisation of the tech debt. Low cost high value tech debt can be prioritised over high cost low value tasks. Constant refactoring along with stories help in maintaining healthy state of tech debt.

As TL, it’s very important to prioritise and make sure that tech debt is paid off in timely manner.

Photo by Igor Peftiev on Unsplash

Delivery measured in Story Points

Projects may fall in trap of measuring delivery using Story points than value delivered by features. Project goals are measured in points, Sprint goals are measured in points. Points and velocity becomes the prize.this is the wrong usage off points. Story points are meant to size your stories relatively. and create a plan that can be re calibrated in a true agile way if assumptions fall flat.

Lesson: Never use story points as a measurement of delivery but value delivered by feature.




Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

DrupalCon 2020, a diverse digital conference about the Open Web

How I wrote my first programming ebook

PVS-Studio 7.19: what’s new?

What is a web developer?

Cloud computing: This new tool from AWS could make life easier for developers

Cloud computing: This new tool from AWS could make life easier for developers

Software Project Management and The Inevitable Crisis

closer and closer to the target


A Byte of Coding

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store


More from Medium

Implementing Agile in Bid and Proposals

How to — Retrospective

Create a team identity

An introduction to Scrum🥊