In part one of this three-part series on Agile Software Development, we looked at developer practices and how technical excellence can lead to marked improvements in quality. Part one focused largely on the test-code-refactor cycle. Now we'll move on to the next circle out and look at how Agile practices affect things at a team level.
Getting the team working effectively - team practices
Once each developer is working in the tight feedback loop of the central circle, we can examine how the entire development team can work together in a more Agile way. Team level practices are central to Agile, as they show us how the team can work together more effectively and drive technical decisions together. We'll look at this evolution of the team in four increments -- setting the tone, team based code, increasing and maintaining effectiveness and the first moves into a "one team" approach, which includes those outside the immediate development team. We'll present you with examples from 3Q Solutions, a software company that creates wealth management systems and uses Agile methods exclusively.
Setting the Tone - step one
One of the central ideas of Agile software development is that of a team working towards a common goal. While many processes advocate teamwork, Agile incorporates practices that support teamwork and puts teamwork in daily practice. Before moving into the team practices we need to set the tone for the team so they begin to feel more like a true team.
Open workspace
One of the best ways to set the tone for more open, team based Agile approaches is creating open workspaces for the team. This means setting up an area or areas that are open and allow for the maximum amount of communication and collaboration. You want to look especially at configurations that make pairing easier. Cubicles and offices are the antithesis of Agile open workspaces and should be avoided. The open space should also ideally have whiteboards and other design and development materials. In one company Exoftware worked with, the open space area was for work only and had only pairing, integration and build machines. A whole other area was set aside for personal machines with Internet access and phones. If you have the space, this is something to consider, as it helps to say clearly "when we are in the work area, we are working".
Don't underestimate how important an open workspace is for the team -- that is why we have it as a first step. Below is a picture of part of the 3Q Solutions development team workspace.
Note that two large desks (with no under filing cabinets) are pushed together to make the optimum pairing desk.
Collective ownership
Next we want to introduce ideas such as Collective Ownership. This central concept to Agile states that everyone is responsible for the entire system, and that anyone has the freedom to change code. This is an important way of thinking as it focuses the team on the project and ensures a common goal. The other steps presented here along with Pair Programming will emphasise this idea, but it's a good idea to introduce this idea early on.
Simple design
Agile advocates simple evolutionary design, rather than big up-front design. The objective is to design only the parts of the project we know about and no more, then allow that design to evolve over time, which helps increase flexibility and minimise the cost of change.
Taking an example from 3Q Solutions, the customer required a rules engine. Traditionally the team would have begun work on the rules engine that would have taken months to produce and still potentially not get sold. Working with the customer, the team decided to design the simplest system that could possibly work for the rules engine and build a thin vertical slice of it with one rule. This gave the customer what he really needed -- a demonstrable rule -- and ensured that the investment was offset against the time committed. The team was then able to evolve the design from the initial build while maintaining flexibility. Simple Design is a complex area, and the best way to begin to look at this is to get external help.
Critical success factors
- Buy-in -- it is important that the whole development team is committed to trying Agile and the practices within the development team circle. Without this level of commitment it will be very difficult to start and even maintain these practices.
- Communication -- this point cannot be emphasised enough. Ensuring a high level of communication within the team and an understanding of concepts such as collective ownership is critical.
- Pairing -- pairing supports many of the team practices and will strengthen team communication and cohesiveness.
- Facilities -- open workspaces can be difficult without some help from facilities. In certain cases, we have simply made changes when the bureaucracy of facilities has become too much.
- Daily Stand-ups -- This is a brief meeting every morning where developers discuss their work for the day and issues they are facing. They are stand-ups because they shouldn't take any longer than a few minutes.
Leave a comment