Building our team - Anticipation

the action of anticipating something; expectation or prediction.

Image Source - https://scoutlife.org/

From marketing and advertising professionals to inventory planners and IT professionals, the ability to forecast and anticipate customer needs comes from a variety of sources. Anticipating customer needs and demand can provide small businesses with a competitive advantage. ~ https://smallbusiness.chron.com/

The ability to make a judgment call during the software development for all the tasks at hand is the skill that is expected from an experienced software developer. The reason I say this is because

1. They have been having more years of industry experience
2. They are working on the product for more than a year
3. They are the expert in the kind of work at hand with greater control
4. They have seen many patterns of projects going wrong
5. They are supposed to take the tough calls

Let me share a story about our recent sprint. There was a lot of pressure from the clients to get the request in the recent sprint. We had no scope to say NO and We could have maybe lost face by saying NO. I am not sure what exactly was the pressure and reason to take more than our capabilities.

Our Team delivered what has required but there were some miscommunication within the team and some internal bugs and we had to drop some other low priority tasks which we have been carrying forward from Sprint to Sprint. One of our team members fell sick so their release was pushed and a couple of other things did not fell in line.

Are you a Professional Team and Do you know your capabilities?

I would ask myself, Why would I stretch myself if I am not sure about something and have I planned for contingency. Have we considered all the learnings from previous sprints?

There are standards shared by many companies out there who have overcome the common problem. Your job is to not do all the job at hand but to find a way to do it in the smallest number of steps whenever possible. You have a set amount of time and energy in hand so you must focus on doing the best work you can with what you have consistently.

I strongly believe that there are tactics that could come in handy to improve your capabilities and improve your commitment.

Create tickets for Bugs

I learned this from the book Joy, Inc.: How We Built a Workplace People Love - by Richard Sheridan. To create a task with story points with title Bug #1, Bug #2 so on. Calculate the % of the time you and your team puts in a ticket. Calculate everything from internal bugs, clients bugs, the support team fix it after few months to the original story points. So if your team velocity per Sprint is 25 story points and your error rate is 20% then you should only take 20 story points and keep 5 for Bugs.

Plan for Surprises

I think I learned this from the book Mythical Man-Month, The: Essays on Software Engineering by Frederick Brooks Jr. You have to plan for contingency and things that are not in your control. My recommendation would be you should allocate 10% of your time to it. It's your insurance to avoid coming under unnecessary?pressure. That means if your team velocity per Sprint is 25 story points. That would be 3 Story points with a ticket name Surprises.

Over Communicate

This is from my personal experience working with so many teams for so many years. After remote work, the team does not read any non-verbal communication and all the introverts with a lack of written communication find it difficult to share their message. The clarity of the team's Goal is more blur and the Goalposts seems to change all the time. I learned about this concept from the Ted Talk of Rory Sutherland. He speaks about Chief Detail Officer. So I think you can record videos, add details to the ticket and share the thinking process along with the task. People with 15+ years of experience may think this is a waste of time but the young programmers are trying to learn so many things at once.

Over Estimation

The penalties for underestimation are more severe than the penalties for overestimation, so, if you can't estimate with complete accuracy, try to err on the side of overestimation rather than underestimation. ~ From the book Software Estimation: Demystifying the Black Art by Steve McConnell. He adds, In software, the penalty for overestimation is?linear and bounded—work will expand to fill available time, but it will not expand any further. But the penalty for underestimation is?nonlinear and unbounded—planning errors, shortchanging upstream activities, and the creation of more defects cause more damage than overestimation does, and with little ability to predict the extent of the damage ahead of time.

Shame

There is No Shame in accepting your shortcoming or your flaws. Our nature to prove something or show someone that we are better is not a good attitude to have. Yes making things better to make progress in good. However, the stretch goal while you're finding your rhythm mostly backfires you.

I think it's better to bet on the skills that you are 100% confident about. Make a note of skills that you are not good at like writing a Test for your code, working with git hub with multiple branches, don't know how exactly the feature is supposed to work or as a leader find the shortcomings of your current team and guide them before they fall. Pad it up with more time so that you can do it in a way that aligns with your Teams' Goal

Chasing Goal

I don't know if it's in our culture, but we think it's a Zero-Sum Game (Only one can win at the end). In the game of business or work it's an Infinite game, similar to life there are different seasons but there is no single winner. If you think Apple made it in the world of Business they said that BlackBerry made it too. If you are too young to know who is BlackBerry? Exactly my point no one remembers the company that made accessing secure emails on phone easy for business people.

Numbers are the by product of your process. Focus on the process

The numbers that are put out there is a benchmark or a milestone. It should be used as a compass for your journey and not a destination. The focus should be more on processes, practices or principles to improve. The result will automatically come every time and each time. It's not that you should not celebrate your results but don't give so much significance because when the result is not in your favour you will feel the hurt.

If you say you are not chasing goal but your actions show you do. It's not helping you.

Photo by Vlad Sargu on Unsplash

I will understand that you won't win all the time. You will end up making mistakes but if you are not growing each time and repeating mistakes from the past. You are here to learn and not learning collectively from the team to anticipate the next 3 weeks of the Sprint is something that is not good for you, your team or your clients.

Share this with one of your colleagues Today.