Agile @ JAOO 2007 #2

I should actually call this post; SCRUM @ JAOO because that was what the track was called. But anyway it was not only information on scrum that I am left with after the second day of the conference.

Key elements
Rythm is important. - Let it be the heartbeat of the team.
Roadmap is still important even you are doing agile.
Do not overload the experts, especially on multiteam environments.
Architecture is allowed! Abstractions and interfaces are a very good way of doing this. (Coplien had some really nice slides on this)
TDD is both good and bad (according to Coplien its only bad, but there where alot of discussions on this).
Domain is important. -It creates the bridge between developers, customers and users.
Retrospectives - Important for learning and communication (Prime Directive)

Wish I had more time to go in to detail on all the issues, but I will have to do that at a later time.

Agile @ JAOO 2007 #1

Yes, I'm attending the JAOO Conference in Denmark at the moment. Today I have seen most of the presentations in the agile track and I'm quite satisfied with the amount of information that has found its way through my ears and eyes to my brain. This information is now in a process of being mixed with my own experiences and thoughts. Hopefully on wednesday I will be able to go home and create knowledge by acting upon the informaton I now have.

I'll cut the chase and tell you. Agile Retrospectives by Diana Larsen was the last presentation on the track and its the one that still sticks in memory (The rest is written down in notes). The presentation was a small summary of Diana's experience regarding the facilitation of constructive discussions and retrospectives. One of the things she mentioned was that there is no blame in such a retrospective. The meaning is to find out what went wrong and fix it or to find ways to improve and not to finde someone to put your finger at. It is a team responsibility so there is noone to blame. Diana claims this is one of the key elements of a good retrospective, a safe environment where one can share thoughts and perspectives without handing out or be blamed for what went wrong (or right for that matter).

A second thing she mentioned was the amount of actions you should focus on for the improvement in the next iteration. This should be one or at the max two actions. These should be followed up in several ways. In the daily standing meeting was one, another being in the planning of the new iteration (ie put it on the sprint queue).

Diana Larsen inspire to a deeper look into retrospectives and from the feel of it, I think that my autumn books might be on the subject.

Have a nice night and I'll be back tomorrow with another tiny bit of the JAOO Conference

Friction and slow delivery

I was just reading up on my favourite blogs when i came over a interesting post on the From where I sit -blog. Michael S. Hyatt describes what he sees as friction when visiting a bookstore. The idea is to get the purchase happen fast enough so the customer does not change his mind or as in Michael's case, leave the shop because it took too long to get the purchase done.

Could we not draw parallel from this to our development of software and project practice? The customers want a new feature in an already developed software. We receive the request and we specify it further with the customer. We estimate the time it will take to develop the new functionality. Customer gives us clearance to start working on it. We work on it. We finish the development on the new feature and we test it. We do not deliver it, because we have more things on our list to do in this release. The customer knows this so he is patiently waiting for us to finish this as well, because he also wants the other changes. We test the other changes, we might find a bug and work more on the issue. Then we hand the release over to the customer so he can test it, this is 6 weeks after the order was placed. They find a bug which get reported back to us and we start fixing it. We deliver a patch for the release and they test this. All is well and the testing is over, the release goes to production. The users finally see the new feature which they wished for, maybe 3 months ago.

What if the process where a bit different? What if we develop the new functionality and test it and deliver this to the customer. The customer tests the new functionality while we develop the other requests on the list. The customer find no bugs in the functionality and we release it to production. Or if the customer finds a bug, he reports it and get a new release from us with the fix and maybe more new functionality in it. Maybe some of the other things on the list was finished and tested in time to get it with the fix for the new functionality. Customer gets the new delivery and test it again, now with additional functionality. It goes through and we release it to production, maybe 3 weeks from when the users wanted the new feature.

To me this sounds better than the initial way of doing things. If the functionality that gives value to the customer is done, give it to them! If the users want changes, make the change and deliver it to them as fast as you can. No need to wait.

