The luminaries who signed the original Manifesto for Agile Software Development in the 1990s have come back more recently, including Dave Thomas who said that "Agile is dead" in 2015, as part of his reflection on what went well, and what didn't go well, in the Agile Software movement they started.
As often happens, practices which had an intent, a purpose, a meaning, and an effectiveness, can lose that purpose, meaning, and effectiveness. As Dave Thomas laments, the Values get lost behind the Implementation, and Agile Software Development, shortened ludicrously to just "Agile", has become that which it mocked, and sought to replace.
That being said, I actually appreciate the core values that underpin the Agile manifesto, even while I advocate a skeptical approach to all methodologies. Don't drink the kool aid. Question. Gather data. Use Data and your ability to Reason. You can be a skeptic of ALL methodologies and also be a bit of a proficient practitioner of one of them, Agile or another.
In my current team, we're actually doing a really light set of "Fairly Agile" practices. I've been on this team nine months now, and I really like the way we work. The things we do are things that give us lots of positive payback.
Here they are:
1. Code Reviews
Shipping code is reviewed (hopefully actually read) by more than one developer. We use a distributed version control system (git) and pull requests to do our code reviews. We use bitbucket. In my previous job we used git with gitlab, which also worked great.
2. Light Daily Standups
Our daily standups are in Slack (text chat) 3 days a week, and are video two days a week. Our team is mostly remote and disbursed. The video standups are much longer than the usual standup time. But since the team is distributed, and there are relatively few other meetings, we are able to spend a lot of each work day building things.
3.Lightweight "Paperless" Audit Trails : Slack All The Things. Don't Email.
We don't ship changes to code that aren't tracked in an issue tracker. We don't make discussions verbally, or in emails. We default to public place accessible by all employees (slack chat) for all architecture and UI changes. Emails are private and are thus problematic for the team, or else turn into an unsearchable tar pit, and may as well have never been sent, as you can never find anything.
4. Pair up when you need it.
We have a practice of teaming up with another developer whenever that would help get us unstuck, or do something that one person alone couldn't do. We don't do that frequently, but we don't do it NEVER. We do it when it works.
I think these practices are great. I don't think we're doing everything perfectly. I think a certain amount of discontent is actually a core value for pragmatic/agile/high-quality software developer work. For example, I wish our codebase let us write more tests. That's something we probably can get to when our codebases are decoupled enough to permit unit testing.
What is your core "Agility" and/or "Pragmatic" practices list? What do you think makes your software team work effectively?
As often happens, practices which had an intent, a purpose, a meaning, and an effectiveness, can lose that purpose, meaning, and effectiveness. As Dave Thomas laments, the Values get lost behind the Implementation, and Agile Software Development, shortened ludicrously to just "Agile", has become that which it mocked, and sought to replace.
That being said, I actually appreciate the core values that underpin the Agile manifesto, even while I advocate a skeptical approach to all methodologies. Don't drink the kool aid. Question. Gather data. Use Data and your ability to Reason. You can be a skeptic of ALL methodologies and also be a bit of a proficient practitioner of one of them, Agile or another.
In my current team, we're actually doing a really light set of "Fairly Agile" practices. I've been on this team nine months now, and I really like the way we work. The things we do are things that give us lots of positive payback.
Here they are:
1. Code Reviews
Shipping code is reviewed (hopefully actually read) by more than one developer. We use a distributed version control system (git) and pull requests to do our code reviews. We use bitbucket. In my previous job we used git with gitlab, which also worked great.
2. Light Daily Standups
Our daily standups are in Slack (text chat) 3 days a week, and are video two days a week. Our team is mostly remote and disbursed. The video standups are much longer than the usual standup time. But since the team is distributed, and there are relatively few other meetings, we are able to spend a lot of each work day building things.
3.Lightweight "Paperless" Audit Trails : Slack All The Things. Don't Email.
We don't ship changes to code that aren't tracked in an issue tracker. We don't make discussions verbally, or in emails. We default to public place accessible by all employees (slack chat) for all architecture and UI changes. Emails are private and are thus problematic for the team, or else turn into an unsearchable tar pit, and may as well have never been sent, as you can never find anything.
4. Pair up when you need it.
We have a practice of teaming up with another developer whenever that would help get us unstuck, or do something that one person alone couldn't do. We don't do that frequently, but we don't do it NEVER. We do it when it works.
I think these practices are great. I don't think we're doing everything perfectly. I think a certain amount of discontent is actually a core value for pragmatic/agile/high-quality software developer work. For example, I wish our codebase let us write more tests. That's something we probably can get to when our codebases are decoupled enough to permit unit testing.
What is your core "Agility" and/or "Pragmatic" practices list? What do you think makes your software team work effectively?
No comments:
Post a Comment