31 October 2007

Developing a Culture For Learning

by mo

So yesterday at work we completed our sprint retrospective for the previous sprint, and as I was reading through the list I thought that this was pretty amazing stuff. So I thought I would share some of what we discussed. First off here’s the unfiltered lists from our white board (sorry no images):

Things to keep doing:

  • Pairing on problems that are complex.
  • More testing = more confidence
  • sharing knowledge
  • retrospective.

Things to change or remove:

  • On certain tasks use pairing
  • Dedicate time to acceptance testing
  • Need product owner here & communication to users we are building it for.
  • using Crystal or not.
  • listen to community
  • sprint plan changes.
  • trying to do before approval.
  • disruptions on task at hand
  • get better at estimating
  • flexible for meetings. (they push our sprint timelines.)

Our list for things to keep doing was short, but the discussion was quite “tall”. I felt like we all felt like we had accomplished a lot and felt that we were making some drastic improvements in our development.
The discussion on pairing came up, and I suggested that I really enjoyed pairing with some of the other guys and that it had helped me immensely with dealing with limitations with Crystal reports. It was my first time using it, so i really wanted to get into the guts of it to understand how it all comes together. I found that by pairing we were able to fire off new ideas, on “workarounds” to get what we wanted from Crystal. Who thought that building a table of contents without using a database, data sets, or data tables could be so hard!

More testing equals more confidence.

I totally back this statement up! I really feel that getting in to a test first mind set has definitely helped me ramp up my skills as a developer. It’s helped me to understand .NET in general at a much faster rate then I think I would have without it. I’m more confident about the code that I write, and I feel like I’m getting closer and closer to understanding and recognizing “separation of concerns”.

Sharing knowledge, isn’t that what teams are all about.

It’s difficult for us as individuals to go spike the world and learn about every single topic, but it’s more achievable when you do it as a team. I find that when learning a new topic, there’s always some friction when getting going. Like where do i get good info? where do i start? where do i get what i need? By distributing the “friction” you can ramp up faster and focus on what’s important.


I’ve really enjoyed our sprint retrospectives, it’s become a time for us as a group to reflect on small milestones and to help identify things that helped us and hindered us in our work. I always seem to learn something new or in the back of my mind say … “He’s so right, I didn’t notice that.” It’s a great way to expose blind spots “quickly”. Our list of things to remove or change is a little bigger, in our last sprint I think we recognized more things that hindered us from delivering more value to our customer(s). If it were up to me, I would like to pair more! I really think it’s a great way to cross train, and learn more of a code base. You lose that feeling of “that’s mO’s code”. None of it is my code, in the end it all belongs to either my employer or the client. (Intellectual Property) It also helps with getting longer more focused sessions of development. In an 8 hour work day, I would love to say that I spend 4 hours pairing with another, 2 hours working on things on my own, and 2 hours for personal development.


Right now we’re having some difficulties with our client. We’re trying to get rid of the “surprise”, by that I’m referring to when they see features in demo that they didn’t expect, or things that were missing that they did expect. I think we were thinking talking about testing, we were talking about getting more feedback, earlier! Sometimes it seems like the client has an expectation of how a piece of functionality should work, but that thought isn’t captured properly.
We would love to have more access to our clients, especially a product owner. By trying to get more involvement from the PO, we believe we’ll have less surprises, and will deliver more value. Value that can be defined daily if possible!

Crystal reports is a terrible product.

We need to spike some alternatives to enable us to build reports how we want to. A tool should allow us to use it in a way we want it too work, not demand expectations of us before we can use it. For example, if I call a method such as “GetLastPageNumber()” I expect it to give me the correct value, not throw an exception when it’s a sub report and sometimes work when it’s a parent report. I would also like more options then data sets and data tables, like custom collections.

Listen to the community

This was a point made in regards to Crystal. On the advice of friends, and several posts out on the net. We found a consensus that Crystal Reports was a deprecated product, not worthy of current industry demands. Some alternatives that were suggested were “Active Reports.NET” and “Reporting Services”.

Sprint plan changes

Referred to major changes in priority during the sprint. We’ve all heard that “Change Is The Only Constant” especially in software development, but if we can reduce the chances of major changes by getting feed back early, it would help to keep our dev’s focused and better able to deliver value. Faster!

We need to slow down sometimes

It sucks but it’s true. Sometimes we itch at the opportunity to jump in, when really it would save us all a lot of hurt if we just waited for client feedback before getting started. I’m not sure how to best deal with this, but sometimes the wait just sucks, so if we can use down time to learning and improving might be more productive!

Disruptions are disruptive

In code complete, Steve McConnell eluded to disruptions being equivalent to juggling, while holding something in the air. I don’t remember the exact line, but I remember reading it and thinking “This is so true.” I equate to being like riding your bike and picking up moment, when all of a sudden you are hit by a bus.

Get better at estimating

We were completely off with one task in our last sprint. I think we need more practice at breaking up stories and offering estimates. Perhaps we need to also look at how we choose stories, are they epic?

Death by meetings

ugh… Although often necessary, some seem to drag on more then they should. We need to get better at time boxing and say no to invitations. Sometimes we just may not want to attend every meeting invitation, although turning them down can be hard.