TL Diaries | Page 3 | Agile Anti Patterns and Antidotes
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.
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.