I started learning about the agile methodologies of software development in 2013 just when the Scrum Methodology was approaching its height in popularity. I was instantly excited and dove deeply into all the material I could find. I read books on Scrum, followed the stream up to the Agile Manifesto, and further up to the Lean Methodology, the grandfather of Scrum. It became the foundation of my team leadership capacity. I saw how this would improve things for my teams, my employers, and myself. Continuously improve, reduce waste and increase efficiency. I embraced the values, principles and methodology and did everything I could to implement them in the workplace. I met every kind of resistance. It was an amazing learning process.

Agile was definitely a huge buzzword. Many organizations claimed to embrace Agile principles for sales purposes or for prestige. Sometimes all it meant was that they could show off how much Agile they bought while at the same time adding layers to their hierarchies. "We bought 200,000$ worth Agile this year! Look how Agile we are! And also cloud! (Cloud is Agile, right?)".  Typically the organization would buy the Agile idea of "increasing efficiency" but the leadership had no intention, ever, of embracing deep change.

Other organizations flaunted their "hybrid" approach, mixes of Waterfall and Agile (i.e. Scrumfall or Scrumfail). Such organizations often equated Agile with Kanban board: "This is an Agile project: we use JIRA. (JIRA is Agile, right?)". They would use a Kanban board to write unmanageable shopping lists of requirements with infinite comment threads where all information disappeared into noise. Sprints would last forever. Agile anti-patterns flourished; the most amazing one I witnessed was using story points to obfuscate estimates. The client saw the estimates in story points, was given some nonsensical explanation about this hot new agile concept, and was thus deprived of information concerning the cost of each feature.

Because everybody and their dog wanted to boast of being Agile, there suddenly was a huge demand for trained (or at least certified) Scrum Masters. These people more or less turned into sad martyrs for the cause. They were given an impossible mission. They were hired to do something that those who hired them did not want them to do. They had to work with teams that were rightfully cynical. The team saw many more meetings added to their calendars and it meant to them that their work would be delayed and they would be required to work longer hours. These Scrum Masters were in a tough situation. They wanted to be agents of change, but they had bills to pay, so tried not to rock the boat and get fired. In essence they were ineffectual.

My situation was somewhat different in those kinds of organizations, and probably more enjoyable, because I always had a dual role in any team. When playing the role of Scrum Master or Agile Leader, I was also either a contributor to the code or provided technical leadership to the team. The Scrum canon does not recommend this dual role, and for good reasons, but it somewhat protected me from the hardships martyr Scrum Masters have to endure. It turned out to be a great advantage. The organizational hierarchies trusted me and tolerated my attempts to bring change because I was an important contributor to the projects; an asset delivering tangible value. The team trusted and respected my experience as a veteran developer. We had a tremendous amount of fun and delivered amazing products. We did our best to embody Agile principles and to enact Agile practices. But in truth, Scrum was always a quest, never an accomplishment. Management would shuffle the teams around, some product owners would be very retentive about backlog collaboration, major changes swathed through teams / projects / organizations with no consultation. But what an education!

Today at Monarq we use the Scrum methodology. We embody Agile principles and enact Agile practices. Our approach is inspired by Permaculture Design principles. 

I leave you with a link to an article by David Marquis I read in 2014 "Small team, multiple projects: an Agile approach to planning" which has been very important for me.

https://davidmarquis.wordpress.com/2011/12/03/small-team-multiple-projects-agile-planning/

Next time I will tell you more about how we apply these ideas.