In Theory and In Practice

We recently completed a small but interesting project at work. The team consisted of Tim Weeks, Lee Walton and I played a supporting role. We shared the lessons learned in an experience report at the Agile Practitioners group. The talk was filmed and can be seen below.

On this project, the developers tried a number of Agile and XP practices. BDD and Pair Programming were tried for the first time, in the video they explain what this was like.

In addition to the Agile aspects, the talk shows what Lean (kanban) principles we followed e.g. making decisions at the last responsible moment.

There is a large section on using code reviews and code metrics to help improve code quality.

I got off to a shaky start, but things seemed to improve as the video goes on.

Part 1:

  • Overview of the project
  • Developers discuss how they felt on the project
  • Discussion on pair programming for the first time
  • The importance of putting people first
  • NUMMI case study (GM and Toyota)
  • Start of project – beginning with the end in mind
  • Re-writing stories, to remove implementation details
  • Simplicity – the art of not doing work
  • Cost of defects
  • Concurrent development
  • Making decisions at the last responsible moment

Part 2:

  • Burn down charts
  • Cumulative flow diagram
  • Walking skeleton or tracer bullet
  • Lean thinking – limiting work in process
  • Pull System
  • Dealing with blocked stories
  • Code Reviews (brief discussion)
  • Relationship with PO – developers having access to users
  • Task switching – cost of task switching on projects

Continue reading

Advertisements

Agile20x20

The Agile Practitioners group recently held a pecha-kucha event at Zuhlke Engineering. The talks were great! The content was intriguing and the Pecha Kucha format added an extra edge to the presentations.

We learned a few lessons that will help improve the next Agile20x20 event.

Here are the talks

Christian Heldstab does a great job of presenting Getting Things Done

Abid Quereshi exlapins the core values of Scrum

Continue reading

Very High Level Language – So what?

When I first heard about Python I thought this is just great. I have had to listen to countless conversations about Java vs. C# and now we have to go through it all again with Python thrown in. I know Python is older than Java, but I only came across it after C++, Java etc. Python and Ruby are described as being Very High Level Languages (VHLL). When I heard that term for the first time I thought here comes another meaningless, yet ubiquitously used acronym. At first I did not pay much attention to these languages. I was very familiar with Java, C# and PHP. I figured Ruby and Python could not be too different from these languages. And sure, I may have been caught up in some Microsoft sales propaganda…

As with many developers, it was Rails that pushed me into learning Ruby. From the start, I really enjoyed Ruby – and still do. Dynamic scripting is a real eye-opener! Although I was enjoying this new dynamic paradigm, I still did not see much value in calling it a Very High Level Language.

This all changed at SPA. I attended “Agile Development for the Web and Elsewhere: A Tutorial in Python” presented by Nick Efford. In my opinion, this was the best session at SPA. Well organised and the content was spot on. It was a 6 hour session and Nick made many valuable points. He also explained the VHLL concept in great way. This was done with the use of this simple and effective slide.

Mental-model

This is when I had my first real VHLL a-ha! moment. Nick had placed Python and Ruby in a different class to Java and C#! I had realised that these languages were dynamically typed while Java and C# are (mostly) statically typed. I knew I was not comparing apples with apples, but I thought I was comparing apples with oranges. It turns out that I was comparing apples with apple pie.

When coding in C# you do not need to worry about the low level details that a C programmer needs to be concerned about. Similarly, when programming in Ruby you should not be concerned about the low level details that a C# programmer needs to worry about. Most of us are aware of the low level details a C programmer is faced with e.g. garbage collection. Now what low level details are there at the C#\java level? We can explore this with a simple example.

Continue reading