Agile PM/Development/QA

Daily Scrum is not for activity reporting

Sometimes on a new team, I've seen team members treat the daily Scrum as a place to account for their time and daily activity.  This is especially true for members who are on a team part time.  They end up going through all their activities for the prior day, instead of concentrating on reporting accomplishments and issues. They discuss what they did on the other team, issues with their hardware, etc.  While some of this information may be useful in the sense that it may take away time from what needs to be done in this sprint, it's usually sufficient to mention that some of the time was eaten up by unrelated tasks, rather than go through the whole list of justifying their job.

To some degree this may be the culture of the organization or the environment created by the team or the ScrumMaster.  People may feel the need to account for their time.  However, it doesn't add any value to the daily Scrum and uses up valuable time.

One of my favorite quotes is "Do not confuse activity with progress".  Don't discuss activity during the daily Scrum.  Report on progress (or lack of it) and any issues that may affect it.

Posted on Jul 22, 2011 by Gene Mitelman

How multi-tasking affects productivity

Ever wonder why some developers seem to be getting things done all the time, while others don't accomplish much?  Clearly, everyone has different degrees of knowledge and experience with certain technologies, industries, and subject areas.  However, some developers jump into a new area (technologically and/or subject-wise) and start producing usable code right away.  At the same time, some others, who have spent years using the same technology and working in the same company (or at least industry), take forever to get anything done.

While not the only reason, I believe that how focused a person is on their work makes a huge difference in their productivity.  And I'm not talking about ignoring your job duties, and instead spending hours browsing the Internet.  You can be actively working  8 hours a day, and still not produce anything useful.  What I am talking about is multi-tasking.

Say you have 5 deliverables due (let's assume each will take you 2 days to complete).  You can approach them in different ways.  Some people will start on several at the same time.  Others may start one, but as pressure is applied, start switching to others.  While they are technically making progress on each of the tasks, it may take about 10 days to see any results, since nothing is being completed.  Add to that the cost of context-switching, and it may be even longer.

On the other hand, some developers will stay sharply focused on one task at a time, regardless of outside pressures.  In that case, their first result will be available in 2 days, next in 2 more, etc.  That's a very big difference.  Kanban tries to force this approach by putting limits on work-in-process items.

Now, clearly priorities change in business and you can't ignore that.  However, people who are consistently productive strike a good balance between accommodating changing needs and working on one thing at a time.  One of my favorite phrases is "Do not confuse activity with progress".  If you stay focused on one task at a time and avoid the pressure to multi-task, this phrase will most likely not apply to you.

Posted on Sep 23, 2010 by Gene Mitelman

Do quick and clean go together?

Some of the arguments against agile development come from people who believe that quick/short releases lead to "dirty" code, creating maintenance problems in the future.  It is absolutely true that some agile teams incur a lot of technical debt by piling bad code on top of bad code in a rush to get features out.  Then 3 or 4 iterations into the project bad things start to happen and progress slows to a crawl.

However, this has nothing to do with agile development.  These kinds of teams would produce the same crappy code under any methodology.  The only difference is that they would be able to hide it for much longer.  When you don't have to produce value every few weeks, these problems may not show for a very long time.  Then once you do go live, all hell breaks loose and you have to go back to the drawing board having wasted a lot of money and time.

When this happens on an agile project, you may be able to hide bad design decisions (or no decisions at all) for a few iterations, but fairly quickly users and management will notice that the pace (or velocity in Scrum) has slowed, prompting a good project manager to start looking for a cause.

On the other hand, teams with experience and a level of professionalism will produce clean code under any methodology.  As a matter of fact, they will produce cleaner code on an agile project, because it will be hard for them to over-engineer the system under pressure to deliver results in smaller iterations.

Hopefully this short post starts to address the misconception that agile is just about writing code faster or finding hacks, instead of doing things right.  It's nothing of the sort.  Agile is about encouraging communication within and outside the team, providing frequent feedback, and doing just enough design to achieve good, clean results.

Posted on Aug 16, 2010 by Gene Mitelman

Agility in database design

Many DBAs wouldn't think that agility applies to them.  They feel that their job is to protect the database from developers at all costs.  But ultimately, the database is needed to support business needs.  So it follows that databases need to evolve just like applications that use them.

If you follow similar principles in database design as in agile development, your database will be able to evolve too.  Just keep design from becoming overly complex and trust that you'll be able to adjust it when the need arises.  Then when it does, it's usually possible to write scripts to migrate data from old design into the new one.

Posted on Jul 28, 2010 by Gene Mitelman