"Based on a wide variety of surveys taken over recent years, many companies are transitioning to something that looks more like Agile than the processes they were using in previous years. However, that transition doesn’t necessarily mean implementations have been done respectfully of the Agile Manifesto and the principles behind it. In large part, industry trends seem to indicate that the sloganization of the word has done a significant disservice to the ideas that were originally founded in 2001. To add even more pain, most people seem to be entirely unaware of the core basis of Agile which is the idea to embrace change but inspect and adapt to that change. Are we lost as an industry? Is there anyway we can recover from this problem? In this session, attendees can expect to engage in a conversation about the rise of the Agile community, the negative and positive impact it has had on the industry, and how you individually can help your organizations and teams lower the risk of encountering the negative problems, and speed your way towards the positives. Topics will include:
- The intentions behind agile.
- Ways you can rework or improve your not so great agile situation.
- Things you should avoid from the start."
Jen Krieger, Chief Agile Architect, Red Hat
As someone who has worked on Agile(ish) teams, the idea of companies claiming Agile software development methodologies while only really adopting the vocabulary is a familiar concept. Unless you truly embrace change and think of it as a good thing, you cannot realize the productivity gains of Agile.
Jen's talk is on how you can move from Agile-ish to Agile, or even better, to implement Agile anew focusing on more than the nomenclature.
Agile is not something you go get a certification for and are bestowed the title of an Agile team. Often people just go implement the specifics of Scrum, leaving out the continuous communication, continuous delivery, business input, planning and retrospectives.
Where We Still Fail
Agile requires organization-wide planning, but it is often just implemented on a per-team basis. After all, it is all about getting more work out of developers, right? Most organizations still fail to realize this change. To realize the benefits, you truly need organization-wide changes and involvement. Without this, it is just a short waterfall development cycle. It is still Command and Control, telling the developers to go do something and leave the important business people alone. To start fully embracing Agile, begin with a few simple principles.
Agile Manifesto
Agile has 16 principles, but to highlight just a few that yield immediate benefit:
- Deliver working software frequently, from a couple weeks to a couple months with a preference to short timescales.
- Define a method of delivery which can just be showing your software to your customer.
- Delivery is not just about features, deliver technical debt reductions, bug fixes, etc.
- Continuous attention to technical excellence and good design enhances agility.
- Know best practices and do them.
- Leave the code base better than you find it.
- Involve SMEs, including SysAdmins, InfoSec, etc, early on.
- Automate all the things.
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Once you take these points, realize that Agile should be fast moving, but not so fast that teams cannot keep up and lose interest. Similarly, don't go so slow that teams are bored or doing the same thing over and over. Iterate and improve, you'll also end up increasing your delivery capabilities.
Importance of Organizational Change
Agile requires systemic organizational change, starting with the manager of the agile team(s). Agile is about collaboration and cultivation. It is absolutely not about command and control. This can be hard for managers, who have to redefine their roles in the Agile world. Managers need to fundamentally trust their teams. If they don't, there is no benefit in doing anything with Agile. Likewise, managers need to be advocates for their teams, resolve roadblocks, and assist with communications.
Just as managers need to adjust, the teams need to do as well. Learn. Don't stop. Learn about CI/CD, best practices, new frameworks, new methods. Ask questions and define boundaries around what people are supposed to be doing.
Finally,
You succeed first and foremost because of the people. A distant Second is the process. Third are the tools.
About the Author
Brian J. Atkisson is a Senior Principal Systems Engineer and the technical lead on the Red Hat IT Identity and Access Management team. He has 18 years of experience as a Systems Administrator and Systems Engineer, focusing on identity management, virtualization, systems integration, and automation solutions. He is a Red Hat Certified Architect and Engineer, in addition to his academic background in Biochemistry, Microbiology and Philosophy.
