Day 18 – The Hawthorne Effect

Its the penultimate day and whilst there is still a bit more QA to do before release we are pretty much there. Next up is an interim Sprint where we get to focus on some cleaning up and automation ready for the next sprint. The Sprint Goal will be to make changes that will allow us to go faster in the next release.

I’ve been pondering the psychological effects of Scrum. I think there is a bit more to it than efficiency improvements, people seem to actually work harder. Why is that? I was originally thinking about a placebo effect. Do people actually get better just because they are working a Scrum and Scrum is known to help us work better? I raised the question on the LeanAgileScrum yahoo group. There were some interesting responses and a couple of people suggested the Hawthorne Effect was a more palausable explanation. The Hawthorne effect is described as a short term performance improvement caused by a changing environment and being observed. Since Lean/Scrum is about constantly improving our environment and being observed in daily scrums and burn down charts I think this theory could have some legs. The beauty of scrum is this improvement doesn’t seem to be short term. Perhaps it creates a self perpetuating Hawthorne effect.

Day 15 – Release First

Scrum is all about doing those things early that you normally leave till last. This avoids any nasty surprises when you should be releasing. We have had lots of focus on testing and CI but one of the really frustrating release delays for an ISV can be the building the install pack. So like testing for the next release I’m going to do the install pack first. OK so we won’t have the final code but if we automate that should only be a click or 2 away. Apart from allowing us to release more quickly what advantages does this give us? Firstly all the problems building the current install pack are fresh in my mind. While we build the next pack people will be using the current one so problems will be fresh in the users mind.  What are the downsides? Well the requirements for the install pack might change but at least we will have a solid base.

Everybody on the team seems to be buying into the need to automate more and more tasks. It still surprises me how much people have changed. I’m used to sitting in meetings desperately trying to convince people that scrum has a way to deal with our problems but these days I need to do this less and less. People seem to be naturally thinking in Scrum Terms. Whats next?

Day 12 – Freedom through trust

A day of collaboration. As we come to the release, proud of what we have achieved, the atmosphere in the office is bubbling with enthusiasm. We have a sense of freedom that comes from a real trust between development and management. Feeling freedom in the workplace is a rare thing. I’m probably going overboard we still have someone telling us what to do we just decide how to do it and even how much we do and how long we spend on process improvement.

Before Scrum I was told the best way to develop was to assign features to single developers and let them get on with it. How could anything be more efficient?! Time and time it failed, projects overrun and software became bloated. It took some convincing that there was an alternative. I negotiated short sprints as proof of concept and with each sprint confidence and trust grew.

Giving the developers full control allows us to get on with doing what we love. Writing code? No. All we want to do is become better developers. (Why else would we spend all our spare time reading books and blogs?)  Luckily for the business we measure how good we are by the quality of the software we produce.

Day 11 – It feels good

After a tough day yesterday a great day today. Managed to sign off the performance testing. Had the servers idling with 200 concurrent users, lovely. Had lunch with the CEO and talked about taking the scrum onwards, he’s a good listener and feels as optimistic about the way things are going. Feels good!

Day 10 – Where are we?

As far as the sprint goes the burn-down is pretty flat. We are plagued by constant testing churn and the all too regular discovery of new problems. We are discovering more because we are testing more. I just wish we could have tested earlier. Oh well the next sprint is only ever days away.

As far as our scrum goes. How successful have we been? By Jeff Sutherland’s criteria in “The Scrum Papers” I think we have a “Team Scrum” with 2 releases in a year, and we really need to aim for a “Continuous Flow Scrum”. We definitely have involvement from the Product Management team (and most of the company) and we’ve started telling customers about doing 4 releases a year, we’ve just got to deliver! To achieve this we need to become more “Lean”. I think we need to focus on 3 things:

1. To test early and be defect free by the end of the sprint
2. To be able to go from sprint end to release in a week (currently taking around 6 weeks)
3. To ensure that only the functionality the customers really care about is included in release (I think this is currently our biggest waste)

From where we are today I think its a tall order but achievable. Wish us luck!

Craftsmanship

Over the weekend I read an article about craftsmanship written by Richard Sennett. He makes the point that true craftsmanship is about collaboration not competition and that modern teaching methods do not recognise this. In the days of guilds of master craftsman apprentices would spend years learning by osmosis. Perhaps the learning we experience in a Scrum is not that different to the way stone masons learnt their trade hundreds of years ago. After all many of the best developers do not have computer science degrees and learn through the huge swathes of information available on the Internet and from their peers. Could agile with its focus on high quality and design be turning  developers  into modern day craftsman?

Day 9 – ScumMaster Vs Team Leader

Being a ScrumMaster is an easier and far more effective job than a team leader. In the days before scrum we were all assigned long running tasks by the development manager. The team leaders role was to assist and review whilst also completing his own tasks. This worked fine at first but as deadlines loomed and the pressure increased the team leaders became less and less willing to be distracted from their tasks and the project suffered. People rarely spent time reducing waste to benefit the whole team through automating laborious tasks or re-factoring to simplify design as they were too busy with their own tasks. A year later we are still suffering the consequences.

As a ScrumMaster it is easier to prioritize the team. Spending time removing impediments is easier to justify as it benefits the whole team and the teams (not the individuals) ability to complete is the only thing being measured. With stories broken down into small tasks I should never be more than a few hours from completion, so stopping to help a fellow team member doesn’t become stressful and is generally a rewarding experience. This doesn’t just stop with the ScrumMaster, the whole team is eager to help each other as we all take shared responsibility.

The willingness to share knowledge has seemingly endless benefits. New members of the team (with the right skills) become effective almost immediately. Back in the day we would think ourselves lucky if they were productive in 6 months. We all learn faster. We have a better understanding of each others code. We spend less time going down blind alleys. Its worlds apart.

Day 8 – Talk it over

Spent the day tackling complexity and wondering how it all got there. We’ve gotta keep refactoring if we are going to get a grip on the product. My first solution to a nasty bug failed the code review. Talking it over the penny dropped and the bug was fixed with a change to a single method. It turned out to be a case of mistaken responsibility and a change of object was all that was needed. Why does talking about a problem, or for that matter writing about it, make it clearer? In this case my victim wasn’t technical and I think that helps, you need to take another step back and make things completely clear if they’re going to understand and that seems to inspire new solutions.