|
| |
| |
| |
|
Statistics |
| Unique Visitors: 0 |
| Total Unique Visitors: 40651 |
| Visitors Out: 653 |
| Total Visitors Out: 653 |
|
|
|
| |
|
|
| |
|
| Three Things Not To Do in Meetings |
| 2012-05-22 16:13:32 |
Nothing is more annoying than unproductive meetings. Some things irritate me in particular: people answering phone calls, people working on their laptops, and off-topic discussions. You would think it goes without saying that you don’t do these things in meetings. However, it doesn’t seem to be so natural. Hmm… Come to think of it, I might be guilty of the last one myself occasionally. 1. Don’t Answer the Phone Once in a while (like, once a year or something) you receive a phone call that cannot wait. This type of calls fall under one of three categories: planned, predicted or emergencies. You deal with planned and predicted phone calls by clearly stating that you expect a call you need to pick up - preferably also what it's about - and that you will step out of the meeting the...
|
| |
|
| Pomodoro Technique® and Scrum: Objective I |
| 2012-05-11 07:00:12 |
This is the first post in a series about applying the Pomodoro Technique® to Scrum and for development. Each post covers one of the Pomodoro Technique® objectives. The first objective is to find out how much effort an activity requires. I started using the Pomodoro Technique® a couple of weeks ago. At first simply trying to work focused for 25 minutes with 5 minute breaks. I didn’t do this all the time, though, as I didn’t feel my working environment allowed it. Today, I primarily use the Pomodoros when developing. When I get a chance, I will definitely apply it to other tasks as well, such as writing and studying. Development Pomodoros Other Articles in the SeriesFind out how much effort an activity requiresCut down on interruptionsEstimate the effort for activitiesMake the Pomodo...
|
| |
|
| Pomodoro Technique® and Scrum: Objective II |
| 2012-05-11 06:59:34 |
This is the second post in a series about applying the Pomodoro Technique® to Scrum and for development. Each post covers one of the Pomodoro Technique® objectives. The second objective is to cut down on interruptions. The Pomodoro Technique® talks about internal and external interruptions. I immediately noticed a change in how I dealt with internal interruptions. It is more difficult to decrease the number of external interruptions. I have, however, noticed a change here as well, which I will mention shortly. Other Articles in the SeriesFind out how much effort an activity requiresCut down on interruptionsEstimate the effort for activitiesMake the Pomodoro more effectiveSet up a timetableOther possible objectives In the previous post, I wrote about how I didn’t use the Pomodoro Tech...
|
| |
|
| Pomodoro Technique® and Scrum: Objective III |
| 2012-05-11 06:58:45 |
This is the third post in a series about applying the Pomodoro Technique® to Scrum and for development. Each post covers one of the Pomodoro Technique® objectives. The third objective is to Estimate the Effort for Activities. All developers are used to giving estimates. Most developers are also aware of the problems related to giving accurate estimates. Especially, providing an estimate in calendar time can prove difficult, not to say impossible. Pomodoros offer an alternative approach that works very well with Scrum. Other Articles in the SeriesFind out how much effort an activity requiresCut down on interruptionsEstimate the effort for activitiesMake the Pomodoro more effectiveSet up a timetableOther possible objectives When you start using the Pomodoro Technique® you become aware ...
|
| |
|
| Pomodoro Technique® and Scrum: Objective IV |
| 2012-05-11 06:57:23 |
Having started with the Pomodoro Technique® and seen how it can help you focus by cutting down on interruptions and improve estimations, it is now time to get the most out of each Pomodoro: Make the Pomodoro More Effective. A big part of making the Pomodoro more effective is to think about how you structure and apply Pomodoros. It can also involve introducing dedicated Pomodoros for specific subtasks, and splitting work into meaningful subtasks. Pomodoros and Software Development Other Articles in the SeriesFind out how much effort an activity requiresCut down on interruptionsEstimate the effort for activitiesMake the Pomodoro more effectiveSet up a timetableOther possible objectives Software development is a craftsmanship, and like a painter or sculptor you have to step back and inspe...
|
| |
|
| Pomodoro Technique® and Scrum: Objective V |
| 2012-05-11 06:45:58 |
This post is about the Pomodoro Technique® objective V: Set up a timetable. Instead of writing about how setting up a timetable and respecting work hours helps you keep a sustainable pace and uphold productivity (curiously enough a key XP practice as well :-)), I will focus on the similarities between objective V and a Scrum Sprint. I think it's striking how well the fifth Pomodoro objective correspond to the essence of iterative development and Sprints. In the Pomodoro book, Francesco Cirillo makes a couple of points. Other Articles in the SeriesFind out how much effort an activity requiresCut down on interruptionsEstimate the effort for activitiesMake the Pomodoro more effectiveSet up a timetableOther possible objectives A timetable measures the results of the day ... our goal is ...
|
| |
|
| Hidden Project Changes: Third Party APIs |
| 2012-05-08 15:24:21 |
This is the fourth post in a series about hidden project changes: things that affect scope but are easily overlooked. The topic for this post is third party APIs. You often have to rely on third parties to finish a project. Having a dependency on third party code is a big commitment though, and you should consider it carefully. If you have no choice but to use a certain API (perhaps it is a requirement by the customer or the only one available) reviewing it is especially important to provide accurate time estimates and properly analyze associated risks. Selecting an API Opting to form a dependency on a third party API is a big commitment. A good API increases productivity and speeds up development. A bad API, on the other hand, will potentially put you in a corner and slow development...
|
| |
|
| Two Criteria for Effective Meetings |
| 2012-04-24 06:55:25 |
So, you have planned the meeting. The purpose is clear. You distributed the agenda. You know the dos and don’ts of effective meetings. Then you're all set, right? I recently participated in a meeting that went so far off-track we needed a map and compass to get back to the office. This led to a discussion with the conclusion that we needed to have shorter, more focused meetings. It's a nice thought, but it won't happen unless the following two preconditions are met. Joint agreement. Unless everyone participating in a meeting agrees on the rules and guidelines and want brief and to the point meetings, even an experienced leader may find it difficult to stay on track. Assertive leadership. The chairman of the meeting needs to steer the meeting in the right direction, and have the manda...
|
| |
|
| Agile Roadblocks: Wrap-Up |
| 2012-04-21 14:09:46 |
In six posts, I have written about agile roadblocks: obstructions for implementing agile processes. The time has come to conclude the series with a summary and a couple of final words. The theme of the series has been issues you might be facing when migrating to agile development. Agile principles are easy to understand but can be difficult to master, and the transition to agile can be as complex as the problems it tries to solve. Stray Team Members deals with a malpractice far too common in my opinion. Resources are shared between projects, or moved around carelessly. This hurts productivity, both for teams and the individual. Drowned by Waterfalls explains the problem you face when asked to adopt an agile methodology even if parts of the organization don't, and are unaware of the imp...
|
| |
|
| Agile Roadblocks: Man Overboard! |
| 2012-04-21 13:06:56 |
In the series about agile roadblocks: obstructions for implementing agile processes, the time has come to “Man Overboard!”. (Also read the previous posts: stray team members, drowned by waterfalls and lost in translation.) Scrum teams are supposed to consist of highly motivated, cross-functional and self-organizing people. What if someone is not on board? How do you deal with people that are not motivated and don’t want to adopt agile processes and team practices? You might find yourself in situations where you are asked to use Scrum and have people on your team that are used to working alone, or using other methodologies, and simply don’t want to change. Description Other Articles in the SeriesStray Team MembersDrowned by WaterfallsLost in TranslationMan Overboard!Predicting the ...
|
| |
|
| |
 |
