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.

Are the customer involved enough?

A while and several blog drafts since my last post now, but here it is.

The question is really, are the customer enabled to be involved enough? While we are quick to think if the customer are participating in creating the backlog or the sprintlog. By this having ownership in the decisions made. Not long ago on InfoQ Little and Spayd gave their views on agile and organisational change and they mention the importance of the customer being part of the agile process if the deliveries are to be successful. This is very true, but are they ready in their organisation to handle the deliveries?

As the Agile Manifesto principle states: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. This assume that the customer are able to handle these deliveries at the pace they are coming. Further the manifesto claim that Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. If we are to adhere to these principles we have to enable the customer to also become agile in their process of receiving the delivieries.

To take a practicle example of this I can relate to my current project which is in the process of implementing a more agile approach. Agreements have been met and deliveries have been delivered, but the receiving end are not able to handle the deliveries at such a pace. They lack both the manpower and the routines to test the deliveries thus bringing us back to how it was before. The team cannot keep on delivering while the tests are not being managed and we have to set a new pace. A good article on Agile Journal describe this scenario as candy coming faster on the conveyor belt, it creates trouble handling them.

This shows that agile processes sets new demands to the organisations not only where the deliveries are being produced, but also in the receiving organisation. Now you have not one, but two organisations that has to adopt agile. The question is are the customer involved enough to make that change?

Code review: increased quality and knowledge sharing

In my earlier post "Make it better" I said we were starting with a more TDD similar approach. We have tried this now for more than a month. We have tried writing tests first, but this seem to be a futile attempt. Arguments used are "I tried, but it took too much time to make the test" and "It is too difficult to make the test and it was only a small change in the code". To these arguments I can say that they are true in our case. Much of our legacy businesslogic has been placed in beans which in our case are difficult to write tests for. Hopefully we will be able to make more tests totally new businesslogic rather than trying to make it for the old code.

This said, I would say that we have in this process learned a lot about our own code and its limitations. Placing the business logic in beans is not good for the ability to test the code. We will try not to blindly do as the one before us did. I figured a way to try to compensate for the lack of writing the tests and introduced mandatory code review before any code can be checked in to the subversion repository. This forces the developer to argument and discuss the code before it become a part of the solution. It gives the developer another perspective and thus enable both the sharing of knowledge and an increase of quality. As in TDD the idea is that one would think differently before coding because we write the test first, we in this case do the code review after the coding but still enable the developer to get comments on both the code and its quality.

At the last xp & agile meetup in oslo we had Robert C. Martin (uncle Bob) present his thoughts on craftmanship and ethics where he mentioned that if we checked in code that was just a little bit cleaner and better than when we checked out we would eventually increase the quality of the code. The code review is a good incentive for this practice.

To quote uncle Bob: "Never check in bad code!"

Motivation at work. More than money?

A process is taking place in Computas these days. It is the annual company negotiation of salary. The process is an interesting one where we have a comitee of members in the worker-union (Tekna) and non-union-members, agreeing on our demand regarding this years increase in pay.
These people sits down and discuss the economy of the company and bring a broad perspective of worker-opinions to the table. When the comitee have reached a proposal, it is presented to the workers in the company and if no one objects, the leader of the group delivers this to the company leadership. The delivered document is then the official demand from the workers. This is where the process gets interesting.

During a month the discussion goes back and forth on what is acceptable and various arguments are put on the table. Some may claim that salary is what keeps them motivated and other may claim the opposite. I tend to think that money is really not what is motivating me at work but as Susan Heathfield so elegantly tells us, it always include money.

The salary I get goes to paying my bills and it enables me to live the life I have today. With this said it is apparent that I need more than just to enable me to vile my life outside working hours to keep me motivated. Buying a flat in Oslo will not keep me motivated at work for a long time. It will of course enable me to have a better life in the sense that I will have my own space and thus hopefully have a better economy than now when renting a flat. It would feel much better to pay for my own flat rather than paying for somebody else' flat.

I am insinuating that salary is a cornerstone in work-motivation, but its role is an enabler. This meaning it has to be there to be able to motivate on other areas (as I've mentioned in earlier posts).

And yes I am very curious on how much this years pay increase will be.

To be agile or not to be agile, is that the question?

What is really agile? Are we really agile or has it become a hype?

These were questions that was brought up on todays xp.meetup without coming to any conclusion, but nonetheless a fruitful discussion inspired me to write this post.

One of the issues mentioned was related to technology and how agile you can get. Many agrees that technology influence our way to work and thus how agile we are in our work. And it was in this context that J2EE was mentioned as something that really held you back from working agile. This might be well and true, but isn't the question really "How agile can you get" and at the same time deliver what the customer want with the agreed quality?

Many projects today deal with legacy technology and different aspects of the past that impose restraints on our solutions. Would it not be possible to say that one is agile in the way they are dealing with this legacy technology? Be it test driven development (TDD) with or without behaviour driven development (BDD). The world is full of legacy..

Make it better

Easter vacations are over and we are finally getting back to work. I have a few exciting things happening this week as my role as project leader is getting more familiar. One of the things is a full day unit-test workshop with my project members.

Testing we do today:
1. Your own testing when you have written the functionality
- Verifies that you do not have any obvious errors
2. Someone else tests the functionality after your description of how to test it
- Verifies that you have not skipped the testing? Sometimes people do different approaches here..
3. We run a robot-test on main functionality of the solution.
- This ensures that we do not have errors that stops the solution or influence the core functionality.

After this our solution leaves the office and is delivered for testing by the customer.
This approach would work great if it had not been for the time between our beginning of the programming/coding and the time we get feedback. It has a high risk of creating a gap between what the customer wants and what he gets. To help with this gap, we have iterations in the implementation phase which is highly influenced by customer feedback.

All well and good so far.

The issues start showing up in Jira (our bug tracker) some time later. This might be issues connected to integration or even several years old code. The amount of code lines and the number of integration points are increasing every day. To avoid the problem of having feedback this late I think we need to increase the release cycle and write unit-tests before we code. The "write the test first" (or TDD) rule will enable us to think differently before we start coding. As well as seeing implications earlier and taking these in account when implementing our functionality. One of our goal is to increase the quality of both code and functionality and this will work as an enabler. After doing this a while we will hopefully be able to start with nightly builds and catch more bugs this way.

Oops..This post got a bit more technical than planned, but anyway thats the main thoughts.

You might ask "why we need a 1 day workshop on this?". The keyword is ownership and engagement. If I just say that we are from tomorrow writing tests before we code new functionality, who would do it?
By doing this together we lower the barrier for something new and we increase everyones competence by working together on the different problems that comes up. We have focus on this for a whole day and might actually remember it.

The ultimate goal is an increase in quality and pride in what we deliver. Even if we work with legacy code and others mistakes, we can make it better! And we will!