A day in the life of an agile Technical Architect

When it comes to adopting agile methodologies in a larger organisation, there are often questions about how architects fit into the agile development process.  I've posted before about how the role can work, but I thought it also might be helpful to walk you through a typical day:

	-00:10 Great, time to get a coffee before the day gets underway. A double espresso with just a dash of milk to take the edge off - just the way I like it. I'm glad they have proper coffee machines here. It's not the best in the world - but it's not too bad.
	00:00 OK, time for the daily stand-up meeting. Good, most things are on track, but One developer says they are stuck on a relatively simple item, but it sounds like they have missed something - I'll need to discuss the item with them. Another developer is blocked because of an environment set up issue.  I'll have to talk to some of the IT Infrastructure people on that one.
	00:15 I speak to the first developer.  He missed some information from the technical guidance I had supplied and has not yet looked at my proof-of-concept.  He's going to take a look at those and get in touch if he still has the same problem. I manage to get some time from an IT Infrastructure person.  Turns out they can't help - but their colleague can.  I've set a meeting between their colleague and the developer this afternoon.  Hopefully they can sort it out between themselves.
	01:00 Right, let me take another look at that email that arrived late yesterday.  Product wants some unplanned changes in before the next release. As I thought, the change isn't huge, but it is in some older code - I need to dig a bit more on this one.  Time to download the latest source code for those solutions and take a look. Hmmm, hasn't changed too much in the last few years. It's not going to be complicated, but it will take quite a few changes in quite a few places.  Changes in these areas have caused problems in production before - we'll need extra testing for those. Ah, the requirements for this work in the backlog aren't quite going to cover it.  I have a quick discussion with the Business Analyst - they are fine with the impact and approach.  I update the requirements to reflect what I have found discovered and include some advice.  Some of these items are larger than the team prefers to support their fast feedback and workflow model.  That means I need to slice this work up a bit. The natural seams in the work weren't all obvious - but I have found them now and the BA is fine with the adjustments and the breakdown. I just need to inform the BA so they can re-prioritise the items in the backlog. Done. That took a little longer than expected, but there should be no surprises when the team picks up the items.
	02:30 Now, to fix that security bug that was found a few days ago.  OK, here it is in the issue tracker. Hmmm, reproducibility criteria is not clear, and this is not the first time.  Looks like the person who raised the issue is falling into their old bad habits again.  I make a note to have a quick chat with them tomorrow after the stand-up.   Let's take a look at the code. Ah, I understand the issue now.   I write a few quick tests to reproduce the issue - the tests fail. The fix is relatively isolated, but I run my new tests, and all the others in the solution.  They all pass now.  I call a developer over for a code review:  they ask for more information in my comments.  Done. I update the bug with some testing hints for QA, and do a quick 'before and after' demonstration to QA.  We've done lots of security work together in the past.  There's no quick feedback so I commit my code.   It's a relatively minor fix, but it's nice to contribute to the team's delivery.
	03:30 I've had email alerts popping up all morning - let's take a look: Mostly FYI's - I delete some, and file the rest into appropriate folders A few meeting requests, I accept the ones I need to be at, and reply 'Tentative' on the remainder, just in case the agenda changes. Now for the ones I have to think about: Some I can answer off the top of my head A few others I have dig through some documents and source code - but I put the answers together and send the reply. Let's check out the company message boards: The continuous integration build system is down again.  That is the trouble with home grown solutions: once it's delivered there is no appetite to fix the issues when they come up.  Fair play to them - at least they are keeping the teams in the loop and being proactive - but restarting the system twice daily doesn't really help anyone.  Still, our team is logging the ongoing time cost - should be enough to persuade IT to change. A few interesting articles have been posted.  I do a quick speed read of them and file the interesting ones to Pocket for reading on the commute home.
	04:00 My stomach starts rumbling.  I take my customary walk outside along the river - getting the blood flowing again and letting my brain wander while the weak winter sun does it's best to deliver my daily dose of Vitamin D.  There are no major issues to ruminate over today so I can give my creativity free reign and think about the medium and long term. I pick up sandwich and grab a coffee on my way back to the office.  Time to be productive again.
	05:00 Back at my desk its time to check up on the architectural health of the latest development.  I pull down the latest source code for the solutions the team is working on. They all build, as expected, but I've learned not to take things for granted. No code analysis warnings - good. Maintainability is good and complexity is highest where the business rules are concentrated.  That's fine. Oh, automated test code coverage is slipping in a couple of places One of them is a bunch of DTO's - that's fine. As for the other, I dig deeper. The code quality is fine, it just hasn't been written in a testable way. I do a little refactoring to make it more easily testable.  I snapshot and shelve the before & after and make a note to talk to developer's manager.  They are capable, just need a little coaching. I log in to Veracode and take a look at the latest scan.  Some issues have been found, but on closer inspection they turn out to be false positives.  I mark them as 'mitigated by design'. Now to take a look at the SonarQube report.  There's some anomalies I don't understand the reason for.  A quick call to the architect for the team committing that code answers my question.  Also, technical debt is skyrocketing for one area of the code. Oh, that's right, it's a rush job for one client to 'on-board' them, with the proper solution already scheduled.  Nothing to worry about then. I finish off by wandering over to the desk of the manager of the developer with the untestable code.  We have a brief chat and agree a time and place for me to walk through my shelveset with the developer in a way that will not draw attention to them.
	05:45 Time for the most interesting part of my day.  I shut down all distracting applications and fire up the predictive search prototype I have been working on. The team isn't due to start working on this for a few months yet, but there are some issues I need to iron out before I ready to hand it over.
	07:30 Time to check in with my email again: My manager is querying the SonarQube results.  This is not unexpected.  I fire off a sound-bite response and offer to have a quick chat if there are any further queries about it. There's some meeting invites about the product roadmap for the upcoming year, I accept those. Good, the build system is working again - QA will be happy about that. There's a few questions from Product asking for impact analysis on some requests from some clients.  One, I turn around pretty quickly, the rest I'll park for tomorrow.
	08:00 The ideas aren't coming quite so fast now. It's been a busy, productive day, and my calendar tells me that tomorrow will be much the same.  I take a look at my watch, it's time to honour that agile maxim of maintaining a continuous, consistent cadence, so I call it a day.  I shut down my machine and head out the door.