One of the challenges we always had with software engineering was finding the balance between strict deadlines and time to get it right. Software development is still more art than science, especially when innovating and working on major changes. Different constituents like customers, prospects, analysts, sales, support, and engineering have things they’d like to see, and want visibility into when the features will be delivered. Naturally, the market changes so fast that as an entrepreneur or product manager, there’s a desire to push back on too many fixed deadlines as that limits flexibility to adapt to new information.
Here are a few considerations with balancing software engineering deadlines:
- Work off short deadlines, like two week sprints, and use that to keep up a good pace of progress (don’t allow any to do items longer than two weeks such that something that might take two months is broken down into two week chunks)
- For longer range considerations and road maps, try painting broader strokes for areas that will be addressed instead of specific improvements
- Find a level of accountability for the engineering team such that there’s ownership over delivering on time while also making sure it’s fully baked (don’t let the balance of influence sway too much such that deadlines and deliverables aren’t met while still being realistic)
The best thing to do is to build a really strong engineering culture that views code as craft and has peer-to-peer accountability.
What else? What are some other considerations for maintaining a software engineering balance between strict deadlines and time to get it right?
4 thoughts on “Software Engineering Balance Between Strict Deadlines and Time to Get it Right”
Great insights in the context of everyone jumping on the MVP train. With respect to the engineering and product management teams meeting a deadline it’s much easier to get the minimum right, but harder to get the viable right.
Also, having one single person accountable for managing the backlog for all sprints would be ideal for maintaining the balance you need to walk this tightrope.
Couldn’t agree more with this line: “Software development is still more art than science”. Especially when you’re talking about technology and startups in new industries moving at a rapid clip
At Scoutmob, we do two-week sprints starting on Wednesdays and then fill in the gaps with daily standing scrums in the morning. The sprints keep the team focused and the scrums keep us organized and on the same page. And naming the sprints is a must. We usually kick off each sprint with a funny video related to the name.
I think this is the “Responding to change over following a plan” part of the Agile manifesto.
Precise deadlines are fantastic as long as things can pivot when they need to. There is always going to be push from the blunt end that the importance of various features has changed, and there are always going to be unknowns that the sharp end clarifies that will require re-prioritization.
Having a single person that knows what is going on and/or a single tool that is the authoritative source of everything going on with a project certainly doesn’t hurt.
I took an entrepreneur class my last semester in graduate school which was taught by a professor who also runs her own company. That was back in 2009. I have been trying to start my own company since then but havent been able to put it all together. The last couple months I have been working on a social ecommerce site called VaStreet (www.vastreet.com). I have really enjoyed working on it. I am planning on launching it in February. I have a full time job so I have been working on it in my free time. I thought this article was interesting because with the limited time I have to work on this, I feel like I am just trying to make deadlines and figuring out ways to slap together this product. I figure I can work on getting it 100% right later.