At the previous place I worked we had a particularly large project with detailed spec crossing multiple powerpoint presentations of UI design. We ended up pasting it on the wall at the end of the cubicles - about 60 pages or so. I don't think I should post it here on this blog, I have photos of it, but I am not sure if the previous company would come after me or not for posting company sensitive information. I am guessing not as it is out in production now, but who knows.

Anyway, the point of the story is that the spec pages didn't move nicely from left to right, they grew out. As people finished a page of spec they posted it to the out edge of the scrum wall, so as the project continued we ended up with a hole in the middle of the wall defined by the absence of spec pages. I thought it was a nice emergent behavior from making the spec a physical item in the project.

We had Agile Training the other day. All layers of the business are going through it. Engineering already does scrum each morning with cross functional groups, we have continuous integration, unit testing, functional testing, acceptance testing with a business representative before it goes to QA, etc. All those have been grass roots and because of developers wanting to ensure high quality products are delivered to QA.

We do Sprints, but what we do is not agile, it is waterfall with our use cases chopped up into sprints. It works ok, as we can keep a finger on the button as to where we are, but it is not agile. Essentially our system is not feature complete at the end of a sprint, it is at the end of the project (2 months dev cycle).

We have use cases as our product backlog, but they are not managed in an agile manner. The business hands them off to us at the start of the project and there is little resorting/re-ordering etc during the project. We tried using JIRA for our product backlog and chopping the use cases up into day long tasks. Surprisingly that did not work at all. Use cases were a more accepted level of granularity.

At a previous place I put all the requirement sheets up on a wall at the end of the cube farm and we moved them around when they were done from one part to another. The spec sheets had names in thick marker on them and were ticked with a green marker when complete. Despite the visual authority it gave, it wasn't that useful either.

Since the entire company is going to Agile Training there is a strong chance it will stick and the non-Agile parts of the production process will become more agile. It is an easy sell with Engineering, we have implemented and maintained the discipline on most of those processes already.

I saw this appear on Slashdot;

Furthermore, the ScrumMasters either cannot or do not separate their roles as Team Leads with those of ScrumMastery and -- worse -- seem to be completely unaware that this poor implementation of Agile development is harmful to our velocity.

At the previous place I was employed I was the Technical Lead and the Scrum Master. One did not impact the other, if anything they were mutually compatible. The team comprised of eleven developers in Phoenix and San Francisco and rarely did a scrum meeting go beyond seven minutes.They were fast and snappy. They were also long enough and gave enough feedback that it was obvious which parts of the project were badly scoped and which were being done on time with high quality.

A quick visual introduction to scrum and burn down charts.

Most software shops have some variation of these methodologies in place. It is rare that a surviving shop does not, as many of these mechanisms are the bare minimum of project and quality management. Once these become formalized they require discipline to adhere to exactly, whether crystal, scrum, SDLC, etc; and that usually requires coercion of process by the project manager which removes the self-organization aspects to a degree.

We have changed our methodology from stand-up meetings where we tick off lines of the spec, to the more formalized daily scrum meeting. We ask the questions:

What did you do in the last 24 hours?
What are you going to do in the next 24 hours?
Anything blocking you achieving that task?
Are you on target to achieve this weeks milestone? (*)

The stand-up meetings were mainly to tick off lines in the specification document. QA writes test cases directly from each line in the spec, so it becomes an easy empirical comparison to see where we are in the project as to how many pages of the spec can be retired as done and how many lines remain.

The difference was we did weekly meetings until the feature complete date neared and then we moved to the daily stand-up meetings. As we found who was being squeezed we would shuffle work around as necessary. It worked well in the last project.

With the daily scrum meeting we are adding more discipline in that approach, the downside is that there are more developers in this project so running through the verbal delivery of the questions takes longer (I type it out as it is being said and post to our internal wiki afterwards).

Already people are becoming bored with it, and trying to skip it by seeing me before the meeting with their tasks, or emailing their answers to the questions. Consequently I read with interest the article on skipping the daily scrum.

The Daily Scrum exists to enable self organization. It helps the team focus, communicate and identify impediments. The team members communicate to each other their progress, goals and impediments. The team members identify how they can help each other to reach the shared goal of the sprint.

We end up with a lot of unplanned work popping up each day. We are juggling a new product project alongside existing products that are in production. My day yesterday encompassed approximately 50% of unplanned work. Which is why the meeting needs to be a team one, rather than a series of IM's, emails and one on ones.

Ultimately the project is the teams and it is impossible for the team to self-organize to unexpected surprises, and hiccups unless the entire team is part of the process and absorbing the issues each developer faces in achieving the milestone.