How do you run software projects in 2020?
October 26, 2020 8:43 PM Subscribe
When I started professional software development, the industry seemed to be moving loosely from waterfall to agile. We didn't have the tooling that's pervasive today, but physical boards moved digital and it feels like a lot changed. It seems the only thing that's really stayed the same is daily standups, which I have a strong dislike for. What's working for you? I've seen some new methodologies/tools like coda, has the tooling changed for the methodology? Are strict backlog grooming/sprint planning/retrospectives worth it or are there better way to track metrics?
I work in consulting / contract development mostly. Clients often have yearly budgets which are fixed, where they have a need for some sort of software project that need to be done by a deadline. Software is seen as a cost center so whatever works when the project is over is going to probably be there without iterative improvements. Simply put, the metrics that work for consumer application like engagement value aren't driving these projects.
Without driving this question in one direction or another, simply what works for you? Are you simply checking in on Slack instead of doing daily standups? I often work with a new PM every 3-6 months, so by the time the PM trusts the team a new one appears. I find that after the stakeholders on a project become comfortable with a team the need for formality relaxes, but since this changes so often for me how do I establish and define formality? I hate to be the grumpy lead developer in a meeting, but I feel like I'm always going through freshman orientation!
I work in consulting / contract development mostly. Clients often have yearly budgets which are fixed, where they have a need for some sort of software project that need to be done by a deadline. Software is seen as a cost center so whatever works when the project is over is going to probably be there without iterative improvements. Simply put, the metrics that work for consumer application like engagement value aren't driving these projects.
Without driving this question in one direction or another, simply what works for you? Are you simply checking in on Slack instead of doing daily standups? I often work with a new PM every 3-6 months, so by the time the PM trusts the team a new one appears. I find that after the stakeholders on a project become comfortable with a team the need for formality relaxes, but since this changes so often for me how do I establish and define formality? I hate to be the grumpy lead developer in a meeting, but I feel like I'm always going through freshman orientation!
working in a larger company may be a different experience than what others may describe, but our development (for a purely internal product, no external customers) is done in Azure Devops, Pipeline and Git. Mainly ADO right now as we are transitioning to the other 2 tools at this moment. My dev/test team is 6 hours ahead of where I work so our daily standups are at 9am (for me). Our updates are not informal, we - quickly - go through our "user stories" and arrange for further discussion either with other colleague/stakeholders or among the PO/PM, other resources. I am pretty happy with this methodology and the overview it gives our leadership. we have been able to push back on too much work by demonstrating our capacity is an objective way and forced the discussion "fine, what do I deprioritise from our backlog?"
posted by alchemist at 11:31 PM on October 26, 2020
posted by alchemist at 11:31 PM on October 26, 2020
Tracking progress remains a big problem. I use Cumulative Flow Diagrams (which visualise work in flight as well as time at each stage of workforbottlenecks) and I like giving the team the tools to be reasonable adults and self-organising experts who can take feedback to improve their work. I would use a metric of sprint-by-sprint reliability using a rolling average of completed arbitrary-story-point units from the previous 3-6 sprints. This helps focus the team on estimating well, corrects over-promise-and-under-deliver, helps create pride in delivering consistently and not choking their swimlanes with too much work in progress. Teams take time to build a sense of how much the team can get through and how much error budget, contingency time or rework that they need. Newly-minted teams estimate badly until they improve.
Publishing progress also remains a big problem. I've not cracked the problem of those estimates having unseen complications or simply being unable to predict the total workload to complete milestones in the readiness of a product. We usually have to do 'how far can you go in this time-frame (or with this amount of funding)?' and hope that the self-organising experts can optimise their work patterns to explore the problem space and use past experience and patterns to solve the problems quickly. I expect also that teams will be escalating issues when they block progress and stay on target to create the product they're supposed to be on.
The thing I'm looking for is a lightweight way to record information that supports the team's decision-making. If there was an easy log of 'decided in favour of X because of contingent information A, B, C' we could track the experiments that led us in the directions we took and why, then when backtracking is needed we've got threads to follow when we pivot to another approach. This also provides a log of 'this won't work because' which helps, if there's change in A, B or C as contingent to the decision, we can re-assess the decision for X.
I see you say you're storming/norming teams. You're still doing Freshman Orientation because each new PM and 6-month stint with a team involves storming/norming as the team settles down.
Many of the approaches, processes or tools don't realise all of their gains. A lot of the promise we'd be agile is just lipservice -- it takes discipline to have a max-15-minute daily stand-up that (i) has colleagues explain yesterday's progress; (ii) today's planned progress; and (iii) raises issues blocking progress at the current time for (iv) a meet-after session to solve them. Most attempts at agility fail, and those that are successful point at things like 'didn't do all the scrum ceremonies so you didn't demonstrate progress sprint after sprint or take on board feedback in a retrospective' ...
...but this is metafilter, so I'll talk about emotional labour. You're seeing teams form and settle down and you're probably doing a great job of storming/norming. It's effort getting the teams to trust each other and to know the peculiarities of how each other person tackles work so that you know how right or wrong will be their estimates for the complexity of a piece of work. It's effort to keep teams talking and effort to find ways to present their progress to the outside world.
posted by k3ninho at 5:52 AM on October 27, 2020 [4 favorites]
Publishing progress also remains a big problem. I've not cracked the problem of those estimates having unseen complications or simply being unable to predict the total workload to complete milestones in the readiness of a product. We usually have to do 'how far can you go in this time-frame (or with this amount of funding)?' and hope that the self-organising experts can optimise their work patterns to explore the problem space and use past experience and patterns to solve the problems quickly. I expect also that teams will be escalating issues when they block progress and stay on target to create the product they're supposed to be on.
The thing I'm looking for is a lightweight way to record information that supports the team's decision-making. If there was an easy log of 'decided in favour of X because of contingent information A, B, C' we could track the experiments that led us in the directions we took and why, then when backtracking is needed we've got threads to follow when we pivot to another approach. This also provides a log of 'this won't work because' which helps, if there's change in A, B or C as contingent to the decision, we can re-assess the decision for X.
I see you say you're storming/norming teams. You're still doing Freshman Orientation because each new PM and 6-month stint with a team involves storming/norming as the team settles down.
Many of the approaches, processes or tools don't realise all of their gains. A lot of the promise we'd be agile is just lipservice -- it takes discipline to have a max-15-minute daily stand-up that (i) has colleagues explain yesterday's progress; (ii) today's planned progress; and (iii) raises issues blocking progress at the current time for (iv) a meet-after session to solve them. Most attempts at agility fail, and those that are successful point at things like 'didn't do all the scrum ceremonies so you didn't demonstrate progress sprint after sprint or take on board feedback in a retrospective' ...
...but this is metafilter, so I'll talk about emotional labour. You're seeing teams form and settle down and you're probably doing a great job of storming/norming. It's effort getting the teams to trust each other and to know the peculiarities of how each other person tackles work so that you know how right or wrong will be their estimates for the complexity of a piece of work. It's effort to keep teams talking and effort to find ways to present their progress to the outside world.
posted by k3ninho at 5:52 AM on October 27, 2020 [4 favorites]
Response by poster: ...but this is metafilter, so I'll talk about emotional labour. You're seeing teams form and settle down and you're probably doing a great job of storming/norming.
Yes I guess by extension I was seeing if there was a way to define success in the storming/norming phase. If I was a doctor and I gave antibiotics I would know if the patient got better or stayed sick. If I'm going to other projects even at other companies how do I define success vs cargo cultism.
Less of an emotional labor component but I'm right now on an 8 week engagement and I'm starting to wonder if there's a better way to define success. Simply I'd like to have metrics on the short feedback loop I'm on and determining sprint velocity, bug count or developer productivity isn't helping. How would I objectively define success since the feedback loop is so short? Perhaps I'm an oddball in this kind of activity but this is why I was wondering what the average software development cycle was and it sounds like it is on a much longer timescale. I'll admit 8 weeks is a bit short, but my average is still 3-6 months.
posted by geoff. at 11:07 AM on October 27, 2020
Yes I guess by extension I was seeing if there was a way to define success in the storming/norming phase. If I was a doctor and I gave antibiotics I would know if the patient got better or stayed sick. If I'm going to other projects even at other companies how do I define success vs cargo cultism.
Less of an emotional labor component but I'm right now on an 8 week engagement and I'm starting to wonder if there's a better way to define success. Simply I'd like to have metrics on the short feedback loop I'm on and determining sprint velocity, bug count or developer productivity isn't helping. How would I objectively define success since the feedback loop is so short? Perhaps I'm an oddball in this kind of activity but this is why I was wondering what the average software development cycle was and it sounds like it is on a much longer timescale. I'll admit 8 weeks is a bit short, but my average is still 3-6 months.
posted by geoff. at 11:07 AM on October 27, 2020
« Older 4 panel classical paintings similar to Alphonse... | What happened to the man who was deliberately... Newer »
This thread is closed to new comments.
(Oops I didn't mean to drop this turd of a comment in here, I've been with too many teams that do egregious things like schedule standups at 8AM to make sure developers are in their seats at that time -- which is condescending at bet. In any case the pervasiveness of Slack or Teams wasn't around even several years ago and I'm wondering if that's fundamentally changed standups from a calendar meeting to an informal channel update.)
posted by geoff. at 10:19 PM on October 26, 2020