Evolutionary architecture in agile environment
Speaker: Xavier Rene-Corail
For more blog posts, see The Oracle Code One table of contents
- Not that we don’t have a plan. We have a plan. But it can change
- Emerging design – do have a high level design. Not chaos
- Things change. There’s nothing that will not change. Make easy to change the things that will/might.
- Prototype architecture. Working software over comprehensive documentation. Architects shouldn’t deliver paper docs
Software architecture is
- “the important stuff (whatever that is)” – Ralph Johnson
- finding internal *abiities
- managing conflicting *abilities and determining which is most important
- ability to move quickly and easily – Oxford dictionary
Evolution of architectural styles
- Monolith – not scalable, single point of failure
- Layered – defacto standard for JEE apps
- SOA – natively scalable, but cn turn into monolith
- Microservices – now need orchestration
- Severless – abstract more
- Dependency hell/service dependencies
- Distributed transactions
- Minimize coupling
- Couple fro highly changing to infrequently changing
- Ask users for feedback. Don’t overarchitect
- Feature flags. Make safe to fail
- Eat an elephant one bite at a time. Design that way too
Decide up front – programming languages and frameworks. These are difficult to change.
My take: Good session. My notes are “less good” because I was eating lunch during the design principles. So listening, but not blogging!
Last year, I wrote about Virtual/remote friendly agile games. Yesterday at the NYC Scrum user group, we played an agile game about circle connections. The game was:
- Stand in a circle with the people at your table.
- Everyone picks two people (but don’t say who they are)
- Keep moving until everyone is equidistant from their two partners.
The idea is to show how chaos lessens and equilibrium is achieved. Ok. Physical movement. Can we make that virtual? Actually yes!
Using a tool like togetherjs’s drawing tool, you can see everyone’s cursor. So all team members can move around the cursor to meet the equidistant requirement.
Not just any collaborative editing tool will do. It needs to be one like the drawing tool which displays all the mouse cursors!
We also played a game where we built towers with newspaper. That one I don’t think I can make remote team friendly!
We had 15 minutes extra at the end of our retrospective today. I suggested we use it to play an agile game. My team has people in three locations on a video conference so it was time to look at my thoughts on virtual agile games. One of our newer team members had learned about online/shared virtual whiteboards this sprint so I picked Beautiful Meadow. I figured drawing on a virtual whiteboard would get us all more comfortable using one.
Not counting myself, there were six people attending today’s retro. I asked them to split into two teams of three with the only caveat being that the three NY people couldn’t be on the same team. (In other words to ensure there was remoteness involved on both teams.) After a bit of silence, one of the quieter team members stepped up and picked two teammates. I designated him along with a quieter team member on the other team to be “captains.” The captains were responsible for opening a Skype session with their teammates and myself.
Both captains were from cities other than New York. (What’s special about New York is that we have the most people on the team from NY and many of them have been on the team the longest. Also, I’m from New York and I was moderating the exercise.)
I then set the stage for the game:
- Each team is going to draw a picture on the virtual whiteboard
- You can only draw in the color I’ve designated for you. (I picked a person on each team to draw in red and another in blue. The third person was allowed to use any other colors.)
- You can communicate over the Skype chat but not verbally. [with the in person version, you can communicate non verbally. That doesn’t scale to remoteness so I added chat. It’s hard to draw and chat at the same time so we still had minimal communication.]
- I am going to paste a description of the task into each chat session. We will draw for 5-7 minutes. There will not be enough time to complete the task, so don’t worry.
Both teams produced nice diagrams. There was some laughter during the drawing which made it run. Then I showed the two problem statements. Everyone understood quickly why the team without the detailed spec produced a picture of a meadow.
What we learned
- More about the virtual whiteboard
- Practice self organizing (two of the people who often set up to suggest direction were out today)
- The value of proper acceptance criteria.
- How easy it is to miss the goal in a list of details.
- We have a team member who is good at drawing electronic cows!