Month: November 2011

Agile As a Sequential Art Team

Posted by

0

Last time I ended by bringing up the metaphor of the agile team as a team of sequential artists with the Customer in the role of writer. This time I’d like to further explore that metaphor and see if we can find something viable here we can latch onto. So while this is a thought exercise I’m always looking for ways to explain how agile teams work to those not familiar with the methodology. I’m also always looking for ways to improve how our agile teams work. Let’s see where this metaphor can take us…

For the sake of our analysis I’m going to pick the most straightforward form of sequential art, the graphic novel or as it’s colloquially known, the comic book. I’m making an assumption that I don’t need to write a definition here, but if you feel you need refresher here is a link to what wikipedia has to say on the topic.

In order to dig deeper into this metaphor let’s try by defining the different roles in a typical comic team and compare them to an equivalent on an agile development team.

Writer: The writer is the one who owns the story. They define who the characters are, what motivates them, and what they do in the world of the story.

Agile Equivalent: Customer. As stated before, this is our agile customer. They own and define our agile stories. Too often I think people see the Customer as the Editor and place the Architect in this role. Unfortunately this places the Customer in an after the fact role and distances them from the team. We’ll talk more about the role of the editor later and I think you’ll better understand what I mean.

Penciler: Sometimes, though not always, referred to as the artist. This person takes the writers script and gives live to the story. They work closely with the writer and together are typically seen as the creative team of a comic.

Agile Equivalent: All Developers. I’d really like to make a case here that every developer has the potential of playing this role on a project. Remember that in agile we have many stories, and the execution or development of each story each story may be owned by a different developer. In this way each developer has the potential of being the penciler of a story with support from one or more other developers in the following roles.

Inker, Letterer and Colorist: I’ve lumped these three roles together not to diminish them, but rather to set them up as both support and specially roles. Indeed an inker on one store may be the penciler on another. And understanding how the application of certain colors will look in the final print copy is invaluable.

Agile Equivalent: All Developers. Again because agile is many stories, within the course of one project each developer may not only play the role of penciler, but will also play supporting roles for others stories, as their skills warrant.

Cover Artist: This is usually an artist of some renowned. While they may not be a part of the permanent team they are brought in to create the covers of comics. These are usually given more time and attention to detail as they are intended to draw potential readers in and entice them to purchase the comic.

Agile Equivalent: Change Management Specialist. It would be easy to say that this role is equal to a technical specialist brought in to solve some particularly challenging problem, and I can’t argue that this is a valid analogy. However; I think that a more useful correlation is with change management. A good change management plan is the number on away to improve adoption of a system, which after all is the goal of cover art.

Editor: The editor is responsible for the quality of the product. They need to make sure that the work begin done meets the needs of the publishers overall goals, and also help to endure that everything gets done on time. Editors also help to remove roadblocks and sooth artist egos when needed.

Agile Equivalent: Scrum Master. Nuff said.

Art Breakdowns: This role is not often seen in comics as the penciler will normally take on this duty. However; on occasion an artist will be brought in to sketch out all of the flows within a comic. this is usually done in cases where multiple creative teams are weaving a series of stories together. Each team is telling their own story , but this over arching artist is preparing the page layouts and weaving all of the story arches into a seamless whole. These breakdowns are usually rough sketches so as not to override the vision of any one team, and in fact the final art, while adhering to the page layouts will look dramatically different from the sketches provided. In many if not all cases the artist doing the breakdowns works closely with all teams to ensure that each teams vision is respected while at the same time guaranteeing the overall quality of the whole.

Agile Equivalent: I think there are two answers to this. The first is a bit more traditional and really only applies in certain types of projects, while the second tends to be overlooked or out and out dropped from scope, but in my not so humble opinion is potentially more important.

  • Enterprise Architect. In a large enterprise project or when dealing with multiple competing platforms, it is the job of the EA to make sure that all the pieces flow from one to another properly, each performing it’s part in the whole. In some ways this role can also be considered a part of the Editors role as an editor is often a key figure in preserving continuity across story arcs. Think governance and compliance.

  • Experience Architect. This is a relatively new role in the software world, and suffers from much of the same ambiguity that enterprise architecture did a few years back. Some feel it belongs more in the domain of the designer and others feel it belongs more in the world of the business analyst. Personally I don’t think either is truly accurate. This is a role that’s emerging out of a gap in the current skills and roles as we have them defined in software development. I’ll try to post more about the the definition of this role in a subsequent post, but for purposes of this topic, the individual filling this role needs to make sure that all of the various moving pieces come into play in a way that creates a satisfying experience for the user, and that going from one part of a system or application to another is not jolting or abhorrent. This means understanding all components of a system, and understanding how both design and technical decisions will impact the experience.

