Justin York – Simdesk

“Del's leadership was instrumental in bringing agile methodologies to our development team. While transitioning to scrum, I often consulted with Del about how to handle things in the scrum framework. Once our team was fully running on scrum, I felt that we were at least twice as productive as we had been in the past.”

Matt Willson – Pervasive Software

“As Delmar's manager for over a year, I was very impressed with the simplicity of his designs, the quality of his software, and the tenacity he brought to problem solving, especially customer issues. Delmar provided strong leadership for the developers who worked under his tutelage.”

Steve Mook – Pervasive Software and Simdesk

"Del is experienced,enthusiastic and tenacious - an excellent team lead with expertise in UI design and development and Scrum project management. He is willing to learn new technologies, challenge assumptions, take risks, and be accountable for results. His skill and leadership would benefit any team that seeks to improve its ability to deliver value to customers and to the business."

My Agile Experience

What was really exciting was to see the Scrum methodology adopted company wide at Simdesk. Because of the success of our team I was able to train and mentor other team leads, managers and corporate executives to use Scrum. This lead to increased productivity and better communication among the teams, support, product managers and upper management. Goals are well defined and consistently meet.

Tags

adoption architecture books build change collaboration deploy design integratoin learning management performing productivity quality release safety sprint team Team Member team safety training user stories

My Reading List

Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition (Addison-Wesley Signature Series (Cohn)) by Lyssa Adkins (Paperback - June 14, 2010)

Available on safaribooksonline.com as a Rough Cut.

Succeeding with Agile: Software Development Using Scrum [Book] by Mike Cohn - Addison Wesley

The Dip: A Little Book That Teaches You When to Quit (and When to Stick) by Seth Godin

Fierce Conversations: Achieving Success at Work and in Life One Conversation at a Time by Susan Scott

Collaboration Explained: Facilitation Skills for Software Project Leaders - Paperback (Jan. 16, 2006) by Jean Tabaka

Agile Product Management with Scrum: Creating Products that Customers Love (Addison-Wesley Signature Series) Roman Pichler

Practices of an Agile Developer by Venkat Subramaniam and Andy Hunt - Pragmatic Book Shelf

Sep
01

Scaling and Architecture

By Delmar Hager

One of the concerns about Agile has been how to scale in a large enterprise system. How do you coordinate teams and have them provide a product that is based on a consistent architecture?

Some approaches are as follows:

  1. Do a big design up front and design the architecture that everyone has to follow
    Well BDUF do not withstand the test of time. We know any architecture will be modified as soon as we start programming.
  2. Have an architecture review board
    This ends up being a bottle neck in the process. These architects are not really doing the coding so they do not always understand the issues that are being faced.
  3. Do nothing and let the teams be
    Well this is tempting and just let the architecture emerge from each team. But you lose consistency really fast. Also, the individual components do not work together well.
  4. Use the Scrum of Scrums meeting
    This is a meeting that focuses mainly on inter-team impediments. We have to remember to keep our meeting focused on their agenda and not to try to do to much in one meeting.

So I propose that a formal community of practice is the answer to this problem. We must recognize that teams left to their own will approach architecture is different ways. This is of real concern on a large project with multiple Scrum teams.

What is this community of practice and what do we expect of it?

  1. A weekly meeting with one developer from each team
    This has to be an regularly scheduled meeting. It can range in length from 1 to 2 hours. I recommend that the developers be rotated who represent the team and  make this a monthly rotation to keep consistency.
  2. Each team  presents the code they have developed during the last week
    This is a high level review of the code. At this time the architecture of the code is reviewed.

    1. Does the code follow best practices?
      There should be automated tools to help enforce best practices. So the question here may be one of accountability.
    2. Does the code enhance the overall design of the system?
    3. Is there duplicated code between the teams?
    4. Where can the code be more efficient?
  3. Each team is responsible for refactoring their code
    The changes will be agreed to by the community and implemented. With this continuous inspection the architecture can be refined and adhered to.

One of the guiding principle of Agile is continuous inspection. The community of practice is a necessary meeting when working with multiple teams. It will scale in a similar matter as a Scrum of Scrums.

Categories : Agile