What does an application architect do? What are the biggest challenges to your role that a SM might not know and might be helpful for them to know.
The typical role of an architect is to understand the breadth of a software system, how different areas of functionality interact with each other. An architect has deep technical knowledge and is able to help guide a development team to choosing a path that will allow them to deliver business value without hindering future development efforts.
Neal Ford often says that “architecture is about choosing the least worst option”.
The architect role can vary among organizations. The same knowledge might exist in someone called a Lead or Staff+ engineer.
My work should be out of the critical path, I do not typically contribute feature code. What this usually means is that I contribute code by building prototypes and proof of concept applications. Exploring new patterns and technologies. I very rarely, if ever, am assigned user stories during a sprint. Depending on the team size and project demands I might do some development for a short period of time, but that’s rare.
My goal as an Architect is to bring the team together to evaluate and help decide how we will build the next phase of the software. We’ll make decisions, evaluating tradeoffs.
Some of the important skills I focus on:
- Pattern matching, i.e. if I see that we are trying to solve a problem multiple times in a row, a pattern emerges and might be an opportunity to optimize, usually meaning we need to refactor
- Identifying trends in the industry
- Desire to constantly explore new technologies and platforms
- Interpersonal skills - Architects/ Lead developers tend to be in an interesting position within most organizations. We are often Individual Contributors (ICs) that have our foot in both the business and technical worlds. We build trusting relationships with developers. Because we have quite a lot of authority on the technical side and don’t have managerial responsibilities we are uniquely suited to identify and resolve technical and interpersonal issues.
I deliver an approach, a set of solutions a few months before development teams are ready to start implementing.
How do developers view Scrum and Scrum Masters? Where are they challenged most about working in the Scrum Framework?
Scrum and agile implementations vary wildly across teams and organizations. This inconsistency in implementation requires us to redefine what Scrum is and how it will be used on almost every project. Developers tend to be frustrated with Agile and Scrum because we often don’t benefit from iterative development. We plan large blocks of, usually what amounts to several sprints worth of work, before stopping to determine if we should reconsider our approach to solving the problem.
Building great software is quite a bit different than building something in the physical world. Often we compare software development to building a house, a building, or a bridge. Software is different. It can evolve and change over time. It requires care and feeding, constantly. The problem usually comes when we try to estimate how long something will take to build. With enough experience among the team working as a team, it becomes easier to give a more accurate estimate. But really, estimations are based on our best guess factoring in our experience, knowledge, and understanding of the problem and desired solution. We try our best to get close, but tend to miss the mark almost every time.
Solution:
Allow significant space in a sprint. At the beginning of a project, start with what you think you can accomplish in half a sprint. Avoid filling a sprint to capacity.
Developers need care and feeding also.
Where are the biggest pain points in the relationship between the SM and the Devs? How can we work through those?
Miscommunication or misunderstanding each other can lead to significant issues. For example, a SM might ask a developer how long a feature will take to build. The developer will likely answer like 4 hours, roughly 1 story point. The SM uses that number for all of their needs. The misunderstanding comes in b/c the dev meant that it would take 4 hours to build. They neglected to factor in the necessary testing, any code refactoring, peer reviews, and deploying the feature. The additional work required to consider a feature “feature complete” moves the total estimate from 4 hours to 2 days or 2-3 story points.
Lesson: Developers tend to be very literal, they give an answer to your exact question, not the answer you needed.
Solution: Define early and often what it means for a feature to be “feature complete” or the “definition of done”. Build a shared understanding of all of the elements required to deliver the feature. E.g. Development, testing, QA, external dependencies (another team, 3rd party translation service)
Software development is both an art and a science. Effective software developers need to hold a significant amount of context in their working memory to solve a problem. Interruptions to this process introduce lost efficiency and often result in software bugs. This “context switching” is very costly to developers, typically requiring 15-20 minutes to regain. Ideally, developers have long uninterrupted blocks of time to code. Short blocks of time between meetings (i.e. 30 mins - 1 hour) tend to be less valuable.
Solution: Create large uninterrupted blocks of time for developers to code. Avoid pings or distractions that can wait. Try to clump questions to the beginning or ending of the day. Try to group meetings together to avoid creating short blocks of less useful time.
Ceremonies
Do your best to make ceremonies happen on a regular cadence. Build some predictability into your ceremonies to allow development teams to know they have a forum to bring up issues (ie. during a retrospective)
Keep standup conversations short and to the point. When conversations happen during a stand up meeting they tend to distract and annoy other developers not involved. Use a parking lot concept to hold those conversations until after the stand up is complete. For example, teams like to discuss how they plan to implement a feature or discuss technical issues during the standup meeting, this can and should be discussed at another time.
Define a “blocker”
Some developers and teams do not regularly call out blockers or impediments to their work until it is too late, if ever. If work is not moving forward at a reasonable time, take time to identify what might be impeding progress. Does the developer need more time? Another developer’s help?
SM always want an answer to “how long will this take” and the answer is almost always “it depends”. Developers are trying to calculate through all of the variables, unknowns, and potential blockers to come up with an amount of time that we know won’t be enough time to deliver the feature properly.
Where are the pain points/challenges between your role and the Scrum Team? How can we work through those?
Both Architects and Engineers appreciate being brought into conversations early. This is often a design/product issue, depending on the team size and structure, but SM may play a role. The sooner the person(s) responsible for implementing a proposed solution are brought in, the more conversation we can have. I like to talk through ideas when we’re in the “napkin” stage, before ideas have truly been formed, designs have been drafted, etc.
How can a SM successfully support the Devs in their role as it might exist today, yet help them continuously adopt an agile way of working? How can we know the fine balance between encouraging people out of their comfort zone to change yet meeting them where they are?
- Iteration
- Tracking and factoring in velocity
- Experimentation
- Definitions of done
- What is feature complete for a sprint? How do we deliver a fully backed feature in a sprint?