People Trump Process
July 13, 2006
As I start to think about implementing Scrum or some other Agile process into our development world, I get scared of the reaction. Everything I’ve read and listened to on managing change in an organization says you have to pay attention to two groups of people, the top performers and the slackers.
Let’s start with the slackers because they are the least interesting. An agile process where you either contribute or get lost, will bubble up the slackers to the forefront right away. These people will have nothing to say at the daily stand-ups. They will consistently be stuck on the same mundane details, and will eventually feel so overwhelmed they will look elsewhere. While this is good, in a budget crunch where I can’t fill that req, the slackers work might be better then no work at all. I haven’t quite figured out if no developer is better then a developer who’s kind of in the way.
Now, how about the top performers. They are quite often the most invested in existing processes. They are quite often the ones most resistant to change. From my standpoint, I am going to get them involved in defining the new methodology and hopefully get them to become agilists along with me. It’s important to keep the top performers happy and engaged in what is going on with their day to day processes and activities.
Thoughts, my non-readers?
Agile Development at my Company? I dont know.
June 16, 2006
We're trying. Seriously we're trying. we do it under the radar and under the covers for the most part. We've even convinced the waterfallers that a phased beta approach is better. Let out features as they are ready. get early feedback and drive more requirements. Hmmm, what does that sound like? Don't tell anyone. It's working great so far. I just wish it didn't have to be done in this fashion. I wish someone would stand up and say "CHANGE NOW OR ELSE" and let us fall into the world of more releases and constant interaction with our customers.
Some of the challenges we face I'm sure are normal. Our customers don't want to uproot their infrastructure every two months for a new release. We've tried to seperate out the application bits from the infrastructure pieces as we could at least go agile on those bits. It still seems to not be the way anyone wants to go. How do we ramp up training in time? How do we get through Export control, and every other process we have to go through before we ship? They are right. The current org does not scale to this method.
Currently, I'm at a loss. I've ben mostly focused on the ideas I've heard about adopting agile methods on top of a waterfall process. Let the overall project stay waterfall, but do agile methods and release betas often to customers to drive a more interactive and fast-paced, innovative environment for my development staff.
We're just starting a lot of this now. More to come soon. Would love ideas!!
Tools to do my job for me…
April 25, 2006
Having difficulty in finding any good tools to use for Project Management on Linux. I have tried Planner in the SUSE Linux distro. I was recently shown a blog entry on Devshop http://www.devshop.com.
Any other tools out there worth my time and effort in trying them out?
Communicate or else!!!
April 25, 2006
I find that my main job here as Project Manager is to make engineers talk to each other. They don't like that whole talking thing… I've been doing this job for 2 years now and it never ceases to amaze me how little people talk. Even when the problem is clearly in someone else's code or a fix will clearly have an impact on another team, zero communication occurs, and you end up in a stalemate or finding out about it after the fact. We have a very distributed team all over the world, but often this problem occurs between offices in the same building.
We quickly realized as we were embarking on many new projects per quarter that we needed to sych up more often. We now force a quick meeting with the managers every morning. Throughout the day I am constantly adding relevant people to email threads and IM conversations. A simple question like "well, have you talk to so and so" always receives a shrug and a "I hadn't thought to do that."
The morning meeting works on a small scale but I clearly can't stop all developers from doing what they are doing every morning. So, how do I make people talk to one another. We tried an IRC experiment but no one seemed to want to log on. Viewed it as a distraction.
I'm pretty sure no one has found this blog yet, but if you do and you have ideas, I'm all ears.
Comunicate with me…
Corey Jackson
Project Manager