If yoda were a developer…

People often wonder where I get the time and energy to work the way that I do; the truth is it that it is all down to the passion I have for my work as a software engineer and the type of work that I am involved in. I am also very passionate about pushing the boundaries and I find it very difficult to accept that something can’t or won’t be done on the basis of “But, we’ve always done it that way” – it doesn’t necessarily mean that it is the right way, nor does it mean that it is appropriate for today’s world. It might have kept companies ahead of the game 10 or 15 years ago, but the world has moved on since then and now we have to be faster, more efficient, better. For me Agile Software Development lends itself to this change and is all about change.

I will be honest and say that this is the first “work related” book that actually captured my attention to the point that I would sit and read whilst my loved ones were enjoying their sweet slumber (and obviously blog about it).

This book is highly informative; being neither condescending, nor pushy and over-bearing on the way that agile adoption should be approached. Without intending to be a partisan; I would even go as far as saying that it is more than recommended reading, it should be required reading for anyone thinking of migrating to agile; recent adoptees of agile or anyone in between.

From the first chapters that guide us through the principles (I loved the annotated 12 principles of the Manifesto for Agile Software Development – section 1.1.2) and the descriptive text on the “paradigm shift from a plan-driven mentality”; to the readiness assessments and the importance of obtaining executive support; through to the population of the product backlog and on to the first iterations of an example company adopting Agility in their software development process.

There is no substitute for actually reading the book, which is a must; however various chapters and sections drew my attention more than others.

Section 1.1.2 – The agile principles:

Although the manifesto has been analyzed and described on various blogs and books; the descriptive text for each principle was really handy when evangelizing on agile and is a good primer for anyone new to the subject (and possibly even for those of us who have been practicing agile).

Section 1.2 – A paradigm shift from a plan-driven mentality:

This is a must read for those of us who have come from years of waterfall and attempts at changes to “traditional” methodologies or processes. The section highlights the change in mentality that is needed to move from more traditional ways of software development to a leaner, more agile way.

Section 2.4 – What does it look like when a team “becomes agile”:

With comparative plan related diagrams of how the change is made from waterfall to agile and the breakdown of how that transition was made; is comforting for those that have made the change as well as those that are thinking about/planning the change.

Section 3.2 – The different flavors of agile:

This section has a really good breakdown of strengths and weaknesses of the two foremost agile methods; Scrum and XP.

Section 3.3 – Create your own flavor to become agile within your constraints:

When I first started in agile there seemed to be a common mantra that permeated throughout the meetings and blogs that effectively stated if you weren’t doing it exactly by the book, you weren’t being agile. It is completely preposterous.
How can the same agile development methods used by a web advertising company be cookie-cut for a software company writing client server applications in a strong regulatory environment? The answer is – it can’t. There will need to be some adaptation. After all isn’t that one of the principle concepts of agile; what is the point of having Sprint Retrospectives to adjust and tweak a process in a constant attempt to improve? This section is a must read for those that are constantly being belittled or set-upon by “those in the know”.

Chapter 4 – The fitness test: all about readiness assessments:

Although I have not had the opportunity of actually performing this exercise; having read through the chapter it is very informative and goes in to great detail on how a company can be measured for it’s fitness to adopt agile development.

Section 6.3.1 – Tough questions:

I liked this section because of the example of typical questions asked by the team that will be adopting agile development and the possible answers to give about the migration process.

Section 7.1.1 – Attributes of a good coach:

This section contains a very good breakdown of the attributes that should be sought when selecting an agile coach. The following sections go into further detail about training and coaching; as well as details on the interaction with managers and stakeholders.

Section 7.3 – Creating a team with an agile mindset:

This section explains what ingredients are needed to create a sound agile team; from “Culture and roles” through to “Characteristics that influence individual performance”.

Chapter 8 – Injecting agility into your current process:

Just the title alone gives the idea of the maturity of mind that the authors have when confronting a company wanting to adopt agile development methods. From documenting the existing process (not everyone has it written in stone and perhaps not all aspects of the company are actually doing what it says in the process hand-book); to deciding what to keep and what to change.

Chapters 9, 10 and 11

Discuss the selection of a pilot project and the team that will be on the pilot project. This is very informative for those companies that have made up their mind to move to agile and are looking around for the best project to guinea pig.

Section 12.3 – Feature cards compared to…:

As a Scrum practitioner it was interesting to read the comparisons between feature cards, user stories, use cases and functional specifications.

Section 12.5 – Hard-copy vs. electronic cards:

I found this section particularly useful as it highlighted the benefits of both, using SharePoint as an example of the electronic format. Although the idea is to keep it as simple as possible I am an advocate of using technology where possible – more than anything to cut down on the waste generated by so much paper; but also for the fact that you can view the information at any time (this is effective when trying to explain PBI or SBI to persons not located in the same area).

Chapter 13 – Prioritizing the backlog:

This is a subject that I find is the least covered in discussions with peers (both at work and outside) and it is really helpful to see the suggestions posed throughout the chapter. Peppered with examples of a product backlog and how to handle various items; this chapter is a good starting point for broadening the discussion.

Chapter 14 – Estimating at the right level with the right people:

I still remember being asked to estimate for a particular requirement when I still felt that I did not have enough information to do a sound enough job of it. How different it is when you are doing it as a team and everyone can voice their thoughts on the matter. This chapter is particularly useful for those still in “traditional” methods or recent adopters of agile methods. Of particular interest is section 14.1 – Contrasting traditional and agile estimation techniques and section 14.2 – The importance of whole-team estimation; both of which ease the reader into the subject that is quite explanatory with regards to the estimation process in agile.

Section 16.3 – Identifying and estimating tasks:

This section has a nice “call-out” titled “Task assignments aren’t permanent” that describes how the early stages, specialist people will be suited to certain tasks and how with the passage of time and acquired experience in an agile environment team members will become more capable of taking on varied tasks that perhaps were out of their realm in the beginning.

The latter chapters of the book, starting with chapter 20, describe the process of adapting to change and learning as we go. Section 20.1 – Common reasons for adapting (i.e. make those tweaks mentioned earlier); describes common issues that crop up and some ways that teams adapt to the situation described.
Chapter 22 is particularly interesting with a detailed explanation on how to prepare and manage the retrospective.
Chapter 23 is a must read for companies that have successfully started a pilot project and are now looking at how to push across the divide and bring about change at an enterprise level.

As I stated at the beginning of this article, I would seriously make this book required reading for those that are at all interested in adopting agile or have just started – it is clear, concise and has plenty of example scenarios that many individuals and corporations would identify with.