Agile Architecture.

Last week I presented a webinar about Agile Architecture and I got an unexpected positive feedback from it. First it was unexpected because I didn’t expect to get lot of people interested in this particular topic. Second it was unexpected because I am still at the beginning of my teaching career and presenting webinars so I am not so good yet to keep the audience interested for 60 min.

Btw, considering the result of the webinar, I decided to post the video of the webinar (thanks to the guys of Typemock!) and a short introduction to Agile Architecture.

Agile Architecture webinar:

Update: slides available on SlideShare.

Agile architecture

What is Agile Architecture? It is a methodology that follows the Agile guidelines but differ from some aspect of its process.

At this web address: you can find probably the official website of this Agile methodology, even if you may find a lot of interesting discussions and articles here and there on the web, just google “Agile Architecture”.

Another interesting web site is where you can find tons of information about Agile Modeling and Agile Architecture. (If you watch the webinar I spoke about both of them).

Finally, if you want just to read a quick article and understand the overall process of Agile Architecture, I found this article of J.D. Meier very helpful: “How to design with Agile Architecture”.

TFS Template

I got various requests about the TFS and Dashboard templates I used during the webinar. I got them from the beta of Team Foundation Server 2011, available here. You need to customize the process to fit better Agile Architecture methodology. I am planning to prepare a custom template for TFS 2011 as soon as the SDK will be finalized.

Q/A from the webinar

Below is a short list of some of the most interesting Questions and Answers I got during the webinar. I am posting them here because during the webinar I wasn’t able to read them because I am using the MAC version of GoToWebinar.

Q: Acceptance Tests should have been written before the model.

Not really, if you adopt the strict TDD all the acceptance tests should be written before, but when you envision the architecture, it is too early to write acceptance
tests. When you start the iteration and you have your requirements defined, you may start to model against the acceptance criteria for that iteration. But remember
that the modeling part should be light enough to provide value for the next step.

Q: the functions of the architect are clear, but it is not clear how these functions are intended to fit into the Sprints.

The sprint is composed by three parts, modeling, brainstorm and coding. The architect will perfectly fit into each of this phase. I think I have explained this
concept during the webinar, but just to be sure. During modeling and brainstorm the architect should help with his knowledge and collaborate in the modeling, during
the coding he should be an active coder too and contribute to the technical decisions providing knowledge and expertise.

Q: Can you elaborate on what you mean with the “design phase”?

Ok, during the first iteration, the envision, there is a light design phase. You should design some scratches of your envision, representing the architecture and the UI, but you should not invest too much time.
Design phase while modeling means adopting UML to design your models.

Q: How does your “Iter: 0” relate to the PO, backlog and sprint planning?

Ah ah, interesting. The envision or iteration 0 is tricky to fit into SCRUM. Take the classic meter to measure an iteration, like 1 or 2 weeks. Inside this timeframe you should have enough space and time to prepare the necessary analysis and mocks required by next steps. So you may consider iter 0 like a beginning sprint.

Q: Couldn’t the use-case diagram be enough for the modelling phase? I’m interested in hearing your reasoning because I’m currently in this situation in my current project. What level of detail is enough when it comes to architecture that lets developers use their brain and problem solving power?

No, the use case is not enough because it may incur into personal interpretation. With the use case and the acceptance you and your team are ready for the modeling phase, where you create the architectural style for that feature. The modeling should be enough to represent the current feature and it should not be implemented, the implementation occurs in the next phase where you apply TDD against the model discussed in the previous part. It is hard to keep the model the blueprint of the code and often it doesn’t provide value. It is important that the model represents what you are delivering.

Q: Does the Process workflow you describe impact the philosophy of embracing change? How can we perform radical change when we get a bigger up-front model?

No, it doesn’t because Agile Architecture pretends the flexibility into your model. Model just enough to represents the feature and remember that you can always come back and re-model and re-factor. Embracing Agile Architecture will force you to have a dynamic more agnostic and flexible model than using a classic architecture approach.
Why would you get a radical change request with a radical model upfront? Of you adopt Agile you should structure these changes into small iterations.

The envision phase is the most critical, you or the architect need to understand what the stakeholder wants from your team. If you get that, you are in a good starting position.
The big mistake is to take too much for the envision, which is not the modeling phase. Mocking out your application doesn’t mean to model everything, so the envision should take few days, at most one week. If it takes more you may have some smells in your team: lack of requirements, lack of business knowledge, lack of technical knowledge.
Remember that every iteration has a modeling phase and a brainstorm phase, so you may move back to the envision and adapt it to the new requirements.