How do we go about to instill an Agile mindset and help teams deliver quality solutions? The two main strategies are the “Big Bang” and pilot project approach. I’ve never had the opportunity to go ahead with a Big Bang, so the alternative has been to find a cool project, get a team together, Scrum the hell out of it and watch all the nasty stuff come up. With a few lessons learned and improved processes, start up a second team and so on and so forth.
During a transition process, I often use the same expression as when I’m writing a piece of code: Baby Steps. Baby steps are a good thing! Write a small test, write a bit of code, make the test pass, refactor, rinse and repeat. But in an Agile transition, baby steps are more like compromises. That is, we start a Scrum pilot project and we “temporarily” set aside, bend or extend some of the principles of the Agile Manifesto and pillars of Scrum.
So when a team or an organization feels it necessary to not go full steam ahead with what I consider to be the best way to create quality software, I constantly ask myself : Are we simply taking a baby step towards something more “agile” or are we setting a bad precedence?
A few examples:
- The core team is not 100% on the project- Baby steps or Bad precedence?
- Co-locating teams might happen…one day – Baby steps or Bad precedence?
- Little to no focus is put on improving Agile engineering skills – Baby steps or bad precedence?
- The newly assigned ScrumMaster has never even heard of Agile, Scrum or XP – Baby steps or bad precedence?
- The project is more mini-waterfall than Agile – Baby steps or bad precedence?
- The first 25 items in the Product Backlog are non-functional requirements – Baby steps or bad precedence?
- Transparency is set aside not to upset upper-management – Baby steps or bad precedence?
So if the members of team A are allowed to not be fully dedicated a one project, and a nonchalante “ScrumMaster” tech lead is assigned, what will happen when team B’s manager sees this? Ya ya, I know… Team A and its manager will see the error of their ways, the appropriate changes will be applied quickly and team B will profit from those learning experiences all will be rosy in lala land. Sometimes it happens but it becomes rare when it involves core practices of the organization.
So why do we accept this?
Well since excuses and justifications are the ointment to any compromise to the Agile Manifesto, let me offer you this one: If we, as Agile coaches push too hard, we are perceived as purist, not in tune to the reality and constraints of the organization. Pushing too hard might actually result in the opposite of the desired effect and the Agile transition will force two worlds to collide and the whole thing will go kaboom!
Baby Steps or Bad Precedence?
So how do we make that call? Even better question, how do we bring a team and its organization to make that call and consider the short to long term consequences? What is the break point between Agile values and half arsed Agile values? Do we simply rely on common sense when common sense is often in short supply, or is there some kind of calculated “kaboom factor” that could help guide our decisions?
Baby steps are fine as long as we are not stepping right off a cliff!