Posts

Bonus for Productivity?

The Whole Idea Is A Little Insulting Scholtes' /The Leader's Handbook/ says that motivation through reward is insulting -- it assumes that you have been withholding effort all this time, waiting for someone to offer you an incentive to actually do your work. Hadn't really thought much about it before. But yes, it does assume you have effort on tap that you're not applying to your work. And yes, it is a little insulting. And yes, you could intentionally hold back until offered another bribe (but just enough not to be punished). Everyone wants a little more money, but P. Scholtes notes that it's out of alignment with the idea of humanitarian management who realize that the employees are their greatest asset. Not Only That, But It Doesn't Work Likewise, Daniel Pink reports that rewards for knowledge workers tend to have the opposite effect of that intended. It might not be a good idea for programmers and managers in non-manual-labor fields. Pink...

Too Many Developers?

Image
My friend and colleague Curtis Cooley recently blogged " You Might Have Too Many Developers ." Overall, I agree that smaller teams move more quickly and swarm more effectively on task than large ones seem to, and that there is definite overhead with large groups. You already know some developers are more effective than others.   What if you could find 1000 within the 2000 that collectively are twice as effective as the other 1000? Joel Spolsky has claimed the best programmers can be as much as 10 times more effective than the worst programmers. The argument continues describing how many developers are much better than others, and are better in a smaller group than they can be when they are encumbered by less competent programmers. I also agree that smaller teams of more expert programmers make sense on many levels and represent a savings in frustration, cost, and time.   As Red Adair would say : "If you think it's expensive to hire a professional ...

Individual Work Assignments: Neither Agile Nor Team

Image
I managed to set off a small avalanche of retweets, agreement, and absolute angst in the past few weeks, when something I'd said sometime last year appeared as a quote in a lovely frame (thank you so much Agile Fortune!). Here is the image for your enjoyment: It seems that maybe I've touched on something that people are thinking about, and possibly on a point of contention in many organizations.  Most traditional management has a focus on resource loading and utilization. What we are learning about people who do knowledge work (for instance, software development) is that utilization of resources is exactly the wrong idea.  Let's explore what I had in mind when I wrote the tweet: What is a Team, Anyway? For now, let's put the whole "agile" thing aside entirely. It doesn't matter if you're agile or not. I can pick that back up in a few paragraphs. For now, concentrate on the concept of a team. To team (the verb) is "come to...

Can Scrum Teams Have Managers.

"Is it safe to say PM has to acquire new skills to make himself fit in the scrum process? "  This question was asked in a scrum forum on Linked In, and many interesting and valuable answers were given. It is pasted here verbatim because I want my answers to this question to come home with me, and to be available to my clients, peers, and colleagues. The fear of "working without management" or "losing my management job" is pretty fierce in larger organizations, and I think it can be a misplaced or imaginary fear. This answer was specifically pointed to people in a Scrum-specific forum, but information here applies generally in any number of organizational change contexts. Even in our migration to Anzeneering , we have seen/felt the powers permission and support. On to my answers: Strictly, yes.  The biggest and most difficult difference is not telling individuals what to do. It's hard for the individuals at first too. It's easier, onc...

QCon London: Taking back development (Take Agile Back).

Ruud Wijnands and I just completed QCon London. I have a few new contacts, a few new stories, and we were able to present "Take Agile Back" -- a talk in three parts: Take Back Agile: "If this is agile, take it back." Take Back Agile: "Give me my agile back." Take Back Agile: "... to your team."  The point was not to shore up the defenses and protect the whole velocity/timebox/points/meetings nightmare, but to remind people that there were reasons that XP (and scrum) worked, and to return our thoughts to the experiments that resulted in a successful, productive, social process that got stuff done. There are underpinnings to consider. Safety (anzeneering) is one. It has to be safe to experiment in order to do things more intensely. We see people repeat some practices, but deny the right to modify the system via experiments and validated learning. This is a mistake. We need to find o ur own "two questions" and focus on nev...

On The Agile Manifesto

Everyone points to the four "preferences" part of the manifesto and ignores the more important first paragraph, and the far more important second page ("principles"). Key phrase: "We are uncovering better ways of developing software by doing it and helping others do it." That's different than "we are cementing our idea of software development process by teaching it and certifying others to teach it." It's different from "we are making people feel better." It's different from "we don't write documentation" or "we force velocity as high as possible" If we lose that key phrase, we lose it all.

Agile At Heart?

I feel safe to say that "being agile" is more than a mere state of mind, because an agile person or team has definite practices and tendencies that are not present in non-agile environments. I don't doubt that there is a change in values, but I argue that those changes will have practical, daily results that can be seen. Too many people hear/see "just a mindset" and think of the four tiny sentences in the front page of the manifesto (which skips over the first paragraph, which is by far the more important IMHO). To wit:  A team is working 80+ hours a week.   The design and architecture were carved in stone last year.   The members all "do their own work."   Each team member has 18 tasks "in process"   They're "debugging their way to release" without automation   The last five retros have ended with "oh, well. We'll try to do better, I guess."   They are all competing against each other for recognition/award...