Nobody can question if you implement the Agile practices in Waterfall projects. If you talk about XP practices in general, they are not really specific about any methodology. Pair-programming, CI, TDD etc all make sense in any methodology. However one of the key difference is – Waterfall doesn’t bound you in anything. It also doesn’t say that the least engineering or project execution practices are these or those or that one except defining 4 phases of the methodology. So in my experience of 10 years with Waterfall some people used to adopt some good practices and some others didn’t. It used to be person dependent case how a Project Manager would like to execute a project.
Scrum and Agile in general took some common-sense based practices formally which could be a beginning point of every project. Ceremonies are defined because they made a lot of sense and also provided a rhythm and discipline to the team (the way brushing teeth is a daily ceremony for everybody). You can do away with them if you want to but you need to have enough valid reasons to say that in your context it’s not making sense. So Scrum defines ceremonies, roles, project execution cycle in very formal manner. On top of it you need to apply the basic Agile principle “Inspect and Adapt” as you move further. So you can do the changes which make sense to you and that’s how you evolve some practices which are general or are project specific.
In this context, I feel the roles mentioned in my previous blog like Agile Architect make a lot of sense. We cannot get away with “get them whenever you need” the way we did earlier in Waterfall. The reason is “whenever” like "it depends" for many people becomes very confusing.
Further even these cases are not generally mentioned in any Scrum literature and to everybody in the world. From the outset it looks like that Scrum just works with generalist-specialist kind of people and it doesn't have any scope for any specialist and again it’s on need basis. However most of the time people don’t get to know those needs and get confused with just generalist team idea.
Why do we need specialist also in the team?
I feel it’s a chicken and egg kind of situation. The reason why we want specialized people to be “team member” is just because of our bad experience with Waterfall world in which Architects used to work in their ivory tower where they couldn’t see the battle-field in real sense. That kind of architect culture didn’t work as Architects were getting out of touch as they grew in terms of the experience gradually.
In the beginning it looks like a great solution where specialist is no more a specialist but just a specialist-generalist which means based on their interest and capabilities people can give suggestions. However practically I have seen it failing not from emerging design point of view but in a sense of having a balance between emerging architecture and business+non-functional requirements. Sometimes they go tangential because of following reasons:
- As everybody is a generalist-specialist and the team is responsible for emerging architecture, the accountability doesn’t remain on one person. In such kind of situations where everybody is responsible for everything, it implies nobody is accountable in real sense.
- There is a mix of responsibilities now. The guy is deep down developer also and has some iota of responsibility from architecture point of view too. So the boundary is very thin here. You never know, when an architect is going to lose the sense of looking out from third-person point of view.
- When everybody is in deep mess in project development, the focus of every generalist-specialist is to get out of the mess. How you do that- doesn’t matter much sometimes. So that eye of somebody who continues to keep a tab on balancing both emerging architecture and non-functional requirements can go for a toss and you will not know when it really happened.
All above cases are based on experience with real projects and with very experienced teams.
So making an architect a full-fledged developer doesn’t work in my view. Instead, I feel it will work when the focus factor for persons’ availabilty is less than 1 for project development. At the same time, it’s important to have some backlog from architecture point of view on which that person works along with multiple team-members for achieving certain non-functional goals.