Although many of the agile principles we’ve come to know today were originally founded by small, innovative organizations, we would venture to say that in the current corporate world of agile transformations, we don’t hear much about agile adoption in small organizations.
However, even though these small organizations employ fewer than five hundred people and might have limited IT teams, these companies make up 99 percent of businesses in the US. These workplaces are interested in transitioning to agile too, and we’d like to share two strategies we’ve learned for implementing agile in small organizations.
Try It before Changing It
The agile mindset was intended to be lightweight. And, compared to some of the more traditional waterfall frameworks with their uncompromising sequential phases and steady stream of seemingly bureaucratic processes, for the most part, agile is very lightweight.
But what happens when you’re at a small company and you have a team of two software developers who work side by side? Do daily stand-up meetings still seem lightweight? What if you have four software developers in the entire company and they work on four different projects together? Will you hold four separate retrospectives every sprint with the same four people?
In these cases, if a team attempted to hold fast to creating a representative of agile utopia as prescribed by agile purists, the team probably would end up seeing its effectiveness and efficiency decline instead.
Still, these, agile practices are rooted in principles. Inspect and adapt. Working code over documentation. People over processes. It is the principles that lead to efficiencies, not necessarily the prescribed roles, ceremonies, or artifacts that arose from the principles. Over the years, certain agile practices have been distilled, and winning practices rose to the top in a sort of agile best practice natural selection. Recognizing this, small companies should at least try these practices first before abandoning them. If they’re not quite right, teams can tailor the practices later to fit to their specific small-company situations.
Scrum, for example, calls for distinct roles: product owner, ScrumMaster, and team members. Trying to implement these roles perfectly just for the sake of adhering to prescribed literature may not make sense for small organizations, but the agile principles are still beneficial. How about the small organizations try collapsing the Scrum roles? We saw one small company effectively combine its existing project portfolio manager role with the product owner and ScrumMaster role, so that person was able to both groom the product backlog and facilitate ceremonies.
What about moving daily stand-ups to twice weekly when work is going well and twice daily when work is not going well? For organizations with a handful developers sitting side by side, this allows the team to still be agile and lightweight.
Transform the practices if experience proves modification is needed, but don’t abandon them outright without giving them a go. They are rooted in principles proven to work well.
Disruption Is a Sign of Optimization
If you have been a part of company change, you’re probably familiar with the growing pains. Team angst can be more intense when the company is small and personable, especially when group members have formed a close bond. Negative gossip travels faster, and rumors get exaggerated more. But it is important to acknowledge that this type of disruption is normal and commonplace.
At one small company where the writers helped implement an agile transformation, the change led to disagreements between the “old guard” and the “new kids on the block.” To keep peace and harmony among employees, company leaders made employee team reassignments over several fiscal quarters that gradually left the company in a sort of de facto “bi-model” operation. Those who embraced agile worked on the company’s fastest growing revenue-generating products as well as cutting-edge technology such as migrating to the cloud, development of microservices architecture, continuous integration, and experimentation with containerization. Those who resisted the agile change were assigned to the company’s oldest technologies and products, plodding along with desktop executable installs, missed deadlines, and twice yearly production migrations.
At another company where the writers implemented agile transformation, daily stand-up accountability and visible task board assignments created more accountability and transparency. This left a few key software developers uncomfortable with the additional scrutiny of their work, and they eventually resigned from the company. This hurt a few key projects at the small company and left product owners in a lurch. But, when faced with the decision, the company leaders decided change for the benefit of the whole company was more important than appeasing a few employees resistant to change.
The point of sharing these stories is to demonstrate that it is easy to begin to have doubt about the agile transformation process. Heated and sometimes public arguments can ensue. Performance reviews and even organizational structure can change. Loyal company employees may leave, and on a small team, the impact can be large. This is bound to create some doubt about the decision to adopt agile.
But we are here to tell you that that this happens at every organization. Some disruption, discontinuity, and discomfort is a byproduct of change. Even some positive attrition can be a byproduct of this change.
When an agile coach sows the seeds of change and nurtures them to germinate, that work not only bears fruit; it sometimes also creates weeds that need to be plucked. Some doubt will arise that forces you to ask whether the change you are implementing is the right one for your organization. To answer that question, you should ask yourself two more: Is the value and benefit arising from the change worth the disruption? And, if there is no disruption, is change really happening?
Agile That Works for You
The experience of implementing agile in a company of thousands of employees differs widely from that of a company of hundreds. Although the risks can be greater, the rewards can be, too. If you work in a small company that is interested in changing to an agile workflow, we hope these strategies prepare you for a successful transition.
