Being agile? Really?
Scrum has been around for 21 years, and has probably for the past decade been THE most popular software development framework enabling companies and organizations in the software industry to behave agile.
By Jan Mikkelsen, Senior Consultant | 16 January 2017
Agile and Scrum methods have also become very popular in the financial industry – to an extent where the perception of not jumping the train will bring your organization in danger. Agile method is a great framework – when you actually behave agile. If you do not behave agile, it may become frustrating to be a Scrum team member and the expected value of transforming to agile is not materializing. Behaving agile is important, and with this article, I will list a couple of checkpoints within the Scrum framework I believe are especially important for Scrum software development teams to:
- Say they are agile
- Start benefitting from the transformation
The Scrum Framework is lightweight and easy, especially on paper – but reaching Zen is not easy nor lightweight. Transformation to agile is a change of mindsets – we are asking our organization to change what they have been taught for many years about planning, managing and deploying software and projects. It takes time and it is a transformation to be taken step by step and learning by learning. It is also a transformation, a journey without a destination, so you will always have to invest in improving.
So transforming to agile can create a lot of tension and problem areas to be improved or fixed to get maximum value out of Scrum. The ambition of this article is not to list all potential areas of issues, but to list a few typical areas where there typically are potential for improvement:
- Not enough focus on building a Continuous Delivery Pipeline
- Management revert to old habits
- Partly allocated team members
1. Not enough focus on building a Continuous Delivery Pipeline
The typical waterfall software development project puts test and deployment of software as closing activities before users will get their first real experience with their new system. Often the waterfall project is under time pressure to finish in time hence tests are scaled down and deployment is done as quickly as time allows – with the intention to be done once. But eventually ends up being deployed several times until all pieces of the puzzle fall into place. Both tasks are often manual, painful and error-prone and can delay the project even though project team perceives they are done.
SEE ALSO: Known failures in buying Capital Markets software packages
With typical 2-3 week sprints, Scrum (and agile processes) requires a fast feedback on the delivered increment. Hence tests and deployment must be automated typically from check-in in the source control system through building and testing to deployment into productions. It is not just an agile requirement, but in the past years the cost to develop and launch software has decreased dramatically. Only a few years ago the cost to launch an internet site was very expensive due in the cost of servers, software licenses and internet. Since then, cloud infrastructure (such as Azure Cloud Services and Amazon Cloud Services), developer tools (Git, GitHub and Visual Studio Code), open-source frameworks (.NET Core and Ruby) have all emerged to increase the development speed and lower cost of deployment. Today you can build and deploy a service for a fraction of the cost. Invest time and money in a Continuous Delivery Pipeline.
2. Management reverting to old habits
When Scrum does not work, when it does not create productive teams, the reason can often be found outside the Scrum team. A large portion of critical Scrum articles blames management as the main external factor for dysfunctional agile implementations, mainly because they are stuck in old waterfall thinking and have a hard time adopting the new mindset.
If the Scrum team must continue to plan and work as they used to before they started their agile journey, nothing has changed.
The waterfall management has even given birth to a range of frameworks and manifesto (aka Saboagile, Dark Scrum og Half Arsed Agile Manifesto). In the old world management, could follow progress by looking at a Gantt chart and celebrate progress as phases and milestones were reached. It was easy to follow progress and the current state if you believed the produced artifacts were telling the truth about your project’s state. It often did not, mainly because the projects live in a dynamic and changing world with new requirements and learnings every day. But the old habits from the world of waterfall are still used by management and sometimes seen as a phased Scrum project with well-defined end objectives. Scrum is not about milestones and working through phases, but is simply delivering great possible value to the client already after the first sprint. If the Scrum team must continue to plan and work as they used to before they started their agile journey, nothing has changed. Further the Scrum team members are kept accountable through their employment agreements and incentives contracts on fixed dates, cost and deliveries to ensure they deliver maximum “value”. In an agile world date and scope shift constantly, so an agile team member would become confused and frustrated with legacy contracts.
SEE ALSO: Do you understand the value of reconciled data?
3. Partly allocated team members
The Scrum commits to a number of Sprint Backlog items to be delivered during a sprint. The Scrum team will self-organize their work to complete the Backlog items – Ideally they will all work toward finishing the items and build the increment per the definition of “Done”. In the beginning the team may have specialized skills making the work happen in silos or maybe even some hero-work. But eventually it should be possible to have a team of equal team members where everyone can solve all presented product Backlog items and hereby create a productive self organizing team.
It is of course unrealistic to never change teams – but it is important to know the consequence of moving people around.
The transformation of the team will happen gradually – for every sprint completed they will work better together and can increase the number of delivered Backlog items until they reach a certain velocity. Typically, after 4-5 sprints the velocity starts to be predictable and can be used in forecasting delivery of the remaining Product Backlog. In practice the teams may change. People are transformed out of the team and allocated to new projects and new team members are transferred in. This creates new relations in the team – and new ways to work, and the new dynamic will make productivity suffer. Even worse the velocity will become unpredictable and the forecast of delivery of features will not apply any more. It is of course unrealistic to never change teams – but it is important to know the consequence of moving people around. Keep your teams steady to maximize your output.
It was never my intent to deliver a complete list of agile transformation challenges – but the listed three areas are typical challenges in many organizations and require focus to make the transformation run faster.
