Feb 25, 2006

Some recommended reading

We all need to keep improving ourselves, our skills and our knowledge. I've just finished reading a few tech books and I thoroughly recommend them.

1. Head First Design Patterns

The book is fantastic - I've done a bit of work with design patterns in the past but this book really helped to put them in context, and the way the information is presented is very conversational, fluid and light while at the same time driving the concepts home. It's very much a "both sides of the brain" book, unlike some of the more onerous tomes that try to explain patterns in a generic text-only manner.

It's so good that I've just purchased a bunch of copied for the team.

2. Agile Project Management with Scrum

I posted earlier about some of the problems I encountered implementing Scrum. This book really helped me reassess what I was doing wrong and showed how I could improve what I was doing.

At first I was a little thrown out since there isn't a great deal of instructional "do this" information. Instead the book consists of a range of different scenarios, what the issues were in the scenario and how scrum was applied to produce a positive result.

It also covers some of the mistakes and errors that can be made while implementing scrum. If only I had found this book earlier!

If you plan on implementing scrum, grab this book and read it first. It will help get your mind into the right way of thinking, and give you tips on how to communicate your changes to the rest of the business.

Feb 23, 2006

The joy of management

If you've got an evil streak there are some parts of management that are fun.

My staff have finally found this blog and have read an entry further below about their technical skills. I'm getting an good deal of enjoymenty over the fact that none of them know if I'm talking about them or not.

I wonder if I should post about a design patterns exercise I asked them to do recently. Since I know they team is reading this I wonder if they want to comment :-)

Feb 10, 2006

Organizational change and Scrum

Over the last 6 months I've been trying to bring about organizational change in order to improve the product development process, change how product development interacts with the rest of the business and to improve the productivity of my department.

As you would expect there were two central ideas to this strategy. Firstly I needed to change engineering practices and secondly I needed to change the management of those practices. It was time to kiss goodbye the traditional waterfall/gantt chart based project management time to move to agile methods.

I started by migrating the team to agile development methods (based on the fundamentals of extreme programming) whilst still retaining the documentation needed to support our ISO accreditation. This has been quite successful. The team understands the need to improve, and the actual methods of producing software are fairly easy to alter since it is an internal process (ie internal to my department). The only areas I still need them to improve relate to refactoring and code reviews. This will come with time and I am quite happy with things being at the stage they are at this point in time.

I've also been changing the management of the development process to Scrum. I tried to do this gradually for a number of reasons, the main one being that I was new to the organisation and didn't want to upset the apple cart or be seen as the newbie trying to change something when they didn't understand the corporate culture.

Well, suffice to say, my attempts at the gradual adoption of scrum have been a complete disaster. Why? Because I only implemented portions of Scrum under the thinking that I need to give people time to get used to the new methods before implementing more change, and that too much change too quickly would upset the organisation. For example, I instituted the daily meetings to foster open communications between the team and I set up the prioritisation of tasks (the backlog) so that the other areas of the business were aware of what was happening.
I moved to regular releases of the system - down to a 3 week period instead of 12 months - and because there was no clear product owner I fulfilled that role as well as taking on the role of ScrumMaster.

Instead of instituting a change for the better I managed to institute anarchy. Filling both roles of ProductOwner and ScrumMaster led to conflicts of interest over what was best for the company over what was best for the team - I broke the rules of Scrum myself by allowing constant chopping and changing of direction based on need and failed to communicate reasons for change with the rest of the business. Obviously these failures are my own fault and lack of time and business growth compounded the errors I was making.

Unfortunately by not enforcing the rules of scrum, I allowed ad-hoc requests to be actioned, allowed staff to be pulled off for other non development work and as a result failed to get the team to own the process and to own the delivery of results.
I was doing the classic "tell you what to do and tell you when to do it" instead of letting the team self manage.
Effectively the daily meeting was a "report activity to Richard" session and was not acting as a team synchronisation meeting. Delivery commitments were estimates only with no repercussion for failure. The business saw the product backlog as just another way of tracking outstanding work requests but having no other value to the business.
The worst result was that without the team owning the product or the process they felt no responsibility for delivery. "Richard will tell me what to do next" was the common thought, and that was the last thing I wanted. It meant all responsibility was on my shoulders, made me the bottleneck for performance of the department, and prevented me from being able to scale up the team size.

As an aside to this, the organisation itself hardly changed. They still worked as before, promising customers unrealistic dates and expecting me to meet them. I failed to get through to the stakeholders that the team can only produce as much as they are willing to commit to. I failed to communicate the rules of no interference to them, and that it's "what to do, but not when to do it". The stakeholders were still pulling priorities all over the place and as both product owner and ScrumMaster I had to try and balance all of these competing issues.

In a nutshell it was a disaster.

If you are planning on implementing Scrum you need to do it treat it as an all-or-nothing change. I talked with my CEO about organisational change and the mess that I made and he told me that if I wanted things to change I had to "go to war with the company. State what I wanted to do and take no prisoners in implementing the change." The only real benefit of the anarchic state things were now in was that any change would be an improvement and likely to be received well by the organisation.

Learn from my mistakes. Scrum cannot be implemented in a piecemeal manner.

Update: Find out what things are like 9 months later