Say ‘agile’ one more time: making space for collaborative innovation

Have you ever sat around a table with your workmates and marveled quietly at the wealth of talent that goes wasted in your organisation? The systems, roles, and processes of the modern office are an enabling platform that channel people into productive activities. But they also work as a filter, allowing certain skills and talents into the workplace, while shutting others out. The office junior moonlights as a jazz guitarist, but you are only aware of it because he mentioned it over coffee. The sales manager builds kitset drones and flies them on the weekend, but no one would know if not for the copies of Make magazine in his office desk drawer.

What if you swept away the pieces on the corporate chessboard and gave every person in the company licence to decide how they wanted to contribute to getting things done? Imagine if all the rules, roles, and processes that structure daily life in the workplace were suddenly lifted and people were invited to bring their whole person to work? Would anything get done? Would the office dissolve into anarchy? How might you organize yourselves in order to keep the ship afloat while enabling people to draw on their gifts? Assuming that this were possible, how might it change the nature of work? How might it feel to freely invest a broad and diverse range of skills and talents in everyday work? Collectively, what could you achieve?

Doing away with systems, roles, and processes in the workplace seems like madness. Yet, a successful example of this approach has existed in the world of software development for almost 20 years. This is agile methodology.

Agile methodology is a composite. It emerged around the turn of the millennium, when a group of influential software developers realized that they had formulated a similar view of how to organize development projects. These developers were critical of the ‘heavyweight’, waterfall methods that had dominated the IT development industry through the 1990s, in which extensive planning and project documentation (usually drawn up by managers) precedes any coding being done. The perception was that waterfall leads to inflexible, document-heavy projects that run over time, resulting in budget blowouts. By creating a division of labor between managers (the ‘planners’) and developers (the ‘builders’), the waterfall method ensures that the chief creative input of the latter lies in objecting to, and correcting, the unfeasible assumption of the former. This situation sets developers and managers at loggerheads with one another and saps the morale of software development teams.

In opposition to waterfall, this group of developers explored a more collaborative approach. They argued for a set of ‘lightweight’ methods, like Dynamic Systems Development Method (DSDM), SCRUM, Extreme Programming (XP), and Adaptive Software Development. The 90s ‘lightweights’ were exploring how to apply the experimental, iterative strategies of hacker communities to software development method. Each of their approaches foregrounds a different aspect of the work. They share the intuition that software development should be an intensely collaborative, iterative endeavor, focused on creating customer value.

In February 2001, a group of 17 developers met at the Snowbird ski resort in Utah to contrast and compare their lightweight approaches. Combining insights, they sought to identify the general principles of a mindset and culture that they (wisely) rebranded ‘agile’. The Agile Manifesto, published online in the wake of the conference, summarizes the core values and principles of agile. While project managers continue to debate the relative advantages of agile over waterfall, the distillation of the method in the form of a manifesto ensured that agile has become a living geek culture.

These days, everyone wants to be ‘agile’. The agile workplace is the latest business buzzword as corporate leaders try to engage their digital natives and make their office spaces more flexible, innovative, and productive. Agile workplaces cater to mobile workstyles, enabling employees to choose their hours and work independently outside the office. The office itself is an open, colorful, creative environment, where employees can choose different spaces for different jobs and tasks.

Is the agile workplace truly agile? The answer, in most cases, is no. Usually, there is little attempt made to transform the nature of work so as to enable employees to actually collaborate in an agile fashion. Hence, while the furnishings are inspiring, the culture of the agile workplace isn’t agile at all.

My thesis is that ‘agile’ is essentially a gift culture. Agile can be understood, therefore, by looking at the different kinds of contributions (or ‘gifts’) that feed into agile work. Let’s use the four gifts framework to distinguish these different contributions. This will provide us with a practical lens on the principles of agile method (which can be opaque to people who are not familiar with it) and indicates how we can apply these principles beyond software development in order to create a genuinely agile workplace.

1. Personal gifts

