Tag Archives: agile

SDLC

The Importance Of… Process

Early this year, Jesse James Garrett tweeted about process:

This appears to contradict the title of this post, so to give you some more context, I should explain that Adaptive Path is a user experience design and consultancy firm, and show you followups and replies in the twitter conversation that followed:

From a user experience consulting and design perspective, this makes perfect sense – analysing what each particular customer and their users need, and how they interact, will by necessity be different every time. However, it also hints at the inherent complexity that you will sometimes find in web application development. Because from a software development perspective, you need to be Schrödinger about process.

To clarify: at a high level, you need to ruthlessly follow the software development process – gather requirements, design, implement, test, release, repeat. Sometimes, there will be pressure to skip one of the steps. For example, starting implementation without designing first. As I wrote last week, this will cost you. Similarly, in Agile environments, and at a lower level, there is sometimes pressure to change the definition of a Sprint once started. This misses the point of an Agile approach – it is between Sprints that priorities should be changed, and the incremental iterations will produce the desired result. Changing priorities within a Sprint will confuse the team or corrupt work allocation, potentially elongate the Sprint delaying the release, or even produce unreleasable code – it moves you away from “Release Early, Release Often”.

At the same time, you must constantly refine, or change, your process. In Scrum, this is done at the Scrum retrospective, by asking what went well and what could be improved. The theory is to continue doing what went well, and to change or avoid what didn’t. The complexity I mentioned comes into play here. There needs to be context to what you continue to do, and what you stop doing. If implementing a design from a third party didn’t go well, the answer is not necessarily to avoid third party designs altogether – it may be that you need to avoid that particular third party, or that you need to discuss the design requirements with third parties, or any number of possibilities particular to the situation.

Different aspects of product development will necessarily have different processes for achieving their goals. In web application development, requirements gathering of the design, functionality, architecture, and user experience/acessibility/usability of the product could all have different processes. Coordinating the implementation aspects and processes is logistically complex. If the processes which are in place are not followed, it is entirely possible that that coordination will be lost, and your team will end up at a standstill.

Photo by Matthew Burpee via flickr.

Cross-functional Lego team

The Importance Of… Cross-Functional Teams

In this series of blog posts I will be exploring what I feel are some of the important aspects of software development management, particularly in relation to web application development.

A cross-functional team is generally defined as a group of people with different expertise working towards a single goal or objective. Within software development, this means a team of people who will collectively hold all the skills required to develop, build, and deliver the product. For example, when developing a web application, you would want the development team to have expertise not just in coding in the programming language of choice, but also in databases, systems, usability, UI/UX/front-end design, front-end development, testing, technical writing, and so forth.

The common single goal and nature of cross-functional teams make the greatest advantages to the approach seem fairly self-explanatory, but difficult to describe. Perhaps Mary and Tom Poppendieck summarised it best in their book Lean Software Development. They described seven types of waste in software development, and cross-functional teams can help in all of them:

  • Partially done work, or work which has not yet been delivered. For example, work which is yet to be tested. Cross-functional teams minimise the effect of this by ensuring no external dependency – continuous testing can take place, and in an Agile environment delivery is made at the end of each iteration ensuring partial work is not left waiting.
  • Extra features, or providing more features than have been requested. This is particularly pertinent when comparing Waterfall and Agile methodologies – in Waterfall this will not be apparent until delivery, whereas with Agile methodologies there will be more opportunity to act. A cross-functional team can help by providing domain experts who can assess when to stop working on a feature.
  • Relearning, or reinventing the wheel. A cross-functional team can share knowledge and prevent the team from working on a problem which has already been solved.
  • Hand-offs. Handing off work to a third party will suffer from two problems: the inevitable documentation, and a potential degradation of knowledge. Within a cross-functional team, less documentation will be required as there will already be prior shared knowledge, and there will similarly be less room for misunderstanding. All this will lead to fewer delays.
  • Delays. As alluded to above, cross-functional teams will reduce delays in communication and external parties, but also those due to, for example, differing priorities.
  • Task switching. Interruptions can be minimised when work can be coordinated within a single team, without external dependencies.
  • Defects. Not just bugs, but misunderstanding the functionality and delivering the wrong thing. A cross-functional team is better suited to defining the functionality, and involvement from all team members means better test coverage.

There is a certain amount of disagreement on whether Scrum should include specialists in defining a cross-functional team, or whether cross-functionality should be achieved by having team members work in areas outside their area of expertise. In practical terms, I’ve found it to be a little bit of both, but either way I think it’s clear that cross-functional teams are important.

Photo by Simon Liu via flickr.