Thoughts on my First Agile Experience
I am a Software Engineering & Management student. This is largely the manifestation of some deeply rooted desires to design and implement large, distributed software systems as well as manage teams in order for them to operate most effectively. When entering my 2nd software developer internship, I was pretty happy to hear they were just phasing in new Agile practices into their software development workflow.
What I wanted to do hear, is comment on my experiences being involved in such a process from a rather novice perspective. I do know this is highly contextualized, pertaining to one person in one company, but nevertheless there could be something to learn when on-boarding entry-level employees into your company.
Agile, a definition
I guess a good place to start is what I think Agile means. This could very well be different from what you think or what all of industry thinks, but this the impression I got from my working experience. Agile is a way to prioritize work. The important distinction I want to make is that you don’t do Agile while you are working. Agile methodologies simply allow you to say “we should focus on A instead of B, because of C”. The most important part of that quote is the C, as it is the justification for doing A over B. In reference to Agile, some C’s can be focusing on value for a customer, coding instead of documenting or changing your plan for delivering a element of work.
What most people (I find) mean when they say they are Agile is they implement practices commonly found in Agile environments which allow those environments to be truly Agile.
Standups
Perhaps the pinnacle of Agile practices, the standup is a daily meeting with all members of the team to speak to the progress of the current task. It is usually, but not exclusive to, the Kanban board. The Kanban board is a way to track progress of tasks through certain stages most tasks travel through. Examples of transitions can be from In Progress to Review or To Merge to Done. Standups usually take 15 minutes, but the average length and capped time can be up to your team to decide. What is commonly instructed to be discussed is the following, for each team member: What did I do yesterday, what am I going to commit it to today, and am I blocked on any task?
I find these questions to be okay to ask, but often lose the purpose of the meeting. If the purpose of the meeting is to ensure goals are being met, what is the purpose of saying you are on track to meet it? For example, if a task I work on is estimated to take 2 days and I get half of it done on the first, should I tell everyone? I don’t think so. Every member should be okay saying two things: I am struggling on this task, or I am running out of tasks. Those are scary remarks, the former says I am not good enough and the latter says you could probably fire 20% of us and be fine.
Instead, I suggest asking these questions: Are there any tasks taking longer than anticipated? Are we on track to meet our goal? Hey Name, can you do something for me to make this task move across the board? The key distinction is to not make the meeting about people, but about tasks and goals. I found this to be much more productive and encourages people to identify problems without attaching a person to it.
One more note is to allow anyone to suggest side-barring ant conversation. Side-barring is the act of saving a conversation which pertains to a proper subset of the team members to be continued after the standup. Developers and Engineering, myself included, can easily lose track of how technical a conversation is getting when it shouldn’t be doing so. Nobody should feel they can’t interrupt it and have an open discussion to whether the conversation pertains to the whole team.
True Autonomy
I am an avid fan of true, fully autonomous teams. Autonomy is the ability for an entity to perform some action. To be fully autonomous, you should be able to do anything you feel necessary to do. Realistically, this is not possible. I cannot change my work from developing a SaaS application for my company to making wicker baskets because I want to. However, I would strive to allow every team to take whatever action they believe necessary.
The kicker? Performance. The less you micro-manage a team, the more you should expect to read and comment on their performance. This involves auditing performance before the change, designing goals based around the change and why the team is doing so and lastly auditing at pre-determined intervals.
The benefits include being able to manage more teams as you aren’t as involved in their processes as much as you were before and you create an environment which encourages unorthodox ideas and has a bias towards action. For Agile environments, this bias is incredibly important to deliver value and accepting changing requirements.
Closing Remarks
These are some of the many thoughts which came up during my internship, but are definitely the most important. If this helped you in any way I am extremely happy it did but if you have any problems with it, I do encourage you to destroy me in the comments. I am open to all comments and welcome the opportunity to learn more about the software development process and team management.
