In my previous post I looked at a slow and incremental approach to transitioning to Agile. When first thinking about transitioning to Agile this seemed like the obvious approach, after all Agile methods advocate continuous incremental improvement. Despite this many people in the Agile community advocate making the change overnight. This is known as the “big bang” approach to transitioning. For us, this means introducing the idea of Agile at the start of the engagement, convincing the client of it, and kicking the project off as an Agile project.
How this works
Prior to kicking off projects with clients we typically have a meeting to discuss the nature of the engagement. This is the initiate phase of the Assured Agile process. This will make it clear whether we are providing a complete team or augmenting another team, who we’re reporting to, and the kind of work we’re going to be undertaking. At this point clients will also want to get a clear idea of the expertise we’re bringing to the project and how they can make best use of this. We can also explain to the client that part of the expertise we are bringing is our understanding of how projects should be run, and discuss how best to develop that alongside the client’s employees.
This is a good time to explain to the client the benefits of an Agile approach, and how it will affect them. It is important to convey ideas like iterative development to the client as soon as possible. Clients will often be used to long term plans, and waiting till the end of the project to see working software. It is also important the client understands how much more involved in the development we would like them to be. This is often met with some scepticism, however once the clients start working like this they usually really enjoy it.
This discussion will likely influence the makeup of the team on the client’s side. Clients will often want to supply business analysts to work with our team, whereas we might split this role between our team and a product owner. Our team could then perform the low level analysis of how features might satisfy the customer best, with the product owner deciding which features are most valuable for the customer and having the final say on the behaviour of features. Similarly, if the client wishes to provide testers for the project, then we can integrate them into the team, instead of them waiting for a complete product to test. The exact makeup of the team depends on whether we are running the entire project, or whether the project is being run by the client. Even if we take on the running of the whole project, we expect the client to have an active role as a customer by providing a product owner or something similar.
Finally, it is important to put in place some sort of structure to carry on looking at the way the team will work. This will typically take the form of Scrum retrospectives, however there are other options for this.
Whilst this approach would usually start prior to the start of an engagement, it is something that teams within Scott Logic have taken on midway through an engagement as well. This depends on a client not being keen on Agile initially, but having a change of heart part way through the project.
The benefits of this approach
The clearest benefit to this approach is the that it involves more senior management. A lack of management support is a common reason for transitions to Agile failing. This is because it is difficult for a team to be Agile in isolation. There is nothing more disheartening for an Agile team than producing working software regularly, only to have it ignored and to have management demand a date when it will be finished by. It is also a waste of a cross-functional team to give them detailed requirements upfront and hand all their work to an external test team when they finish.
It is common for the managers who we work with initially to be stakeholders for the project. This means that they will need to understand their responsibilities for the project to be successful. If not then the team risks lacking direction and failing to produce the software the client desires.
Having upfront discussions about Agile will help make clear to the client about the direction we intend to take the project. That will make the introduction of practices such as pair programming and code reviews easier to sell. Practices such as these tend to have a long term impact, and so can be hard to sell initially. If we introduce the idea of collaborative development to the client early, and as an important part of Agile development, then it will be easier to sell to the client.
Collaborative development is a practice that can be incredibly hard to kick off without introducing Agile upfront. As consultants we typically work remotely from our clients. This means that if we are not collaborating with the client to start with, then there does not tend to be a forum to kick this off. Collaboration makes a huge difference to the speed and quality of the product developed, so it is important that this practice is used.
It is also beneficial to discuss Agile with the client to allow the team to come up with an initial process that will be responsive to changes throughout the development process. Whilst it is important to avoid trying to design the ideal process upfront, it is worth putting some effort to define a process that the developers and clients are happy with. The process needs to be designed in such a way that it can change if needed.
Weaknesses of this approach
The major weakness of this approach is the risk it introduces at the start of the project. Clients will already have a process that they follow and may well be averse to changing it. The suggestion that we prefer working in a way that involves change on their part might put them off the engagement completely.
In a similar vein to avoiding upsetting the client, is to avoid upsetting any of the client’s developers that we end up working with. Agile can hardly be considered Agile if it is imposed on a team. Any developer working as part of an Agile process needs to feel ownership over that process. This will mean getting the client developers involved and bought in as early as possible. This makes the upfront approach more limited when we are augmenting client teams compared to when we are forming our own teams.
It is worth noting that this approach brings very little benefit for introducing technical practices. Whilst we can talk about which practices we are likely to use, this is not typically relevant for the start of a project. Instead practices will be used as and when they are needed.
Experiences with this approach
This approach has tended to fare far better than the more gradual approach to introducing Agile. Using this approach as part of the Assured Agile process we have had projects run successfully in a fully Agile way. This has included having our clients act as Agile stakeholders, looking at updated versions of their product every two weeks and adjusting the direction of the team as they saw fit. Whilst our clients have been happy with us as we try to introduce Agile incrementally, this doesn’t really compare to the delight of the clients who have worked with our fully Agile teams.
It is worth noting that part of the reason for our increased success is that it has been used with clients who are already keen on Agile, or at least happy for us to completely control the process used for developing software. This fits in nicely with Assured Agile. By making it clear that Agile is part of the way we work, clients will be more confident with Agile at the start of the engagement, and we will be more likely to attract clients who already have an interest in Agile. The nature of the client massively affects the approach we take to introducing Agile. This is something we will take a look at next.