Archive for architecture
Rhythm and development (Part 1)
Posted by: | CommentsWe see rhythm all around us. Day and night, awake and asleep, 7 day week, the years, the seasons, and music. Rhythm is very much a part of our lives. When the rhythm of our lives is disrupted we may become anxious or our productivity decreases. I know from personal experience if I do not get my Sunday afternoon nap my workweek is affect adversely.
Rhythm is important to any development process… Rhythm can battle complexity, keep competition off-balance, maintain sanity and predictability for architecture and development teams.
Software Architecture Organizational Principles and Patterns, Dikel, Kane and Wilson Page 73
This is one of the underlying principles of Agile that we are aware of but have a tendency to assume. As you will notice from the above quote this is a principle that is recognized as a good practice for architecture.
What are the benefits of a team getting into a rhythm?
- Predictability
Our customers and stake holders know they will see working software on a set schedule. When the stake holders see the team meeting their commitments with scheduled demonstrations a sense of order comes over the project. - Managing requirements
We can manage many requirement “crises” by instructing the stake holder we will consider the new requirements in the next iteration where the product owner can prioritize the requirement. All new requirements are reviewed so no one feels they are being ignored. - Periodic inspection
Continuous inspection is the mainstay of Agile development. Knowing that we have our customers reviewing our work will make us comfortable in that we are creating software the meets the needs of the customer. - Demonstrations of working products
We have working products that are tested and ready of the customer to use at the end of every iteration. This help guarantee quality. We are “putting the stake in the ground” which helps us to make critical design choices expediently. We cannot get into analysis paralysis if we know we have to deliver working products.
I am sure there are many more benefits of being in a rhythm. But as noted above rhythm is very important in Agile development.
Scaling and Architecture
Posted by: | CommentsOne 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:
- 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. - 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. - 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. - 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?
- 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. - 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.- 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. - Does the code enhance the overall design of the system?
- Is there duplicated code between the teams?
- Where can the code be more efficient?
- Does the code follow best practices?
- 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.