When it comes to scrum and agile way of working I consider myself a pragmatist, not a purist. As far as I'm concerned, process' value is determined by how it can be adapted to project's special characteristics while still doing what it is supposed to do: provide a sensible and practical framework for productive work with minimum managerial overhead.
Now, I admit I'm the last one to assume any position of authority: I have no certificates, nor have taken any courses or spent hours arguing about the theory. Well, scratch that last one - I have argued about the theory, a lot :) Mostly with people who got their certificates after taking courses and attending seminars. The only thing I can base my opinions is my meandering practical experience.
Not too long ago I worked as an architect in a major customer platform project, but due various practical reasons I had to function also as the ScrumMaster and Product Owner as well. Sounds bad, I know, but at that time it was the only way to get things working and indeed, we did quite alright and everybody were happy. I kept wearing three hats for about four months and during that time I made an interesting observation: I was better able to communicate and control the implementation of my architectural vision and design through product owner's methods and channels, while also receiving more useful information directly from the stakeholders. In other words, the quality of user stories and information available to the scrum team improved (says I) and the overall vision of what we were working on become clearer.
It makes sense when you think about it. A good architect has most if not all capabilities and skills as a good product owner has, but in addition architect is better suited to design and explain to techies what needs to be done. A good architect is fully capable of negotiating with various stakeholders and to understand business needs and requirements, all of which is information architect would need anyway to do his work. A good architect can write the scrum user stories from the business end-user's point-of-view and explain it all to scrum team's developers and testers. While a sprint is on-going the architect-PO can keep the backlog in healthy shape, keep in touch with stakeholders, provide support to the team members and work on design documentation as well. And when the team shows how they implemented the user stories, who else would be better suited than an architect-PO to evaluate whether or not the implementation is acceptable?
Now, I can almost hear purists gasping air in aghast... calm down and breath deep. Can you really give any valid reason why this shouldn't work apart from "this is not how things are supposed to be done in Scrum"?
And are things any better now that there is a another person doing the Product Owner's work? In my opinion, no. He has no prior experience from scrum projects, he has not received any scrum training apart from two hour tutorial that was arranged by our company nor does he bother about writing user stories (this is typically delegated to the team ScrumMaster, instead of project architect), which in any case often tend to contradict prior design, implementation and/or plans. Neither does he use ScrumWorks (or any other available tool) efficiently, he cares more about new features than quality of existing features and removal of technical debt (and he used to be a test consultant!) and bullies the team to accept more user stories to sprints than they should. Caveat: But I'm being unfair here, the man does his best under never ending pressure from the business and within the confines of his organisation's politics and business practices. I even have to admit that often I had to agree with his reasoning even when I disagreed with his methods and solutions. All and all he is a good man and I respect him.
The reason why I brought this up is to point out that while the theory might sound good when a lecturer explains how much better things will be once Scrum has been properly adopted, the reality check can be quick and harsh when the theory is being implemented in practice. Admittedly, often it tends to be a acute case of "people are the problem", as Douglas Adams to apptly put it.
It is not practical nor even possible to expect all involved people to adapt to the process, and this is only emphasised when a subcontracting organisation tries to introduce Scrum to a customer organisation (why should they even try, you ask? Often a customer organisation might have no knowledge about IT processes and you do need one, whatever it might be). The process should be able to adapt to people, organisations and project specific aspects. And when the process reaches its limits of adaptation? Well, try another one - perhaps one that is approximately closest to overall starting point?
The Architect's Point-of-View
What about the architect's point of view, then? Gone are the good old times when architects were allowed, even expected to reside in their cozy ivory towers; absent mindedly looking down where plebs... er, developers were slaving away long hours to implement the architect's latest vision of grandeur and excellence. Time has become a rare commodity in projects and no longer are architects given ample time to think, to plan, to ponder, to design and to document before development is even started. Somehow ivory towers got demolished when architects weren't looking and now many of them are standing amidst the tower ruins wondering what they should be doing next.
Obviously a good architect is ready and willing to jump into the trenches and get his hands dirty. Except... a scrum team does not recognise roles, like the one of architect. Everybody are developers, everybody are architects, everybody are testers. No specialities, just a regular cornucopia of Jack-of-All-Trades (well, lets be fair: things are not as bad anymore, now it is alright to have technical testers in Scrum teams). So, should an architect become a developer and participate in writing code along with other developers? Not necessarily a bad idea, but while doing very detail oriented implementation work there is not much time to think about the big picture, about how all those nitty-gritty details end up forming something that actually works. This is not a problem when the team is working on some reasonably small sclae system, but when it comes to large scale enterprise systems that have multiple sub-systems, third-party integrations, legacy systems along with newly implemented systems, multiple databases and several teams working in parallel... You really need to have somebody who really understands what is going on and why certain sub-systems need to be implemented in certain way because another sub-system that a developer might not even know about, requires it.
And so the architect's role is changing; agile architect rarely gets involved with low-level technical design, which is now done by team developers as they implement sprint user stories, but instead they are likely to start from high-level business requirements specification, designing the overall architecture, defining sub-systems and their interfaces, databases and data structures, support various team members, generally influencing the best practices, do risk analysis, hold customer's hand and of course, produces barely good enough documentation just in time. There is much more to do, of course, all of which places greater requirements on architect's skills. It is no longer enough to just know some UML and key implementation technologies, but one has to have wider range of experience and knowledge that makes it possible to operate various domains (e.g. business, technical, human relations and even politics).
All this makes the agile architect's work so much more interesting if also challenging. Methodologies such as IEEE 1471 helps, but a simple yet practical move to combine the roles of an architect and a product owner can make a real difference, in my opinion.