Menu
I'm reading the book "The Software Architect's Profession" by Marc and Laura Sewell (Amazon link) and it got me wondering whether a software architect is a part of the old non-agile BDUF approach.
Is there a place for software architects in an agile approach? I'm especially interested in Scrum.
BTW I currently am the Unix Application Architect for a major company.
cheers,
Rob
732
Architect as part of the Scrum team Those team members with architectural skills or responsibilities by the nature of being in the Scrum team will be involved in the sprint on a day-to-day basis. They'll attend the stand-up meetings, take items off the backlog, and work on them.
The architect is responsible for defining and maintaining the structure of the solution, and ensuring that it will meet the requirements. An agile architect must also help the team to work together in an agile fashion, to jointly own the solution, and to interface well with other parts of the organisation.
Architects help the product owner reduce the level of uncertainty, making it easier for the product owner to set priorities and for teams to focus on the specific solution within their areas of expertise. Architects are present daily on agile teams.
I can speak from some experience, as I'm currently both Scrum Master and development team member (such as an architect, who is 'just' a development team member in Scrum terms). Though often frowned upon, this is possible and not explicitly forbidden.
My role as architect in Scrum includes the following.
Technical spikes -- proofs of concept -- how will we do that. ("It would be simpler if you'd simply using the SMTP library directly, it already wraps the existing SMTP libraries; writing your own wrapper around our wrapper doesn't help much. We can add the method you want.")
Coordination among the developers to fit the intended architecture. ("Ummm... why are you using your own properties file?"
Working with users to prioritize the backlog appropriately. ("These three are related, if we do one, we get the other two at almost zero extra cost.")
Working with managers to cost the backlog. (No, a project manager can't do this; they don't have the technical depth. No, the programmers can't do this, they don't have the overview.)
Articulating why the package names are that way, and why the data model has those features.
Finding the things we're missing and reprioritizing the backlog on technical grounds ("We're going to need this additional sprint to integrate [X], upgrade [Y] and replace [Z] or we'll never get those sprints done.")
199
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
