How to handle software project pressure – Part 3

How to handle software project pressure was already described in Part 1 and Part 2 regarding free time and project management possibilities. Now you can read my approach when it comes to software development and I also want to close that series on project pressure for now with that. I want to kick this of with this short video worth watching   So if you have seen this you know what transition I want to do. Never ever promise anybody things as developer (not only as developer) that you cannot do technically. But to bring you some structure I have 3 big topics in mind for you today:
  • Estimations
  • Test Automation
  • Meetings


I hope you get asked before your project is starting and you can get an overview about it. In agile development teams it is very common to involve the whole team in estimation meetings if you are doing sprints. Most projects also have  a longer plan, not only a sprint and I think also for this developers should be involved in the planning on this. The reason for this is to support your project manager with information he cannot have. It also shows upfront which person is already deeper into the topics and this helps later on to compose teams. As is wrote earlier it comes down to expectation management. The other reason is that you are more committed to do things you are involved early on. And please also think of the topic of software design and architecture. If you know the whole deal it is easier to decide about a proper system design.


Test Automation

"We have time for test automation after the first software release is published." I am a big fan of test automation and I always recommend to build test automation from the beginning on. For me I see not the need for test driven development. But what I really recommend is to create unit tests and integration test for the most important core classes and functions. I see this as biggest mistake over and over again not to do. You know it already but still you are not doing it. But this is making the difference as the project reaches one level of completion after the other to make your day easier. You know it is true.



How many meeting are you having? How much time are you spending on this? Can you answer this question? And if you have a intense project is the number of meetings, especially status update meetings going down or up. Ever meeting where nothings actionable is coming out is a waste of time. If you think you are having to much meetings just refuse to attend. If your team lead wants you to join tell them exactly how much time you waste and ask him which feature or bugfix should not been finished in exchange. You will see what happens fast.