The Three Stages of Agile AdoptionOver the past decade, I’ve witnessed common patterns of successful agile adoption and have grouped them across three stages shown below, which I call the apprentice, journeyman and mastery stages.
When speaking about agile, we're talking about the agile values and principles. How these are embodied in your day-to-day practices depends on your culture and the framework for your process. Scrum is one such popular framework, Kanban another. These frameworks are great scripts for starting agile, but over time teams change the practices and even blend them. In this article, I'll mainly use Scrum terms, but your terms may vary.
ApprenticeTeams that are newly formed and/or are new to agile aren't expected to apply agile practices very well at first. They need constant coaching as they struggle to figure out who does what and when.
Apprentice teams learn how to deliver features at a regular cadence and apply new roles such as Product Owner and ScrumMaster.
I prefer to see apprentice teams follow the practices, such as those of Scrum, “by the book”, because changes at the start of Scrum adoption are usually done to conceal problems Scrum exposes.
Effective Daily Stand-ups
One example of abandoning a practice too early is when teams skip the daily stand-up meeting because they feel an electronic tool is better for reporting task status. Reporting task status is a part of the stand-up, but it is not the primary purpose and so something is lost. The daily stand-up is meant to align a cross-discipline team to their daily priorities, revisit their commitment to their sprint goal and recommit their accountability to delivering quality features. Thinking that it's all about task reporting is a vestige of a task-assignment culture and it takes a while to change this mindset.
Forming cross-discipline teams that can commit to goals is critical to early adoption. Departmental or siloed organizations will resist the formation of cross-discipline teams. Not only do department managers fear losing control, but developers themselves will resist being teamed with those outside their own discipline. Yet, if cross-discipline teams don't form, then the weight of dependencies and the inability to deliver a demo-able game every iteration, will prevent most of the benefits found with agile.
Well formed cross-discipline teams can take more ownership of their goals, which leads to more effective problem-solving and higher productivity.
Roles, such as Product Owner and ScrumMaster, are meant to balance the need to build the right features in the right order and in the right way. The roles are separated, because they often come into conflict with one another and need to be balanced for there is a fine boundary between building features faster through improvements to productivity and building features faster by dropping quality.
Realigning existing roles with the new ones take a while to establish and even longer for the teams to understand how they are meant to function.
JourneymanWhen agile teams create a definition of done and start altering their practices to achieve it every iteration, it's a signal that they are entering the Journeyman stage. The following areas of development maturity are common with Journeyman teams.
Through close collaboration, Journeyman teams reduce handoffs of written design documents and concept art. For example, instead of a dozen storyboards for a level, a concept artist will draw half as many and spend more time working directly with the level artists and designers. In this way, all disciplines can more effectively collaborate and iterate on more emergent and higher quality levels than a one-way handoff of concept art would allow.
As cross-discipline teams iterate more, the inefficiencies of practices such as branch-and-merge and hand-testing everything are replaced by practices such as continuous integration, test servers, unit testing, etc. These practices allow more iterations on up-to-date assets and code throughout the day. The ability to iterate more frequently contributes to higher quality.
As mentioned above, faster integration requires improved testing practices, such as test servers. Additionally, Journeyman teams will increasingly integrate members of QA onto their team. This will lead to further refinements of the definition of done.
As journeyman teams improve their definition of done, agile estimation techniques can be employed to produce a more reliable forecast about the schedule, cost and scope.
MasteryMastery is a stage occupied by so-called hyper-productive teams. These teams hold themselves accountable to their results, practices and organization. For teams to enter this stage, they must have an established level of trust within the organization and be allowed to achieve higher levels of self-organization.
Sometimes, when I visit a team that has been effectively inspecting and adapting agile and Scrum practices for a while, it’s hard to say “they're doing Scrum” anymore. They completely own their work, and take much pride in it.
The goal of Scrum is to leverage the power of small, self-organizing teams to maximize the value they create. By giving teams and individuals more freedom to make decisions about their work and providing structure, coaching and mentoring, their work becomes far more focused and meaningful.
Studio culture and structure are often barriers to this “low constraint” form of self-organization. Fortunately, as more studios emerge that demonstrate the value of this approach, the acceptance and proof of it will continue to grow.
Following a set of prescribed practices isn’t the goal. The goal is continuous improvement. Markets and technologies change. Individuals change. Processes have to change as well. There are no "best practices" because the word "best" implies that there are no better.
It's Not Easy, but it's RewardingThe agile state of mind challenges our beliefs and assumption and insists that we continue to challenge them. It flat-out defies the persistent superstition that we can treat creative people with the same tools that make machinery more productive, that we can add more people or add more hours they work or write bigger planning documents, which will result in more output. People are far more complex.
It makes us coach, listen, challenge, inspire, care, respect, and collaborate in ways we were never trained to do. It's a lifetime challenge with no finish line in sight.
 These are not unlike the three stages of martial art mastery called “ShuHaRi”
 This is not inherent to Scrum teams, all new teams go through a settling phase. Google “Tuckman’s stages of group development” for more on this.