September 2006

Monthly Archive

Consistent Architecture through Facilitation

Posted by Chris Sterling on 29 Sep 2006 | Tagged as: Agile, Architecture

Recently there was an email on the Scrum development mailing list regarding how to keep a common, consistent architecture which is maintained and used throughout multiple Sprints without someone designated as architect. Here was my response:
I would consider myself a software architect with quite a few projects under my belt. I started using some Agile techniques before I knew what Agile, XP, or Scrum were. I ended up finding myself working more on getting teams to collaborate and come to decisions based on good information rather than prescribing a particular architecture approach. As I have come to find out over many years, there are many approaches to architecture (as in design) that can work in particular contexts. Just as OO development and design patterns are not the best way to develop software in every project (such as real time systems and device manufacturing), so to is it not the case that architecture (more than minimal design) is needed.

“Disclaimer”:

—

Before I go sticking my foot in my mouth, the following scenarios are generalized and probably overkill for most organizations. Stick to the least amount of controls that will keep enough chaos for your particular needs. I am working with a company right now in which we are possibly implementing some of what is discussed below. They have an existing “Architecture”-based organization and we are trying to help them become more Agile. I hope that the topics discussed below are helpful in thinking about your organization but if not I wouldn’t be surprised.

—

I run a local chapter in the Puget Sound (Seattle) area of the IASA (Int’l Assoc. of Software Architects) and will be facilitating discussion and breakout activities on how Agile and architecture teams work together. There is more information on this at http://www.solutionsiq.com/iasa.html. There are multiple disciplines within the “Architecture” realm such as Enterprise (more business focused), Infrastructure (more hardware / facilities focused), and Solutions (more application/data focused). Each of these perform a service based upon a perspective of the organization which I believe can fit well with Agile.

“Potentially about the original email”:

—

If the Solutions Architect can be closer to the team (potentially on the team) to help in the development of the product that could be very helpful. We want to make sure they are prepared to be a member of the team and not a special case. If the rest of the team can understand and somewhat agrees with the architect about their ideas then that person will automatically get respect from other team members. It is also good if the architect can be coached on how to incorporate the ideas of others into the design, potentially on less critical areas, to help foster respect across the team.

As for the “not coding” aspect of this, I think this may be a concern overall. I just conducted a training session on TDD where one of the attendees, whom we coached to implement Scrum and Continuous Integration already, wanted to make it clear that design was needed. We tried to make sure it was understood that design was still done, whether it was through the automated unit test code or on paper napkins translated into test code, but that decisions about platform, frameworks, and services may not be needed from the start. We should implement in the simplest form first and then refactor to a desired design which may over time incorporate what is thought of as software architecture design. It was very difficult to get this point across entirely but I believe it can be learned over time.

This may be the situation that you are in. How do you facilitate that learning about keeping good design even though it is emerging throughout the product development life cycle. One way that I sometimes facilitate this is by giving the problem context to the group (possibly the solutions architect group) and have them figure out how they can best work in this model. Allow them to be skeptical of the model and answer their own questions. You may need a coach for this if you do not have somebody who feels comfortable speaking about architecture design and it’s use in Agile development.

—

“To further the Architecture and Agile discussion”:

—

The Solutions Architect is closer to the implementation of products/projects within an organization. They are a good fit to be team members on a particular project, a mentor for teams using new technology, taking tasks on multiple team sprint backlogs (hopefully not all at the same time), and providing communication support to the Enterprise Architecture group (feedback loop for potential best practices, issues with vendors, etc…).

An Infrastructure Architect “may” be close to the implementation teams at times and have their own long-term vision, short-term goals, and possibly running multiple Agile projects. They need to align closely with the teams, Enterprise Architecture group, and possibly product teams to make sure the vision and goals of the Product Owner and supporting cast (SME, customers, analysts). We still need to think about deployment in large organizations in order to keep it manageable, supportive of product delivery, and cost effective.

The Enterprise Architect tends to be a helper in the translation of product vision into attainable goals. The problem with many implementations of EA within organizations is that it is quite prescriptive in managing vendor, platform, processes, and data choices. This can put a strangle hold on the potential output of the entire organization and is a large burden on the EA group itself. In my experience, an EA may be a good choice as the Product Owner mostly in large projects. They understand how to remove potential integration dependencies, how business functions with technology, and the higher level picture of the business. They can help in the discussing all of these important items with the implementation teams to help them in making better decisions with a bit of Product Owner training and further understanding of Agile values and principles.

