Waltzing With Bears by Tom DeMarco and Timothy Lister

Why I recommend Waltzing With Bears:
Reason 1: It is a very fast read covering many topics concisely and accurately
Reason 2: It is the best book I've read about risk and managing risk
Reason 3: And the shortest best book on estimating


It has been 3-4 years since I read this book and I still recommend it to every PM and PMO and any other team member who is interested in the topics in it.

Scaling Software Agility Presentation by Dean Leffingwell

This is a followup to one of my previous book recommendations - Scaling Software Agility by Dean Leffingwell

You can access a summary basically of the major themes Dean focusses on for Scaling of Agile: Scaling Software Agility (pdf)

Introduction to Agile for Traditional Project Managers by Stacia Broderick

I just found this really good Introduction to Agile for Traditional Project Managers presentation that Stacia Broderick put together for Agile 2007. I am quite comfortable with what she says, and the relaxed pace that she presents it at. A well "knit" session integrating some good points from various influences and showing some solid experience she has clearly encountered in real world situations.

Hosted on InfoQ: Introduction-Agile-Stacia-Broderick.

Stacia's blog site: Agile Evolution Blog ... is not all "agile" focussed, but some gems are scattered. :)

I think it's a good complement to my Agile Introduction recommendation from about a year ago: Agile Project Management - a place to start though at 1 hour 26 minutes it is a little longer. But I think the time invested is worth it.

Thankyou for supporting!

3 Keys to Getting Your Projects Under Control

I had a little free time over lunch so I browsed on over to to the latest CIO articles quickly and came across a series of three that I quite enjoyed: "Three Keys to Getting Your Projects Under Control"

Part 1 (Plug Leaks)
Part 2 (Have an Idea)
Part 3 (Go Granular)

The series attracted my attentions as I recently attended the BCS miniSPA event which is a summary of the 6 most highly voted sessions from the real SPA event held in March earlier this year.

At the miniSPA, I attended Marina Haase's workshop on Best Practices for Finding your way into new Projects - quickly....

Other than the ?obviously huge? amount of good ideas that attendees put forward during the individual brainstorming slot, Marina also introduced us, during the group work, to Analogy/Metaphorical Brainstorming techniques which I had heard about and practiced a little privately on some problems, but never in a group. The effects were pretty amazing and I definitely recommend you find out more about the technique and try it!

Edward De Bono also promotes using analogies for creative thinking in his books on Lateral Thinking and The 6 Thinking Hats. Although he advocates random selection techniques for the selection of the scenario that needs to pull/generate ideas.

Scaling Software Agility by Dean Leffingwell

Dean is the former founder and CEO of Requisite Inc, responsible for the Requirements Gathering and Analysis Tool: Requisite Pro. It seems like his vast experience from startup to merging with IBM has touched on a number of key software development issues and he is now consulting very successfully and writing good books!

I picked up Scaling Software Agility at a book store/stall at SPA 2008 as it seemed to have a couple of new things to say, or at least say them in new ways - and I was very pleased with my choice!

I believe there is something for everyone in this book - wether you are new to agile or an experienced practitioner. The book touches on a number of topics and leads you from brief "beginner" chapters through to more interesting ones that are very relevant in today's software development arena - the scaling of agility.

Things that stand out in my memory of this book are the application of valuable software quality and management metrics, and the many strategies that Dean suggests can be used to counter the arguments typical organisational "police" will use to counter the attempt to "go [more] agile" and potentially inadvertently lead to "acceptable failure" or worse, "death march".

Usually corporations do not react to the infiltration of agile practices as they are kept within [small] team perimeters, thereby "flying under the radar". If you have a requirement to scale agile, then by definition you clearly have more people and teams that you are concerned about. There is more visibility and attention from the people who might strategically oppose the changes they do not understand, and/or department(s) or programme(s) it is being attempted in - key strategic people that you never previously even knew existed, nor what their concerns were, are now watching your every move.

http://www.amazon.co.uk: http://www.amazon.com:

Why I recommend Scaling Software Agility:

Reason 1: Part 1 covers the essentials of Agile, Waterfall, XP, RUP, Scrum, Lean Software, DSDM, FDD in 85 pages!

Reason 2: Part 2 follows with more depth about the 7 Agile Practices that work: Agile Component Team, Agile Planning and Tracking, Iterations, Small Frequent Releases, Agile Testing, Continuous Integration, Retrospectives.

