The retail industry has been squeezed on many fronts over the past decade, from Internet giants flexing their technology muscle (and willingness to not always turn a profit) to disrupt markets to fast-moving start-ups who are unencumbered by big company process, and who are able to attract strong technology talent.
So, you’ve decided that responding to change over following a plan is going to be one of your guiding values. You look at your plans and think “Gosh a lot of decisions went into creating this roadmap, I don’t want to be changing these without good reason”. Then you start getting conflicted over what good reason is, “How can I be confident that rearranging the roadmap is for the best?”.
So you are trying to build a fast moving digital organisation, one that responds to market opportunities, is decisive and can get things delivered. One of the challenges you may encounter is a thing we call Analysis Paralysis.
There have been a few rumblings recently between the subculture of TDD-lovers and the rest of the programming community, as always. I’ve heard reports that TDD doesn’t work, that it is snake oil, and that there are studies to suggest that TLD and TDD are no better than each other in a scientific study.
The primary goal of slicing software is to make it cheap to ship, and inexpensive to ship additional features.
With the latest reforms to IR35 having come into effect on April 6th, public sector bodies (PSBs) are facing the mounting challenge of keeping teams filled. This, coupled with the Civil Service-wide recruitment freeze introduced in 2010, is a particular problem for PSBs tasked with delivering digital projects, where software engineering teams were once largely made up of contractors who now have an incentive to look elsewhere for work. The reforms are here to stay, so what options do PSBs have in terms of continuing to deliver good digital products?
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.
At the end of an iteration it’s good to take some time to reflect as a team to assess what worked, what didn’t work, and what could be improved upon. This can result in future iterations being more efficient and productive, as well as increasing happiness in the team.
Code quality is a term that is often thrown around in the software engineering industry. And like the art of coding itself, it is very subjective and its true meaning will differ depending on an individual, or a team’s beliefs. But at its heart most engineers and teams would agree that good quality code is easy to read, well tested, and maintainable in the long term. But how do we achieve this?
Morale is closely related to job satisfaction. When morale is high, your team is happier, more productive, and more likely to believe in your organisation’s vision. On the flip side, not enough (or any) praise for a job well done, dealing with a difficult clients, or heavy workloads can significantly lessen morale, and sometimes lead to higher employee turnover.