Browsing all articles from November, 2008
Nov
4
Comments

Agile and Event-Driven Management

I have read an article on VentureHacks on Lean (Agile) Companies. In this article Agile = Less Waste

At Typemock we are take Agile development and being an Agile company seriously. In the development we use a scrum/XP hybrid and we use Event-Driven Management for the company. I will explain Event-Driven Management later, but I want to show you the problems that I found in the Agile Development Process.

The End of Iteration is too late

Lets take an example of a feature request that a major client needs. This feature was added as part of the development iteration and the client was told that the feature will probably be ready in 2 weeks. But at the end of the iteration due to its priority the feature was not created. The agile process says that this is ok – as we produced higher value features!

But we have a problem here: The client is stuck without his feature, but only at the end of the iteration that we knew the feature was not going to be implemented. There was no time for management to react to this problem and to solve it. For those who want to know there are a few ways to solve this

  1. Change Priorities
  2. Add a developer from another team
  3. Tell the client when the feature will be ready

How can it be better?

This is where Event-Driven Management comes in. It start by everyone saying what they intents to do that iteration and if they can’t do it (for whatever reason) they have to immediately tell everyone that they can’t make it as soon as they know about it (=the event).

A good example are meetings. Suppose there is an 8:00 am meeting, when I accept I am saying that I intend to be in the meeting. If at 7:45 I am in traffic and I know that I just can’t make it, I can do one of the following:

  1. Turn back and miss the meeting
  2. Try to get to the meeting as fast as possible and appear 30 minutes late
  3. Phone the person I am meeting and tell him that I will be 30 minutes late.

Event-Driven means that we choose option 3. we immediately tell people about the change. Doing this will allow the other person to react to the change and for example reschedule the meeting. At least he won’t sit around and wait.

Event Driven Agile

Doing this with Agile will mean that once we understand that a feature that we intended to do won’t be done – we DO NOT wait to the end of the iteration but immediately tell everyone that we won’t be doing the feature. There can never be a case that we know about missing features at the last minute.

It is quite simple once you use a burn down chart, when the time left on the burn down is more than the time actually left – we can raise the Event and immediately tell the team about it, allowing the company to find solutions to the problems as they arise.

Communication by Events versus Communication by Polling

An event driven company is one where everyone knows what the other teams intent to do and they get are notified when these are postponed.

Whereas polling driven companies are companies where the employees are constantly asked ‘what is the status of’ (because we can’t know if we are going to be there on time). People will wait for others and poll at intervals – leading to waste.

Being an event driven company – will stop waste and make the company much leaner.

Nov
3
Comments

Future of Unit Testing and Economics

Author Eli Lopian    Category .NET Tests, Agile, TDD     Tags

Euan Garden managed the PDC 2008 Panel Session on the Future of Unit Testing, and Andrew has made a short summary.

Unit Test => (Automated) Developers Tests

An interesting thought that come from listening to this panel is that there is a confusion about what unit tests are and I agree that we should really call it (Automated) Developers Tests. This is one of the cases where Microsoft got it right when they called their developer testing tool msTest and not msUnit. Even so, I will continue to call these unit tests, but my meaning is for all tests that developers need to do.

I also agree that many developers still have the concept of “I am a developer so I don’t need to test my code – that is something that the QA team should do”.

Two Futures…

Watching the panel it is obvious that there are two paths that are being considered. The first is that we should not use any tooling at all, and that the pain of doing unit tests will help us write better code – (if you have any pain – it means that you are writing bad code, if you keep on having pain perhaps you are not a good developer), while the other camp say that testing is boring/complex, lets make it easier with tooling

Developer Testing Economics

There is a lot of economic sense in making developers testing there code early on, the early you detect a bug the cheaper it is.

image

So even without creating a better designed software there is still great value in developers testing their code. The thing is that most developers are not willing to test their code, it is too painful/boring. The future is that more and more developers will unit test the code as it cuts the costs of developing software, and that unit testing will be an industry standard. But what is going to make these developers start testing their code?

The Future – Unit Testing will be industry standard

I follow the Rails mantras of Opinionated Software, and my opinion is that we have to make unit testing easier for the masses to follow. It is great to see that Microsoft is also investing in tooling (Pex and TDD in Visual Studio 2010. Other vendors have these tools already – Parasoft .TEST).

The biggest obstacle for developers to unit tests is the need to isolate the code under test. Software is complex, which makes testing it complex. Using the divide and conquer technique to reduce the complexity of the tested unit will render testing these units simple.

Mocking frameworks today are not the same tooling they used to be, they are now isolation tools and these isolation tools will keep developing and progress and help developers focus on simplifying the task of testing their code.