The previous blog describes the roadmap towards delivering software solutions better and faster. This blog will deep dive into the first step: starting to work agile.
In an IT context, agile is a generic term for a group of iterative software development methodologies. The goal is to already show the product to the end user in the early stages of the development life cycle. This allows refinement of requirements to start earlier than in classical ‘waterfall’ projects. Furthermore, teams working agile are better at managing changes in scope.
Scrum is a widely used agile methodology, but by no means the only one. If your organization already uses another agile methodology, there is no need to change that. However, in this article we will assume the implementation of Scrum as the agile methodology of choice. In this article, we won’t go into detail on how to implement scrum. There are many very good websites and online or offline courses available on this topic. For the road to DevOps it’s important that the implementation leads to the following results:
- All team members are familiar with the concept of sprints and the regular scrum ceremonies are in place
- Scope of work is chunked into backlog items that can be developed within one sprint
- Sprint progress is managed by the team on a daily basis using a tool like VSTS, Atlassian (JIRA), ServiceNow, or VersionOne.
Most agile methodologies assume that all necessary skills for developing software are part of the team. In larger organizations we sometimes find separate teams that ensure compliance with architecture guidelines, legal regulations, security, corporate risk policies, etc. Those teams will typically not provide full time scrum team members. Instead they will want to assess the items on the backlog on a regular basis for potential non-compliance and only want to be involved when those items are picked up in a sprint. In that case it makes sense to set up these teams as so-called guilds or chapters that can assign members to actual scrum teams.
It may take a while for the agile way of working to ‘stick’. But once it is embedded in the DNA of the teams, you will notice that these teams are better at responding to changing requirements from the business.
See for next blog: step 2. PRODUCT!