There are of course issues around this. One of them being the ability of the customer to actually receive and test the new functionality as fast as you deliver it. Another might be that the initial software is used 24 hours a day and a production release will hinder them in their work and cost money. But I urge people to think on this and ask their customer if they really cannot receive and test small parts rather than big chunks of functionality. Do they really want to wait that long for something they ordered? Why should they order and add all these orders in to one delivery? Does 15 minute downtime on their production system really cost that much versus having users waiting for functionality for months? Do their lack of motivation towards the use of the system cost less?

In this post I have not even started talking about the cost of long feedback loops on the delivered functionality. I'll save that for another post sometime.

TDD momentum continues

Just a small update this time. The TDD course seemed to go ok and many of the participants now have an understanding of how to actually write the tests first and then move on to the production code.

I got good feedback on the theory of the course, but the practical part was a bit unorganised and some found it difficult to think as proposed in TDD. This was great! It shows that we are truly not used to think this way and hopefully it will inspire to more.

I will refine my course to be even more streamlined when it comes to the practical part and hopefully with other employees we will not have the issue of an unfamiliar IDE.

For the .Net guys out there I came over this CruiseControl.Net demo today. So no excuses for not having continuous integration on your platform either!

I'll be back with a longer post on management issues when faced with delays which is out of your control. (promise!)

Test-Driven Development Momentum

Tomorrow I have, what we in Computas call, a competence-block with the new employees. These blocks contain information that we think that most employees in the company should know something about. Mine is about Test-Driven Development (TDD).

It all started last week when I was reading up on various blogs. Then I read "Learning The Holy Ways of Consulting" from Thomas F Nicholaisen and it spurred the idea of doing a TDD course for my two new project members. I started designing a course much like the one Thomas had and when I started talking about it at work people wanted to have such a course themselves as well.

Even though I have tried to implement this in my project before and not having much success (see: this post), I wanted to try again with the momentum of two new people. What I have now is an even better possibility, to show all new employees TDD and it's benefits. I mean it is extremely important that a company which not only produces code, but also maintains code has to use all quality-increasing tools available. Since we often maintain code for several years after the initial release anything else would be shooting yourself in the foot! For a good post as well as an example of old code renewal through TDD see Anders Norås' blog and his Ending a Legacy post.

Ok, let me get back on the actual subject of this post. The course will be held in two sessions. These two days being Monday and Tuesday from 9 to 11:30. During Monday I will go through some of the theory of Scrum, TDD and show them how to make a sprint log of the items I've made in Jira (thanks for the tip Thomas!). From there on, it's all practical. The task at hand will be the famous bowling assignment from uncle Bob as I'm using much of his ideas on TDD in the theory part of the course.

Lets hope that I will win them over to TDD and by doing this start something wonderful in our company. Maybe this is enough to create a critical mass of people to win over the rest? We will also of course make this competence-block available to all employees when I'm done with this prototype.

I'll tell you more later!

Agile and Post-Agile?

What is really agile? I've touched upon this topic earlier, but I have come across a few blogs on the topic again that are interesting. Especially David Anderson, Agile Management Blog where he asks the question "Are you part of the Post-Agile movement?". He also asks the question of what agile is and points further to Jason Yip and his Agility is not the point post. In this post Yip compare the so called Agile elements to those of Lean and he does a good job of it.

As Anderson says, we need to keep pushing.

To me it does not really matter if it is agile or not, as long as we can improve the way we perform our craft and deliver better solutions. Agile for me right now is to implement Scrum and see if this improves our abilities. When this process has settled I will keep pushing. Will you?

Rationale for the change

Change can happen in many ways and there is so many factors involved. As mentioned on my favorite leadership blog: Leadership in Practice, change fails when employees dont grasp the rationale for the change. By rationale meaning the why in the change. Why is it happening? Does the change only happen because some leader have found out that this should be better for the employees or its the latest hype? Head over there and read the post, it's a good one.

As i commented on George Amblers blog, it is more than just the rationale in change. It's the what and how as well. Many of these decisions should be taken by the employees afflicted by the change. They should know best how to perform changes. At least most of the time.

Maybe its naive to think that way, but to believe in people make them do incredible things.