How do we go beyond seeing documentation as a burden and ensure that it is maintainable, reliable and valuable? Documentation is necessary to explain how something complicated works and defines a critical process to ensure a successful software release.
More people are now being forced into a remote working lifestyle that they may be unprepared for. I’ve been a mostly remote worker for around two years and wanted to share some of my routine in the hope that some may find it helpful.
Do you keep an up-to-date record of the current context of your product? And the needs being met by your product?
Some years ago, I worked as part of a development team on a project to upgrade a tangled legacy system managing a company’s payment systems. Two months in, and we had very little to show for it – pages of diagrams that looked like spiderwebs, a few outages caused by failed attempts to untangle the pile, and a rising level of frustration.
A silo exists in an organisation when one group within the organisation has differing goals to another. In most organisations there are groups of people that, usually, have an objective to fulfil by an agreed upon date. For example, the Sales team is set a mandate to increase the number of customers of the company by 10% every month, whereas the Support team has internal performance goals, and one of them is to deliver support within a fixed budget.
It’s not a particularly well kept secret that there can be challenges organisations face when offshoring software development, both for greenfield builds and for products running in support and maintenance.
Both words, “agile” and “planning”, mean different things to different people. In this article I hope to provide an overview of agile planning without going into specific implementations like Scrum or Kanban whilst still providing practical advice for any implementation.
It’s a poorly kept secret that increasing levels of responsibility, particularly with knowledge workers, often correlates to an increase in performance.
A solution problem is an emergent property of a solution. Experienced Software Engineers avoid creating solution-problems, they create simple solutions for the root problem.
In any organisation, one of the most powerful ways you can empower your team is to give them an environment that allows them to communicate freely at all levels. At Made Tech we actively encourage every member of the team to initiate or join any discussion that interests them, whether it be giving their opinion on how a part of the business runs, or introducing a new way of approaching how we work.