Agile, by definition, is a list of values and principles located in the agile manifesto. But that's just it, it's a group of phrases, by sticking them on the wall and telling people we're going to 'do agile', you are kinda missing the point.
So what does it mean to 'be' agile? I believe that agile is more than the sum of its parts, it's a mindset, it's a way of being. I want to explore a few things that can help us live these values and principles and in this first part I'm going to share a few thoughts on cross-functional teams.
In a waterfall environment, team set up is easy. Each piece of work passes through a stage that needs a certain skill set before moving on to the next stage in the process. As long as you have at least one person who can perform that function, the work continues. It therefore makes sense to identify common skill set requirements and have a team of people who fit that requirement, who have the same skills as each other, so they can complete the work and get it on to the next stage.
We see this in manufacturing all the time, one team designs, another sources materials, you have a team for preparing the materials, one for building the item, you may have a team that checks for defects and even one that does the packaging when the product is complete. Some of these stages may even be machine driven nowadays, removing the need for people at all!
This approach works well where the product which is being built is predictable and won't change. A mass market toy or confectionary product fits this really well and you'll find a lot of that process is automated already.
Where this approach has been applied, but doesn't work so well, is in the software industry. A traditional approach has been taken by many, split the workforce into teams of similarly skilled people, so Design, UX, Back end developers, UI developers, Project Managers, Marketing etc. This is common place in many software houses and for years has been considered industry standard. It has delivered many products; some of which have been really successful but many of which were over budget, late and underused.
Part of the issue is that the software industry started using an approach that wasn't fit for purpose - it was assumed that products would be discovered and scoped before being built and then used exactly the way we anticipated. With the world changing at such pace nowadays, for something as fluid as software, used by so many people every day, this just doesn't work. 2 year projects were coming to an end and users were saying, 'yeah I could have done with this two years ago, but what about now? Now my expectation is somewhere else.'
Predicting people and their needs and wants is so hard! Which is where agile came in. Agile is a set of principles and values which allow software teams to fail fast, to learn quickly and adapt to this ever-changing environment.
At a basic level, that means the teams you have need to break the work into smaller chunks and have that delivered quickly and gain feedback from users so you can decide on your next steps.
At practical level, that basically means each part of the product goes through each team as before, but it just takes less time, right? This small piece of work goes to Design, UX, Back end development, UI, Marketing and comes out the other side much quicker. Many people taking this approach think they are 'doing agile'.
While I agree that it works better than a waterfall approach, I'd actually call this 'mini waterfall'. It does answer some of the 12 princples in the agile manifesto:
- 1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- 3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- 7. Working software is the primary measure of progress.
I think we'd agree that this approach goes some way to addressing these principles. But to me the 'teams' are still in their own silos.
Going back to the agile principles, what about these:
- 4. Business people and developers must work together daily throughout the project.
- 6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- 11. The best architectures, requirements, and designs emerge from self-organizing teams.
If you have people further up the 'chain' working on something completely different to someone further down the 'chain', how do you find an ecosystem where business people and developers work together daily, regular face-to-face conversation happens and self-organising teams evolve?
The team by function approach means that each team has it's own priorities and every team becomes dependent on every other team when trying to deliver a single small piece of work. The design team might be looking at the next element when a UI developer has a question about something they have previously designed. This means someone in the design team needs to stop what they are doing to help the UI developer or the UI developer is told no one is available and has to make up their own interpretation of what they are supposed to be delivering.
This may mean that the product goes on to the next stage with elements in it which are not as intended if communication is impeded in this way.
Which gets in the way of one of the core agile values:
- Individuals and interactions over processes and tools
I'd suggest cross functional teams as a solution to this issue. Put people with different skill sets in a team, make a team that is not dependent on anyone else to complete a piece of work. It then becomes that team's responsibility and priority to focus on delivering that chunk, without it being passed from pillar to post and communication (and ultimately the finished piece of work) suffering.
If you let a cross functional team work together, they will have a shared responsibility to get the work done, if questions need to be asked, they will be answered and a shared understanding will evolve, the outcome will be what was intended as well as the progress being more predictable.
A cross functional team will be able to work together closely with daily face-to-face contact. Working as a single team towards a singular goal, they will be able to self organise to use the different skills whenever needed during development of the product and therefore the best architectures, requirements and designs will emerge.
“‘we grasped the fact that ‘human errors’ often emerge from poorly designed systems.’ ”
It's a complete step away from the traditional ways of working and it's risky to start, but if you find your products are suffering and you think you need to place the blame at the people in your company, think about whether it is actually the process you are making them follow that might be causing the issue. Try a cross-functional team or two for a while, give people an alternative to the way it has always been, see what happens. (Read about one of my experiences in a previous blog post) You may just find another of those agile principles fall into place.