—

I am quite interested in hearing other people’s views on this and any constructive criticism about the content. This topic can get quite deep and have so many potential scenarios that I have discussed here but if we keep our eyes on the Agile values and principles we can figure out how we can work together better. Thanks.

No Comments »

Need-Driven Design as an Integration Strategy

Posted by Chris Sterling on 25 Sep 2006 | Tagged as: Agile, Architecture

As we develop software, it is common to design before we code. On average, I have found that the more time between when design occurs and the actual implementation is developed, the more unexpected detrimental effects surface. A common reason for design problems when integrating external dependencies into a project is that the project team was using what was available from the integration dependency instead of deciding on what they needed and mapping that to a solution. Design by contract made a step in this direction by supplying the idea of a contract between a supplier and client.

Over the past few years, we as an industry have started turning a corner towards a more business driven approach to software development through Agile values, principles, and methods. As we develop software we must take the same business driven approach to design. As anybody who has used Test-Driven Development (TDD) knows, design is a continual part of our development cycle. We design our software through the creation of well defined criteria (tests) and refactor our code mercilously to an acceptable design. Another interesting aspect to TDD is the YAGNI (You Ain’t Gonna Need It) principle which states that one should never add functionality until it is necessary. Instead of designing towards the use of an external dependency we should only integrate upon need. This is why I have coined Need-Driven Design as the business driven approach to software integration design. Need-Driven Design has the following steps:

  1. Only add external dependencies to your project when the value outweighs the integration costs
  2. Integrate external dependencies into your project at the last reasonable moment
  3. Define a well defined interface for interactions with systems which may be out of your project’s full control
  4. Develop executable criteria for expected interactions with the an interface implementation
  5. Create integration criteria which meets the expected interface intent and integrates with the external system dependencies

An example of this approach to software design is a project which needs data from an exposed web service. In this example, the web service returns an XML represntation of a customer with the following information:

  • Customer Name
  • Company
  • Address
  • Job Title
  • Phone Number

The business has informed us that this external system is the most up to date view of our customers and therefore must be used by the application. This satisfies step 1 of our Need-Driven Design approach. Next, we should develop enough code to know that we need to interact with the external system and where that interaction is going to occur in our application which satisfies step 2. The business case for this example is that our end users must see the customer name, company they work for, and a phone number to reach them at. For this business case, we define an interface that returns only the customer name, company, and phone number which as you can see is less information than the web service returns. After defining the interface to satisfy step 3, we should create executable criteria for interactions with the implementation of this interface and our application. We can use mock objects to do this through the setting of expectations across multiple tests with variable response message signatures. This may lead into the development of validation functions, exception handling, and defined results packaging. This executable criteria from step 4 can now be used as the intent for consuming the exposed web service. Automated integration tests should be developed as criteria for implementing the defined interface for external web service consumption. This will not be a replica of the interface tests defined using mock objects. These tests should make sure that the consumption of the external system dependency maintains the integrity of the defined interface intent described in those tests.

By driving our integration strategies through the steps defined in Need-Driven Design we can decrease integration costs, reduce coupling to external dependencies, and define business driven intent into our applications. Integration can be a headache in development, design, testing, deployment, and operations. Through the steps in Need-Driven Design, we can assure those that pay for maintenance of these integrations get the value they need.

2 Comments »

A New Blog Focus

Posted by Chris Sterling on 24 Sep 2006 | Tagged as: Agile, Architecture, Scrum

For quite a few years now I have been working in the software architecture and Agile space which may seem like an oxymoron to some. I got asked the other day, from somebody who knew me for both, what type of reaction I got from the XP community members when I brought up the word “Architecture”? Honestly, I had gotten some rolling eyes, criticism, and the usual YAGNI blurb. It hasn’t affected what I am doing and I keep closely aligned with the Agile Manifesto and the Principles behind it. So how can I work with anything regarding software architecture and still be “agile”?I have found that in some cases the guidance provided through higher level views of systems has enriched the product delivery. Definitely it is not needed in every case and I will freely admit that the “Ivory Tower” approach to software architecture is mostly misguided. There are the cases in which you do have a need for infrastructure and enterprise architecture. But instead of the “Ivory Tower”-type teams, these groups could be more in line with the product delivery cycle. I was amazed the first time that I had an Enterprise Architect work as the Product Owner of a Scrum project. The EA had a great ability to manage communication from business customers into the product backlog. The EA could help breakdown multi-team work with minimal dependencies and integration points. The EA was able to have great negotiations with the team regarding new information learned during a sprint. I was amazed at how well it worked. Then I thought about it and these are the skills that many of the EAs I have worked with and respect had already.

