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.

Day 7 – Half way and still spiking

Ups and downs today. My install pack woes are still causing frustration. I fear my test server may have become possessed by some supernatural being. On an up note our superstar did a quick spike today to investigate if we could solve the problem of page caching with our home spun MVC architecture. Within an hour he had come up with a solution using cookies to store a pseudo query string. The code is shelved for now but it’s good to know we’ve get at least one option when we need to ramp up the products scalability.

Doing spikes so close to a release may seem strange, but it gives us the possibility of “pulling” in some scalability when we need it rather than “pushing” out some functionality that isn’t currently needed. Extra functionality adds extra complexity and excess complexity slows down our ability to respond to the real needs of the customer.

Day 6 – Ditch the Debugger

Like a fool I missed the obvious. Most of my day and some of the teams was spent trying to get to the bottom of a “Item not found in Dictionary” error on my install test site. During development I would have just attached a debugger and quickly discovered that the item wasn’t in the dictionary because I hadn’t got the latest database from source control this morning. We ended up on a wild goose chase involving thread synchronisation issues. Had we just raised a more useful error or added some trace information to our code we would have had it fixed in seconds.

So what was the root cause of this problem? Was it really my carelessness or was it our incomplete code that could have thrown a more meaningful error? Well I guess it was both but the danger of relying on debuggers is starting to become clear to me. You only have to add defensive code once and you won’t need to attach a debugger to solve the problem again (saving time in the long run).

If we say the code is incomplete we need to recognise that because the cost of this incompleteness is not immediate it is so much greater. These lessons just reinforce the principles of Scrum and Lean Software Development.

Day 5 – Ditch the Bug Log

The goal of this sprint is to cut a release. It contains a few features, Install Packs and some outstanding bugs. Its the bugs I fear most. Things are starting to get tense as we realise things aren’t as complete as they should be. People slip into old habits when the pressure gets up and there is even talk of “pulling the release”. We won’t pull the release but we might pull a few low value features.

It is too easy to underestimate the cost of the bugs. Bugs created during development distract us from creating new stuff. Bugs caught after the sprint require a soul destroying period of bug fixing before the release. Bugs caught by the customer at best require patches or at worst loose you the customer

TDD requires more coding but after all that’s what we are paid to do! Automated acceptance tests can also be interesting to code using tools like watir. They both give us a safety net that gives us courage to re-factor rather than bolt on new functionality. So why don’t we do it?

What about having no bug log at all? If we have nowhere to record bugs we have to fix them immediately. This should be disruptive enough to ensure something is done about the bugs but not as soul destroying as not being able to release a product due to a huge backlog of bugs. It might slow down development but if you wait till something is really complete (ie bug free) before moving on to the next thing you at least know where you are.

Day 4 – The Surgeon

From Perez on Medicine

Yesterdays burn down was more of a green run than black with a few hiccups but we are still on track. After yesterdays team love-fest I thought I’d tell you a bit more about our team and what I think makes it special. 6 months ago I left our company and went to a start-up. It turned out to be a nightmare and I returned to my old company with renewed enthusiasm. The day I restarted my replacement also started and I got him on my team! It turns out he is a far better developer than me, he has a huge depth of knowledge, amazing focus and a complete lack of ego. I think back in the days of the Mythical Man Month he would have made a great surgeon and in some ways he does work a bit like that. If there is a complex bit of design to do he will always get to work on it. But unlike the surgeon he is almost always pairing and we all get to learn from his great Wisdom! (Hope he’s not reading this) Hopefully pairing during the tough bits allows us all to develop at his level giving us the productivity of 5 surgeons. I think that explains why our man month is mythical but in a good way rather than a bad one.

Day 3 – Courage and Humility

Looks like I didn’t give the team enough credit. There were no issues about testing at this mornings Scrum . Everybody agreed and we knocked 60 points off the outstanding points. The burn down is starting to look like a black run.

It is generally accepted that agile requires great developers but it takes more than just technical skills. It takes courage and humility to admit you were wrong to your peers. It takes an open mind to constantly reappraise our assumptions and a complete lack of ego to accepts that what we did yesterday needs rethinking with the knowledge gained today. Once the whole team comes to terms with this everyone is free to make suggestions without fear of causing offence, knowledge is shared and the team feels alive.

Day 2 – Up the critical path

Yesterday went well with lots of progress however the team found allocating the tasks a bit tougher this morning. I only stepped in when the Product Owner uttered those dreaded words “He’s on the Critical Path”. How can this be? This is supposed to be Scrum. It seems we had all made an assumption that 2 of the overly long stories were going to be taken by one person and the 2 stories together would take the whole sprint to complete. Ouch! Can we break these stories down more? Apparently not, this is in a horribly complex area that would take too long to explain. What about pairing again? Yeah OK. As in a lot of other companies our managers get a bit nervous about extended pairing. Can two really go twice as fast as one? Courageously (!) we went for it and the 2 developers ended up getting the first story (21 points) coded by the end of the day and I’m guessing the quality and design will be twice as good as well. Pairing kicks the critical path into the history books.

Tomorrow we need to tackle testing this behemoth. The guys have done unit tests, one of them thinks its ready for QA, the other wants over a weeks testing. Hopefully we can work with our QA expert to work out how much testing we really need and ensure that it isn’t done twice by both devs and QA. This is a waste we need to tackle.