While this metaphor isn’t 100% accurate I think it offers an interesting slant on the agile team and it’s dynamics. Particularly in illustrating the importance of certain non technical roles. I especially like how it points out the importance of the customer as a vital and active part of the team. To often clients say they understand their role in an agile project, but when it comes time to start work they don’t understand why the team wants so much of their time.

My company uses the slogan “The art and science of winning.” In that spirit I think this metaphor helps point out the fact that the methodology can truly be seen as the art of science as it pertains to delivering software.

Thanks for reading. I know this was a long one. And, as always, keep thinking malignant thoughts.

To Architect Or Not To Architect

Posted by

0

OR… question = (2_architect | !2_architect);

I just posted to a thread on linked in about whether or not you should blow out a full architecture on a project to let the design evolve over time. I’m reposting and expanding may response here because I think there are some important elements to the topic worth consideration.

This is a topic that I’ve seen pop up again and again since I’ve started doing Agile.

The basic premise is that if you’re using sound design principals/patterns, and have a solid understanding of what the customer wants, (Remember you’ve gone through release planning with the customer, and have hopefully developed a solid product backlog) then you can allow the architecture to evolve iteration after iteration. Using techniques, such as refactoring and strangulation, you can keep the code base moving forward without ripping things out and starting over.

At this point let me point you to an article that Martin Fowler wrote back in 2003 called, “Who Needs an Architect?” (I told you this debate has been going on for a while.) In the article he describes the role of the architect within an agile project, and even has a section towards the end called, “Getting rid of software architecture.” Whether you agree with him or not, it is an interesting read, and one of the best arguments I’ve ever heard for not doing a lot of architecture up front.

Personally I always try to do as little as I can get way with up front, in order to allow for future scenarios I can’t see today. I always have an over-arching architecture in my head, but I don’t want to make it real until I need to. That way if new requirements pop up later, the project has not backed itself into a corner that might cause major overhaul. “What do you mean we’re going to deploy all the services as workers in the cloud? We just spent two weeks setting up an application server farm!” is something I hope never to hear because wrote something down on paper too soon.

When I look at the times where I “Over-Architected” a solution, it was usually because I had to have the full architecture documented before the team could write code. As a consultant I don’t always get to do things my way, and this includes the use of Agile. In these situations it can be easy to overthink things, as there tends to be pressure to “Get it right up front,” and “Account for all eventualities.” In my humble opinion this is one of the top reasons projects fail. In cases where requirements are simple, or very well defined, it’s ok, but oftentimes customers don’t really know what they want up front. A good indicator of this is when you start getting conflicting requirements.

If you’ll allow me the metaphor, I like to think of the software architecture as a collaborative art installation, and the role of the architect as one more of chief artist. As chief artist I select the medium we’ll work in, wood, canvas, marble, etc. If we’re working on canvas I will usually step in and take the requirements of the customer and begin to paint in the larger areas. I may lay down a patch of azure across the top of the canvas for the sky, and then work with the other artists to begin painting clouds, birds, balloons, or whatever else is needed. As we reach stories that involve a landscape or ocean, I may decide the placement, size and/or shape. Again blocking the pieces in, then working with the team to fill in the detail.

Now there is a place where this metaphor begins to break down for me, and that is in regards to the customer. In our metaphor the customer is exactly that, a customer, and our installation piece begins to be a commissioned piece of art. The reason that this bothers me is that commissioned works of art tend to be seen as somehow lacking in quality in comparison to art created for the sake of the artist’s own vision. At it’s worst I think this type of commissioned art can be equated to purchasing a painting to hang in your living room that matches your couch and curtains. In our tech metaphor this might be buying off the shelf software, or utilizing inexpensive labor. You tell them to draw a line, they’ll draw a line, and it will be mostly straight. While there is certainly a place for this type of art it leaves me wanting more. So lets see if we can’t fix our metaphor to make it more appealing.

So what if our customer is more than our customer? So what if instead of our band of artists creating just any type of art, we are instead are focused on creating sequential art? We can still keep our artistic mediums open. For example instead of sequential images that tell a story we might install a series of life-sized dioramas along a park trail that reveal the story. By making this simple change we can now put our customer in the role of writer. Our customer has now magically been transformed from patron and bill payer to an integral and active member of the artistic team. Now we’ve got a metaphor we can really work with, and in true agile fashion we’ve gotten there through iteration and a desire to keep our customer integrated with the team.

Next time I’ll explore the metaphor further and see if we can’t iterate against it even further.

Until then, keep thinking malignant thoughts.