There are a lot of myths around agile software development. Agile teams need no discipline, no documentation, no planning are some examples of the misconceptions about agile. Here I want to share about two other myths regarding architecture and agile practices.
Myth #1: Architecture is not an agile practice.
Some say that agile teams don't waste time on architecture, they focus on coding the solution. This (false) statement is often made by people convinced that architecture has been intentionally banned from agile methodologies.
Of course, this myth is completely false. I checked my IT bookshelf for concrete proofs. I found specific recommendations for architecture on agile project from various agile though leaders such as Scott Ambler, Ken Beck, Alistair Cockburn, Mike Cohn, Ron Jeffries, Robert Martin, Mary Poppendieck, and James Shore. Check the recognized agile references. You will learn about architecture.
Myth #2: Agile teams don't do modeling
So myth #1 is declared busted: architecture is part of the recommended agile practices. And architecture is not only refactoring and test-driven development. Agile teams also conduct modeling activities.
Conclusion: Let's be pragmatic. As agile teams, we have to think about the structure and the behaviors of the solutions we develop. And very often, simple modeling sessions are very efficient to build better applications. Architecture is definitively a key activity of agile developments. It helps teams teams build better software-intensive systems.
Pragmatic Architecture, DevOps, and Cloud Computing
Matching: pragmatic X
jl.marechaux 060001NWA6 Tags:  distributed rational agility-at-scale collocated pragmatic 6,910 Views
Distributed teams are often defined as teams with members in different offices, cities, or countries. Compared to collocated teams, they need more disciplined approaches to address the specific communication and collaboration challenges that they are facing. But geographically distribution is not the only factor to consider. Some collocated teams may fail in their agile endeavors because they do not their working environment.
Let's take the (fictitious) example of SatoriGeeks, a small company specialized in innovative solutions for the finance industry. They have a team of 6 people to develop their current solution. They all work at the SatoriGeeks office in Montreal, Canada. They have an open space to sit together for better collaboration, they have scheduled daily meetings for better progress status. They have also adopted a whole team approach with cross-functional people to maximize project success.
What can go wrong with this small collocated team? Their working environment may actually be more complex than it appears at first glance.
Marie, the product owner, is often visiting customers to understand their concerns. On a typical week, it is rare to see her at her desk. Simon, a team member, had a new baby girl last year. To balance work and family life, he is working from home twice a week. Rachel has flexible working hours (she lives in the Montreal south shore and tries to avoid peak hours to cross the bridge). Thomas had a knee injury playing tennis a couple of months ago. Since the beginning of the project, he must visit the physiotherapist twice a week during working hours. And he works from home when the knee hurts to much.
So for many good reasons, key members of the team are not always able to meet in the same workspace. Communication is affected, collaborative work is not as effective as it used to be. The team should consider itself as a distributed team because they have flexible working hours.
Flextime and flexplace has become mainstream in many organizations. It is too often considered as an human resources matter only, although flexible working hours affect project teams. Even if they are small and collocated, teams like SatoriGeeks would benefit from a more disciplined agile process to facilitate collaborative.:
Flextime and flexplace should lead collocated teams to consider some agile practices usually adopted by distributed team.
jl.marechaux 060001NWA6 Tags:  featured agility-at-scale pragmatic rational tools architecture agile agileadopt 23,405 Views
\'prag-me-ti-zem\: a practical approach to problems and affairs.
In software engineering, architecture is a concept difficult to define precisely. One word is used for very different concepts such as functional architecture, data architecture, solution architecture or enterprise architecture. In addition, boundaries between architecture and design are unclear. Some say they are similar concepts. Others argue that they are complementary concepts with different levels of abstraction.
The real question is not what architecture is or is not. The real question is whether or not architectural analysis is useful for your project. And most of the time, if your are developing software-intensive systems, the answer is YES. It is where pragmatism comes into play.
Many methodologies try to define the architectural work that you should complete. Some fundamentalists recommend that you define your architecture before you start your development. Dogmatic theoreticians say that architecture is a waste of time and that only code matters. Pragmatic architecture is about adopting the approach that works best for you. And what is best for you is not necessarily what is best for others.
The pragmatic architect focuses on essential concrete tasks and prioritizes the work according to the value it brings to the project. The pragmatic architect is open-minded and never refuses to consider a solution just because it is not the trend of the year. The pragmatic architect revisits the design as the development of the system progresses.
Your goals during p.r.a.g.m.a.t.i.c architectural activities
As architects, we must value pragmatism and practical experience over dogmatism and theory.
The posts in this blog are written by Jean-Louis Marechaux (aka