Hi! I am Stephen R. Palmer, a principal consultant at Borland (the middle initial helps separate me from the multitude of other Stephen Palmers on Google and Yahoo, etc.). My work at Borland revolves around two main themes, model-driven software development and agile process coaching. My interest in these areas really started when I worked as the development lead on a major project in Singapore in the late 1990’s.The project was the first to use Jeff De Luca’s Feature-Driven Development (FDD) model-centric agile process and Peter Coad’s ‘modeling in color’object modeling technique. In addition to the privilege of working closely with Jeff and Peter, the project team also included other agile practitioners like Paul Szego and David Anderson.
More recently, I have written a book about FDD, worked with enterprises developing model-driven service-oriented architectures, and coached teams adopting agile processes based on Scrum (I am a Certified Scrum Practitioner) and Smart Agile.
One team I coached this year was a large defense client. The client was keen to see if an agile approach could improve their productivity and give management a better handle on the status and progress of projects.
The agile manifesto states that it values “Individuals and interactions over processes and tools”. It puts people and the ways they work together at the center of things. Processes and tools support these collaborations. For organizations undergoing an agile transformation, this ‘people first’ idea is proving useful in introducing and establishing agile practices.
In nearly twenty years of working as a developer or consultant, one thing I have learned is that simply deploying a software product or mandating a particular process rarely produce the desired transformation in the way people work. It is all too easy for people to continue applying the same thought processes and working practices while using the terminology of the new tool and process. ‘Play it again, Sam! … but this time call it something different.’
This is not something particular to agile approaches. I have seen the same thing happen when introducing UML modeling tools as a replacement for generic diagramming tools, requirements management tools for monolithic requirements documents, and configuration management tools for basic version control of source code. A shift in paradigm needs more than a switch in technology. Those old enough to remember the switch from structured programming languages like Pascal and C to object-oriented programming languages like C++, Java and C# will remember that for a long time, developers simply used these new languages in much the same way has they had the old ones. What we needed to realize the benefits of these new languages was a change in the way developers thought. The programming languages supported this new way of thinking but they could not cause the change. The same is true of the shift from traditional software development management to agile approaches.
For my defense client, the ‘people first’ principle has worked well. We decided to concentrate initially on establishing the values, principles, and practices of a Scrum-based approach within the team, postponing any discussion about the use of software tools to manage the project in which they would be piloting the agile approach. Instead, we started with index-cards and a large corkboard.
The idea was for individuals to get a feel for the new ways of working without having to worry about operating a particular software product. With this approach,the team was able to concentrate on establishing the new ways of communicating and interacting, instead of learning the idiosyncrasies of a particular user interface.
Once the team had two or three iterations (sprints) under their belt we started to discuss how software tools might help improve management of the project. For example, one member of the team was having difficulty because he worked from home - in another country - part of the time. He had to attend standup meetings by phone, call or e-mail his daily updates for the corkboard to the scrum master, and so on. Another problem this team had was the growing size of the backlog. The product owner was struggling to manage the stories coming in from multiple different sources. Because we had established the new way of thinking, the selection of tooling focuses on addressing real problems experienced by the team.
From a vendor’s perspective, it might seem counter-intuitive not to push your product hard from the start but it actually makes considerable sense. It is all too easy and common to blame software tools for frustration caused by lack of understanding, bad communication, and poor process definition. Agile transformation programs are no different. As a vendor looking to establish a lasting relationship with a client, you do not want to see a process-improvement program struggle or fail. You certainly do not want your products cast wrongly as one of the causes of that struggling or failure. And yet, ‘Play it again, Sam!... but this time call it something different,’ is likely to happen if a tool is viewed as the key to transforming traditionally managed teams into agile teams.
It is not a coincidence, therefore, that all consultants in Borland UK are Certified Scrum Masters or Practitioners. We have recognized that for us to be successful we cannot simply throw our products at people and expect them to transform the ways they work. We have to help change the way people think if they are to realize the larger benefits from using our products.
Comments