By John Carrington, AgilePM® Practitioner and Trainer, CSM, PRINCE2®, LSSBB
Let’s start with how and why Agile came about. In 2001, 17 Software Developers met in Snowbird, Utah. They recognized that the way being used to deliver software in projects was not working and software developers typically burnt out in their careers.
Teams would be working all hours to deliver on commitments given at the beginning of the project, which could no longer be met due to changes encountered along the way, like the customer changing their mind or things coming to light that hadn’t been planned for. The pressure of delivering using traditional methods meant that life as a software developer in the 80s and 90s simply could not be sustained. They needed to find a way that people could work and deliver software at a sustainable pace and keep going in their chosen careers, past the age of 40! The Agile Manifesto was born.
According to the 2016 VersionOne State of Agile™ Survey:
- 87% of respondents reported being better able to manage changing priorities after implementing Agile.
- 85% said they had increased team productivity.
- 84% reported improved project visibility.
So let us not forget the reason Agile came about in the first place: to improve the daily lives of the team.
Agile helps teams adopt and continue habits which produce regular, consistent results at a sustainable pace of delivery.
One of the benefits of doing that, over the long term, is the longevity of team members’ careers.
Businesses are often attracted by the better, faster, cheaper benefits — and the teams delivering software benefit by becoming self-organized, high performing teams.
In traditional approaches to managing projects, the time when commitments are made and milestones are confirmed is at the beginning of the project in the planning phase. At that point, delivery dates are far enough away for everyone to be comfortable in their commitments.
The problem with this approach is that the beginning of the project is the time when the development team knows the least about the solutions the team is building, but it is also the time when plans are formed, dates are committed to, and deadlines are set. So they don’t know at this stage which problems may surface and what investigation work will need performing. In other words, they don’t know what they don’t know.
Scrum is one of a number of Agile frameworks that encourages ceremonies or events at various points in the sprint which is the time allocated to development work. These ceremonies enable the team to adopt working practices, like regularly reviewing the work with the customer, and retrospectively looking back at how the team performed in respect of the framework, which facilitate iterative and incremental development.
For example, the 15-minute Daily Scrum is a meeting for the team to update each other on progress, to ensure they are on target to meet their commitment of the Sprint Goal and to ensure there are no blockers.
You don’t need more than 15 minutes to do this, but new teams tend to overrun, which means people stop attending because they take too much time up and it becomes “Anti-Scrum.” This is a clear example of where “doing Scrum” because the guide says we need a daily meeting and “being Agile” are in direct contrast, as approaches.
Scrum can help teams to adopt Agile ways of working by providing enough rigour and discipline in the form of ceremonies/events, roles and responsibilities and artefacts for those teams to develop strong habits of working with Agile practices.
By sticking to the somewhat rigorous Scrum Framework, Agile teams learn good habits and develop a sustainable pace, working to their own commitments rather than to a schedule defined and managed by someone else.
Agilists are generalising specialists… Scrum teams are the “Special Forces” versions of software development teams because they are multi-skilled and cross-functional – small enough to have all of the skills they will need but not too large so they remain agile.
In fact, the special forces analogy continues because in Agile, we talk about “T-shaped” teams where team members have more than one skill, just like in special forces patrols. If one team member of a special forces patrol becomes unavailable, then the idea is that the whole team is not compromised.
In Agile teams, whilst the situation is less “life and death” (although it does not feel like it sometimes!) team members are cross functional so that we limit the amount of times we need to go outside of the team to get the work done. The other benefit is that we continuously learn and improve from each other and as a team.
It’s a Brave New (Agile) World
As we look at the job market over the coming months, we are likely to see more permanent and contract roles specifying Agile skills and there is certainly great opportunity to be realized with those with Agile and Scrum qualifications. That being said, many traditional roles are not, at first glance, part of the Agile vision, so Project Managers, Business Analysts and others are naturally wondering where they fit in.
Many larger organizations are experiencing transformations at the moment and businesses of all sizes are trying to figure out how Agile works at scale. We are seeing job postings for hybrid roles such as Scrum Master/Project Manager and Agile Business Analyst, Agile Delivery Manager, and Agile Coach/Scrum Master as the job market struggles to understand the roles and the differentiated responsibilities within an Agile environment.
Part of this momentum will be a natural restructuring of hierarchy, a necessary re-organizing of roles (both in title and responsibility) and recruitment campaigns that bridge the gap between the hybrid approaches of the early Agile adoptions and take the job market through to the required level of understanding of permanent and contract roles.
Until both organisations and recruitment agencies truly understand what it means to be Agile, we are likely to see more of these “hybrid” roles until organisations catch up with their own transformations. The job market is likely to see lots of changes in the near future whilst the changes that large organisations are making by transforming to Agile approaches filter through to their talent acquisition efforts.
Take this opportunity to ensure you have the key Agile skills that these businesses are going to need to give yourself the optimal chance of getting that next position!
More insights await at the virtual Agile and Scrum conference, going live on May 4th. 5 keynotes and 20 sessions to choose from, plus networking and PDUs/SEU®s.
About the Author
John Carrington (AgilePM® Practitioner and Trainer, CSM, PRINCE2®, LSSBB) is an experienced consultant, well versed in all aspects of the Agile project lifecycle and program management, with over 20 years of experience in corporate businesses. John has been involved global software implementations, business transformations, and change projects. John is an excellent communicator with strong influencing skills and a passion to deliver the highest quality outcomes, on time and within budget.