Workshop background
Earlier this week, I ran a workshop at the first ever Agile Europe conference organised by the Agile Alliance in Gdansk, Poland. As described in the abstract:
Architects and architecture are often considered dirty words in the agile world, yet the Architect role and architectural thinking are essential amplifiers for technical excellence, which enable software agility.
In this workshop, we will explore different ways that teams achieve Technical Excellence and explore different tools and approaches that Architects use to successfully influence Technical Excellence.
During the workshop, the participants explored:
- What are some examples of Technical Excellence?
- How does one define Technical Excellence?
- Explored the role of the Architect in agile environments
- Understood the broader responsibilities of an Architect working in agile environments
- Focused on specific behaviours and responsibilities of an Architect that help/hinder Technical Excellence
What follows are the results of the collective experiences of the workshop participants during Agile Europe 2016.
http://www.slideshare.net/thekua/how-architects-nurture-technical-excellence?ref=https://www.thekua.com/atwork/2016/06/workshop-outputs-from-how-architects-nurture-technical-excellence/
Examples of Technical Excellence
- A set of coding conventions & standards that are shared, discussed, abided by by the team
- Introducing more formal code reviews worked wonders, code quality enabled by code reviews, user testing and coding standards, Peer code review process
- Software modeling with UML
- First time we’ve used in memory search index to solve severe performance RDBMS problems
- If scrum is used, a good technical Definition of Done (DoD) is visible and applied
- Shared APIs for internal and external consumers
- Introducing ‘no estimates’ approach and delivering software/features well enough to be allowed to continue with it
- Microservice architecture with docker
- Team spirit
- Listening to others (not! my idea is the best)
- Keeping a project/software alive and used in prod through excellence customer support (most exclusively)
- “The art must not suffer” as attitude in the team
- Thinking wide!
- Dev engineering into requirements
- Problems clearly and explicitly reported (e.g. Toyota)
- Using most recent libraries and ability to upgrade
- Right tools for the job
- Frequent availability of “something” working (like a daily build that may be incomplete functionality, but in principle works)
- Specification by example
- Setting up technical environment for new software, new team members quickly introduced to the project (clean, straightforward set up)
- Conscious pursuit of Technical Excellence by the team through this being discussed in retros and elsewhere
- Driver for a device executed on the device
- Continuous learning (discover new tech), methodologies
- Automatic deployment, DevOps tools use CI, CD, UT with TDD methodology, First implementation of CD in 2011 in the project I worked on, Multi-layered CI grid, CI env for all services, Continuous Integration and Delivery (daily use tools to support them), Continuous Integration, great CI
- Measure quality (static analysis, test coverage), static code analysis integrated into IDE
- Fail fast approach, feedback loop
- Shader stats (statistical approach to compiler efficiency)
- Lock less multithreaded scheduling algorithm
- Heuristic algorithm for multi threaded attributes deduction
- It is easy to extend the product without modifying everything, modularity of codebase
- Learn how to use something complex (in depth)
- Reuse over reinvention/reengineering
- Ability to predict how a given solution will work/consequences
- Good work with small effort (efficiency)
- Simple design over all in one, it’s simple to understand what that technology really does, architecture of the product fits on whiteboard ��
- Systems’ architecture matches team/org structure
- Self organisation
- Ideally separated tests, Automated performance testing, automatic front end functional testing with selenium, unit testing done for the first time 10 years ago, constructing new performance testing cases takes minutes, after refactoring unit tests are passing (majority of them – hopefully all!)
- Constant curiosity for new technologies/approaches
- Good knowledge of software patterns (when to use and when not)
- Learn from mistakes
Definition of Technical Excellence
- (Technical) Excellence is an attitude to be better than yesterday
- Technical Excellence is the holy grail that inspires teams to stay on the path of continued improvement
- Technical Excellence is a process that continuously improves product design and the development team. Examples: Automation, knowledge sharing, culture. Synonyms: Dream
- Technical Excellence is an ability to consciously apply tools and practices to solve and continuously improve over complex problems in a sustainable way and within constraints (e.g. time and money). Examples: Continuous Delivery
Activities of an architect
- Explains decisions
- Able to choose the right solution amongst many possibilities (awareness of consequences and limitations)
- Being able to justify technical decisions made
- Thinking (find time to think about the product, structure, technologies used, etc)
- Helps resolve interdependencies, helps to identify/minimise external noise (i.e. technical dependency change with negative impact), co-ordination of integration with other teams working on the same project
- Start and moderate discussions on design, longer term consequences of decisions, etc
- Requirements definition, making sure ‘nothing’ is omitted during analysis/design
- Questions decisions to encourage thinking about wider picture amongst developers, asks questions (non obvious especially), Asking difficult questions about work being done
- Listens to others
- Encourage people to bring ideas, encourage idea sharing
- Setup backlog for achieving technical excellence
- Challenge old decisions
- Business decision support (IT, 3rd party)
- Make sure we don’t bite more than we can chew – incrementally/iterative
- Ensure architecture is visible, understood and accessible to the team, keep the technical cohesion, helps team consider the bigger picture and interdependencies, helps team define the system and diagram it
- Detailed knowledge of technologies/protocols used
- Forward thinking
- Proposes solutions to complex problems
- Diagrams/presentations
- Wide view of situation/projects, look what other teams are building for things to reuse or interface to
- “Main” test scenarios definition
- Definition of components structure and interactions
- Guard technical vision (dialogue with stakeholders)
- Focus on project goal
- API specification
- Verification of current design vs planned use
- Ad hoc just in time consulting to feature teams when things get complex
- Teaching teams, sharing technical knowledge (and expertise) with the team
- Coaches team. Gets buy-in from the team for change they are about to trigger, coaches dev team
- Identifies technical skillset gaps in the team
- Pro-active thinking
- Gaps identification
- Mitigates the risks
- Out of box ideas
- Research for solution, helps team identify areas for experimenting, exploring new territories
- Creating proof of concept (POC)
- Learns new things, research and try new tools, ideas, technologies, etc
- Gains an in-depth understanding of a system before attempting to change it
- Reviews teams’ system design, performs code reviews and coding standard support, reviews code
Behaviours that support Technical Excellence
Active
- Gives team rapid and timely feedback
- Patiently explaining all the tiny details responding to simple questions
- Be there whenever needed
- be the safety net whenever devs need you
- Set communication for knowledge sharing
- Explain the reasons behind the design
- Raising the visibility of good developers
- Do pair programming, works with the team
- Explain technical excellence value for business
- Encourage team to think and work towards Technical Excellence
- Growing people, mentoring developers to improve tech skills, training the team, educate actively – organise coding dojos, etc
- Set up backlog for achieving Technical Excellence
- Raising the team spirit and motivation
- Waking up with 3am to connect with a team on a daily basis (for a distributed team)
- Discussing discovered problems with the team
- Sat down with the team to teach and record architecture training for future use
- Keeping an eye on new things on the market and bringing them to the team
- Staying current in technologies, tools, concepts, etc.
- Being a visible role model in terms of pursuing Technical Excellence
- Encourages experimentation
- Support team in collaboration with other teams
- Helps team identify blindspots
Passive
- ability to change contexts between projects
- Lets the team make decisions
- Take a step back and make room for technical advancements of the whole team
- Not doing stuff from actively discourage column
- Team makes decisions
Behaviours that discourage Technical Excellence
Active
- Dictatorship, have to do it my way, will to control (every small detail)
- Blaming and shaming
- Making arbitrary decisions, especially without explaining the reasoning behind it
- Rejecting too complex C++ code
- Using ambiguous, complex, uncertain English vocabulary
- Shutting down emergent ideas from the team
- Discouraging ideas “I couldn’t care less about your sophisticated C++ SPT initialisation”
- Created ugly prototype for a demo and forced team to clean up afterwards
- Imposing BDUF (Big Design Up Front) over the development team
- Created non-viable design (i.e. could not be implemented with current constraints)
- Enforcing old known technologies, etc out of inertia/ignorance, sticking to the “old ways”
Passive
- Doing too many activities to follow through – not focused on any (and no time to encourage Technical Excellence)
- Invited but never attended meetings
- “I don’t meet with the Architect”
- Software Architect with poor development skills
- Not working with the team
- Leaving obsolete information in documentation
- Getting involved in design only if prompted
- “I don’t know how, so I won’t define it”
Stories
- Developers supporting software (getting email feedback)
- Anti-Story: “Let’s *NOT* sit together” – Person leaving showed them how it was done
- “Let’s sit down together” (solving a memory leak problem)
- Group Problem (Security problem)
If you liked this article, you will be interested in “Talking with Tech Leads,” a book that shares real life experiences from over 35 Tech Leads around the world. Now available on Leanpub.
| Reference: | Workshop outputs from “How Architects nurture Technical Excellence” from our JCG partner Patrick Kua at the THEKUA.COM@WORK blog. |
