The Art of Agile Development

Keep this book to hand

The Art of Agile Development was recommended to me by Jeff McKenna when he provided some Scrum coaching to those of us in the Dublin office working on Oracle Social CRM. Back then it was a new, hot off the press book, but I have recently reread it because I have found it useful in providing guidance on what to watch out for when changing agile development practices. This was necessary due to changes in teams and technologies as some of us focused full time on Fusion Applications. Practices, roles and responsibilities we had gotten used to had to be adapted or dropped to blend in with APM, Oracle Fusion Application’s development methodology.

The book, by Shane Warden and James Shore, is a great introduction to agile development methodologies by covering both XP and scrum. Practical examples are generally from XP projects because that is where the authors have the greatest experience. The authors identify a broad set of practices that would be considered as characteristics of agile development methodologies in way or another. Recognising that it is very rare in most organisations to be able to follow an agile methodology completely as prescribed alternatives are mentioned, but not in every case. Shane and James are also very clear that many of these practices are often taking place at the same time in a software project rather than in a sequential waterfall methodology. However, categorising practices by what sort of activity and the nature of the activity give a very useful matrix for teams to analyse how agile their own practices are and perhaps identify areas where realistic improvements can be made. Just being able to have a label or term for a specific practice makes discussing within a group easier.

Download poster from James Shore

I see the collection of practices being grouped by phases (planning, analysis, design & coding, testing, deployment) and verbs (thinking, collaborating, releasing, planning, developing). For example, when team members are working on implementing a specific feature that kind of collaboration is ‘design & coding collaborating’ and the section in the book covers some pair programming techniques. In fact, this particular section addresses the misconception that pair programming is a fulltime ‘paired for life’ regime. It is a useful tool that can be used for a few hours a day to make some significant progress, reduce interruptions, and spread the knowledge of how and why parts of the system being developed work.

Other useful techniques peppered through the book include the Agility Self Assessment and the many skill development routines, which the authors called ‘etudes’. These are short exercises that may help in getting the feel for a more agile approach. When reading the chapters you might be thinking we don’t have the development experience to let team members do organic, incremental architecture design, or implement thorough automated testing. I wonder how many people never complete the book because they do not believe they can carry out these changes and deliver software in a timely fashion. It’s not until towards the end of the book that the authors address the reality of the mixed capabilities of the team. If this was at the beginning it might give the readers more staying power. The book does have some helpful advice on working with and around the politics, the mixture in experience levels, and heavy weight project management within your organisation. It has to be read in it’s entirety though and does make for an excellent reference book to dip in and out of.

This article has been edited since it was first published.

Interface Oriented Design

This book has been sitting on my desk for a long time and I’ve been dipping in and out of it for at least a year. I’m a big fan of The Pragmatic Programmers and the topic of interface is very close to my heart as it is often the most ignored when system analysis and design occurs. Apart from performance, interfaces are generally the biggest problem that is faced when a system goes live because once people start to use it, they want to use it with the other systems and tools they are using. The human interface to a computer system gets, quite rightly, a lot of focus. The topic gets it’s own module in Computer Science degree courses. This has meant that today’s software developer is familiar with the concepts of usability, task analysis, workspace arrangement, error detection and recognition.

I was hoping that Ken Pugh’s Interface Oriented Design was going to be that seminal book which would set out design principles and approaches for deriving robust interfaces. It is not. While it does introduce some interesting concepts such as the Three Laws of Interfaces and Interface Responsibility Interaction it lacks a real world sense about it. In fact, the purpose of the book appears to be the platform to launch Pugh’s Interface Responsibility Interaction format. It’s an interesting idea, but unfortunately it does not make a strong case for using such a format in real projects. Some case studies from other projects where IRI was used would have been beneficial.

One gets the sense that this is a serialisation of some lectures within a system design module in college, with a trivial exercise to prove the points. Put simply, there’s really not much in the book to grab the experienced developers attention.

Oracle SOA Suite Developer’s Guide

Service-Oriented Architecture (SOA) is not about technology, although technology is used to implement it. The principles of reliability and accommodating unexpected changes at a manageable cost can be applied equally in any programming language. However, as with most things in life, not just software development, it is easiest to use a model that is supported by tools and inter-operable (the ability of two or more systems or components to exchange information and to use the information that has been exchanged). A standards-based Service-Oriented Architecture (SOA), is such a model that enables IT infrastructure is continuously adapted to keep up with the pace of business change.

Matt Wright and Antony Reynolds have just published a book Oracle SOA Suite Developer’s Guide that provides a best practice guide to using the Oracle SOA Suite for building a real world applications. This book bridges the gap between SOA theory and the Oracle SOA Suite Manuals and is based on the experience of implementing SOA across a number of organisations in EMEA and APAC. It is a book of three parts. The first section of the book provides detailed coverage of all components of the SOA Suite, namely OSB, BPEL, Rule, BAM and OWSM. The second section addresses the common question: “What is the best way to combine / use all of these different components to implement a real-world SOA solution?”. Using a working example of an online auction site, it leads you through key SOA design considerations in implementing a robust solution that is designed for change. Though the examples in the book are based on Oracle SOA Suite the book will still be extremely useful for anyone using 11g. The final section addresses non-functional considerations and covers the packaging, deployment, and testing of SOA applications; it then details how to use Web Service Manager to secure and administer SOA applications.

I’m sure this book will continue to be relevant in years to come to. Unlike other technical books, this one does more than just explain “how” to do A, B, and C, but goes to great lengths to explain the concepts. As a software developer it is vital to understand why we were doing what we were doing, so that we know which principles to apply in different situations.