JurgenAppelo's blog
This is my last post on AgileSoftwareDevelopment.com. I let Artem know that I need to concentrate on my own blog for a while. The success of my site is a welcome surprise for me, but it also means that it's demanding all of my attention.
On AgileSoftwareDevelopment.com I published 46 articles this year, including some timeless classics such as 10 Principles of Agile Project Time Management, The 12 Best Questions for Team Members, and Oh My God, They Fixed the Bug!. I also published my share of useless and controversial drivel, such as Professionalism = Knowledge First, Experience Last, and Specialization is Good. But I had fun writing it, and I'm glad that most of the people throwing bricks at me missed me.
Bookmark/Search this post with:
People often try to solve problems by introducing rules in an organization, in the form of "When situation X occurs again, you must do Y." I admit that I am sometimes guilty of such behavior myself, though I am convinced that it is not the best approach. It is better to leave rule selection to individual team members, and instead focus on imposing the proper constraints. Agile software development should be about setting constraints, not rules.
It has been discovered that the flocking of birds can easily be modeled on a computer. This behavior, which is also apparent in many other kinds of animals, emerges through the application of a few very simple constraints:
- Don't leave the group;
- Don't bump into each other;
- Fly in the same direction.
Specific implementations of these constraints are often used in the movie industry to create computer animated birds, bats, fish, penguins, you name it. (An example of such a model of flocking behavior is available here.)
Bookmark/Search this post with:
A number of weeks ago I asked readers to tell me what motivates them. The most original/inspiring contribution was awarded with $100 worth of software development books. Some of my colleagues acted as an independent jury, and Russell Ball, the author of the Caffeinated Coder blog, was selected as the winner, because of the great blog post he wrote on this subject. (And Russell's blatant attampts at unashamed begging did not even make a difference!)
In this post I want to share some highlights of the many emails that I got. The list below should serve as a reminder that your team members' motivation is often very personal, and as undefineable, unpredictable (and ridiculous) as their tastes in food, music, and (wo)men. On the other hand, the list can also serve as a sanity check for our own motivation. Software development is a great profession. If you look at this list, isn't it hard to be not motivated...?
The original question:
What is it that gets you motivated to do your job really well?
Bookmark/Search this post with:
When software development gods like Paul Graham tell you that people should not be managed, it makes you wonder what we need bosses for. However, after reading You Weren't Meant to Have a Boss I felt the terrible urge to justify my own position as a manager. (And if this post is not going to convince you, then at least it will make me feel better about myself.)
In his post Paul Graham compares employees to lions. He (rightfully) says that lions are not meant to be kept in zoos, and that lions in the wild seem to be "ten times more alive". (He probably meant "ten times more awake," a statement that, according to research, has some truth in it.) Similarly, Paul says, people are not meant to live in big companies. They seem to be "ten times more alive" as entrepreneurs in small startups.
Unfortunately, Paul's analogy is as far away removed from being accurate, as my mother is from being Yahoo's next CEO.
Bookmark/Search this post with:
In their book First, Break All the Rules: What the World's Greatest Managers Do Differently Marcus Buckingham and Curt Coffman present the twelve best questions you can ask your team members to determine how they feel about their jobs.
These questions are the result of one of the largest research efforts ever performed on the topic of people management.
In order to get a feel of your team’s motivation, you would do well to use these questions as the basis for an in-depth conversation. You might want to do this in a formal way, with an objective interviewer and a linear scale of ratings, so that you can carry out some statistical analysis after the interviews. Or you can just do this informally, by pasting the list onto the coffee machine. And whenever you “coincidentally” meet someone while getting a cup of coffee, you make sure to point at one of the questions on the list and have a little chat about it.
Bookmark/Search this post with:
In a previous blog post I wrote about the 1st Law of Software Development. This law deals with each manager’s concern to make sure that team members have the motivation to do their jobs well. But, for a job well done, their motivation alone is not enough! (I might be motivated to work in the middle of the night, but if I'm not allowed to, then what is my motivation good for?) In creative and productive organizations people require the power to do what is needed, so they can achieve the results their managers have asked for.
The 1st Law of Software Development = Motivate People
The 2nd Law of Software Development = Empower People
Bookmark/Search this post with:
In three earlier blog posts I talked about multi-functional teams, matrix management and maintenance. In my maintenance article I argued that maintenance work on an application should done by the developers who were responsible for building it. However, I also pointed out that this introduces some additional resource planning problems...
When software developers are responsible for multiple projects, you always end up with complications in resource planning. This is not just the case when you let developers perform maintenance on previous projects. Similar problems arise when they are required to do some other activities, like spending time on consultancy or estimations for projects that haven't yet been signed into contracts. Likewise, many developers need regular training, or they like to do some quality/infrastructure stuff for the organisation itself. Therefore, maintenance work on old projects is a challenge, but it's just one of many types of work that can take people's attention away from their current projects. This requires a professional approach to resource planning...
Bookmark/Search this post with:
In two earlier blog posts I described how we have organized the software development efforts in our company. I wrote about cross-functional teams and matrix management.
This time, I'd like to talk about software maintenance.
I have recognized two lines of thought regarding maintenance:
- Software maintenance should be separated from new software development. This means that, when a software development team considers a project finished, it is handed over to a maintenance team.
- There's no clear difference between software maintenance and software development. A team should perform both new development and maintenance.
Personally, I lean towards option 2. And these are my reasons:
Bookmark/Search this post with:
In How to Do Many Projects (Part 1) I explained that it is good to have multi-functional teams, where each team includes a project manager. Here is part 2, which is about the merits of matrix management...
Functional Managers
As in every other organization, in our company each employee has a (functional) manager. I prefer management to be arranged along functional lines. Therefore, a project manager has a manager who knows a lot about project management. A front-end developer has a manager who is herself fluent in CSS and HTML. And our software developers have development managers who are proficient at building code, delivering solutions and making nerdy jokes that no ordinary person understands.
I believe it is imperative that managers understand the work their employees do. There's little reason for software developers to work with a manager who cannot distinguish a bit from a byte. (I have blogged earlier about how to select a fine technical manager.) Similarly, project managers should be led by someone who understands agile principles, Scrum practices, and how to turn Notepad into a planning tool.
Important: a manager does not have to be better than the sum of his subordinates. It is only natural for his senior employees to exceed the manager's knowledge and expertise at some point, because management requires other (soft) skills, some of which the seniors might be lacking. However, the manager should be good enough to earn trust and respect, and to be able to coach and lead.
Bookmark/Search this post with:
Given the problem (most managers call it a 'challenge') of running many dozens of projects concurrently, with just a small number of people, I've been asked a few times how we organize projects and resources in our company. Well, there's a lot to tell about this subject, and my attention span (as a manager) is rather short. So I'll spread that information over several posts.
Many of our customers have simple, small requests: requirements that take just a couple of days or weeks to fulfill. This means that the organizational complexity (some employees call it 'chaos') is vastly different from other companies, where they have teams of many employees working on just one project, often for many months at a time. But I am sure that lots of people face similar problems (or challenges if you prefer) as we do, working on numerous small projects. So let me tell you what we did...
Bookmark/Search this post with:
RSS feed