Reason 3: The 7 practices Leffingwell recommends for Scaling Agile:
- "Intentional Architecture": Approaches on how to tackle large software systems with Agile Architecture
- "Scalable Lean Requirements": Three simple topics that avoid analysis-paralysis failure mode: vision, roadmap and just-in-time (JIT) elaboration
- "Systems of Systems and the Agile Release Train": how to plan, and deliver, complex software components with interdependencies
- "Managing Highly Distributed Development": It is very difficult, and is a problem all successful software programmes face. Sooner or later the team is too big to fit in 1 room, on 1 floor, of 1 building, of 1 city, of 1 country. Inevitably practices have to be developed that can assist software that is developed by many different people, in different locations
- "Impact on Customers and Operations": How marketing, or product owners, or programme owners, will be convinced that Agile is a good thing for them
- "Changing the Organisation": How to address the arguments and fallacies that the corporate immune system is going to throw around as things become more agile
- "Measuring Business Performance": Real, usable, useful management metrics that can be used to control and manage large scale [agile] software development efforts

Thankyou for reading my recommendations!

Best Practice Applied In Wrong Context - Example 1

A friend of mine was ranting the other day. He had just done an iteration retrospective with his development team wherein they took a look at their quality metrics and discovered that "quality" had actually dropped off even though his team had spent more time than ever before on the client's official Quality Process.

I discussed this further with him and we agreed that quality is a mostly subjective concept when it comes to software ... we agreed that it can't be objectively meaasured ... we agreed that it can't be artificially injected "to meet the required metric" ... we agreed that it is something that Software Quality Assurers infer based on monitoring the various metric trends that make sense in the particular environment/context that the software is being developed in/for.

So with all this agreeance I asked him to explain further.

This story is probably a symptom of why I think there is so much cynism in the software industry. Read on if you dare!

It turns out that the client has a well worked out, well defined Quality Process that they are extremely happy with. This Process is guaranteed to prevent massive loss of life/income/spiralling out of control costs/etc etc - you can imagine why a large company invests huge amounts of time and money in creating a bullet proof Quality Process: manage risk, whatever that risk is.

Okay ... so why is my friend ranting? His team followed the process, passed a bunch of procedural milestones apparently and everyone was happy. Yet when he and his team look at the metrics they defined for how they measure quality, they noticed that the number of issues had risen, that some important tests had not been run early enough in the iteration to find issues that they could then respond to before the end of iteration. There were known open issues, and the were issues that had been addressed, but had not been signed off. There was waste accumulating that had not been a problem before.

How did this happen? The people whose responsibility it was to run the tests, to provide the early feedback had been too busy ensuring the team met the Quality Process requirements - they had been documenting, and reviewing and getting documentation reviewed and spending a large amount of time away from the product they were responsible for delivering. They were going on a tangent from users' needs.

And it showed.

There is no happy ending here - key client representatives (project stakeholders, but not users) have to ensure that their organisation's process is followed. Even if they know, and everyone else knows, that the process is not adding value, and that indeed, as above, the process is actually diminishing value. And it appears often that several times a group of client representatives need to experience failure and pain before they will attempt to address a badly formulated, or in the example above, placed, process. Sometimes, regrettably, these lessons are learned during retrenchment phases.

Yuck!

Some Peter Drucker Management/Leadership/Society Ideas

I stumbled on this 5 Things William Cohen Has Learned from Peter Drucker CIO "taster" article a couple of days ago and realised that now is the time when people are going to start talking less and less about what Peter Drucker used to say and what he used to stand for.

From my perspective, his name has appeared in almost every management text book (about 25) I studied during my BCommerce. I even bought 1 of his books from a bookstore once purely because I recognised his name and just knew the sales price was a bargain!

I really hope some truly controversial "new ideas" person starts challenging the status quo once more - it seems like there is a great deal of regurgitation of management thought process going on.

4 Ideas I took away from quotations of his that gave me much to think about:
1. During the early 80's he argued that CEO compensation should not be more than 20 times what the bottom earner in the company was earning.
Imagine what the world would be like if this thought had held...just imagine... all the people ... living for today ... living in peace ... sharing all the world. *sigh*

2. The most useless thing to do, is do something that should not be done at all, efficiently.

Efficiency takes time and money - it costs A LOT! The absolute waste that goes into doing something that should not be done at all, and then making the process more efficient - awful! I guess this is one of my influencers for always trying to find the fundamentals of what I am doing and why.

3. "Management is doing things right; leadership is doing the right things."

Actually this quotation has been driven home repeatedly throughout my limited exposure. I am unsure if my current thoughts are more influenced by study or by experience: There are a huge number of managers (title) without leadership skills, and there are a huge number of leaders (personality) without management skills. When you find yourself in the rare (in my humble opinion) circumstance that there are layers of management with leadership skills all around you, magic is very likely to occur, not only during times of crisis, but also during times inbetween.

4. "The best way to predict the future is to create it."

Strange that one of Peter Drucker's core concepts was Management By Objectives (MBO). Or perhaps it is once again a case of Best Practice being formulated and applied without customisation to the circumstance/environment, and without empowering people to do the right thing as they are being measured on the wrong thing. Regardless - about this quotation - imagine a company culture where everyone is an opportunity seeker. When combined with radical and forward looking MBO, things get interesting, but most companies seem to base current MBO plans on past experience/objectives/successes/failures which is all data driven decision making and does not allow for much innovation and active workforce participation.

