Some decade ago you wouldn’t think of using the word “agile” to mean anything other than an adjective to describe a brisk and lively way of moving. That’s unless you were working in IT where it was the rising star of project management and productivity philosophies since its introduction in 2001.
Observing, how marvelously it’s doing in the world of IT, you may find yourself asking the question ‘Is Agile only for tech?’. The fact is, that Agile is already making its way into other industries beyond IT and is quite comfortable in non-IT environments. Companies experiment with implementing Agile for non-software teams on a smaller scale and, when proven successful, move on to adopting it company-wide.
According to KPMG Global Agile Survey 2019, the number of companies that have fully embraced the Agile approach can grow to 32 percent in the nearest future. In this regard, Agile project management for non-software projects is possible, but it’s desirable.
Start your agile transformation journey now
So, how do you introduce Agile to a non-IT team?
That’s a tough question but not one without an answer. The following tips can help you get started:
- Evaluate and assess the current state of processes. Agile for non-IT teams may differ depending on the specifics of your line of work – not all teams can deliver results on a weekly basis, some may even have trouble identifying what would be a “delivered” value and “increment” if, for example, they work on a continuous support basis. The initial assessment may help with detecting points of entrance for Agile ways of working. Moreover, an initial audit of the state of things in your organization will identify pain points and bottlenecks that might be addressed whether you’re new to the Agile world or have been practicing it for some time already.
- Produce an Agile transformation roadmap with milestones. After the initial evaluation, you should be able to create a SMART plan for your Agile transition. It can be as detailed as need be, providing the steps to take when first starting out, defining roadblocks to look out for and milestones that need to be achieved. All this will help you make your transformation smooth and stress-free.
- Create a baseline in the roadmap for future reference or “as is” state. Once you are further along in your transformation, you’ll occasionally look back to see how you are progressing and if any adjustment is required. It helps the teams to be able to recollect how the processes worked before and not go into frustration with the new Agile approach. Try to include some clear, relevant metrics that can be compared to similar ones in the unique setting. This way you will be able to drive your Agile transformation with data and not only with your “gut feeling”.
- Choose your framework. Picking the right framework may be just the thing to set you up for success. Choose the proper framework to start which can be either one of the further mentioned or some combination: Scrum, Kanban, Scrumban, etc. Scrum would fit best for starters as it’s pretty straightforward, ceremonies and roles are predefined, and everyone can learn it from scratch quickly. Kanban would fit more mature teams and those where the iteration approach cannot be implemented due to the very changeable work nature. Such teams cannot afford the luxury of blocking a timebox for 4, 3, 2, or even one week. Scrumban would be applicable to the more experienced users of Agile who already tried out the two main frameworks and can generate a combination of processes that addresses their needs best.
- Decide on sprint length. If your team chooses to start with the Scrum framework it will be crucial to decide on the right sprint length. Breaking the cycle into iterations can be confusing and somewhat intimidating. Decide on the optimal sprint length for your realistic and manageable team. It can be anything from one to four weeks. It’s usually not advisable to have sprints that run for longer than a month. But make sure that all usual workload can be delivered from the start to the end within this timeframe otherwise you will run into smaller “waterfalls” divided into sprints without clear start and finish points.
- Decide on meetings. From daily standups to retrospective meetings, there is a great selection of Agile ceremonies that you can apply to your work processes and plan more efficiently. Decide what works best with your workflows right from the beginning. It is highly recommended to start with the standard set of ceremonies, namely Planning, Daily Standup, Review, Retrospective, and Refinement if needed. The team can democratically agree on the best time for the meetings which will reflect your working routines. After a few weeks or months, you can discuss and adjust those agreements if needed.
- Decide on the roles. The typical Agile team structure comprises the Product Owner, Scrum Master, and Developers. When you are applying Agile to non-development teams, you may need to adjust your team composition to have the proper accountabilities represented. Choose your Product Owner who will make sure that you are right on track with the tasks. A Scrum Master will see to it that the team adheres to Agile principles in their work. Even though the word “Developers” implies Software development, feel free to rename this accountability into “Doers” or “Performers” or any other name that fits the context of your organization. According to the new Scrum Guide, the role itself is not that important anymore. What’s most essential is to get those accountabilities distributed within the Scrum Team; for example, there should be a clear flow for creating a product backlog and prioritizing it, all ceremonies should be scheduled and facilitated properly to make them effective, impediments and blockers should be addressed and resolved quickly, and it doesn’t matter if those responsibilities belong to PO, SM or some other person on the team. The most important thing is to get your Agile rolling in the right direction.
- Translate to Agile estimation in story points, artifacts, increment, product, and working items. Understand that not everything can be translated ‘verbatim’ from how it is in a development team – an equivalent may simply not exist, so try to adjust those terms to your reality as best as possible. For example, implementing estimation in story points will take a while since it’s a cultural shift of mindsets. In this case, you can start slowly transitioning from hours to story points, maybe even having both in the beginning in order to smooth out the “lost in translation” process. And as soon as the team becomes comfortable with the new system, remove the hours from the picture. Primarily, all the new terms and substitutions proposed should make common sense and the team members should understand the value of the change. Without having the team’s consensus, it’s very easy to get your Agile transition sabotaged and failed.
- Get an Agile expert on board. You can invite a Scrum Master or an Agile Coach to guide you and your team through the initial steps of your transformation, pinpoint your shortcoming and help you adjust the processes to your specific needs dictated by the non-tech nature of your work.
Start working with your framework of choice
Start running one of the frameworks for some time and do constant checkpoints, improve continuously and collaboratively as you go. You can use retro or other meetings to do that. Remember your baseline for the “as is” state defined in the previous steps; always reflect and compare with it to track your progress with Agile metrics and the team’s milestones. This way you can detect any ‘rough’ corners early on and adjust the framework to your needs.
Take the next step
When the ‘point of no return is crossed, and you are well on track with introducing Agile to your non-tech team, do the next step and scale your success. For instance, it can be switching to PI (quarterly) planning and Scaled Agile Framework. It will help the team to get to the next level of Agile Maturity and start thinking about their work in terms of features/epics and product/service they are working on instead of being limited to the planning horizon of a few weeks only.
Sooner or later the team will become quite fluent with Agile and will be able to handle the processes and accountabilities themselves. As the team becomes more mature and self-sufficient they don’t need as close supervision so the role of Agile Coach or Scrum Master will become redundant.
Enjoy the journey
Continue on the Agile Transformation path evolving together as a team, and just enjoy the process. As is the nature of Agile, you will quickly see its worth – within the first sprints perhaps – and never want to go back.
