There are some smart guys on there and more have promised to contribute so I suggest you take a look and stay in touch as more consultants are added.

Real agile adoption – lessons learnt

Comments should be posted on the Agile 2009 conference site.

Two tools are helping me with this, Plaxo gives me online access to my address book. Through Plaxo I can easily update contacts when my addres details change and receive automated updates when others do the same.

Linked-in is alowing me to construct a network of contacts as well as an online CV.

Of course, the way to make these tools work is convince others to do the same; so if you know me please consider looking me up on Plaxo, also link to me on linked-in and join the network.

In naming the company we have tried to draw attention to the 7 driving principles of lean software development. These provide a backdrop on which we can build agile processes such as SCRUM and practices such as test driven development and refactoring.

For more information about the new company please check out www.principle7.co.uk although I must emphasise that at present the site is under constant change.

Question like this come up fairly regularly in discussions about lean software development. Lean manufacturing is a set of principles pioneered by Toyota; this includes the minimising of waste, pull rather than push manufacturing and time boxing of when to make decisions. While lean has worked extremely well in manufacturing there is always someone willing to point out the differences between manufacturing and product development.

The jidoka principle is to stop the production line as soon as a fault is detected. This minimises the compounding of the error (i.e. building a car with a faulty part). Having stopped the line the fault must be resolved and finally the root cause resolved. So, can we apply this principle to software?

1. Detect a fault
2. Stop (any continuation is based upon false premise)
3. Fix fault
4. Fix root cause (process improvement).

In presenting this concept Kevin lead us through a history of the application of this technique in weaving. Following this we experimented with feedback in a game of Chinese whispers.

The discussion that followed highlighted the need for pragmatism when transferring the technique into software development. In particular we must acknowledge that multiple threads of development exist. We must assess which threads need to stop when a fault is detected. Also to apply this technique we must have a continuous integration environment along with regular check-ins. Finally we must be realistic about our sphere of influence and not waste time tackling root causes that are out of our control. Perhaps a root cause list should be kept for use in the retrospective?

In my introduction I invited attendees to share there reasons for being there. Amongst the 16 or so people we had a majority who had either had some difficulties in applying the techniques effectively or felt that the use case approach had inherent weaknesses. The remainder were looking for a refresher on benefits and limitations of use cases.

In making an initial stab a managing peoples expectations if highlighted a few points

• Use cases are not a golden hammer
• Use cases provide a useful mechanism for elicitation of behavioural requirements.
• The use case diagram that many people present is a HOAX.
• In the vast majority of cases the only necessary relationship between use cases is <<includes>>

I was also asked to present a mapping from use cases to “service oriented architecture”. I ducked this question as I have found SOA to have a negative effect on OO design.

At this stage Mark took the floor to introduce use-cases and a process for their development.

As a means of communication, use-cases are dependent on the adoption of a common vocabulary. Other parties have referred to this as “ubiquitous language”. The approach that we advocate to developing this vocabulary is domain modelling. We use a noun search technique to help identify key concepts, relationships between these can be shown on a UML class diagram. The result is a glossary for the project.

Having developed and agreed the terms to be used in describing the problem we will begin to elicit the behavioural requirements. The term behaviour did cause us some difficulties in this forum. Use cases are a highly effective tool for describing the required interactions between the system under design and external stimuli (people or systems). We at this stage took the opportunity to take stock and discuss the make up of a requirements document. I see it as consisting of a number of chapters, these may include:

• Business rules (formulae and calculations. not workflow)

• GUI wire frames (or similar)

• Non functional constraints

• Quality of service (availability, performance etc.)

This discussion highlighted some significant concerns regarding the use of terms such as non-functional requirement, business rule and of course behaviour. It was generally accepted that while we held a common understanding of these terms they were perhaps not ideal. For instance business rules is a term I use to separate out calculations from use-cases. However, the term can be used to describe workflow.

Having got past a significant diversion to cover terminology Mark continued the elicitation process. We need to obtain a list of prime capabilities of the system under design.  Mark emphasised that the “system under design” (SUD) could be a system or a business.

Rather than dive in and try to discover capabilities we start by brain storming actors.  This list will include all parties who interact with the SUD. This list of actors leads us to the next question; why do these parties use the system. With this question we are trying to ascertain actor goals. Alternatively if a system is used by our system we describe it as having a responsibility.

Following this we begin to identify certain goals as primary capabilities of the system. These are the beginnings of our use cases. Finally, for Mark, the possible structure of use cases was covered.

Mark emphasised that this approach will only cover the behavioural requirements. On average this will be in the region of 30% of the requirements for a system.

I re-took the floor here to present a technique called robustness analysis. This I borrow from Doug Rosenberg’s ICONIX process. This technique can be used at two stages; first to improve the standard of a use case, second, to kick start the design of a system based on the use case.

The final point for discussion was the applicability of use cases in an agile process. My particular area of interest is SCRUM. I am happy to acknowledge the benefits of an on site customer. However, many of my clients cannot donate an appropriate individual to the development team for the required time. In this case we leverage use cases to capture a conversation with the customer. This must be use in combination with the usual agile principles of minimising up front investment and achieving feedback ASAP.

Over the next couple of days I spoke to a number of the use case sceptics who felt that our pragmatic approach had effectively eased there concerns. I thank all attendees for taking part in a session that I enjoyed and I feel all parties took some benefit away from.

The conference sessions I attended were universally interesting and of a high standard. However, of even greater value to me was the attitude of a free sharing of thoughts and experiences shown by all.

Over the next few days I will be posting comments on all of the sessions I attended. I hop someone will find them of interest.

In the workshop we will show how we approach eliciting use cases by discovering the stakeholders of a system. From here we cover techniques for authoring use cases in a robust yet readable style.

This first part of the workshop will be followed by an open, led discussion regarding the appropriate uses of use-cases in a agile software development environment. While use-cases are a little out of fashion in the “user story” led world I intend to show when and where the investment in robust use cases is appropriate.

I’ve started again now as quite alot is going on that I would like to share. You can look forward to comments from scrum master certification training and SPA 2006 followed by more agile stuff from the agile north group.

The first speaker was Kent Beck talking about test driven development and a concept that he termed software health. As a software engineer first and formost I am particularly interest in any approach that claims to improve quality. Kent was claiming more that this.

The term software health covered, in addition to quality, attributes such as flexibility to change, resiliance against regression and maintainability.

The second speaker was Mary Poppendiek. This was my first exposure to “Lean” thinking. Lean seems to me to underpin agile. Lean is a set of guiding principles that originated in the late 1970’s in the development of the Toyota Production System. Since then the same ideas have been rolled into many manufacturing businesses and also other areas such as logistics. Mary has taken these ideals and applied a software spin. After hearing what Mary had to say I went and bought her book and would recommend it to anyone interested in agile.