Along with EAs, the Infrastructure Architect is still needed in certain contexts to help in large scale deployment configurations. I have heard of instances where this team can run Agile projects and incorporate Lean principles to remove waste such as duration to deliver in the supply chain. Instead of taking the approach that “this is how things are” we can decide on how things “should work” and then work towards that. If it takes 2 months to procure a server for our staging environments then we should be asking ourselves why? What would stop us from being able to deliver on these server requests in 1 week? Sometimes we don’t take a step back and look at these options. If we do, we might just find out that we can increase the productivity of our entire organization.

I have been holding these two spaces, Agile and Architecture, away from each other for the most part but I am going to change that. Agile and Architecture are compatable and I will continue my quest to promote my findings on this topic, good or bad. Just remember that I am not speaking about the traditional Architecture role but rather what I have found as an Architect that works. An Architect is not a role which is the “know it all” in designing an application for teams of developers. Prescriptive approaches to working with development teams can be characterized as intrusive and misguided. We must understand how we can help in the true guidance of a team doing their work and delivering on goals.

No Comments »

And Then It Was Over…Agile 2006

Posted by Chris Sterling on 24 Sep 2006 | Tagged as: Agile

My time in Minneapolis was amazing with so many great moments that I found myself reeling as the week ended about what I would take away. I thought that I better get some of what I thought was important into a blog entry before it slipped too far out of my mind. Here is an overview of my experience at the Agile 2006 Conference:

  • Scott Ambler on the Agile state of the union

I thought that some good points were brought up in this framing of the current Agile community. I am still quite skeptical of AgileUP and MSFAgile and their prescriptive nature but it is good that our large corporate software leaders are understanding the shift in market to Agile values and techniques.

  • Tamara Sulaiman, Brent Barton, and Thomas Blackburn on Agile EVA

Two of my colleagues, Tamara and Brent, gave a great presentation on their “Agile EVM in Scrum Projects” research paper. The ability to calculate earned value from existing Scrum data is important for organizations which use earned value as a decision making variable. It is great to work with such intelligent and innovative people here at SolutionsIQ.

  • Jennitta Andrea on Functional Acceptance Testing: The Essentials

Many of you reading this may not know that we at SolutionsIQ have open sourced a great functional acceptance testing tool called StoryTestIQ based on Selenium and FitNesse tools. The creation and usage of this tool with our customers has shown to be incredibly valuable. Getting a true “definition of done” for our user stories in an executable tool allows for quick regression of functionality as seen by the end user and removes much of the interpretation of functional specifications. Jennitta did a great job of explaining the nuances of creating and maintaining functional acceptance tests.

  • Todd Little on Context Driven Agile Leadership

