This article is about The Dev group in relation to other business units in the company. In this article, “the Dev group” is shorthand for whatever business unit the software development team is in (Technology, IT, …).
Many times in a company, the Dev group is seen not as a consumer of requirements and a provider of solutions, but as somehow subservient to other groups, like Marketing. The Dev group has to be very careful not to challenge their statements in meetings, and just accept that they know what they’re doing, no matter how little it’s based on actual customer feedback, or how SWAG the finance estimates are, or how much of their input is colored by personal bias. I’ve been taken off of meeting invites because I dared to challenge the statements about the Dev group and defending them from other business units. We even say things like “Let’s find out what The Business thinks of these features” as a short hand for “the other business units”. But phrasing it that way implies that the Dev group isn’t a separate but equal business unit.
I think a lot about process, process improvement, productivity, and efficiency vs effectiveness (believe it or not the difference is not universally understood). Lately I’ve been thinking a lot about team composition and how it affects the productivity of the team. In part I’ve been thinking about it because of the teams I’ve had in the past; in part because I’m currently hiring and having to make trade-offs like salary level vs skill level and overlapping skill sets, but also because I’ve been playing the game Overwatch a lot, where team composition essential.
MVP stands for (in this article) Minimum Viable Product. It’s not an Agile concept. It’s not even a software-specific concept, though it’s certainly easier to do with software, since upgrading software is usually easier than upgrading hardware. The concept is simple: Instead of building every feature under the sun into your product then releasing it, build the least you think people will buy and release that, following up with more feature-rich versions. There are several good reasons to do this.Continue reading
Performance evaluations and performance management are areas I disagree with many Agile coaches’ opinions on. “Popular opinion” is that you don’t evaluate individual team members at all. You only evaluate the team as a whole. They maintain that team members are self-motivated and will do their best to support their team. They also feel that evaluating individuals on the team could lead to stratification, and all team members should be treated equal and be at the same level. Team Leads have no place in Agile. When a team member is not performing, or is hindering the team, the team should have the power to remove that person.
Personally, I have never seen an Agile group where everyone was at the same skill level, let alone contributing to the group to the same extent. In fact, in most teams I’ve seen, different team members have a different level of commitment and focus on the team. And I’ve never seen a team that had the power to kick non-performers out on their own. What I propose is to evaluate individuals, but to emphasize team support and commitment in the evaluation.
Nothing in this world is completely black or white, good or bad. The human brain likes to categorize things. Put things in neat little buckets, so it can think of groups of things, and assume all things in that bucket have certain attributes. When that happens during a decision-making process, though, you’re throwing away information before assessing its value. As soon as you feel you’ve categorized it you let go of the information that went into that categorization. Incomplete information is the enemy of sound decision-making. Sometimes you need to make snap judgements when timing is of the essence, but even then it should be a first approximation, to be re-evaluated later.Continue reading
When someone, especially new software developers or those still in college, asks me whether they should learn Java or C#/.NET, my normal answer is something like “They both do about the same thing, but Java will run on almost anything, and almost all the development tools are free. With C#/.NET you could pay hundreds for Visual Studio, and the programs will only run under Windows.
Microsoft has a long history seeing open source as the enemy, but has never had a problem stealing ideas from it. They even use marketing jargon that is directly opposite of reality. My favorite case of this is Microsoft Windows Services for UNIX, which is actually UNIX-like utilities you install on a Windows computer to give it UNIX-like functionality, not something you add to a UNIX box to help it communicate with Windows. In the past Microsoft has even called Linux a cancer. These days they’re singing a different tune, one that goes “We love open source“. We know what the motivation is. In the real world, business computing environments are of mixed architectures and operating systems. Everything needs to interoperate. They’re not going to dominate the server world like they do the desktop. But you know what? I don’t even mind that they don’t mean it as long as they act like they do. And they are.
Microsoft is opening up major parts of the .NET codebase to open source. They’re doing so under the MIT license, not a GNU license, and that makes sense. They’ve made major contributions to Linux in the past decade. There’s also now a community edition of Visual Studio so you can use it for learning and some projects for free, which is long overdue for them.
I’m a Linux lover, not a Microsoft hater. Any steps they take in the right direction are OK by me!