The primary personal gift required for agile is — agility! Agile work proceeds in fast-paced collaborative ‘sprints’. In agile software development, these sprints can be anything between a couple of weeks and a couple of months long. Since the nature of the work conducted in each sprint is determined in conjunction with the customer prior to the team embarking on it, and the precise activities that team members are responsible for may differ from day to day (depending on the outcome of the daily stand up meetings), it can be unclear for developers what personal skills they’ll need to apply in order to engage in agile work. The most important personal attribute agile work requires, therefore, is an open mind and a flexible outlook.

Agile is a kind of dance. To do it well, you need to stay on your toes.

Usually when we reflect on the kinds of gifts, or contributions, we can make to collaborative work, we think of the technical skills that we can offer. Technical skills are certainly important for agile development work. Agile development teams are tasked with solving a multitude of problems, so they benefit from having a cross-functional skill set at their disposal. A well-rounded team will include people adept in a variety of programming languages, as well as designers (who work on user-facing aspects) and testers (who run test cases to validate the software against requirements).

When reflecting on what we can give to agile work, however, we should not underestimate the value of the behavioral traits that are required to create an agile culture. In the context of less technical projects, these traits are arguably more important than technical skills, since they help create an environment in which people feel safe and inspired to engage with the work and to think laterally about how they can tackle difficult tasks.

The traits required for agile work are a mix social skills and moral dispositions. They vary depending on the work, but the short list includes:

• agility
• autonomy
• initiative
• empathy
• humor
• communication
• self-discipline
• self-awareness
• efficiency
• honesty
• authenticity
• responsibility
• integrity

Integrity is very important. Agile work requires the ability to commit to work and to deliver on deadline. Without this everything falls to pieces.

2. Gifts to collaborative work

As noted, it is not always clear when engaging in agile environments what personal gifts will wind up being valuable to the work. Consequently, it is vital that we maintain an agile mindset. Prior to any other contribution, an agile mindset is an important gift to collaborative work that helps maintain the energy of the team and keeps things lively.

The other behavioral trait that is particularly important to agile teamwork is initiative. Whatever we contribute to collaborative work, it is vital that we contribute something. There is only one person responsible for venturing a contribution and that is you.

Agile teams don’t require a manager to delegate tasks and responsibilities because team members take the initiative and volunteer for tasks and responsibilities themselves.

In the agile workplace, this volunteering/gifting ritual takes place in the daily stand up meeting. First thing in the morning, the team gathers in a circle and does a quick once-around, so that everyone can update everyone else on their progress and their current situation. These meetings call for careful listening, attentiveness, empathy, and resourcefulness on the part of team members to work well. However, the most important trait is initiative.

Your fundamental gift to collaborative work is agency. Don’t stand there waiting for someone to give you something to do. Take initiative. Enact your agency. Put up your hand and volunteer for something. Put your best foot forward and invest something of yourself in the collaborative creation.

Apply your signature skills. If you are a programming wizard or a design savant, work that magic. Be ready also to draw on your T-shaped capacities. The best agile teams actively resist role specialization. Agile theorists juxtapose the agile environment to the Fordist-Taylorist factory, where everyone has a place on the conveyor belt and people are cogs in an oily machine. These kinds of environments turn human beings into machines.

Agile innovation, by contrast, requires fully-functioning, autonomous and proactive human beings. People who are thinking about how they can add value to the work. People who volunteer for tasks because they know they have it in them to do the job well, even if it’s not something that they were employed to do. People who just want to get stuck in and have a go.

Agile innovation requires participants who are ready to give their all to collaborative work. When such a group of people come together on a team, we have the beginnings of an agile culture.

3. Gifts to customer or user

Agile method focuses on creating value for the customer. As the first principle of the Agile Manifesto states: ‘Our highest priority is to satisfy the customer through early and continuous delivery of valuable software’.

This reflects a gifting mindset. Delivering quality work on schedule is not a gift — it is part of a commercial transaction. But the attempt to identify a product with unique value for the customer, which can be built within a limited time frame, is guided by a gifting mindset, and becomes motivating and inspiring for participants to the extent that it is conceived in this light.

