From the Agile Transformation Trenches

Agile Scope: A picture and a few words

A couple of weeks ago, I was peer reviewing some work by a colleague. I was struggling to communicate what was and what was not covered by the popular agile processes  - what I call the scope of the process. For example, Scrum and eXtreme Programming essentially focus on a single small, cross-functional, development team. At a fundamental level, they do not cover larger teams or projects or organizations consisting of many small dependent teams. They say little about how customers or product owners decide on the business value and priority of the user stories or backlog items they create. Neither do they say much about working with a formal testing organization.

While there are plenty of suggestions and some popular approaches to extending Scrum and eXtreme Programming to cover multiple dependent teams, they are just that; extensions to the original core set of rules or practices. 

Anyway rather than try and explain this by waving my hands around I resorted to drawing a picture to communicate what was in my head. Although very simplistic, it seemed to help so I thought I'd share it. If I have done it correctly, you should be able to click on the image below to see it full-size (legibly in other words) in a separate, pop-up window.

The circles represent perpetual activities all running concurrently taking input off lists (or queues, backlogs, or whatever) and generating results on subsequent lists/queues/backlogs.

The green dashed box represents the scope of Scrum/XP and supporting tools like Borland TeamFocus today; sets of small independent teams working from their own backlogs.

The red dashed line represents the space where more and more organizations that have been using agile successfully for a while seem to be focusing. In these organizations individual development teams are working well. The result is that inefficiencies in working practices around the individual teams are starting to show up. This enlarged scope is closer to that covered by an approach like Feature-Driven Development (FDD) with broader demand management aspects informing the individual team product backlogs and collaboration across teams around an overall domain and technical architecture where appropriate. It is the space I see the combination of tools like Borland Team Demand and Team Focus being applicable, for example. Of course, we can't forget Borland Togetherfor recording and communicating the overall architecture as it emerges from collaborative design sessions.

Outside of the red dashed line are the activities that trigger new projects or changes to existing systems, and my colleague's interesting contention that this should all be inspired from a business process improvement perspective. He asserts that all IT development work should be about improving one or more steps in a process somewhere and if we understand our processes or our customer's business processes well enough we can use that knowledge to identify and prioritize development work. For example, Borland as a software tools vendor needs to understand the end-to-end processes involved with developing and delivering software. Identifying pain points, bottlenecks, opportunities for increased efficiency, etc,  in those processes enables us to deliver genuinely useful and easy-to-use products.

What the picture does not show explicitly is the current interest in more sophisticated agile testing with tools like the Borland Silk suite. The idea is included implicitly in the Design, Build and VERIFY activities.

Also not shown are the measurement and analytic aspects that I view as another dimension to the picture entirely.

All suggestions for a better picture would be gratefully received.

He planed and worked that wood until he made silver from the yellow pine

Craftsmanship has always been widely admired and appreciated. Anyone can pick up a paintbrush, but few compare to Monet; a wooden chair from Walmart will provide a place to sit, but the beauty of handcrafted custom furniture is undeniable. There is a movement in software to try and capture some of this magic, but with the large amount of truly terrible programs and outright project failures this crusade clearly hasn't yet taken hold. Given that, is there anything more satisfying that completing a project? Whether it is woodworking or software, that feeling of a job well done is beyond compare.

One of my teams recently got to experience this euphoria: Borland TeamDefine 2009 was just released to the market for the first time. TeamDefine is simulation software that helps people flesh out requirements early in the cycle, eliminating time-wasting rework. Agile is all about short feedback loops, so a with tool like this which can deliver both rapid prototypes and gather comments from a wide variety of sources, those feedback loops can get even shorter. Most agile stories are a collection of words with an occasional screen shot; if a picture is worth a thousand words, a simulation is worth a thousand pictures! The earlier a team knows it is building what the customer really wants, the more likely they are to build well-crafted software.

Our team is now using our own product to explore stories, which is very cool. I've been on a lot of different software troupes, but the number that actually got to use what they built as a part of their job is very small. We have had a lot of fun building TeamDefine, and it has developed into a product of which we are unabashedly proud (and are having a lot of fun using). Check it out for yourself by watching the (funny) video below and downloading a free trial. Play with it and let me know what you think!

Post title is a lyric from Walnut Street by Walt Wilkins.

Agile and Object Modeling? Surely Not!

I have been told unofficially that my submission for a session on managing large product backlogs at Agile 2009 has not been accepted.  That is a bit of a shame. The topic seems to resonate with many teams that have been successfully doing Agile for a number of years.

However, I am not too downcast because I have also heard a rumor that two sessions on ‘modeling in color’ (or ‘modelling in colour’ as we call it in the UK) have been accepted. Given the choice, I probably would have chosen a ‘modeling in color’ session over a backlog management session too. Much more fun. In fact, I may end up co-presenting one of them if David Anderson gets his way.

For those that have not met it before, ‘modeling in color’ is an object modeling technique developed by Peter Coad in the late 1990’s. It involves categorizing classes representing problem domain concepts into one of four ‘archetypes’ and employing proven patterns of these class archetypes to rapidly construct object models of the problem domain.

Talking about object modeling in an Agile context is often contentious. For many Agilists it conjures up memories of elitist analyst/designers wasting months creating incomprehensible diagrams in purpose-built modeling tools and then throwing the so-called models and next-to-useless generated skeleton source code over the wall to developers who generally ignored it – the antithesis of Agile in many peoples’ eyes.

Although, ‘modeling in color’ models can be constructed in UML modeling tools like Borland Together, the favorite ‘modeling in color’ tool is a packet of four-colored sticky notes, and the recommended means of constructing a ‘modeling in color’ model is in cross-functional, collaborative sessions.

Before I get into too much trouble with the Borland Together team, I must point out that Borland Togetheris my 'very favoritest' software tool for object modeling and one of the main reasons I joined Borland. I especially love its LiveSource technology that I believe makes it one of the best modeling tools on the market for Agile teams.

If you cannot wait until Agile 2009 to find out more about modeling in color there are some old introductory notes written by yours truly hanging around odd places on the net such as:

• Object Modelling in Colour
• A New Beginning
• Accelerated Analysis

There is also a book by Peter Coad on the subject, Java Modeling in Color with UML. Don’t be put off by the title. There is very little about Java in the book and only a very small subset of UML is used. However, the writing style is a little unusual so worth flicking through chapter one available here to see if you like it before spending hard-earned cash on it.

Putting People First in the Transformation

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.