The Agile Manifesto has been around a while now, although looking at many of the projects labelled Agile you’d be tempted to think nobody has read it. However, even when read, there are plenty of antipatterns in the industry stemming from misapplication of the Manifesto, resulting in rather cavalier behaviours that trend towards an undesirable anarchic state.
The Manifesto contains statements that prioritize focus on one side of four contrasting values, however the Manifesto does not state that the “other side” of the scale is not necessary or intrinsically bad; just that we focus on one side OVER the other. The Manifesto concludes “While there is value in the X…” Too often that has been misinterpreted as “Agile doesn’t include X”, giving rise to the Myth that Agile equals no process, Agile is the Wild West of Delivery….
Agile Manifesto value #1: Individuals and interactions over processes and tools
Just how much process and tooling is suitable?
Like an onion, the outer layer of processes and tooling are the most visible, and hence can be the easiest to adopt, like wearing a costume. That typically leads to a focus on processes and tools over individuals and interactions and is in my experience the single most common failing in attempts of Agile adoption. However – assuming you have avoided this pitfall, what processes and tools are sensible beyond those embedded in the software development system?
Processes
Scrum, and even Kanban, come with their own processes, do we need them? The original concept in Scrum, three roles, four events and three artefacts is a sensible starting point.
Scrum is a framework, and therefore, by definition, is incomplete; so customising it to meet your needs is expected, even necessary. I’d argue that Scrum in a software context without underlying Extreme Programming practices is likely to be a lot less successful than the other way round, but also many teams in any context will also have extra meetings, scheduled backlog refinement being a good example, or their own way to run retrospectives, or organise sprint planning. Many very common Agile concepts are not actually part of Scrum, User Stories, Planning Poker, Kanban Boards, etc., all of these are useful to some teams some of the time, it’s up to the team to decide if it’s right for them.
These concepts are not to be shot down in flames with a cry of “Processes are Evil”. This is due to the fact that in the majority of cases these customisations are ways of working that the team has intentionally adopted to simplify their activities, they might have even made them up. There is a significant difference between an externally defined process forced upon a team and an internally customised one, adopted from within. Rules (and by extension processes) enable action without full understanding, and consequently stifle innovation. Teams should be encouraged to regularly challenge their processes to ensure that they still support activities rather than restrict them. If you are going to have a process, then make sure the team owns it, and therefore is free to change it.
Processes are often the consequence of a lack of relationship. As the personal relationships between people become weaker, then processes are often brought in to compensate. Relationships can be strained either through failing trust or most commonly just due to scale. The growth pain organisations feel is partly a result of the shift from relationship and trust based operations, to one of process based. With good relationships within your team and the people around them, the need for processes is reduced. To establish where processes are necessary, approach the question in reverse and ask where and why the relationships are poor and how to improve them, then when they remain weak could a process help? Could it be that there already is a process and that is inhibiting relationships. One should always look to trust the person before trusting the process.
Unless the whole organisation is Agile minded and relatively small, you are going to need to apply processes at the interfaces of poor relationships. That could be some structured status report into a nameless, faceless (at least from the perspective of a lowly team developer) steering committee, or maybe an agreed set of steps to request the support of an inflexible deployment team.
A consequence of the association between relationships and processes is that those team members that are not fully embedded in teams usually have more processes around their work than those in teams. So Policy Czars might have review sessions, User experience might need their own schedule of work and SLAs to deliver against etc. Again, these aren’t intrinsically bad, but need to be agreed as a compensation for the lack of relationship rather than as an opportunity to reinforce it.
Processes as Common standards
When there are multiple teams working together there will always be some people that work across those teams, either operating above them or with multiples teams at once. These people tend to be fairly senior or specialized and their desire to be able to compare activity across the various teams will be a drive towards standardisation of process and practice. This is entirely reasonable and understandable but should not be taken to extremes.
Any output or practice from a team that is expected to interface with another team should be considered for mutual standardisation between those teams. This ensures that when they pass things from one to another, then there is clear understanding and fewer errors, it also enables the work from those two groups to be more easily aggregated. This is common sense and the errors on the space programme from teams working in metric units, versus those on imperial units is a great example of the risks of not doing so. However, we only want to standardise processes that have this cross-team impact, that contribute towards systemic alignment. There is a temptation to over standardize which is counter productive because it results in a loss of team control, and loss of control is a reduction in empowerment, autonomy and consequently engagement and ultimately performance.
For example, the Definition of Done for a delivery system is something that should be standardised, same for the format that requirements are written in and the syntax of a progress report, as all of these concern interfaces between teams. More team centric artefacts like Team Health Checks, Product Backlog refinement approach, and estimation approach are examples of things that could remain with the team because these are used internally to help themselves.
Tooling
So do we need one of those shiny Agile tracking tools, like JIRA, Version One, Rally or one of the others? Instead of assuming you do, try assuming you don’t and then establish why you do. If a tool is truly needed, specifically what elements of the tool you really need, rather than adopting it blindly wholesale. Distributed teams are usually one of the main drivers of tool use but these tools then risk becoming one of the biggest challenges to team interactions. Most teams, especially in our enforced distributed working era, will need a work tracking tool, but within that tool, stay focused on what you actually need, and try to limit it to that.
This is not to suggest that one should regard all tools with suspicion, with a degree of puritanical arrogance that things are somehow better, purer, without the crutch of tools. The point is to be objective. It is fairly well agreed that for effective Agile software delivery you are going to need some manner of continuous deployment. For example, it is common practice to have a tool to support code reviews and quality checks and many of these continuous deployment activities can now all be integrated into a single suite. These types of tools can be really helpful where the only guidelines are really that tooling should be brought in deliberately due to a defined need, rather than an assumed starting tool kit.
In summary
- All teams operating with Agile principles and values are likely to have processes, and an environment without any tools is likely to be quite inefficient. It is a complete Myth that Agile = No process
- Ensure that your processes don’t obstruct or disincentivise human relationships
- Processes are usually needed to provide a basic framework to show work and to harmonise group time
- Own your processes, externally applied processes can be damaging to engagement
- Consider all the relationships inside and outside the team. Wherever there are issues – either due to a lack of building trust or maintaining good communications, then consider adding a process
- Processes compensate for lack of relationship, only adopt to fill the gap and resist going further as you may reinforce the lack of relationship
- Process and Tooling will likely need to be standardised by the teams that use them for interfaces and common standards that affect their collective delivery on the same product or service
Catch me at @philagiledesign or https://www.linkedin.com/in/phil-thompson-65466b2/
philagiledesign 