Alexander Stetsenko

Recently I have come across this great old parable of stone cutters.

A man came across three stonecutters and asked them what they were doing. The first replied, “I am making a living.” The second kept on hammering while he said, “I am doing the best job of stonecutting in the entire county.” The third looked up with a visionary gleam in his eye and said, “I am building a cathedral.”

Although these three men were doing the same job, there were three different answers. I think this is a great example of motivation “in action”.

Tweet This

Popular in journalism, the Five Ws (also known as the Five Ws (and one H), or Six Ws) formula can be adopted in software project management.

• Who? Who was involved?
• What? What happened (what’s the story)?
• Where? Where did it take place?
• When? When did it take place?
• Why? Why did it happen?
• How? How did it happen?

Even short answer on each question above gives a good story on something happened. Especially if that took place unexpectedly. Documenting those answers could be very helpful to make a step forward and resolve the situation as well as better understand how to prevent similar issues in the future.

Speaking on preventing similar problems to occur. H. William Dettmer made a good point that manager’s value is assessed not by the importance of the tasks he\she is working on but whether he\she is solving the same issues multiple times.The quote is actually applicable to (software) engineers too who normally should resolve the problem for good instead of hiding it or inventing another ‘temporary fix’.

Tweet This

Intriguing Dave’s Pink talk on the surprising truth about what motivates us.

Tweet This

It seems like short and effective meetings are becoming a hot topic – check out this awesome presentation on the 22 minute meeting by Nicole Steinbok.

And here is a download link for the 22 minute meeting poster mentioned in the presentation.

Tweet This

People often say that motivation doesn’t last. Well, neither does bathing – that’s why we recommend it daily.

Zig Ziglar, motivation speaker.

Tweet This

In case you don’t know where to start with Scrum or just need a reference for further research, Geir Berset made a short, stripped down introduction.

1. Create and maintain a product backlog. This is a list of functional and non-functional requirements sorted by importance, and given estimates on a “best guess”-basis. These requirements should be understood by the customer (Product Owner).
2. Hold a monthly sprint planning meeting. Select the top requirements from the product backlog. The team break these requirements into actionable items (tasks), and carefully adds their estimates. A goal is constructed for the sprint that the team can commit to. Everything put into the sprint should be potentially ready for production before the sprint ends, remember? Tools to aid you adding the correct amount of requirements to the sprint is the calculated sprint velocity (how many man-hours you can put into the sprint) versus the task estimates. Sprint velocity, in turn, depends on the focus factor. More on these new terms later.
3. Do the sprint (with daily scrums). The team carries out the sprint during the coming month, and scrum masters (managers) are mere facilitators at this stage. The team self-organizes to make the real magic happen. Through daily scrums (short, informal team get-togethers) of only 5 to 15 minutes duration regardless of team size, the team stays synchronized and focused on the sprint tasks. Every team member answer only three questions; a) What did I do since our last daily scrum? b) What am I planning to do until the next daily scrum? c) What is stopping me to do what I plan to do?
4. Sprint review. AKA The Demo. The team explains the goal of the sprint, and shows off the requirements that has been turned in to finished functionality, potentially ready for production, in a demo. Anyone can turn up to this event, and the demo should be understandable by the customer. Feedback is gathered during and after the review.
5. Sprint retrospect. The goal is to learn something from the just finished sprint. The team discuss the following three questions : a) What went well? b) What can be improved? and c) What will we focus on improving in the next sprint? Suggestions for improvement can be turned into requirements and put into the product backlog, ensuring that the team commits to them during upcoming sprints.
6. Repeat every 30 days.

Obviously this list of activities is not enough for team and project success. But it is a good start to review each of these topics in more detail and ultimately get benefits from Scrum.

Tweet This

There are many books and articles have been written to answer this question. It is possible to find many interesting ways and techniques like prepare agenda, hand-outs, limit meeting time, meeting leader etc.
However recently I have discovered one more trick to make meetings short and effective. The best part of it is no requirements on either any special knowledge nor expensive equipment.

So the solution is very simple – conduct stand-up meetings!

Normally standing people want to sit after a short period of time. However it won’t be possible until meeting is done. As result there should not be any talks on unrelated topics because after a few minutes everyone wants to sit.
So attendees will speak on subject strictly as well as make decisions faster. Which means meeting is going to be short (topic related discussions only) and effective (decision is required to stop the meeting).
Additional ‘side effect’ is that teams could have such meetings more often without much loss of productive time.

The only disadvantage is that it might not be easy to make some attendees to stand…

Tweet This