Moving Towards Frequent Delivery

As we all know Agile/SCRUM often needs to be tailored to the team it's being applied. More often then not. However, it is important to understand that tailoring Agile to "the team" means tailoring it to the situation. I propose to evaluate your situation through the following 4 dimensions:

Product type (Consumer/Enterprise/Specific vertical)
Product Lifecycle (where the product is in it's lifecycle and the competitive situation)
Technology (Mobile/Web/Systems)
Deployment Model (SaaS/On Premise)

The situation is constantly changing as the dimensions change, and therefore the approach that worked for your team few months ago, may not be the approach for going forward.

The combination of these dimensions will often dictate the Release Cadence. For example, you can organize the team for frequent delivery, but if the product is an on-premise solution, the customers may not want to absorb frequent releases. Mobile/SaaS world is different and there is an expectation for frequent delivery. If you add an enterprise aspect to the situation, then again, the frequent delivery may not be very welcomed even though the Mobile/SaaS nature of the product allows for it.

When we started the development of a v1.0, we had one big team of 12 people. When the team grew to over 20, we stayed in a one big team model, with the standup still taking under 15 minutes, which was really cool. However, the nature of the standup wasn't any more to coordinate the work, but merely to share the status, therefore losing it's real value. The functional teams were split by platform (mobile, web, server) in a service model, where the Server team would get a request for changes from the Mobile team. With the demand to deliver more frequent releases this stopped working and wouldn't scale, considering we wanted to keep the organization flat.

Because of the current competitive situation and considering how early the product is in the lifecycle, it was decided that frequent delivery model is to be followed even though the product is targeted for the Healthcare industry that doesn't absorb frequent changes well. With the pressure to deliver more frequent releases to the market we needed to reorganize.

The Product: Cloud based Mobile&Web app, Healthcare industry. v1.0 just 6 months ago.
The Idea: Cross-Functional Feature Teams + Parallel Releases

The approach we took was to assemble the cross functional teams around the next priority feature, the next feature and so on. Each team would have their own Feature Lead, responsible for the coordination of the work and making sure the design is getting done and documented etc. Think "Feature Team Scrum Master". With this approach the stand-ups make more sense: the people on the team are planning their project's work.
The next step is to lower amount of work in progress and amount of features in each release. This allows part of the team to work on the next release, eventually increasing the overall release cadence.

Agile By The Book?

Recently I was asked to introduce a process to a very senior team that joined our company not long ago. The team did not have much process established in the first place, so the goal was not necessarily to transition from traditional (waterfall) to Agile/SCRUM, but rather to establish a process. Having a very talented and senior team, with decades of software development experience presented a challenge: should we go ahead and implement Agile “by the book” or should we consider a different approach? Additional challenge was multiple other changes happening in the group, in terms of the personnel and the development infrastructure. The risk of imposing too many changes and too rigid process was very real and could impede progress rather than facilitate it.

Armed with experience of introducing Agile “by the book” to 6 teams in the last two years, and knowing the challenges that specific team would have I decided to try a different approach. First, I have done Agile/SCRUM training, similar to what I usually do for a team that is about to begin their SCRUM implementation. At that point I stressed, that this is an overview/introduction only, and by no means a prescription to how we will implement Agile. In addition I have communicated in advance, that the entire team will be involved in designing their own process, building on some of the practices they learn from the Agile overview. Setting this expectation has helped a lot: there was no antagonism towards the attempt to introduce yet another change, after the stage was set this way. However, there was also a risk that when the time comes to design their own process they would take an easy way out and will chose only few practices to implement, not realizing the real benefit of implementing SCRUM.

The next day after an overview we got together to design the process to be implemented. The guiding principles were the following:

1. We have new product development ahead of us with time to market being most important. Practices that we choose should help us focus on working software at all times and allow for making frequent changes and getting frequent feedback.
2. We want to implement enough process to benefit from what Agile/SCRUM has to offer, without introducing too much process overhead.
3. No decision is cast in stone: the team would inspect and adapt often.

With these guiding principles agreed upon with the entire team, we went ahead and examined each SCRUM ceremony, artifact and role and have designed our new process.

At the end, the team and I were very happy with where we’ve ended, in terms of amount of the changes the team will need to absorb, potential benefits and amount of overhead.

If you were to ask me 2 years ago whether the approach I described above is recommended, I would probably say “no”, because all we’ve heard from Agile practitioners at that time was “start by the book, then adjust as you go”. In retrospect, I can see how both of the approaches can work well, and more importantly, each situation has its own context and no approach should be applied blindly, without carefully analyzing that context.

It's time for course correction

After a year of doing Agile development with 6 teams and getting 2 releases out, it's time to reflect on how we are doing and identify areas for improvements across the organization. As with any organizational change the key is to move forward, because only when you move you can make course corrections.
This month I have facilitated a half day Cross-Team Retrospectives workshop with our global product development organization. Prior to that session each team has identified their own pluses and deltas an filled out an Agile Maturity Assessment survey. Output of these two activities has fed the Cross Team Retrospectives.
After identifying top 6 issues we've asked small groups to work on finding the root causes of these issues, describing the desired state and proposing ways to get to the desired state. Teams were told about "5 why's" and "Force Field Analysis" techniques, but in the time allocated for the workshop we could implement these techniques only at the high level.
Teams were given opportunity to present their findings and rest of the group has engaged in the discussion on each topic.
Overall the session was very productive. Main contributor to the session success was openness with which people shared their opinions, despite the fact that some senior managers took part in the discussion.
This workshop has not solved any of the 6 identified issues, but this wasn't the purpose. The idea is for the Engineering Management team and the Product Management team to analyze the outcomes of discussions, come up with concrete proposals for improvements and follow up with all the Agile teams.
Here is an example of what can be a follow up. Let's take the problem that people do not see value in daily stand ups. The action that we recommend taking in such case is for the team to identify what is the right information to be shared at the standup, such that it will benefit team members coming to the meeting. This is not "a" solution, but this will help the team to help itself to find value with stand ups. Another example. Let's take an issue with carry overs. Specific techniques would be to break down stories that are 8 points or bigger, and otherwise to not pull them into the sprint.
Now couple words about Agile Maturity Assessment. There are several assessments available on the web. I tried to stay away from the ones focusing on the actual SCRUM practices, and have designed a model that focuses on desired behaviors and results. The assessment measured our Agile Maturity in following areas:
1. Communication and Collaboration
2. Embracing Feedback and Change
3. Focusing on Working Software
4. Technical Debt Control
5. Planning and Predictability
Each area has topics and each topic has questions and weights. Total score is presented on a "radar" where we can see how we as a team perform with respect to being Agile.
Both the Cross-Team Retrospectives and the Agile Maturity Assessment are great tools in transformation leader's toolbox to assess and correct the organization's course.