Category: daily

Micromanagement in Scrum. Day to day control

February 11, 2008 by Artem Marchenko

There are quite many people to whom agile processes look like a lot of micromanagement: developers have to report on their actions every single day, management picks its nose to every feature, wants the team to report with demos every two-four weeks and has problems allowing to spend a couple of months on thinking through and building a good architecture. Sounds like micromanagement, doesn't it?

Micromanagement devils

7 Tips for Improving the Daily Scrum

February 8, 2008 by Artem Marchenko

Daily Scrum also known as daily standup meeting is an important element of the Scrum process. The structure of the meeting is quite rigid and fixed. Everybody has to stand up, meeting should take no longer, than 15 minutes and everybody should answer three questions: "What did you do since the last meeting?", "What are you going to do until the next meeting?", "What impedes you from being more productive?". The purpose of this rigidness is for making sure that daily Scrum is to help team members synchronize between themselves, not to solve problems.

Things to watch during the daily standups are:

Daily Scrum - the feeling of synchronization

November 9, 2007 by Artem Marchenko

How does a large project get to be one year late? - One day at a time!
(c) Frederick Brooks

Every software development is not like hardware manufacturing or building identical houses.
Every software development  project aims at creating a new artifact - something never previously developed by anybody else. Similarities with other projects can exist, however, a number of unique challenges is always significant. As a result unpredictable problems with many possible solutions arise regularly during the course of software development and many meetings can be held in order to choose or form the most suitable solution.

Distributed Agile Development - 2: Managing daily Scrums.

October 5, 2007 by Vaibhav

This is part 2 of an indefinite series of posts centered on using agile techniques in distributed development scenarios. (See also Part 1 on Reinterpreting th Manifesto)

At work, most of our projects have daily Scrums. For some of our projects this simple activity becomes much more laborious because part of the team is in a different time zone. In this post I will write about some key guidelines that we follow to make sure that Scrums remain productive and interesting. Without further ado, here we go: