After talking quite a bit about how to break a Feature into tasks and avoiding leftovers, I would like to address the natural habit of what I call “blindly moving forward”. How often do you find yourself after 3 days of coding, still unclear of how many days are left or whether or not you’re closer to the end? How often you tend to forget what exactly you originally meant by “the end”? How often you find yourself feeling too invested to stop and figure out what the hack is going on?
We are, naturally, very outcome oriented. “I need this Feature done until tomorrow” or “I need to see your plans for next Sprint until end of day” keep pushing us during our daily effort. We are driven to supply outcomes, losing the ability to track the big picture because of vast, ever growing demand for results. Just like multi-threading coding, it’s not enough to throw some languages, tools or IDE with cool debugging options to the mix; we need to change the way we think and act, to supply visibility rather than mere progress.
When breaking a Feature, ask yourself these questions:
- Do you fully understand the Feature business value?
- Do you have Risks mapping (what can go wrong and what to do on such case)?
- Do you have the right people in-sync? (QA, Operations or other relevant team members)
- Do you break the Features by layers or by verticals? Are you OK with that?
- Do you have low granularity of tasks (up to 3-4 hours)? Enough to make you feel good about “no surprises”? Enough to allow others to join you?
- Do you know when you’ll be code-ready? Can you commit to a date?
As a Team leader, you should ask for visibility from your teammates. They should earn your confidence by offering a complete plan, knowing what the expected outcome is and communicate their status during the development time. If you ask me, I will always prefer better understanding of current status over naïve “I managed to progress today”.
As a developer, you should aspire for complete visibility to make sure you’re moving in the right path. This will allow others to give you honest feedback, join you if you’re a bit behind schedule and practice leadership in a way that is building confidence in your organization: people will feel that you know what you’re doing and will trust your good judgment and commitments. They will feel more confident when you’re behind the wheel.
If you feel that this is an overhead, you probably in a misconception of the time it will take you versus the time it will save you. Answering the above shouldn’t take 5 days; it should take couple of hours. This will ease your mind regarding “did I miss something?”, saving you hours of juggling between building confidence with your manager(“Can you update your progress?”, “Where are you standing?”) and actually building the software.