How To Motivate Your Team?
Bas de Baar asked this question in his blog Project Shrink and asked his readers to suggest their opinions. I have always thought that having motivated people is the key to the project success but I really haven’t got “a recipe” how to motivate a software team. In fact, I know a lot of things that you can do to undermine your team’s motivation and trust, a lot of classic mistakes you can do but I didn’t have a ready answer to that question so I had to think a little deeper but I finally came up with an answer.
Let you team members be creative!
The Most Important Rules of Delegation
I found recently an article by Richard Lannon entitled 12 Rules of Delegation. While the article is fine and it really gives some insights on how to delegate I think it fails to emphasize the most critical issues of delegating responsibility to the others.
I started thinking and looking for some more blog posts on delegation and I came to some conclusions which I would like to share here with you.
Delegation is a two-way street, says Richard Lannon. Yes, this is an important thing that we shouldn’t forget. And when we assign a task to someone and we hold them responsible for it we have to have in mind our reasons to delegate and their reasons to accept it.
What are the issues from our perspective? There are two major questions we must ask ourselves: Why to delegate? and What to delegate?
Filed Under Leadership, Links, Teamwork | 8 Comments
Rich Maltzman, Crowdsourcing, and Project Management
Rich Maltzman is a certified PMP and a project manager with huge professional experience. I didn’t know him until recently I found the Fiddler on the Project Wiki where he tries (together with Ranjit Biswas, PMP) to write a book based on the principles of crowdsourcing. While I didn’t know anything about crowdsourcing either, I started looking around and I found that generally crowdsourcing is a way to create something with the significant help from the crowd. Fiddler on the Project is an experiment in using crowdsourcing to create a book on project management with the help of a hundred participants. Intriguing, isn’t it?
Filed Under Links, Project Management, Teamwork | 3 Comments
The Two Types of Programmers
Jeff Atwood at Coding Horror wrote a post called The Two Types of Programmers, which gained a lot of controversial comments. Then he wrote another post trying to explain what he meant in the first one and to bring up the peace but the war has already started. I read them both. I read them many times and I still don’t understand what exactly he meant.
He says that there are two types of programmers - Type 0 (20%) are the people who program for fun. These people live programming, they breathe programming. They use Linux and they contribute to Open Source projects. In other words (although he doesn’t say it), these are the good guys, the smart guys. The other group are Type 1 (80%) - people who practice programming for living. They work from 9 to 5, they use only Microsoft technology and they don’t read the technical news. “They are not stupid”, he says but I believe it is just what he means because the final appeal is to the smart guys to swallow their pride and to hope the stupid guys become smarter.
If you feel that you belong to the Type 1 programmers, the stupid ones, don’t worry - one of the most important characteristics of the 20% group is that they read blogs, especially Jeff’s one. So you just need to read one article of his and you’ll automatically become a member of the elite group.
Sorry Jeff, I don’t buy it!
The Pros and Cons of Distributed Teams
I got this article recently, called 5 Reasons Distributed Teams Suck. This is an answer to another article that argues that distributed teams are great and gives us 5 reasons for that. The funny thing is that using the same arguments both authors come to different conclusions. For example:
Reason Number 5:
Pros: It saves energy. While you work at home you don’t waste time and effort for traveling.
Cons: It wastes energy. When you have to travel, you waste a lot more than if you worked in the same country and in the same office.
Where is the problem? Why these guys think so differently upon the same situation? My answer is very simple. The very definition of the “distributed team” they use is different.
When I ask myself the question “What does a distributed team mean?” I divide it into the following questions:
1. How distributed is the team? If the team works in the same town and they don’t work constantly in the office but instead they work at home I believe it really saves money and energy and this kind of distributed team works effectively because they don’t spend time traveling, they use their own computers and they only need a good internet connection to do their work (especially if the team doesn’t need any other special technical equipment). But if the team is disbursed through the globe then it might not be cost-effective at all. Especially if there are long time differences and there is a need to meet face-to-face frequently.
Filed Under Peopleware, Teamwork | Leave a Comment
Managing Padding in Time Estimates
Estimating time is one of the most difficult and most unsure activities during the planning phase of the project management process. We had a discussion recently with some colleagues of mine about the extra time that sometimes the developers or the project managers add to their estimates, called padding.
There are two extremes about this approach. On the one side is the management’s urge to shorten the project’s duration leading to unrealistically short schedules. Sometimes the developers (usually younger and inexperienced ones) get infected by the flowing optimism and make unrealistic estimates, which you know are impossible to meet. Then, when you make the final schedule you add some percentage of time (usually between 10% and 20%) to make sure that even after the management shortens your schedule you will still have the necessary time to complete the project on time.
Filed Under Project Management, Teamwork | 3 Comments
The role of the Business Analyst - poll results
I wrote a post in Bulgarian about the role of the business analyst in a software development team and I put a poll to survey how the people in the software development business in Bulgaria evaluate it. Now the poll is closed and I am giving you the results.
Question: How do you evaluate the role of the business analyst in your team?
Total votes: 27 (little but I still have few readers).
Answers:
- Very important role. The BA investigates the customer’s needs and represent them before the team - 14 votes (52%)
- All roles are equal. The BA is responsible for the functional (requirements) specification, which the developers implement - 6 votes (22%)
- We don’t need such a person. The developers do the client’s business analysis themselves - 4 votes (15%)
- What is a “business analyst”? - 3 votes (11%)
- He just hangs around here and looks silly. He cannot write a simple JavaScript - 0 votes (0%)
How to interpret the results? Obviously, the first thing that has to be noted is the small number of the votes. For me, the main reason is the fact that still very few people visit my blog and most of them weren’t impressed by the poll. I think I will open it again in the future when there will be more visitors to my blog.
Anyway, the good news is that despite the few voters, the results show that the position of the business analyst exists in the software teams nowadays and it is appreciated positively. No matter if considered as very important (answer #1) or considered equal to all the others (answer #2), the business analyst takes his/her well-deserved place in the software team (totally 20 votes for both answers, which gives around 74%)
Answer #5 is rude and represents the vulgar and arrogant attitude of some developers to the surrounding world that doesn’t write code. I am glad that nobody voted for it. It probably means that this attitude was already buried in the past.
Answer #4 is a little silly. How can you be a self-respecting developer and not know what a business analyst is? I put this answer on purpose with the intention to be chosen for fun and to make the poll more colorful. I believe that this was the intention of the three guys who voted for it. And if they really don’t know what this is - keep on reading here - there will be more posts devoted to the job of the BA.
The most interesting answer for me is answer #3. It has a double meaning. There are companies, on one hand, that work on small projects or such that work on products and don’t use project principles at all. In such companies, every developer, having been working long time on the same product and having been communicating with the field experts from the business area being automated, gradually begins to gain exactly that knowledge and experience, which make him or her a business analyst. And if you add the aspiration of the company for more exploitation of its employees we come to a natural merging of the role of the BA with the role of the software developer in one person.
However, there is another interpretation. The team (or the company) could consist only of “great programmers” - people who think they know, understand, and can do everything. It was the ideal of the past socialist society in Bulgaria - so called “multi-dimensionally developed persons” - people who believe that a developer should be skilled in every aspect of the software business and there is no need of a narrow specialization in particular areas like business analysis, project management, testing, user education, etc. The developer can do everything!
I really would like to know what were the reasons to vote for this answer. I hope some of the voters will post a comment about it. And if you have an opinion about the role of the business analyst in your team - please, share it with me. It will be useful.
Filed Under Business Analysis, Polls, Software Development, Teamwork | 2 Comments
Project Management 3.0
It seems it became a fashion these days to put version numbers to everything. When I saw Bas de Baar’s post with the title Project Management 3.0 I was first shocked. Wow, how could I miss the all those versions?
But in a while, after reading his post and the article he cites I started to realize that there is nothing new under the sun - it’s just a new, fashion name for the thing we already know.
Obviously, the version numbers 1.0 and 2.0 were created by the agilists. To put it roughly, PM 1.0 refers to the classic or heavy methodologies in project management. They focus on large projects, large budgets and big teams. Ugly Gantt charts, many stakeholders, horizon and beyond timelines and (note!) expected failure! PM2.0 respectively has only positive characteristics: small teams, made of smart and motivated people (does it mean that the large projects are performed by dumb people?), fast pace, feedback, responsiveness, etc.
It smells like a religious war from very far and isn’t worth mentioning. As Glen Alleman says in his blog Herding Cats, if you want to show the advantages of the agile methodologies you shouldn’t compare it to Waterfall because “Waterfall is dead, dead, dead“. The modern version of the “classic” PM approaches like PMBOK and Prince2 also embrace change and calling them “heavy” or “rusty” is not relevant anymore.
What caught Bas’s (and mine) attention is the idea of “Social Project Management”. As he states:
The Project Management style, and the supporting tools have to be “social”, and now more then ever. The project landscape is turning mobile, multi-cultural, 24×7, highly distributed and in ever flux.
But this situation will increase the risk of getting into some social “booby” traps and he points out the three most important ones:
- Communication trap: proper understanding of what the other stakeholders need in the project;
- Trust trap: letting go of control and hoping people still do what they are supposed to do;
- Isolation trap: no sense of belonging to the project through geographical, cultural and timezone differences.
This is the Project Management 3.0 and the real challenge for it will be a social one. According to Bas, this is the place were social software can help a lot. Not only in collaboration but more in building a sense of community, enhance trust and stimulate open communication.
You can read his entire post here.
Filed Under Project Management, Teamwork | Leave a Comment
-
-
Subscribe to this blog!
-
License
The content of this site is licensed under a Creative Commons Attribution- Noncommercial- No Derivative Works 2.5 Bulgaria License -
Admin
