Last year, I wrote a 4-part blog series titled ‘Software Architecture and Design in Agile World’. You can read all four parts of that series in less than ten minutes. If you haven’t read yet, I suggest that you read those before proceeding further. The main reason is that I am writing this post as a sequel to that series.
One of the factors I considered in Part-4 of that series is ‘Project Complexity’ which is based on two key aspects – the size of the project and complexity of requirements. These two aspects along with time-to-market constraints become a significant determinant of the team size. When you need to run a large project or a program with hundreds of team members and follow Agile Software Development, you are scaling Agile. ‘Scrum of Scrums’ is a pattern of Scrum in scaling agile. SAFe is a framework meant for executing large projects with agile practices. Disciplined Agile Delivery (DAD) provides a flexible and pragmatic platform for large scale distributed projects.
When you have 200 or 300 team members spread across two time zones, you are going to have at least one team of architects – for example, a team of 5 to 7 architects. That is not it. You may have to have designers, story authors, developers, testers and so on. In a situation like this, in addition to having a team of architects, you may need to have one or more teams of designers, one or more teams of product owners and story authors, several feature teams and some independent verification teams etc. Why do we need a team structure like this? What difference does it make? I will answer these questions in another post. Now, let us focus on the main question - In large projects or programs, what do architects deliver?
Do they deliver a roadmap? Do they deliver prototypes? Do they deliver some high-level code? Or do they deliver something else? What do you want them to deliver?
To answer these questions, we must wear the hat of program managers. Assume that you are program managing a large-scale multi-year multi-release agile program distributed across two or three time zones and your teams are working on emerging technologies. What questions will you ask week after week, month after month to make sure that your team is moving forward in the right directions? Which of those questions will have a significant focus on the team of architects you have?
Here are the key questions.
1) Is decision making effective and timely in our project? - This includes all decisions – architectural, design, integration, and so on.
2) Are we able to assess or measure or understand the cost of ‘not doing’ certain things in a timely manner? And are we highlighting those to our product owners?
3) Do we have a backlog (prioritized) of technical stories (related to architecture/design/complex coding issue, etc.)? How do we assess the ‘technical debt’ associated with those and track them to closure?
Questions like these will help us figure out the deliverables of architects. At the time of writing this post, I read an article by Eltjo R. Poort published in the September/October 2014 issue of IEEE Software. The title of the article is ‘Driving Agile Architecting with Cost and Risk’. I have provided a link to this article at the end of this post. In this article, the author says “Decisions are your main deliverables. Thus, the role of the architect is to make sure that the group’s decisions are consistent across the whole solution, even when multiple teams are working on it simultaneously.”
Decisions! Yes, a whole lot of decisions right from decisions related to the basic building blocks, trade-offs, integration points, interfaces, dependencies, data storage, performance, scalability, deployment, cost, maintainability, and so on. Decisions are the main deliverables. Also, as the author says that architects need to have a backlog of architecture concerns and convert them in to decisions in a timely manner. This is a good practice to make sure that nothing is ignored or forgotten or assumed.
Had you been part of large-scale Agile projects? Did you project have a team of architects? If yes, what did they deliver? What more did you expect them to deliver?
Reference: ‘Driving Agile Architecture with Cost and Risk’, Eltjo R. Poort, IEEE Software, September/October 2014