AgileIndy, a developer’s perspective
First, I want to give some background on myself and my relation to the Agile movement. I have read the manifesto, I have worked on teams that have used scrum, and have also worked on some teams that practiced Agile. However, AgileIndy was my first agile conference and my first software related conference in general. I also personally believe that the Agile brand has somewhat taken over the movement. Going into this event I had a strong negative bias that I attempted to correct for. I most likely did not completely succeed, so my views will be somewhat colored.
I will go through each talk I attended and provide details as well as my opinion. The slides are available on the AgileIndy website. My notes are from what was not on the slides or things I felt were emphasized enough to note despite their presence in the slide deck.
AgileIndy: Opening Remarks
Bryan’s emphasis was on getting to know the other people attending AgileIndy. He challenged everyone to set up a meeting with someone you do not know, come out of the conference with at least one new idea, and at least one action you will take based on information you learned at the conference. If you did these three things, you would receive a cash reward at the end of the conference. He also proposed MAMA (Make America More Agile) hats. This was on account of us being next-door to an NRA convention attended by President Trump. There was also some football talk.
I think he was right in that there is a lot of value in getting to know the other people who are attending the conference. However, I did not have any intention to schedule a meeting with someone for next week. It would have been interesting to replace one of the 50 minute talks with a networking session. I think someone had a little chat with him about MAMA off screen, as that was not mentioned again for the remainder of the conference.
AgileIndy: Morning Keynote
His talk focused on Business Agility. This is the concept that if the business is not agile, it will not matter much if their software development is agile. Specifically, he argues for a focus on the people in the company as what drives the company. Humans should not be treated as resources. On an individual level, you should favor in-person interactions and choose to take action when others hesitate. On a process level, focus on continuous incremental improvements. If you are doing sprints, bring the stakeholders in several times during the sprint to build acceptance. During the end of the talk and Q&A, people were leaving – most likely on account of the late start.
This was a good talk. The points were clear and his personal anecdotes were in support of them. I don’t have any real disagreements with his topics. I do think that the line between Agile and common sense is a little bit blurry. For example, what is the argument against continuous improvement?
The F Word: Why your project is failing and what to do about it
Laura’s talk started off with identifying the signs of failure:
- Lack of trust – Poor rapport between teammates
- No one talks with each other about their life outside of work
- Avoiding the client / hiding information from the client
- Meetings before/after the meeting
- Low morale – People not willing to put in extra effort when needed
- Emphasis on the letter rather than the spirit of what was asked for
The following solutions were proposed:
- Lack of trust – Build interactions with the team
- Transparency with the client (especially when it hurts)
- Low morale – Celebrate wins, even small ones at the start
I came out of this talk a bit dissatisfied, but couldn’t put my finger on it at the time. The example given was of a project that was failing, but had been turned around. I have been on my fair share of failed projects as well, but none of them were failures on account of lack of trust or team morale. This talk was focused on failures that can be conceivably turned around. Trust and morale are issues that can be corrected. Sometimes there is no way for the project to succeed. The only thing keeping it going is the sunk-cost fallacy. So I guess what I was looking for was ways to identify that early and how to convince the stakeholders to cancel the project. That being said, I did not think this was a bad talk – I just had a different expectation based on my experience with failure.
5 Effective Ways to Leadershift
Prathima’s talk was discussing the issues around changing company culture. The key point is to build trust with the people who need to implement the change. When meeting resistance to change, re-evaluate the change and temper it if necessary. Also, accept that some changes will fail, and that is okay. Ensure the changes are focused on making it easier to share skills throughout the company.
This talk was a bit less memorable than others. I think the examples used to further the argument were a bit undetailed / abstract. One of the statistics mentioned during the talk was that only 12% of agile companies are success stories. I was curious if this was meant to be only 12% of agile ‘transformations’ end in success. I’m going to assume it was meant to be transformations, because that makes more sense. Hiring coaches to make my company ‘do the Agile’ is somewhat at odds with putting people ahead of processes.
AgileIndy: Lunch Keynote
The speech was about using a priority map to help get things done in your personal life. Choose 3-4 fairly generic goals that are important to you. Then create tasks that map to those goals using colors to differentiate them. Try to get some number of those tasks done every week. The second half of the talk featured a personal experience of overworking almost to the point of death. Concluded with the wisdom of not focusing on your accomplishments at the expense of living.
This talk was somewhat inconsistent. The messages were mixed and I did not find the examples compelling. I personally am not a fan of motivational speeches, so I am somewhat biased in my assessment. That said, the concept of applying a priority map to your personal life is interesting. If the talk had been focused on examples of people doing that while maintaining work-life balance, it could have been excellent.
Dealing with Team Dysfunction w/out Ending up in jail
Kimberlee’s emphasis was on building interpersonal trust with team mates. She posits that any organizational change can be expected to cause team dysfunction. Also, when there are people issues, they cannot be solved with process. A good way to prevent dysfunction is to build a common vocabulary shared between the team, any managers, and the customer. Highly dysfunctional teams do not happen overnight, but they become more dysfunctional over time. It is best to recognize signs of dysfunction as early as possible and act to reverse it.
This was a good talk. The examples were relatable and entertaining. I’ve noticed a trend of trust being an important topic of almost every talk at AgileIndy. I have been on teams where the lack of a common vocabulary created problems with communication and morale.
Agile Assessment: Helpful Remedy or Harmful Toxin
I did not know what an Agile Assessment was prior to this talk. So I may have noted down some things that are pretty obvious. There are four types of assessments that vary in how invasive they are. Ranging from looking at metrics that are already being collected to issuing surveys and sitting in with teams. Dan emphasized that the assessments were not to be used for deciding anything salary related. Instead of highlighting weaknesses to remove, you should focus on finding strengths to enhance. This analysis should be performed with the cooperation of all stakeholders.
I did not find this talk particularly compelling. It may just be that I have not bought in on the usefulness of the Agile Assessment. Kinda reminds me of Six Sigma.
Fakes & Bullies: Taming your impostor syndrome to find your inner thought leader
I didn’t notice until now that the title on the pamphlet and the title in the presentation don’t match. The first part of this talk was about managing the imposter syndrome. This is done by being aware of your own vulnerabilities and attempting to compensate for them. At the same time watch your own tendencies to bully others. Do not defend yourself from criticism. Listen, and then evaluate the criticism once your emotions are out of the picture. The rest of the talk was about developing thought leaders inside your organization. You should ensure it is safe to voice ideas, even dumb ones. Provide opportunities for people to grow, including trialing some of their dumb ideas. Who knows, maybe something doesn’t turn out to be quite so dumb after all?
This was a good talk. It is definitely harder to improve when people do not feel like they can safely voice their ideas unless they are 100% thought out and bulletproof. A deeply flawed, incomplete idea can be shared, then elaborated on and enhanced by others.
AgileIndy: Closing Remarks
This part of the conference was almost purely vendor giveaways. I will note that only one person accomplished the objective from the opening remarks (making an appointment to talk to someone they met at this conference next week). Theoretically, I would have expected at least two people, but maybe the other person had to leave early.
I noticed while writing this that my notes were much more detailed in the morning than in the afternoon. Overall, I am glad to have attended AgileIndy. There were good ideas, bad ideas, kool-aid, and somewhat of an echo chamber. However, I do believe that the good outweighed the bad.