I was just thinking.
So many business people, or those who want to be in business, are keen on that awesome big, sparkly idea that will make their business successful and themselves wealthy.
You know more than you think you know, just as you know less than you want to know.
As I wrote last Friday, you just can’t know everything at the beginning of a project. A lot of times, you can’t even know things at the end either! That’s one way of looking at the whole “Agile” concept–simply realizing that your knowledge is limited and therefore letting go of a lot of things that you can’t control correctly anyway.
So what kind of manager works best with an Agile team?
If pair programming feels threatening at first, you’re normal. Two developers, one keyboard… yuck. If you’re like me, you want your own space, and you get a kind of rhythm going with mid-compile checking email and stuff. Taking that away during pair programming time sounds like it would be incredibly awkward.
What kind of organizations benefit from an agile approach to software development?
I was thinking of this around a year ago while working with a client who was thinking of reimplementing, for the first time, some important applications with .NET. One of the business-interface people started a planning meeting by stating:
Before we do anything else, we need to plan this whole project in detail. We need to know exactly how this is going to be done. Right now.
I don’t recall exactly how I responded out loud, but the monologue in my head went something like this:
Someone asked on LinkedIn the other day how to handle technical discussions in a Daily Scrum meeting that is ending early: do you use the free time, or defer the discussion for after the meeting?
To me, that’s an easy call. You do not have time for technical discussions in a Daily Scrum, the same way you do not have time to talk about last Sunday’s football game in traffic court. It’s not a matter of time, it’s a matter of focus and appropriateness.
This question just came up on Stack Overflow. It reflects a pretty common misunderstanding of how C-style strings are represented by char pointers in both C and C++.
Greatly condensed, it goes:
When taking on a new Project That Sucks, the most important thing for me to do first is to find out, in a big-picture sense, what has gone wrong. Why It Sucks comes before Making It Not Suck.
Sometimes it really is as simple as needing another bright software developer. Other times, the client can throw people at the problem but the problem is really structural: it’s set up to fail, and they should consider just dropping it. And still other times there’s a team or management dynamic that could use a push in the right direction.More