We just want to be agile— Part 1
Everyone either claims to be Agile or wants to implement it. It’s the buzz word companies are looking for. By implementing Agile, our industry seems to continue moving further away from the initial intent of agile. Take a gander at the Agile Manifesto.
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
**This is based on the assumption you have some basic understanding of Agile & Scrum practices and development life cycles.
In the manifesto there is value in the items on the right, but we value the ones on the left more. Why does it seem so difficult to implement Agile then? This simple set of guidelines has spawned a mass of confusion and negative perceptions of becoming agile.
We seem to be so caught up in implementing Agile that I believe we’re moving away from just being agile. Yes, we’re talking about the noun versus the verb hullabaloo (Agile vs agile). Agile has created some great process and structure to support agility. Unfortunately, we seem to get so caught up in this process that we lose focus on what we set out to do.
If you’re unfamiliar with the noun vs verb thing, here’s a little update. It was set out for development teams to become more agile (verb). As the Agile manifesto was created, it was quickly adopted as the Agile (noun) process. The Agile process is now used to create certifications and sell services. Many believe Agile has moved away from the initial intent of being agile.
Definition of agile:
1. quick and well-coordinated in movement
2. active; lively
3. marked by an ability to think quickly; mentally acute or aware
At IHME, we’ve tried a couple times to implement Agile. We created all the meetings like daily standup, backlog grooming, and retrospectives. A scrum master was brought in to help set up and manage the process. We were strict on sticking to our sprints. We tried to estimate in story points and hold our weekly retrospectives. IHME has a fantastic atmosphere that supports collaboration and innovation, but, for reasons I won’t explain now, we failed to implement Agile.
There is a misconception among the business folks that Agile is just a way for development teams to say ‘No’ and hinder their ability to get projects done quickly. Impressions that requesting a feature that “should be quick and easy” could take weeks to get into production or the idea that they can get 5 times the productivity out of the same development team.
You’ll see me use Scrum and Agile interchangeably throughout this. I understand this may not technically be correct but that helps emphasize the confusion within Agile.
Where do these misconceptions come from? According to Scrum, you should avoid disrupting the sprint, if at all possible. This means that requesting a feature in the middle of a sprint means it ain’t happening now. If we assume the product owner is able to gather all requirements before the next sprint, we’re not starting the work for 1–2 weeks. In Scrum, you should have all work completed in the sprint releasable at the end of the sprint. This means we’ve now pushed this feature to 3–4 weeks before it could make it into production. A simple feature that could take a couple hours to a couple days to complete and test takes 3–4 weeks?! Business owners don’t want to hear a simple feature can take up to a month to be implemented. I know this isn’t how all scrum masters and agile coaches work but a lot do. There are a lot of people who have the perception this is how it works. Perception is reality.
How do we provide the benefits of agility with the structure of Agile? We can’t be so pinned down by process that it stifles our creativity and ability to iterate quickly. At the same time, we need some structure to properly commit to work as well as understand the amount of work we can effectively complete. We want our business partners to be happy we’re agile and not upset we’re implementing Agile.
Our aim at refining our current implementation of Agile is to simplify our Scrum process. We want to focus on providing a better experience for our business partners by providing clear expectations of priority and product delivery. Within the team, we hope to improve our developer dependencies and increase each developer’s skill set.
Over the next few months, we plan on publishing multiple posts around different areas of the process, meetings, and team structure.
Part 2 — Team Structure/Organization (Coming Soon)