Like all people who get used as sources of education and inspiration he had/has many proponents and many opponents. You can read more briefly about him on Wikipedia - Peter Drucker and on the Drucker Institute which houses many interesting articles.

Anyway - I hope you read the CIO "taster" article and perhaps some of the ideas spark your further interest! (let me know if they do!)

As for book recommendations - I can't find the 1st/2nd year text I purchased years ago, but I did look around and find these good looking "professional" sources that I will be buying in the near future:

amazon.co.uk

1.
2.
3.

amazon.com

1.
2.
3.

Lean Software Development

I've been working in "officially" agile environments now since 2000, mainly influenced by Scrum and some eXtreme Programming. A while ago a I did a course on Lean Management amongst other topics and was struck by how some similar concepts (just in time, prioritised work queue, continuous reduction of waste, skilling people, empowering people) seem to be in agile.

The chance to get into my copy of Lean Software Development by Mary and Tom Poppendieck finally came along a few weeks ago after seeing it being referred to in high regard on the web and liking the essays I found on their web site: The Poppendiecks. Basically - "WOW"! This is just really really good stuff. For me it is the kind of jump (up or forward I am not sure) that Scrum makes from Agile fundamentals to real world tools that are completely understandable and easy to try.

The great thing is that they concentrate on fundamentals and then supply thinking tools to help you apply them in your context - ie, they KNOW the lesson that Best Practices are awful as it is the fundamental that must be understood and copied from one context to another to be successfully applied in the new context. Too many Best Practices have resulted in failure and too much waste for my liking!

They touch on some fundamental concepts that are important in modern software development:
- waste
- learning
- last responsible moment
- fast turnaround
- team empowerment
- perceptual and conceived integrity
- holistic view

Why I recommend Lean Software Development:

Reason 1: Identify the value chain from point of need to point of delivery - it is strongly argued by some that anything but coding for that need fulfilment is just a waste of time. IE - as per Agile - lighter weight documentation, lighter weight project management, focus on delivering real value to the client!
Reason 2: Collaboration is better - cross disciplinary people working together are more efficient AND enjoy their work more AND result in a better product AND it is cheaper AND AND AND!
Reason 3: Specific facts, graphs and examples that you can refer to when justifying reasons why you would want to try something different in your own environment, all with a firm basis in Lean Management Theory and which has been studied, well understood, and implemented by some very successful organisations ranging from Toyota to 3M for between 60 and 100 years!!

Thankyou for supporting!

Scrum and Organisational Patterns

Jeff Sutherland has posted an excellent short entry linking some sources together about how 33 Organisational Patterns of Agile Software Delivery that James Coplien and Neil Harrison formulated actually underlie Scrum. Read Jeff's post for further details: Agility and Organisational Patterns.

Thankyou for reading my blog!

Organizational Patterns of Agile Software Development by James O. Coplien and Neil B. Harrison

Covering a very wide spectrum of software team related issues from distributed remote team participation to architecture, to project control and team building.

This great book is highly relevant and useful in my team lead and architect roles yesterday, today, and I am 100% sure tomorrow also!

James Coplien is quite an interesting guy. I've read a bunch of his essays in the past which have been quite enlightening. You can find them on "Cope's" web site.

Why I recommend Organizational Patterns of Agile Software Development:

Reason 1: It is based on a great deal of research which looks to be scientifically thought out, hypotheses were created, samples statistically selected and information collected and then analysed carefully. So its fairly safe to refer to it and the cases/patterns mentioned that worked or failed.
Reason 2: In my studies of Organisation Behaviour, Industrial Psychology, Business Management and Human Resource Management, there were a number of consistent themes that were delved into deeply in this book, which has a great deal of real world emphasis and quick illumination, whereas the theory texts are more verbose and not as readily applied.
Reason 3: It is also consistent with my past experiences of organisation behaviours that were dysfunctional as well as those cases where organisations were extremely functional.
Reason 4: Like the Gang of Four's Design Patterns, this book now somehow "lives" in the back of my mind (knowledge was deeply absorbed and incorporated into my thinking without conscious study) so that when I encounter situations I can either more clearly identify what's going wrong, and what possible patterns could be applied, in which possible sequences, in order to address the problem(s), or simply refer to this reference book and delve deeper into the issues and solutions effectively and efficiently.
Reason 5: People I have already referred it to have come back to me and been as astonished by it.

Thankyou for supporting!

Agile Project Management - a place to start

Over the past 2 years whenever anyone has asked me "What is Agile Project Management"? or "What is Scrum?" I have been pointing them at Ken Schwaber's talk at Google. Don't get me wrong I am not trying to get into a debate about Scrum, nor about Ken Schwaber, nor even about my Scrum Master Certification.

I do however like this Scrum video as it is a clear and concise summary related (closely) to Agile Project Management that can be absorbed within an hour of time.

Thankyou for supporting!