Monday, December 20, 2010
One area of consideration is that of the self-organizing team. Indian culture supports team work. However, there is also respect for hierarchy, so the team may not feel empowered to make decisions. The team may feel the need to defer to a senior person for decisions. I have found that I am being asked to make more decisions compared to a US based team.
Indian culture also tends to avoid open confrontation. I think some conflict can be good as the team is developing. On my US-based teams, it isn't unusual for one developer to provide constructive criticism to another's work. This type of feedback should be delivered with a softer tongue for my off-shore team.
Another area that I have noticed relates to communications. Indian culture puts more emphasis on written communications. I know my off-shore teams have often asked for more formal requirements documents than what I expect from a US based team. One adjustment I've had to make is to provide more documentation for my off-shore team to work from.
Indian businesspeople tend to be tough, smart negotiators. While this conflicts the idea of customer collaboration over contract negotiation, successful negotiation is built on trust. However, building this trust can take time. In my case, I had time to start working on building that trust before the project work started up.
So what does this really mean? First, my points are just generalizations. For anyone working with other cultures, this type of understanding is just the starting point. You shouldn't rely solely on generalizations for determining how to work with your team any more than you would use New Yorkers as a benchmark for working with Americans from other parts of the US. For any cross-culture work, take the time to know the people you are working with.
Monday, December 13, 2010
Another interesting presentation was by Ali Zewail and ElMohanned Ahmed. They discussed the challenges of implementing agile in an Egyptian company from a cultural perspective. They even compared the principles of the Agile Manifesto to the cultural attributes of Egyptians. It made me think about my team in India and how agile aligns or conflicts with some of their cultural characteristics.
Wednesday, December 08, 2010
In the book, Pink sites why the "carrot and stick" approach to motivation doesn't work. You can read the book for the details, but in summary, this approach tends to drive the wrong behavior, only works in the short term, and kills creativity.
So what do you do to motivate people? There are three things people need to be intrinsically motivated; autonomy, mastery, and purpose. Autonomy is letting people decide how they accomplish their goals, or even what some of their goals are. Mastery is becoming an expert at what you do. Purpose is knowing that what you do has some higher purpose than just adding to the bottom line of a corporation.
One example that brings this home is the battle between Microsoft's Encarta and Wikipedia. Microsoft used money to motivate people to build their encyclopedia while Wikipedia was build by a bunch of volunteers. Encarta failed while Wikipedia is extremely successful. So if you have a team to motivate, money isn't the answer, nor is a autocratic leadership style. Providing them the tools they need to succeed, giving them the freedom to use those tools how they want, and providing a vision for what is needed are going to get you closer to your goal.
Wednesday, November 17, 2010
We talked about multi-tasking; one of my favorite topics. I often think of multi-tasking at the personal level. If I have one of my developers working on 2 different tasks at once, they are less efficient at both and loss time to context switching. Sanjeev pointed out the organizations multi-task as well, something I don't think about as often, but in hindsight, have observed frequently.
This situation occurs when organizations are trying to run to many projects at once. Teams are getting pulled back and forth; again resulting in all the projects coming in later than they could if a more focused approach was taken. Sanjeev often recommends to clients that they cut back on the number of active projects going at one time. It made me think of Kanban, but at an organizational level; you pick the most important project and get it completely done before starting the next.
The other part of effective delivery from Sanjeev's perspective is ensuring everyone knows the priority of the work at a task level. This is the project manager's job to drive this message. So instead of having a complex project plan with resources assigned to multiple tasks (with no priority), you provide each resource a prioritized task list and have them focus on the highest priority first. Just like having a prioritized product backlog.
So does everyone on your team understand the priorities? Do you find them working on tasks that may not be so important? At an organizational level, does everyone understand the priority of the projects?
Tuesday, November 09, 2010
One example given in the book is when school children are asked if they are artist. In first grade, everyone says yes, only a few say yes in third grade, and none by sixth grade. As the education process evolves, we teach our children to focus on left-brain thinking and the creative side is pushed out.
However, the need for good design is growing. I'm a fan of Apple products. I watched yesterday as a colleague opened a new iPod Touch. Even the packaging was well designed. Apple knows that enough people are willing to pay extra for good design to make them successful.
So how does design play into a project manager's life. Do you prepare a lot of PowerPoint presentations? Have you read one of the books on good PowerPoint design such as Presentation Zen or slide:ology? A well designed presentation will go farther in communicating your point than a poorly designed set of slides will.
There are other areas where design can play into your role as a PM. If you're delivering any kind of product, you should be thinking about design. Even if someone else is responsible for that aspect, you should still know what good design is. Even the way you're team's workspace is designed can impact their productivity.
Tuesday, November 02, 2010
Friday, October 15, 2010
Wednesday, October 13, 2010
- Jesse Fewell on Modern Agile Contracts. He had some new ideas on contracts and was able to make what could have been a dry topic interesting
- Michele Sliger's Goodbye Scope Creep, Hello Agile.
- Jeff Ottman and Dr Preston Smith on extending agile beyond software development.
- Richard Sheridan's The Keys to a Sustainable Work Pace
- Elizabeth Harrin on social media for project management
- Dr Thomas Juli on collaboration tools
Monday, October 11, 2010
Wednesday, September 22, 2010
Wednesday, September 01, 2010
Context switching between projects takes time and is a cost to the organization. The more projects involved and the more complex the projects, the higher the cost. By focusing on one thing at a time for a longer time period, individuals can work more efficiently.
Wednesday, August 25, 2010
- Problem solving - does the culture you are working in put more emphasis on facts or on logic/reasoning? Do they come at the problem from different angles or try to focus in on just one solution?
- Governance - how is power shared or controlled? Are people punctual or not? How do they approach risk?
- Relating - are tasks more important or relationships? Are individuals or groups more important? Are communications explicit or implicit?
Sunday, August 15, 2010
Wednesday, July 21, 2010
I came across an article on this topic on Harvard Business Review. One of the interesting recommendations of the article was to tell stories. As a former Navy guy, I have heard my share of sea stories. While entertaining, sea stories also had a lesson to teach. It was usually about how to avoid doing something stupid, exemplified by someone doing something stupid.
Friday, July 16, 2010
Monday, June 21, 2010
“Nothing in the world can take the place of persistence. Talent will not; nothing is more common than unsuccessful men with talent. Genius will not; unrewarded genius is almost a proverb. Education will not; the world is full of educated derelicts. Persistence and determination are omnipotent. The slogan ‘press on’ has solved and always will solve the problems of the human race.”~ Calvin Coolidge
Friday, June 18, 2010
Thursday, June 10, 2010
Friday, June 04, 2010
Friday, May 28, 2010
Transferring your passion to your job is far easier than finding a job that happens to match your passion.
Monday, May 17, 2010
My niece graduated from KU School of Journalism this past Saturday. The keynote speaker talked about 1988, the year most the students were born. I started thinking about how much journalism has changed since then. This was pre-web. Not many people even had home computers back then and newspapers had no idea what was coming as far as the changes in their industry. The professors must spend a lot of time updating their knowledge so they can send graduates out with the latest skills, but that won't be enough. The new graduates will have to continue to keep their skills updated if they want to remain competitive in the workforce.
Friday, May 07, 2010
So my first question was, why did it take so long? I can understand keeping the pressure on, but I think there's a difference between an aggressive date and an impossible one. In one case it will motivate you to work hard, in the other, it will only discourage you. Did this decision maker not have the information needed to make an effective decision? Were people afraid to provide the information?
Of course the throw more bodies option was used at one point prior to the delay. Anyone who has tried this knows that this approach doesn't really work. Nine women can't have a baby in a month and you can only divide up a project so much before you're spending more time on overhead then on development, not to mention the increased complexity of communications.
I've seen a number of huge projects that go down in flames and every time I see a new one starting I have to wonder why. In some cases it may be necessary, but in many cases a better option might be to break the big program down into more manageable chunks. This will reduce the overhead, communications challenges, and impact to the organization.
Thursday, May 06, 2010
This becomes important when you are trying to accurately track your progress. If a developer says they're done but they forgot something or it doesn't work right, there's still work to do. You may be nearing the end of your iteration and have a lot more work left than you think if you have a lot of tasks in the done stage but not really done-done.
So I don't even try to get % complete estimates I have found these to be notoriously inaccurate. I ask the developers to tell me either not started, in progress, done, and done-done. For those tasks in progress, I look for when they will be done. The tasks are all pretty small, around 8 hours of effort. That way, if I don't see at least some tasks getting done (and done-done) each day, I know I have a problem.
Agile is about being able to identify when you have problems as early as possible so you have more time to fix the problems. Having an accurate status plays a strong role in knowing the health of your project.
Tuesday, April 20, 2010
- Learn the rules
- Practice the rules
- Break the rules
This is also the idea to having an adaptive project management approach. First, learn the rules. Get your Scrum certification, read some books, or attend a conference. Apply what you learn on your projects. I've talked to a number of folks that say the way to implement Scrum is to first do it by the book (rule 2).
Once you get to know what you're doing, move on to rule 3. Every project is unique, so figure out how to break the rules for your project. Again, it doesn't mean drop everything. It means knowing how to improvise without throwing the whole structure away. Have you had your jazz today?
Tuesday, April 06, 2010
Thursday, April 01, 2010
One of the topics is passion. I recall when I was interviewing for the job I have now, one of the interview questions was "what are you passionate about?" Of course I said project management.
The idea here is that if you're passionate about something, you are going to work on it not because you're getting paid but because it's important to you, the end result is you become a linchpin.
So my question to you...are you passionate about what you are doing? If not, how can you find the passion?
Friday, March 26, 2010
This can apply whether your using agile or a more traditional approach to your projects. If you blindly follow a standard approach, you may be creating problems rather than solving them. We have to admit that we don't know the answer and be willing to learn as we progress through the project.
I've seen this with one of my clients. They were following agile and all the ceremony associated with it. They had their stand up meeting, iteration planning meeting, and even their retrospective, but I didn't see their approach evolve as the project progressed. The retrospective became a thing they had to do, because the methodology said so, but it wasn't helping them learn and adapt on the project.
So where do you draw the line? You don't want to throw the baby out with the bath water; abandoning the things that are working, but you have to be willing to adapt and fix the things that don't work. This is where you need to be a leader and help the team adapt while focusing on delivering the value your project was undertaking to deliver.
For example, if you are measuring progress through story points and you drop in the number of points you deliver from one iteration to the next, you need to figure out why and adapt so that next time you deliver more. So how are you helping your team evolve today?
Friday, March 19, 2010
I took a few days of vacation this week. We took a family trip to Chicago. I was almost able to completely forget about work and just enjoy myself. Now I'm back at work with a little more motivation.
There was an interesting article in the March issue of Wired. It talked about how distractions such as Twitter or Facebook can actually make us more productive at work, especially when doing creative tasks. These distractions help our mind break out of a single mode of thinking, especially when they involve activities that bring about some novel information.
When I use Twitter, it's usually to find what other people are reading or writing about, some new article about Agile or Kanban or Personal Branding. According to the article, by looking through this other material, I may unlock some idea in my mind to solve some problem that I'm currently working on. So next time you're stuck, pull out that article you've been meaning to read for the last 3 months, it may help get you through your impasse.
Friday, March 12, 2010
So I contrast this idea of going to the edge to the project I am on. We are automating a number of manual processes, but because we also have a tight delivery timeline, one of the project themes is "evolution, not revolution." In other words, we'll look for some simple improvements but we aren't trying to re-invent the organization.
One of the criticisms of this type of approach is that is stiffles that ability to think outside the box and come up with that idea that will really set you apart from the competition. So how do you decide if you should aim for evolution or revolution? The Kaizen approach would say make the small improvements, but what is your competition doing. Did Apple set out to build a slightly better MP3 player when it invented the iPod? Can you afford to make yourself just slightly better? What is your competition up to?
Thursday, March 04, 2010
Submit your own video in a Pecha Kucha format telling us your story. Perhaps it was a guerrilla project conducted quietly so as to deliver value without attracting too much attention, or maybe it was an organizational transformation. Whatever your experience, we want to hear from you, the community, about your experiences using Agile.Anyone can submit and vote on their favorite, you don't have to be a member of PMI or the Agile CoP. Most importantly, we will have cash prizes for the three best submissions!
Submissions can be made to the PMIAgile YouTube group.
- March 5th: Contest officially begins
- May 10th: Last day to submit videos
- May 17th: Last day to vote on videos
- 1st Place: $1000
- 2nd Place: $750
- 3rd Place: $500
Anyone is eligible to submit and vote on videos
Submitted videos should be in formatted as pecha kucha presentations. This is a power point (or similar presentation capability) showing 20 slides that auto-advance every 20 seconds, for a video that is 6:40 in length. Videos that deviate from this format significantly, while impressing us with their creativity, will not be considered for the competition.
Wednesday, February 24, 2010
I just finished the book Drive, by Daniel Pink. The book focuses on motivation. In the book, the author talks about other companies that do something similar. At Google, people get to spend 20% of their time on projects they want to. Many of these have made it to products. Atlasian software has "FedEx Day" where people are given 24 hours to come up with something, so called because people must deliver overnight (Side note - Atlasian's Jira tool came out as one of the top agile tools in VersionOne's 2009 State of Agile Development survey).
People get intrinsic motivation through autonomy, mastery, and purpose according to Daniel Pink. Autonomy is getting to choose what, when, and with whom they work with. In our science fair, people get to work on teams if they chose. Mastery is getting good at what you do, through such things as "Goldilocks tasks" that are hard enough to challenge but not so hard as to seem impossible. The purpose is why the company exists, something that everyone should relate to.
These intrinsic motivators will drive people and organizations much more effectively than the old carrot and stick approach, which we're all used to...if I hit my utilization target, I get a bonus. The carrot and stick can backfire in a number of ways, including stifling creativity. Things like FedEx Days or Science fair, on the other hand, will bring out creativity in a group of knowledge workers, leading to new products or services. So what's your organization doing to promote creativity?
Wednesday, February 17, 2010
One reason for this has to do with communications. The more people you have on a project, the more communications channels you have. Two people, one channel...10 people, 45 channels. Agile works because you keep the teams small and keep everyone in the same room (ideally), minimizing the amount of communications you need.
Joel Spolsky recently wrote an article in Inc on this topic. He mentions the team responsible for the main menu for Vista at Microsoft, 43 people in all, or 903 communcations channels. In a year, only 200 lines of code were written because so much time was spent coordinating.
So what do you do? Think more about your communications. Don't invite people to meetings who don't need to be there. Don't send email to large distribution lists. Take a little more time planning your communications instead of blasting it out to people just to keep them in the loop.
Sunday, February 14, 2010
I had a requirements document sent to me this week to review. It was a piece of art! The document was about 100 pages long. It was prepared about 3 years ago and has sat on a shelf until now. Now it's time to start planning the project.
The first step was to ignore most of the document. My approach to move forward will be to look at the high-level business process and come up with a rough estimate on how big the project is. Then my team will engage the process owners to start drilling down into the requirements as we start building the process. We'll have regular reviews, and probably in 2-3 months, we'll have the process ready to deploy.
I think of how much waste went into this document. First, there was the time to try to document everything. In all likelyhood, a lot of what was documented doesn't really need to be in the final system. Then the document sat and gathered dust. Any Lean advocate will tell you to avoid work in progress. Regardless of how the requirements were being captured, it shouldn't have been done until everyone was ready to start on the project. Finally, there was my time trying to read/understand the requirements. As typical, it was written standard requirements-speak "the system shall provide the capability to..." and then followed by use cases that provided the same information in a more confusing manner. I could probably summarize the whole thing in a dozen user stories.
I'd like to start a reality show like "What not to Wear" expect about project management. Each week it would look at a different project and help get the project moving in the right direction. I'll have to think of a good name.
Wednesday, February 03, 2010
The problem with the buffers can happen in agile or waterfall projects. I can remember the old days of project management...I would be working on the schedule. I'd go to the various team members and ask them how long their tasks would take. They would add in a "fudge factor" to account for any uncertainty. Then when it came time to do the work, they would procrastinate on starting, knowing this buffer was there. However, when they did start (later than they should have), they would come across the uncertainty and now their buffer was gone and the project got behind schedule. This phenomenon was referred to by Eliyahu Goldratt as Student Syndrome.
The trick of course is not to put the buffer into each estimate in the first place. In my client's case, what has happened over the last couple interations is that all of a sudden at the end of the iteration, everyone gets their work done, doesn't need the extra buffer, and the burndown takes a sharp nosedive. The only real issue is that the PM taking unnecessary steps during the iteration to try to fix a problem that doesn't exist (and try to explain what is happening to management).
Friday, January 22, 2010
But how often do you do a personal retrospective? Are you reviewing your performance to see how you can do better in your role, whether you're the project manager, product owner, or a team member?
My company does quarterly reviews to see how we are tracking against the goals we set out at the start of the year, but even that isn't often enough. It's hard to remember what I did 3 months ago.
My solution is to sit down once a week or so and take time to journal. I use this as a way to reflect over what I've been working on and identify things that I could be doing better. It's an effective technique; I set some goals in writing and then review those goals on a regular basis. I can see if I am making progress or if I need to set a new direction. I've been doing this for a few years now, so I can look back at old journals to see if I'm facing the same challenges I've had in the past.
Give it a try. The only things you need are a notebook and a pen. I like to get away from my computer when I do this, but you may choose to use your computer instead. Make sure you can avoid distractions...turn off the phone and the IM. Take a few minutes to relax and take some deep breaths and then write whatever comes to mind. Sometimes my thoughts seem random but they usually lead somewhere.
Friday, January 15, 2010
One idea that was brought up had to do with measuring value. The technique involves assigning value points to each feature or user story by the product owner. For example, the most important feature may get 10 points, some minor feature only gets one point.
As features are delivered, you track the points to show how much value is being delivered. So if you look at the graph below, you see for the first few iterations, the value goes up pretty quick but then it levels off. Since you're not delivering much value by the fourth or fifth iteration, you should consider ending the project and moving on to another project that would be adding higher value.
Wednesday, January 06, 2010
The quote that stuck with me was this;
You will be judged on voice, not just your resumeWhen I was interviewing for jobs back in 2008, the company that hired me told me they looked at my on-line brand. I had gone through a series of interviews, included a day at the company. It was after they went and read my blog that they decided to make me an offer. This trend will continue to grow. How is your on-line brand?
Most people judge others by their resume. A resume is an account of what you’ve accomplished in the past and an attempt to show a prospective customer what you’re capable of in the future. Sorry to say that a resume won’t be powerful enough to build your brand in 2010. In addition to all that work experience and all of that credibility you’ve built up, your online conversations will be just as valuable. If you don’t blog or comment on blogs or at least update your status on social networks, then you won’t be perceived as a valuable contributor. Your opinions and thoughts is what people will want to hear in 2010 and beyond, not just previous projects that get outdated really fast.
One topic I’ve touched on when doing public speaking is personal branding. Back when I got my PMP certification, that was something that made me stand out. Now, it’s expected that any project manager will have that. What are you doing to make yourself stand above the crowd? Have you thought about other certifications such as ITIL or Six Sigma or Scrum Master? Having said that, don't chase after other certifications just to add letters to your name, go after those things you are passionate about. In my case, I've always been involved in process improvement, so Six Sigma made sense to me. However, I look at the new Scheduling Certification from PMI and have no interest in that. As an agile guy, the thought of building complex schedules is not something I care about.
So for this year, set a couple branding goals for yourself. Start a blog, get tweeting, write some articles for other blogs...something to show your passion for what you do.
Monday, January 04, 2010
Often people spend this time of year setting goals for what they want to accomplish…exercise more, lose weight etc. What don’t you want to do this year? Are you ready to throw that away?
Saturday, January 02, 2010
The focus of the book is on how to take something you like to do and make money at it. For example, one story in the book is about an artist that was able to find a niche market painting wineries and then selling them at the winery. The example was meant to show how even in a field that in general is hard to make money, this person was able to find a unique market.
A large part of the book focused on the on-line world. Topics like becoming a better blogger, using tools like Twitter or LinkedIn. The book has some very specific suggestions and places to go for help. Even if you aren't looking to start a new career, this book can help you improve your presence on line. I would recommend it to anyone looking for some ideas on increasing their personal brand awareness.