Even though I did not understand what this talk was going to be about I found the name alone was convincing enough to get me in the room. Once in I was glad that I came. Todd spoke of what they called the “Houston Matrix”, loosely based on the “Boston Matrix” developed around market growth and market share, to identify the types of projects within their company. The types of projects fell into 1 of 4 groups:

  • Colts - high uncertainty, low complexity - simple, young projects which need agility and tight teams
  • Bulls - high uncertainty, high complexity - need agility to handle uncertainty process definition to cope with complexity
  • Cows - low uncertainty, high complexity - complex, mature project which needs defined interfaces
  • Skunks and Dogs - low uncertainty, low complexity - just use core practices and easy to manage

    There was good information on determining where your project would fit into the “Houston Matrix”. Also, there was a great video clip within the presentation revolving around a karate fight between a man and a cow. Great stuff!

    • Jean Tabaka on Homer’s Odyssey or Her Life as an Agile Consultant

    For those of you who are Agile consultants, I think that this presentation would likely hit home for most of you. Jean drew comparisons of character in Homer’s Odyssey to situations and people she has ran into during her Agile consulting experiences. I won’t go into detail since you must see the presentation to get the value from it but the characters were Sirens, Laestrygoneans, Poseidon, Suitors of Ithaca, Leucothea, and Argus the dog. Jean has a great presentation style and this talk allowed me to reflect on my past few years and how situations had turned out for good or bad.

    • Agile Coaching in British Telecom: Making Strawberry Jam

    It was good to hear of large organizational rollouts of Agile software development. At SolutionsIQ we have transitioned our professional services division into an Agile organization based on Scrum and Agile software development practices such as TDD, continuous integration, and pair programming. Laura Waite impressed me in this presentation and then later on impressed me more with her vision of what Agile is and what it will be.

    • Mike Cohn on User Stories for Agile Requirements

    If anybody has read either of Mike Cohn’s books, “Agile Estimating and Planning” or “Users Stories Applied: For Agile Software Development”, you probably appreciate the concepts that are described for helping Agile teams succeed with planning for their projects. I could reiterate the ways to develop good user stories but I thought the most interesting concepts were not described in the presentation slides. Mike went a bit off topic to answer a question. While doing this he brought up the following:

    • Abuses stories - stories from the perspective of somebody being harmful to your product. This has value for stories for cross-cutting concerns such as security.
    • Wild stories - I paraphrased what he called them but these are stories which can help to innovate on a project. In Mike’s example of this, the Palm OS folks wrote a story from the perspective of the Pope. What would the Pope need from our Palm OS? These stories may not ever see the light of day or show direct value but they do start conversations which can lead into great innovations.

    It was great to meet Mike after being so influenced by his books. We have used his techniques very successfully at SolutionsIQ.

    • Monica Yap and Lance Young on Discussing the Need for Agile Certification

    Another colleague of mine, Lance, and his wife, Monica, facilitated a discussion using the “Fishbowl” discussion format. I thought it was quite effective for discussing the topic of Agile certification. There were a broad spectrum of opinions on this topic. My personal opinion is that we should not do any type of Agile “certification” because I think this will go against the principals and values of the Agile Manifesto. I could go on about this but I think the best thing that came out of the discussion was an action item to create a mailing list to discuss hiring techniques for Agile teams. I will post a blog entry about this new list if and when it becomes a reality.

    • Scott Ambler on Refactoring Databases: Evolutionary Database Design

    I can’t think of a bigger deterent to Agile software development than the existing relational database market. Of course this is my own personal opinion but I have found too many projects which get bogged down in relational database details which have little effect on business value. I do believe we need to bring our database administrators and data architects into the Agile world though. Those that handle the data must be agile in order to help business succeed over time.

    • David Hussman facilitation of Community Reflections

    I have great respect for David since I saw him present on Agile topics at No Fluff, Just Stuff symposium last year. In fact, I see those talks as the catapult for me to put more emphasis on agility in my projects. Upon entering the room I sat down at the first available chair that I saw. As a small chuckle came from the audience I noticed that I was sitting in a “fishbowl” discussion and had no idea what was being discussed yet. The discussion was incredibly deep regarding different topics presented at the conference.

    • Esther Derby and Diana Larson on Tuning Up: A Team Leader’s Guide to Retrospectives for Agile Development

    Esther and Diana are amazing ladies and are exceptionally skilled in facilitating Agile retrospectives. They have a new book which just came out called “Agile Retrospectives: Making Good Teams Great” which is good reference material for exercises and activities to help provide value in retrospectives. It was fun to actually run through a project and retrospective all within the 90 minute session. I picked up some good exercises and activities for use in retrospectives that I facilitate in the future.Some of the best moments for me at the conference were not in the sessions. During lunch one day I sat with Ward Cunningham, inventor of the wiki and Fit, showing him StoryTestIQ and how we use it with our customers. Ward is a great guy and we talked for well over an hour. It is great to speak with a visionary like Ward and hear his thoughts on our community and tools. While out boozing I ran into David Hussman and I thought we had a great talk about Agile coaching, some ideas I am working on which I am tagging “Building Integrity In”, and of course some non-software stuff like kids and family. He has a 3 year old like myself and we had some interesting stories to tell.

    Overall, the conference was amazing. I will definitely be a regular. I can’t wait for Agile 2007

    1 Comment »