Agile developers seek to create value for the customer in each sprint. Prior to each sprint, the teams liaise with the customer and other stakeholders with a view to determining their requirements in the current situation. They propose a piece of working software that the customer can play with and build on. With the customer’s consent, the team goes to work. It has a limited time to complete the work, which is why it’s called it a sprint.

After each sprint, the team reconnects with the customer. They demo what they have built, referencing the project requirements, and discuss next steps. This is a two-way conversation. The team reflects on what they have learned in the course of the sprint, and considers whether and how this should impact on the project plan. Meanwhile, the customer reflects on their business situation, and considers whether the initial requirements for the project remain valid in light of this or need to be changed.

Regular customer collaboration creates transparency about the work and enables a high degree of flexibility. Project requirements can stay loose and emergent, subject to the learnings of each iteration of the project. In the waterfall approach, project requirements are drawn up prior to design, which comes before the coding and implementation, which comes before verification by the customer. This linear approach is superb for managers, enabling them to draw up budgets and plans in advance of the work. But it creates the risk of wasting months (or years!) of work when a new technology emerges, rendering the bespoke design redundant, or the commercial situation changes (as situations are liable to do). Suddenly, the project has to meet a new set of requirements. What has been built is no longer fit for purpose. The project team finds themselves in a lower pool of a cascading waterfall, incapable of swimming back upstream.

For the customer, the flexibility of agile massively reduces the risk inherent in a development project. This is a gift in itself. Add to this the fact that the agile team seeks to create value in every sprint (as opposed to some far-away time when the whole project is complete), and we can see why agile has secured such a powerful grip on the software development marketplace.

4. Gifts of context, time, and space

Agile strategies aren’t restricted to software development. As the culture of online collaboration seeps into the commercial world, and business leaders explore new ways of engaging employees and enabling innovation, agile strategies are filtering into the broader workplace, empowering individuals and granting creating licence to self-organizing teams.

For team leaders, the question is: how agile do you want to be? Imagine sweeping away the pieces on the corporate chessboard and implementing a wholesale agile innovation culture. Imagine if all the rules, roles, and processes that structure life in the workplace were suddenly lifted and people were invited to invest their whole person in their daily work?

The lesson of agile software development is that this can work — assuming we have the right cultural practices and norms in place. Agile is not a process. Agile is a culture — at base, a shared mindset concerning ‘how we get things done around here’. To make agile method work, leaders need to ensure that everyone in the company is on the same page culturally-speaking. Everyone should have a common view on how to interact, engage, contribute, and collaborate to get things done.

How exactly do you lead agile work? Clearly, agile transforms the nature of leadership. The goal of creating self-organizing teams makes traditional command and control leadership redundant. You are not adding value to the work by imposing your will upon the process. You are getting in the way.

Instead of trying to control collaborative processes, agile leaders seek to empower, enable, and service the needs of their team. Agile theorists call this ‘servant leadership‘. Leadership, in this model, is a kind of stewardship. It involves a series of gifts to the team: the gifts of context, time, and space.

The best agile leaders are storytellers. Through their stories, these leaders create a shared context and a common reality for their team. Drawing on agile values and principles, they seek to ensure that everyone on the team knows how to proactively engage with a problem, agree on a method for dealing with it, and proceed. Everyone on the team should have a clear sense of why they are here and what they are trying to achieve.

Another core function of agile leadership is to give the team time to complete each sprint. The leader must ensure that the work proceeds at a mutually agreeable pace and that no one is in danger of burnout. Part of this involves ensuring that team members don’t inadvertently overcommit themselves in stand up meetings. Another part involves setting the length of each sprint so that the team is challenged to move fast and yet everyone has time to complete the tasks they’ve volunteered for. As a rule of thumb, an agile sprint should be as short as possible and as long as necessary.

The third gift of agile leadership is the gift of space. This means, first of all, a physical space where collaborative activities can take place. But making space for agile innovation has a cultural dimension too. Once the leader has created a context for the work, and ensured that the team has adequate time to complete it, he or she must step back and give the team space to catalyze collaborative magic. The leader must let go and trust the team to deliver.

— — — — — — — — — — — — — — — — -

This post was initially published on Gifts for Greatness.