Agile and other means were created to solve the problem of 'how to deliver a project', and create a product or service. From the sheer number of these systems extant we can probably guess that nobody knows how to consistently build a product or service without failure.
There are a shit-tonne of ways a project can fail. Sabotage, incompetence, bad ideas, etc etc. So how can one live a happy life and get shit done? Probably these steps:
- you need to know where you are
- you need to have an idea how things are when they are going well
- you need to state the actual purpose why you are doing what you are doing
- you need to do what your purpose is
- you need to be aware when you drift from that purpose
As a developer I've experienced 'you need to work 40 hours a week', 'you need to log your hours done on a task in Jira' etc etc. Pretty much bullshit if you ask me. So what if someone clocks in and does 40 hours? What is the actual metric of a software engineer? I remember being in a meeting chaired by the business. They wanted a way to measure progress. They went round asking how many lines of code a developer wrote. 1000 the lead said, 600 said the senior, 150 said me. The business realised that was a stupid idea as they knew I had built a sleek system that solved some of the businesses problems.
How can you monitor productivity? Why would you? Well, if you are doing any activity you should be striving for as close to perfection as possible. Don't piss your pants or have a knee jerk reaction to 'perfection'. I don't mean perfect per se; I mean the best of what is possible. Why do an activity if it is pointless? Might as well work for the government. Joking aside, this leads to the question 'what is the ideal'? As a developer you want to work smart, deliver what is needed and wanted, on time, have high morale and not be stressed by the whole thing. Ok, lets spell this out. The ideal scene for a developer is:
TO DELIVER THE EXACT, QUALITY SOFTWARE SOLUTION TO A GIVEN PROBLEM, ON TIME, WHILST BEING IN HIGH MORALE AND STRESS FREE
As an aside, one thing that leaps out at me from the above is how many times in the past I have done some work that has turned out to be a completely pointless activity. This is a red flag and indicates that the product owner does not have a clear idea of what needs to be built. It is a cop out to say 'in agile you respond to change'. What this actually means is you adjust priorities in order to get to your destination. Analogy here: you are sailing across the atlantic, your destination is New York leaving from Porstmouth, you set a compas direction, you monitor and steer to keep on track. What you don't do is set a course for New York, then Iceland, then Canary Islands. Another thing to be aware of with product owners is Daddies money. Are they really spending their own hard earned cash or spending on whim? This reflects badly on vision and results in a drop in morale of the developers.
So how could we quantify morale and actual productivity? When we use Scrum we estimate tasks. This estimation changes over time as we get more and more precise the closer the team get and with more experience. So if each developer completes 15 points per week, consistently, we consider that a 'normal' situation. However, how is the developers morale? How are the quality assessments? What is their stress level? These other points are indicative that the scene is either working or something is missing.
- points per day
- morale
- ratings from code reviews (maybe ratings such as bad, mediocre, good, very good, excellent, from colleagues)
- stress level
So if points per day are low, it indicates blockers, or unclear task definition.
Morale indicates whether the activity is needed and wanted and aligns with the general purpose.
Code review ratings shows how much attention the developer is taking to what they are doing. Is it clean and easy to understand? Is it efficient? Is it correct? etc.
How is their stress level? If it is high it indicates some friction somewhere.
One does not need to get bogged down in needless admin. If that happens then morale will go down. Instead I like to think of this as a communicative task.
Product owners should have no excuse for any negative situations or pointless activities.