Book Excerpt: Scaling Software Agility

As a co-founder of a small start-up company that grew to 160 people, survived the internet bubble / burst and ultimately was acquired, I never truly understood why large software companies continuously fail to convert themselves to more agile driven organizations.

That is until immediately after our acquisition. For the past year, my team and I have successfully convinced many crucial business owners throughout the organization that agile driven concepts as described by Dean Leffingwell are crucial to delivering better software faster.

Unfortunately, even though we have made tremendous progress in several key areas, we have been unsuccessful in truly influencing other organizations throughout the company. The past year has been an extremely frustrating experience in many aspects. Furthermore, no matter how hard I tried to learn and research proven methods, I rarely found extensive material to help us on our journey.

For the first time, a book accomplished the missing void we saught so hard to find. Dean's book truly hits the mark and accurately describes why so many companies have such a hard time converting. He provides history behind the agile methodologies in order to provide proper context. The history lesson is informative even for individuals who have a strong background. He completes the book by breaking out agile concepts that scale regardless of size and more importantly, he also covers several concepts that if implemented, help a large company adapt to more agile best practices.

My only knock on the book is that I wish he would have spent more time on the one key issue that continues to kill us - the need for organizational change. However, after thinking about this issue for a while, what can an author really do to improve a company's ability to change the organizational structure? Not much I am afraid...

This is a fantastic book that everyone should read - even folks that work in small companies. I am confident that the reader will walk away with at least a few good ideas to leverage now or as the company grows. If you already work at a large company, the book will at a minimum give you some peace of mind and hopefully will serve as a vehicle to encourage change by others.

In terms of previews, you should consider sharing chapter 9 - it is an outstanding account of what really makes a team succeed and it touches on the organizational boundary issues that must be solved at some point...

Well done!

I will buy this book, but working in corporate environments, I naturally have some questions I would like answered about applying these methodologies in bigger companies. This should not be new to the "agile enterprise" community, as I'm sure these questions are coming up often.

At least from what I see in the telecommunications world, most companies are piggy-backing some agile practices to the essentially waterfall "PROPS (Tollgate)" project management process (orginally defined by Ericsson). I don't know if the book will have answers to my questions, but here are some of them:


1. in order to decide which projects to do (usually demand exceeds the resources) early cost, effort and time estimates are required. I am interested how is cost estimation done in agile methodologies, with the rolling set of requirements - companies plan their investment budgets in 6 / 12 months cycles (at least).


2. how do agile methods apply to stuff turnover - how is knowledge shared and handed over - usually teams move on and work on different projects in time, or sourcing involves a mix of internal and temporary staff.


4. do the methologies apply to integration projects where multiple vendors play different roles - for example there might be a need to agree on detailed interface designs that will be delivered following a fixed-price/fixed-time that should also cover features planned in later iterations


5. what's the impact on the test environments when multiple projects have the same target systems, their short-term iterations / sprints etc. must be co-ordinated (thus losing some of the freedom).


Generally I see the benefits of agile methodologies but I also see a lot of struggle ahead when implementing it at corporate level with impact on program management, controlling, business processes etc. - and wonder if agile can be applied isolated or whether it actually requires a re-work of the entire development processes with awareness at all levels (marketing, customer care, finance etc.).

First two chapters is impressive. Will help lot of people selling agile and setting up in their organisations. It was bit of a pain. Is it just possible to buy the whole book in pdf?

Actually - the book IS available on InformIT Safari
safari.informit.com/0321458192

And, depending on the kind of membership you get, you can pdf single chapters for your own use.

I use this service even for books I have paper copies of: the internet is everywhere and it keeps my luggage light :-)

deb

I don't think this book will get you these answers. Personally I found the book a little shallow, though a useful read.

1. in order to decide which projects to do (usually demand exceeds the resources) early cost, effort and time estimates are required. I am interested how is cost estimation done in agile methodologies, with the rolling set of requirements - companies plan their investment budgets in 6 / 12 months cycles (at least).

Using Scrum, every requirement gets estimated immediately, so making budgets, time estimates and cost estimates are just normal. More info on this can be found in Mike Cohn "Agile Estimating and Planning" book

2. how do agile methods apply to stuff turnover - how is knowledge shared and handed over - usually teams move on and work on different projects in time, or sourcing involves a mix of internal and temporary staff.

Well, the team can document the software if they find it useful :) Nowhere in agile it says that you aren't allowed to write maintenance documents. Though there are other ways like pair programming. The amount of work you need to do is often a function of the staff turnover vs cost of getting new members up to speed without taking it into acocunt.

4. do the methologies apply to integration projects where multiple vendors play different roles - for example there might be a need to agree on detailed interface designs that will be delivered following a fixed-price/fixed-time that should also cover features planned in later iterations

Sure, I'd normally recommend to still try to work from one code base and apply continuous integration cross company. When delivering binary components then interfaces probably need to be defined. Also binary components can be integrated in a CI system.

5. what's the impact on the test environments when multiple projects have the same target systems, their short-term iterations / sprints etc. must be co-ordinated (thus losing some of the freedom).

Well techniques like TDD can be used on the development environment (so testing not in the test environment, but in the development environment). This should increase the quality before it's tested on "the real environment".

The rest, allocation of test equipment is not much different. Some test equipment would be needed for CI environment though.

Generally I see the benefits of agile methodologies but I also see a lot of struggle ahead when implementing it at corporate level with impact on program management, controlling, business processes etc. - and wonder if agile can be applied isolated or whether it actually requires a re-work of the entire development processes with awareness at all levels (marketing, customer care, finance etc.).

IMHO, on long term, it requires a complete rework of the entire organization.