I was able to attend the AgileIndy conference again this year. What I will do here is give a summary of the content of the talks I attended. Or at least some notes that I took. These notes do not entirely capture the talk itself. If you want more information, hopefully, that will be a driver to attend AgileIndy next year. I will also provide some discussion about what the topics meant to me. I hope that you gain some understanding of what AgileIndy is and what you can expect to learn by attending.
AgileIndy Kickoff Rita Emmons
Rita began by thanking speakers, organizers, sponsors, and attendees. She then went over various event facilitation topics. She also spent some time talking about how this is the first in-person AgileIndy since COVID. Finally, she hyped people up for the keynote.
AgileIndy Keynote | Building a Culture of Agility Mike Cottmeyer
Summary
Agile Culture and Performance
Mike’s keynote began by discussing the relationship between culture and performance. Then questioning the intuition about which one of those drives the other. The premise of the talk is that you can change a culture by demonstrating good performance. But if you try to change culture, and that does not result in good performance… that change is likely to revert. This is a challenge to the notion that an agile culture will produce agile processes and delivery systems.
Instead, focus on the system. First, create a working system that delivers value. Once stakeholders see that they are getting more value out of this new system, trust will increase and they will be more amenable to agile practices.
There are two types of culture (4 in next version of the talk): red culture and blue culture. Red culture focuses on results and accountability. Blue culture focuses on trust and empowerment. We want both of these cultures/personalities in the company. Without the blue focus, people won’t want to come to work or be motivated to do much more than the bare minimum once they are at work. Without the red focus, managers will step in and mess with the process: micromanaging, dictating the process, etc…
Dependencies Inhibit Agile
The talk then shifted into how to deal with dependencies. Primarily dependencies a scrum team has on other parts of the organization. If you try to ‘self organize’ the dependencies away, that’s not going to go very well. If you try to ignore them, the scrum boundaries will end up breaking down, meaning the teams no longer act independently. Dependencies impede agile practices. Therefore, they need to be either broken or managed in order to develop an effective agile delivery process.
Mike gave two examples of dependency management, SAFe and the Spotify Model. Agile transformation is about breaking dependencies at scale to enable encapsulated teams. SAFe can feel like a heavy process, but in an organization with many dependencies it is probably too light. Once you reach a certain level of scale, a component architecture is required to minimize and manage dependencies.
Random notes: Sometimes the customer is another agile team. Kanban is waterfall in small batches. At the team level, people are doing scrum/kanban, but governance requires some sort of visualization. PO is supposed to bring a prepared backlog to sprint planning. A scrum team should have 3-4 weeks of ready backlog. Planning means a prioritized list of epics. A scrum team should do 2-3 stories per sprint. Don’t let your team build something that takes longer than 3 months. Sprint commitment is a number of points, not specific stories.
Agile Transformation
For a large scale agile transformation to take effect, agile needs to happen at multiple levels of the organization. If we don’t want command and control style leadership, we need to give leaders other levers to pull. No transformation happens overnight, even if you attend AgileIndy. It is a process and will take a long time. That said there will be notable improvements that happen along the path.
- Start by being predictable against a known backlog
- Reduce batch size, get more predictable, add CI/CD
- Turn seems in the organization / technology in order to break dependencies and encapsulate
- Fund teams rather than products
- Ask team to disrupt market / research
Add an abstraction layer to the organization, achieve a critical mass of agile practices, then break the abstraction layer. Trust your teams with their throughput, don’t overload them. If you want regulatory controls dismantled, demonstrate a better way – make the system trustworthy. Functioning systems are a predictor of a balanced agile culture.
All published practices work. But they require a specific context. Which is often difficult to achieve outside of the organization that published the practice. Build a system for your organization that people want to work in.
My Thoughts
I found it interesting that a scrum team (6-8) people should be doing 2-3 stories per sprint. What I have typically seen is 2-3 stories per individual contributor per sprint. Probably the disparity is the size of the stories. If those 2-3 stories for the team break down into several tasks, we could be looking at the same thing. It could also be an exterior context vs an interior context type situation. The customer sees 2-3 significant changes per sprint vs the team seeing 12-18 work items per sprint. This thought will be revisited in the next talk.
Furthermore, I liked the idea of the sprint commitment being the velocity rather than specific stories. That feels a lot better than just not having a commitment. Even though it is essentially the same. And a lot more realistic than committing to finish every story that was added at the beginning of the sprint.
I am also on board with dependencies and lack of encapsulation being the major hurdles that need to be overcome.
AgileIndy Talk | T-Shaped Teams: How to Speed Throughput by Avoiding Over-Specialization Dave Todaro
Summary
Dave introduced this as a way to handle dependencies that may interfere with delivery. For this talk, the dependencies are inside the team. What often happens in a cross-functional team is that you get several small (maybe even 1 person) teams. For example: back end, front end, mobile, and test. This result is siloed specialization and dependencies within the team. This forces a waterfall process.
In some respects, an agile process is a mini waterfall process. But the difference is we’re doing a little bit of everything all the time. That is not the only problem with the hyper-specialized team. The work is usually not divided into equal buckets. We might have a lot more back end work than front end work, vice versa, or anything in between. This leads to developers dipping out of the backlog because they have ‘nothing to do.’ Meanwhile, the most valuable user stories are still in progress. There is little/no swarming or pairing.
The goal of sprint commitments is to on average meet them 80% of the time. It’s okay for people to be the best at x. But not the only person who can do x. T-shaped teams more refers to the people being T-shaped. They have deep specializations, but are capable of working outside them.
How to Mold People Into T-Shapes
Ask team members what they are skilled at and what they would like to be better in. 3-5 stories for a scrum team per sprint. T-shaped teams also manage risks better. If a specialist gets sick or takes vacation, there are others who can step in and do the work. The key success factor is making work a team driven process. People need to be willing to share or acquire skills as needed. Good methods for sharing information: pairing, mobbing, code reviews, and fixing bugs.
The scrum team owns everything related to the project, including maintenance and operation. Try writing down all the times you have been waiting and for whom. Get stakeholders to show up to sprint reviews.
My Thoughts
Velocity rehash
I said I’d revisit my thought about stories per sprint. In this talk it was 3-5 stories per scrum team per sprint. So we’ve got at least 3 people at AgileIndy who think different things when saying story. I believe the size of a story varies from team to team. Or company to company. I don’t think it is useful to compare / give a guideline of how many stories per sprint a team should do. However I can share what I like about 2-3 stories per individual contributor per sprint. If we are achieving that, then each team member should be going home for the weekend satisfied that they have accomplished something. I think the why is worth more than the number.
On T-Shaped Teams
For our company, we don’t really have front-end/back-end/mobile developers. We have developers. As contractors we don’t expect to be working in the same tech stack from project to project, so the assumption is you will learn. We do tend to build our teams around one or more people who are familiar with that tech stack to facilitate the learning process. So I guess our default shape is T-shape.
Though what I was thinking during this talk was on teams where you have, say, software engineers, mathematicians, and therapists. I feel like the concept breaks down when you have people who went to college for different things. That said, I think it’s possible for these people to help each other when it comes to areas within one specialty. You would just need to, for example, frame a portion of a software problem as a therapy problem. Easy.
I think the answer is this is a completely different problem than T-shaped teams is meant to solve. I think the “scrum” answer to this problem is that it ends up being painfully obvious when one of these specialists runs out of useful work to do. And in that case it’s time to change up the scrum team. Or a better way of putting it is you have, say, mathematicians on the scrum team while the product has a dependency on math. Once that dependency is irrelevant, the mathematicians can move on.
AgileIndy Talk | Powerhouse: Building Durable Agile Teams Laura Hansen, Tessa Hoeing, Ryan Matey
Summary
Laura opened with introductions – you may be surprised to be listening to a talk by recruiters at AgileIndy. Then moved on to describing how it’s important to be very intentional when it comes to building teams. The interview process has three phases:
- Introduction, work history, salary
- Technical Interview
- Meet with team, determine fit and culture
The ideal team player is a combination of hungry, humble, and aware. However, team members may be threatened when someone smarter, more engaging, or experienced joins the team. Don’t let people on the team if they are not a good fit. This is bad for both the team and the candidate.
The whiteboard interview measures how the candidate deals with pressure, how they can explain complex concepts, and their ability to read a crowd. After the interview, we will discuss the candidate/new hire with team members. Once the candidate is hired, we meet roughly half a year or so to dicuss how things are going.
OpenAir – professional services automation
The cost of adding a bad fit to a team is high. This cost manifests on recruiting, onboarding, and existing team members. Furthermore, it is also bad for the candidate. The cost is approximately 35% of the candidate’s salary.
Clear and complete onboarding is very important for new hires.
Lessonly – on demand training
It is important to invest in employees consistently throughout their career.
My Thoughts
I was surprised that this was a recruiting talk. Given the context of recruiting, I can see the title. When I first read the title I saw something different. I thought building and managing teams within the company. That said, I do participate in technical interviews at my company. So, I was still interested in the talk.
I’ve actually wondered for some time if the model of building a team first, then searching for projects would be effective for us. It looks like that is the standard practice for emagine. The way we work is we assemble a team to tackle a client’s project. Therefore it is quite abnormal to have the same team persist across multiple projects. Or even the team size be consistent through multiple projects.
Okay, tangent over. For recruiting, we actually do a lot of the same things. However, our recruiting team consists of volunteers from amonst the engineers. At every step of our interview process you are dealing with your potential co-workers. I’m sure that makes our recruiting process more expensive.
AgileIndy Talk | Blending Product Thinking with Architecture Joel Tosi
Summary
Joel started the talk off by reviewing a quote about technical debt: Technical debt is the difference in knowledge between now and the time the code was written. All architecture decision points have tradeoffs. Bad architecture cannot be solved by a good process.
Strategic DDD: look at the product for ways to map it to teams or structures.
First, find the product boundaries – where the context of the application changes. Next, look at the clustering of events from the product lifecycle to find context boundaries. Then, find the commands that cause the events to happen and find parallel events. Finally, look for areas where the context is distinct.
This allows you to see which teams are dependent on each other. Then you can find the core data set that each team is responsible for.
Model Exploration Whirlpool
- Scenario
- Model
- Code
- GOTO 1
Challenges: inventory of systems, often lots of duplication in products. Reports tend to be within the context, not a separate context. Overloaded words within a context is often a sign that there should be more contexts.
C4 Modeling
C4 Modeling – model systems architecture in a certain context
- Context – persona, external systems, user’s system
- Containers – various applications (web, mobile, backend), teams, visualize dependencies
- Components – services, api, components needed to service the applications, see severity level
- Code/class – Didn’t do it, was enough benefit in the first 3 Cs
Serialize the architecture – let the other teams know what is going on. Look out for loops between teams. We saw proxy/passthrough teams.
Architecture Decision Records – update to keep people informed about the tradeoffs and decisions. Try and think of ways you might be wrong and what you would do different. Think about modeling that provides rich context to people. Sign of success: developers comment about how much easier it is to do their work.
My Thoughts
This talk strikes some of the same chords as the morning keynote. Teams work more efficiently in encapsulated areas where they have the authority to make decisions.
Developers commenting about how much easier it is to work in a good architecture is definitely true. The comment was kind of laughed off as something that never happens. And maybe those comments don’t often make it back to the architect. But if you’ve worked in a variety of code bases, it can be obvious. Consider how much you don’t have to think about when working in a code base with a solid architecture. It is really all about encapsulation.
Speaking of encapsulation, you can encapsulate too much. And that is where the concept of meaningful context comes in. Teams need to be able to make independent decisions within their contexts. If the encapsulation is too fine grained, there are no decisions to make. Which is fine if the people creating the encapsulation layers have ultimate knowledge. Unfortunately, that is not the case. The team working within that layer will have more local knowledge and will be better able to make those decisions.
AgileIndy Talk | Scrum Meetings Gone BAD Kim Brainard
Summary
Kim started this off with an exercise to crowd-source problematic meeting behaviors. The most problematic meeting behaviors amongst attendees were yelling, fighting, sleeping, (remote) absent when called upon. Leadership has a lack of trust in teams (15% have trust in workers, 87% of workers feel productive). Too many meetings are happening because people are paranoid about productivity.
Therefore, we need to minimize meetings while keeping them sufficient. First, begin a meeting with engagement related to the content. Then, motivate participation and give people a reason to participate.
How to deal with the Daily Scum. Reframe standups to focus on the future. Then have actionable discussions. If an item has been in progress for 3 days, talk about it.
Finally, facilitation is not dictation. Get to deeper thinking – the why/root cause. Enumerate competing interests with roles on the project. Then talk through the benefits and problems with the simultaneous competing interests. As a facilitator you can capture nuggets of conversation not obvious to the participants.
My Thoughts
First off, I should mention that we at SEP have recently published some thoughts on meetings as well: Keep Your Team Organized with the ART of an Effective Meeting Checklist.
I’m glad I haven’t worked in teams where people were yelling and fighting during meetings. Sleeping, I don’t mind so much. It just means that person doesn’t belong in the meeting. Personally, I don’t think a meeting should involve anyone who is not expected to contribute to it. If you want people to be aware of stuff discussed in the meeting, record it or take notes.
As for the ‘Daily Scum’. I agree that it is regrettable. Though, in my experience it is usually corrupted by some other goal. Typically to report status. Perhaps detailed status. Perhaps way too detailed status. I wouldn’t be surprised if that need is caused by production paranoia as called out by the talk.
I think it’s certainly possible to remove that behavior from the daily scrum via facilitation. But if the need isn’t being met it’s going to resurface. I think the person who desires the status needs to have a conversation with the team about how they are going to meet that need. It could happen during the retro, but ideally closer to when it is observed.
I did like some of the ways to force retro topics – what flavor of ice cream is this project and why? I have noticed inviting people outside the team to the meeting tends to stifle retro topics. Probably not going to write a sticky about how much of a PITA it is to get a reply e-mail out of Jon if he’s in the meeting. Especially if Jon happens to be your manager or the client.
Closing Thoughts
I’m glad AgileIndy is back as an in-person conference. I learned quit a bit by attending. Furthermore, those learnings led to some introspection that I would not have done otherwise. If you’ve made it this far, hopefully, I have given you some reasons to attend AgileIndy next year.
Let’s build the future.
We’re curious makers, always asking “Why?” and “What If?” and “How might we?” We take a ton of pride in sharing what we learn and leaving customers better than we found them.
You Might Also Like
