Nothing slows a developer down than having to attend meetings constantly. It’s counter intuitive to, in the name of agility, demand that developers leave their desks behind to sit and pretend they can predict how much work it will be to complete a feature in a future, possibly very different, environment.
A great way to kill morning productivity is to force everyone to drop their keyboards and walk to a meeting room where everyone will stand in a circle and mumble what they did yesterday and what they will do today.
Here’s a shellscript that does the same thing:
#!/bin/sh
IFS=$'\n'
# Only track authors that have committed the past 6 months
AUTHORS=$(git log --format="%aN" --since "6 months" | sort -u)
for author in $AUTHORS; do
echo "$author"
git log --author="$author" \
--no-merges --decorate \
--oneline --all -1 \
--pretty=format:' %C(auto)%h%d %w(100,0,8)%s %C(bold green)(%ar)%Creset'
done
unset IFSThis will show the latest commit each author has made. If everyone has a habit of pushing their work to their own topic branches then this will accurately convey the same information as a stand-up meeting does, while easily letting you inspect commits if you need more in-depth information about what is currently being worked on.
So now we have optimized away the morning stand-up. Sweet! If your team needs to communicate more clear than this with each other then I’d suggest a irc/slack channel where everyone posts this information in the morning, without needing to leave their computers behind.
Kanban is pretty nice. It gives the whole team an overview of what is about to happen, what is happening and what has happened. At my first job, we handled this with post-its on a whiteboard. The medium itself is not too important for the board itself, but when you a year later bump into a bug or issue that feels familiar, sort of like you’ve been doing this before but you don’t remember, it would be nice to be able to read up on this sort of thing. Your first stop for this would be git log, but usually you don’t post comments in the git log with debug logs, discussions with other developers, the bug report in full, and so on. What you need is a system that is quick to work with, so there aren’t any roadblocks when you input information into it. Don’t worry about which sprint to assign it to, don’t worry which team to assign it to, or what iteration it should be, or any of those extra parameters that usually bog down these issues that makes a lot of developers throw their arms in the air and go fuck it, just put the bare minimum that our policy requires and spend time coding.
If your task management system requires your developers to spend time finding where to put the task, or how to categorize it, or anything that is not directly related to just writing about the task itself, then your system has failed. It’s flawed and must be thrown out as soon as possible, because the more resistance it brings to the actual work that needs to be done, the less information it will store. It doesn’t matter what your coach told you when you took your agile certification.
The absolute simplest issue tracker you could implement would be a raw text file checked into the same repository as your source code. Searching it is as simple as using grep, but if you want something with a bit more substance than that then I’d suggest tools like redmine or taiga.
These don’t seem to be worth their time. The idea behind sprints is that you plan ahead tasks to be performed within a set time, such as a week or two typically. To quote Atlassian:
Sprints help teams follow the agile principle of “delivering working software frequently,” as well as live the agile value of “responding to change over following a plan.”
This doesn’t cover responding to changes during a sprint though, and nothing stops you from releasing often if you don’t use sprints. Just branch out a release/x branch and release from there.
To support sprints, you must have planning meetings as often as you have sprints, where everyone will guesstimate how long tasks will take to finish. The scrum master will then populate the sprint with these guesses, which if they turn out to be incorrect means either spilling over into the next sprint, or picking things out of the backlog. In the end, it will play out exactly as a no-sprint, except that the fields in the issue tracker will be more populated.
Another thing that bogs down development time quite a bit. If you require code reviews, along with testing suites, to be performed before code can be committed to the master branch then you lose a lot of developer momentum. A possible optimization here is clear - scratch all those requirements. Each developer may use their own branches during development to simplify rebasing when other developers push their code, but when they’re done, simply push to master and close the branch. Inspect your fellow authors code whenever using git log, simplified by using --since:
git log master --since "1 day"This will display all commits on the master branch since yesterday. Using a program such as tig will simplify the process of thumbing through commits that have gotten in. The new code review strategy is now post-merge, any comments or fixes you may have on merged code is similarly committed to a feature branch and then put into master, which may or may not include informing the original author. You will have to rethink your concept of “code ownership” with this flow, because as soon as code hits the master branch, it is now everyone’s code, and everyone should be expected to be able to fix it. In the case that some code is Bobs code in a repository that you operate, you have a problem.
Enforced testing metrics never pan out. Avoid setting goals for these. Automated testing require a lot of maintenance and will never catch even half of the stuff that a seasoned tester will. You should strive to keep at least one tester per three developers in your team, but the more the better. They will continually test new commits, or hunt down bugs to report. They are vital to the projects success.
This is what you want though! Frequent in-team demos or with stakeholders are a great way to get feedback on the project, a great opportunity to ask questions and will act as short-term goals to get things cracking. Using the git methodology above, it’s simple to branch out things like a demo/10 for the 10th demo which would focus on bugfixing and stability, which would then get merged back on master. Demos should be the only thing that is planned regularly, perhaps once or twice a month. It shouldn’t be a whole/half day activity, it should only last as long as it takes to show what’s new since the last demo.
Demos should always be optional to attend for people outside the project and doesn’t have to involve everyone inside the project.
Since we love to slap labels on everything I’m calling this Ad-hoc Agile.
git logOnly do things that are needed when they are needed. You might think this ends up with planning problems down the road, though in my experience with planned projects, that kind of stuff happens anyway, and the idea of “Agile” was to free yourself from pre-planned conceptions and adapt new requirements and circumstances.