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, 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
Related Posts:
