Skip to main content

Standup

Recently I was asked if it makes sense to do standups. Is it just a formal waste of time? Wouldn't it be more useful to spend the same amount of time by actual work?

This is how our standup looks like, this is how the work would look like without it according to me and this is why I think it's worth doing standups:

Standup optionally starts with a half-minute long announcement by the Scrum Master if somebody is missing and when will be this person available again.
Without standup: We could check out this information from a well-prepared shared calendar but unexpected lates or illnesses which are missing from the calendar would require a little bit more communication and irrelevant discussion during the day. It would cause some delay for sure.

Then we look at the burn-down chart of the sprint and to the status of the latest nightly build. Is it stable, what about automated tests which were run last night? We make a common standpoint in one minute which is clear and acceptable for everyone. Are we good / are we late / do we have unexpected problems? If we can't come to the same opinion, optionally a new meeting can be scheduled after the standup, but it's quite exceptional. It happens when the test result is very bad or our progress is excellent and we tend to run out of tasks.
Without standup: we would look to the burndown chart and to the NB's result anyway during the day, but it's not sure that we would have a common understanding about it. One would think that the team is a little bit bellow the burndown guideline so it's OK, so he/she can spend more time on fine-tuning some insignificant little feaute but other would have some knowledge that the team will meet serious problems soon. There might be discussion about it during the day even in person or in team-chat but some people might miss it who are working on some task very deep. If there's too much discussion that's too much noise which prevents concentration to the real work.

Then a round happens when everybody tells what he/she did the day before and what will do on the current day. Others don't just listen and look out on the window but also think in themelves if they are affected by the current person's status update. Short, some second interruptions are permitted.

'What did you do yesterday?' It's just for making a context for today's plan but also gives some useful information. If the progress of the sprint isn't good enough we are usually more critical about this question. 'You couldn't do the anticipated progress. What was the problem, was it solved or do you need help?' It's important that's not about blaming.
Without standup: We'd eventually discuss what were we doing recently and if we have problems but more introvert people would tend to keep their problems inside for a longer time. This could cause quite some delay and loss of effectiveness.

'What do you do today?' We discuss this by looking at the task board. We make sure that everybody has some task, optionally who is blocked by what. Usually the outcome of this round, by some interruptions, that some people want to have some short discussion after the standup about how to continue the work, how to collaborate more effectively for the subsequent tasks.
Without standup: eventual discussions would happen during the day but as before, it'd cause too much noise and/or some people might miss important pieces of information.

At the end of the standup we set up a realistic goal for the day which everybody agrees with: 'We should close this story today.' 'We should finish this and that tasks for the story today.' This makes some motivation and makes some common standpoint again. This can be the base of the next day's standup but also It's very good when at the end of the day some well definiable part of the story is done.
Without standup: we could set up a goal during random discussions but it's quite not lifelike. It's much more likely that everybody would work with a regular, or little bit less, motivation and the story would proceed as it comes. Probably more half-baked and non-integrated parts would remain for the next day which isn't so lucky.

So, I think a standup, or any daily dedicated time-slot when everybody is listen responsibly and responsively, call it what you want, is quite useful and makes a team more effective and motivated.

Of course it's not straightforward that every team who does standups will become suddenly effective. There are some agile antipatterns which can make standups or using the whole agile methodology useless or meaningless, but it's another story.

Comments

Popular posts from this blog

Client's transaction aborted

I've met the above error message using a Wicket 1.2 / EJB3 intranet application under Glassfish v2 . Here is the more particular head of the stack trace: javax.ejb.TransactionRolledbackLocalException: Client's transaction aborted at com.sun.ejb.containers.BaseContainer.useClientTx(BaseContainer.java:3394) at com.sun.ejb.containers.BaseContainer.preInvokeTx(BaseContainer.java:3274) at com.sun.ejb.containers.BaseContainer.preInvoke(BaseContainer.java:1244) at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:195) at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:127) This exception raised on the integration server sometimes, randomly, for simple page fetch operations. After pressing reload on the browser, the operation was usually successful. I couldn't reproduce the failure on the local machine where I regularly restart the app server and

jxl.log

In an intranet production environment we have running a Glassfish v2 appserver with several J2EE applications which all use JexcelApi , a.k.a JXL, which is an open source library for accessing, generating or manipulating Microsoft Excel documents. We use version 2.6.3 of JXL because it's the recent one in the Maven repository which we use, however, at the official JXL site there are newer versions. Additionally we have log4j and Java Commons Logging (JCL), ignoring Glassfish's JSR-47 Java Util Logging (JUL) facility. Application #1 uses purely log4j and gets its log4j.xml config from a custom location. Application #2 runs Java Commons Logging with no explicite configuration file given, so JCL uses the default JUL facility of the appserver. Application #1 had been running for a long time without problems but when we installed #2 we realized that a jxl.log file had been created in the glassfish/domain/domain1/config directory and it's rapidly growing. As it happens, we

Brillien

There were three presentation as usual at the 14th Java User Meeting at Budapest yesterday, but this time I'll write only about the first one. Imre Fazekas had been invited from Debrecen to make a presentation about Brillien , their Java enterprise platform. It's an alternative way of modeling and implementing business logic in place of Java Enterprise (J2EE) Technology. It uses invasive programming model which means we have to extend classes from Brillien superclasses and we may use annotations. The whole system based on asynchronous XMPP communication and a set-context-flow concept. It's something like an application server, but uses a more logical and set-based approach. As the presenter said, it has very good speed and performance characteristics. Currently there are no IDE or other tools for editing models because this is a very young project, however a Maven plugin and a Maven archetype is accessible on the homepage. A very good introduction and tutorial can be also