Our Daily Stand-Up

In our continued attempts to provide the most value to our (internal) customers in the shortest time possible we are always looking at possible improvements to our process. Due to the limitations imposed upon us by the organization as a whole we do not run as a “pure” Agile team. We have borrowed some structure and process from Scrum.

Our processes are something that we do have some ability to change. In a mildly ironic turn of events as I was completing studies for my PSM 1 certification we realized the daily stand-up was not adding value equal to its cost.

The Scrum Master in me wanted to fix the stand-up. The stand-up is for the development team. The product owner can attend, but is not supposed to be a participating attendee. The self-directing development team uses this time as directed interaction. In the spirit of Agile it is a chance to openly inspect and adapt on a task level. Actual problem solving is acknowledged, but pushed off for after the stand-up.

There are a couple of reasons that we were not getting the value we needed from the stand-up. Our team has run with the business analysts’ (BA’s) doing double duty as proxy product owners. This is partly an organizational constraint and partly a practical concession. (Our internal “customer” is really multiple groups using our applications.) One of the BA’s is also our project manager. (Another organizational constraint.) It can be hard for the BA’s to keep the product owner part of their role quiet in the meeting. It is also hard to keep the PM part of the lead BA out of the meeting altogether.

Another reason is that our team is not cross-functional and self-directing in the traditional Agile sense. We hand user stories out to developers at the planning/kickoff meeting. Tasks are created for the stories at that time by the developer doing the work. We also have separate dev and qa teams. We run the 4 week to production iterations as 2 iterations of 2 weeks, one for dev and one for qa.

The team is co-located and communicates well during the iteration. What this has done is caused the stand-up to, over time, devolve into a status meting with asides about fixing problems. There has been a lot of resistance to attempts to force the resolution and problem solving discussions to wait until the end of the stand-up. There is no other meeting that allows for status to easily be communicated among the team.

It was time for the Agilist in me to take over for the Scrum Master. A large portion of the trouble we were having with the stand-ups was out of our control to change. On the surface the goals of the stand-up were not being met. What really happened was that the goals of the stand-up were met via other means and the stand-up had changed.

Our team used the stand-up as a chance to update project status and brainstorm issues. We realized this didn’t need to happen every day. Our big change was to move it to a M-W-F meeting. The true use of the stand-up was better realized for our team by making this change.

The moral of the story is that running with an Agile mindset can often mean breaking molds and models that are in place. The trick is to make sure you are working to better serve the customer with value. We didn’t change Scrum to hide the problems it showed when trying to become Agile. We changed Scrum because our organization hasn’t yet bought into Agile at that level. We are trying to model Agile, not Scrum. When we can successfully show how Agile mindsets and practices provide better results we may be able to get a pilot project in place using straight scrum and “pure” agile. Until then we do what we can to move forward in our Agile journey.

What concessions do you have to make to the organization as you try to be more Agile? How do you balance this tension?