I was recently asked:
Within the team we have a person working as “development lead”, and a second person working as the “solution architect”.Â What responsibilities and deliverable artifacts we should expect from of each of these roles?
As usual, Iâ€™d answer “that depends.” Here are some various answersÂ Iâ€™d give for various situations.
First, it depends on the level of Agile experience the team has, particularly in the areas of adaptive engineering (emergent design, TDD, mock-free true-unit testing, pair programming, done-done) and adaptiveÂ delivery (vertical slicing, 1 week iterations, frequent releases, etc).
If the team lacks these skills, then the purpose of these roles is a whole lot like theyâ€™d be on a waterfall team. Basically, the team does not yet have the skills to code as a team of generalists, so they should operate like specialists. I might add one responsibility to the development lead: help the team learn the above skills (probably with use of an engineering coach, Industrial Logicâ€™s online training, or the like).
If the team has these skills, it is able to function as an agile team of generalists. In that case, the role of solutions architect would be exactly the same as the role of any normal dev on the team. That title difference is just a recognition of past accomplishments, not a differentiator of responsibilities. The role of the dev lead would be â€œeverything as per a normal devâ€, plus ensuring that everyone on the team discovers new stuff and teaches it to others on the team. It might also include ensuring that retrospectives happen, that they generate real experiments to try, that those experiments result in data, and that the data result in process improvements.
Second, it depends on what individual people fill those roles. In a generalist agile team, the role doesnâ€™t define the work nearly as much as the individual does. Thatâ€™s part of why itâ€™s so hard to get a definition for a role out of an experienced Agile practitioner (who isnâ€™t selling you something).
Thus, Iâ€™d look at what this individual can do that others on the team cannot. I would do that for each person on the team, not just the leads. And then Iâ€™d expect that each individual teach others on the team to do what they can do. Pairing is a good way to do this (probably the cheapest way), but there are others.
In several of my agile teams in the past, Iâ€™ve made both teaching and learning part of each personâ€™s quarterly review (annual review, but more frequent). The minimum expectation was that they would have, each quarter, learned one substantial thing that no one on the team knew previously, and that they had taken one thing that only they knew and spread it around so that at least half of the team could do it at above a beginner level.
Getting a good rating was set at a level above that (varied by team). Something substantial could be â€œlearning how to use seams to section legacy code and refactor it piecemeal, as well as a half a dozen types of seams that address this teamâ€™s common cases.â€
Thatâ€™s one of the big differences in Agile culture (big A intentional): the learning and teaching are important deliverables. So are happy, paying customers. Not much else â€“ some would say nothing else â€“ is.