This year, I hope I will have more time to dedicate to this blog. When I started as Worldwide Technical Enablement Lead in February 2013, I had to focus a lot on my new role, and I mostly posted on internal IBM blogs and on an internal community of practice that I am leading.
Now that the dust has settled a bit, I may have more opportunities to share through this blog. I will also continue to contribute to IBM communities, both internal and public ones, such as the DevOps Community, Jazz.net or the Rational Learning Circles.
Modified on by jl.marechaux
You want to start a software development project on the Cloud? You have no money? You want to collaborate easily with a team?
JazzHub is the solution for you. Read this Project kickoff on JazzHub article to understand how an agile team can start using JazzHub to collaborate efficiently on a new development.
And guess what?. JazzHub is free for public projects, and free for private projects through 2014 is you register by Dec 31, 2013.
Modified on by jl.marechaux
For those of you who read this blog since I started it, you probably know that I am a huge proponent of architecture and design in software development. I am also convinced that agile methodologies help us build better products.
A framework like Scrum is very good for managing software projects but it may not provide enough information for less experienced agile teams, or teams working in a complex environment (multiple Scrum teams, programs, agile initiatives at the enterprise level). And architecture and design are not really first class citizens in Scrum.
Here comes SAFe, the Scaled Agile Framework. And guess what ? Architecture is part of the framework. I like it! Looking at the SAFe big picture
, the first thing that you will notice is that there are three different levels: Team, program, and portfolio. Let's have a look at the architecture in those levels from an architecture standpoint.
The team level is where the agile team define, build, and test stories during iterations. During a time-box, the team builds assets until they deliver a Potentially Shippable Increment (PSI). The main architectural concepts at the team level are the Spikes, the NFRs, and the Refactoring.
The notion of spike comes from XP and it is good to see it reintroduced here. A technical spike is an activity to explore potential solution for a complex technical or design problem.
Non-Functional Requirement (NFR), sometime called Quality of Service, is a constraint to the system. Any agile team building a software-intensive system has to take into account requirements such as availability, scalability, security, or transactional throughput.
Refactoring is another important architectural concept. It may be used to reduce the technical debt or to address emerging design needs (including new NFRs)
SAFe introduces the concept of the Agile Release Train (ATR), where the ATR “is to the program what an iteration is to the team”. To put it simple, a train delivers features in a release, at a regular cadence.
An architectural feature is the technical aspect of a system that is needed to support a business functionality. Over time, architectural features may evolve into NFRs.
With architectural features implemented in a program, the enterprise incrementally builds an architectural runway. Instead of big up-front architecture, agile teams develop the technology platforms to support business needs during each release.
At the program level, the System Architect is responsible for the technical framework to support business needs. Architects focus on architectural features and NFRs. They are involved in the architectural runway. System architect is a role, not a job position. The role can be played by different individuals.
The portfolio level is where the enterprise defines its vision, its business strategy. High priority investment themes are implemented through agile programs to achieve business results.
Architectural epics are large technology initiative at the portfolio level. New epics are continuously identify to improve the technology platforms that deliver business functionality.
The Enterprise Architect operates at the portfolio level. The role is to drive the work around architectural epics and support the development team as needed. SAFe suggests a Kanban approach to manage architectural epics.
SAFe is not meant to replace Scrum, but to scale Scrum to an enterprise business context. If you have to manage a portfolio and multiple programs in your organization, then SAFe can be a good option for you. And at the team level, agile team can keep using Scrum or other agile frameworks.
With SAFe, architecture is back in the game, and architectural activities are no longer hidden. Pragmatic architects, the agile world can be SAFer with you. So don't miss the train!
Modified on by jl.marechaux
Earlier this month, Dan Leroux and I delivered a session at the Innovate 2013 conference. Our objective was to cover two different aspects:
How architecture & design fits in an agile environment (such as a team using Scrum)
How one team in the IBM lab is applying light design principles to develop a product
Back from Orlando, I created a prezi with some of the information that we presented during the conference.(Click the image to launch the presentation)
In June, I will be a speaker at the Innovate Conference in Orlando, FL. The presentation will describe how a lightweight design approach supports agile teams to deliver software. Real examples from the internal Design Management development team (the IBM lab) will be used to illustrate the approach.
I am honored to co-present this session with Dan Leroux, Distinguished Engineer at the IBM Lab.
If you are interested in attending the session at the conference, here are the details
Title: Design on a Diet! A Lightweight Design Process
Room: Dolphin - Northern A1
Date/time: Wed, 5/Jun, 08:30 AM - 09:30 AM
On January 22, Vishy Ramaswamy and I talked about Agile architecture during an InformationWeek webcast: Agile Development: Three Pillars of Success. Questions which had not been answered during the Q&
A session for lack of time are listed in this blog entry:
On January 22, I co-presented an InformationWeek webcast with Vishy Ramaswamy. the architect of the Design Management Server. The webcast was mostly an informal discussion where Vishy and I shared our opinions on four different topics.
- What is Agile Architecture and what is the difference between this approach and conventional design and development practices?
- What is a recommended practice for just enough traceability across the life cycle?
- What are the kind of architectural and design expressions suitable for "just enough" design?
- How do we still support generating or creating formal models from the informal expressions?
To access the material, you need to register with a valid email address. You will receive an email with a link to the recording session.
Yesterday, I was co-presenting an InformationWeek webcast on Agile Development: Three Pillars of Success
. With Vishy Ramaswamy , the lead architect for Design Manager, we talked about some agile architecture practices and how these practices were adopted by the IBM development team to create and deliver the Design Manager
During the Q&A session, there was a question that we saw a question that we did not answer (lack of time, too many good questions). It was something like: “What should we pay attention to when we try to adopt agile architecture practices on our projects?”
When I started this blog, I used the following description (from http://bitly.com/Sg2FQe) to define what Pragmatic Architecture is:
To summarize a bit, I would say that the three pillars of pragmatic architecture are:
- Team collaboration
- Evolutionary design
During sprints, agile teams focus on development to deliver working software. Developers examine user stories to implement business needs. They also consider language best practices, design patterns, code complexity, or easiness to evolve and maintain the software. That's why agile design is an important activity during a development sprint.
Development is not a mechanical activity. You don't write code without thinking...and you have many opportunities to think while you develop a feature.
Sketches for ideation and problem solving
An image is worth a thousand words. Often, complex ideas can be conveyed with a simple diagram. Recently, I read a really serious study from researchers of an university (in UK I believe) were they tried to measure the amount of information conveyed by a picture (diagram, sketch, drawing...). They calculated a 84/1 ratio. So according to them, a picture is worth 84 words. It is not 1000, but it is not that bad!
So anyway, sketches are useful to convey and discuss ideas. And sketches are definitively design elements. They help teams agree on the structure and the behaviors of a component.
During a development sprint, the team can have a need for a quick design activity. The “design in a flash” session can happen anytime to address a new technical problem uncovered. Such design sessions are not planned ahead of time. They are part of the development activities. Only the right teammates are involved to provide their input, and the session can last only 15 minutes.
Designs as input to development activities
When design information is available (sketches or others), agile team members can reuse it to better understand the tasks they have to complete.
To create a test or implement a new feature, a developer can quickly take a look at the design of the component. Of course, the user story is important, but the design will provide other key information such as the relationship with existing components, the interfaces, or the technology to use.
Because software programming requires some thinking, design is part of development activities. In a software intensive system, a component does not work in isolation. It interacts with other components. Good thinking (design) leads to coherent and resilient architecture, which is key to agility..
[Previously on ALM and agile design.....Part 2 – Release plans, iterations, and design
Each sprint begins with a planning exercise where the team defines the sprint goal and the sprint backlog. Team members examine the backlog to select the most valuable stories that can be contained in the sprint.
During sprint planning, design information can be used for three different purposes.
First, to assess the technical feasibility
of a requirement. If the new feature is straightforward, then this task can be skipped, but for more complex features, the team can explore different design options to agree on a target solution.
Second, design information is used to identify the tasks to implement the sprint stories
. A technical perspective on each story is needed to understand the work to complete. For some stories, the team will need to develop new component, for others, the team will need to integrate or reuse existing assets.
And last but not least, agile team can leverage design resources to evaluate the development effort.
If the team is using the planning poker technique, design information will help choose the right card.
Development effort should be assessed based on the understanding of what needs to be delivered. Design information helps the team identify what can be delivered (technical feasibility) and what can be contained in the next sprint (estimation)
Then read the related article published on developerWorks and tell me more about the pragmatic architecture approach that you have adopted in your agile projects.
Share your experience!
Just back from Agile Tour 2012
, a conference held in Montreal (Canada) on November 24.
Ok, it was not a long trip as the conference center is probably at less than 2 miles from home.
This year, I was a member of the organizing committee. Quite an experience which started around March, an initiative led by the Agile Montreal community
Key facts and figures from the conference:
- Sold out event: 500 registered attendees
- 23 speaking sessions or workshops, 7 parallel tracks
- 2 word-class keynote speakers
- 12 members on the organizing committee. Not that much for such a big event
- About 16 volunteers came to help out (thanks a lot guys!)
- 500+ lunchboxes... wow... a lot of food. Unfortunately, I don't know how many gallons of coffee were consumed.
- 17 sponsors. Definitively helps to pay for the 500 lunchboxes
- My day started at 4:30 am. Way too early!
- My speaking session was at 3:30 pm. Way too late when you get up at 4:30 am :-)
- The conference ended at 5:00 pm but a lot of people decided to keep the discussion going during the evening cocktail.
People I talked too during the conference are not interested in the "agile dogma". They value "pragmatic agility"
, agility applied to their specific context. Sometimes it means governance
, sometimes ALM
, sometimes lean
So far the feedback from attendees is very good. It was an amazing day. I am glad I had the opportunity to be involved in the organization of this conference.
I will be a speaker at Agile Tour 2012 (Montreal) on November 24. My session is about the role of the agile architect in an ALM environment.
Here is a teaser.....I hope it will prompt people to attend the session.
"The session explains how Pragmatic Architecture fits into an agile software development lifecycle. It describes some Agile concepts applied to architecture and design. Using a realistic example, we illustrate how agile teams use design information during the ALM cycle. We also explain how teams achieve lifecycle traceability and better agility with ALM tooling.
"What someone can expect to take away from the presentation?
Table of content
- Discover Pragmatic Architecture: Agile concepts applied to architecture in an ALM environments
- Understand how architecture and design information is used throughout an agile ALM cycle
- Comprehend how tools can support agile ALM and design tasks
- ALM and agility
- Pragmatic Architecture
- Case study: An agile ALM scenario
Interested?..... Take a look at the Agile Tour 2012 (Montreal) page for further information.
Pragmatic architecture for agile Application Lifecycle Management
is a new article published on developerWorks this week. It covers Agile concepts applied to architecture using the Rational Solution for Collaborative Lifecycle Management (CLM).
Architecture & design is a key discipline in ALM. Agile teams value pragmatism and practical experience over dogmatism and theory. They focus on key collaborative design activities that accelerate the development of software-intensive systems. Design information can help during several agile activities such as backlog prioritization, sprint planning, development, impact analysis, and technical debt reduction.
Read more here
The Eclipse Foundation is not-for-profit community that hosts open-source Eclipse projects. You may already be familiar with some of the projects, such as the Eclipse IDE (and web tools), TPTP (for tests), or Mylyn (for tasks).
But do you know about the Eclipse Process Framework (EPF)? With EPF, you can create, document, and publish a custom process. And that's exactly what the Eclipse Foundation community has done for some popular Agile processes.
As a result, you can access documentation on XP, Scrum, or OpenUP online.
Btw, EPF is not new, but I digged out the links during my fall bookmark cleanup. More on EPF and published processes here: http://www.eclipse.org/epf/
Studies show that a lot of software systems are not aligned with business needs. Sometimes, it is because a few requirements are not implemented. Most of the time, it is because the software system contains features that do not correspond to any real requirement.
The main challenge for a development team is to understand the requirements. Otherwise, the team will develop features that nobody needs. But understand requirements is not easy in business domains always more complex.
Let's take a simple example. On the following diagram, here is the requirement: "Connect the nine dots with four straight lines, without lifting the pencil".
You've got it? Bravo!
If you don't, read the requirements one more time. Take your time. Need some help to find the solution? Click here
Don't worry if you failed to solve the problem. The test is a well known cognitive science puzzle. Most of use are supposed to fail. Why ? Simply because of the way our brain works for problem solving. We interpret the problem statements in the light of our own knowledge and experience. In other words, human reasoning is often biased. So what can we learn from this?
Requirements are hard to understand. And we (our brains) often misinterpret the needs. So it is no surprise that software systems do not always correspond to initial requirements. Agile teams should catch on cognitive science.
Agile approaches foster collaboration between business people and developers throughout the project. When the development team works closely with the customers, requirements are clarified on the fly, during informal discussions. The overall quality of a software system is improved.
In the nine dots square example, it would have been helpful to ask questions about the requirements. You would have discovered early that there is no constraint to keeps lines inside the square. The solution to the puzzle would have been easier to find.
The Agile Tour is a series of conferences on Agility in 15 countries, making it the single most important event in agility worldwide.
In Montreal, Canada, the 2012 edition will be held on November 24. The program is (almost) finalized. The speakers have been selected. Now we need to publish the program details (sessions, time, length).
Agile Tour 2012 will present 22 sessions or workshops on various topics such as:
- Agile development, design, and architecture
- Coaching and mentoring
- Cultural changes and agile adoption
- Agile management
- Games and simulations
We will also have two amazing keynote speakers, two visionary leaders in their respective domain.
For further information, go to http://agilemontreal.ca/agile-tour-2012/
[Previously on ALM and agile design..... The pALMatic architect
Agile teams develop software iteratively. The product backlog lists all the stories to implement and the team decides which ones they will address during the next release or iteration. In an ALM environment, teams want to plan and align their activities across all the disciplines, including requirements, design, development, and tests. The real challenge is to identify the right set of features to develop first. Any mistake in the priorities will lead to plan commitments that you will not be able to deliver. For most teams, business value is an important factor to prioritize the product backlog. But other aspects must also be considered, such as risks and dependencies.
Seasoned agile teams want to address risk early in the process to remove uncertainties as soon as possible. When a story may imply some technical challenges, it is a safe approach to increase its priority. Also, pragmatic practitioners know that some dependencies may exist between stories. Sometime, a high priority story can only be implemented once the work of a related story is completed. So when a new iteration starts, it is important to identify the most risky stories and to uncover the dependencies between features. This information influences development priorities for the team.
How can you identify risks and dependencies? In most software-intensive systems, practitioners must apprehend the structure of the application before they commit to deliver any change. They must also understand the impact of a new story or a change request on the existing code. This is where design helps. It provides insights to the team so that they prioritize the backlog based on concrete information. With a quick access to a design element or a diagram, team members can decide if the priority of a story must be increased. They may even conduct a brief brainstorming session to better understand the technical challenges.
Design management is an integral part of ALM to deliver software-intensive systems in a complex environment. During planning activities, agile teams refer to design information to make rational choices. The backlog is prioritized as the team takes into account the business value, the risks, and the dependencies.
Today I am starting a series on ALM and Agile design (probably 4 or 5 different posts in the coming weeks).
bit like humans, software-intensive systems are conceived, come to
life, grow, evolve, do their job to contribute to business goal
achievements, are retired, and die. Application Lifecycle Management
(ALM) is the process of managing a system throughout its entire life.
small teams and simple environments, core agile practices are usually
enough to manage applications. For agility at scale, things are a bit
more complicated. ALM is often defined as an approach that integrates
disciplines as diverse as requirement management, design management,
quality management, and change and release management. Benefits are
obvious. ALM breaks down functional silos and promotes collaboration and
role-focused views of the application lifecycle. The entire team gets
greater insights into the project. Actionable information leads to
better productivity, improved quality.... and enhanced customer
Design management is a key building block in ALM.
The pragmatic architects do not work in isolation (read more on Pragmatism in architecture
. Those completing
architecture and design tasks want to understand the business needs
(requirement <--> design). They also have to make sure that the
design supports the implementation of the solution (design <-->
code). And design is eventually validated by some tests to validate its
quality (design <--> tests).
In other words, design
participates in lifecycle traceability. During the life of the
application, the pragmatic architect evolves and refines the design to
meet changing requirements and new technical challenges. And the
pragmatic architect also ensures that the design information is
available for efficient requirement management, quality management, and
architect is also a pALMatic
- A: Adapt to changing requirements and new technical challenges
- L: Link design to other lifecycle artifacts (requirement, test, code, changes)
- M: Manage design information to help other ALM stakeholders
Design management is an integral part of ALM to
deliver software-intensive systems in a complex environment. The
pragmatic architect manages design information and conducts design tasks
for successful and collaborative ALM.
If you ever worked in a project where a scaling factor applies, you know that appropriate tooling can help a lot achieve your objectives. But on the other hand, tools are often identified as impediments for agile adoption.
The Agile Scaling Model
defines several reasons why you may work in an environment where core agile practices are not sufficient. But even in such an environment, you want to ensure your product owner, your scrum master, your development team, and your stakeholders collaborate efficiently through sprints and releases.
IBM Rational provides an ALM (Application Lifecycle Management) for disciplined agile teams. Based on Jazz, the platform integrates requirement management, design management, quality management, and change management. Team members and stakeholders have access to the same project information and assets from a web browser. Anytime, from anywhere (distributed teams will appreciate!). They can collaborate through a centralized platform., The Jazz repository provides real time status on project progress. And the team can quickly react to changes by leveraging lifecycle integration and traceability, dashboards, queries, impact analysis, an reports.
Because the ALM platform leverages OSLC, you can even integrate with other OSLC compliant vendors. No more vendor lock-in. No more silos. Everyone working together to deliver better software. This is agility for ALM !
On February 14th has been published the list of the most-loved Rational articles in 2011
. Even if I am not sure what “most-loved” means here (can you really be in love with a technical paper??), I am glad to see that the one I wrote on architecture with RSA 8 is on the list. (http://www.ibm.com/developerworks/rational/library/define-application-architecture-rational-software-architect-1/index.html
But I must that this popularity raises a couple of questions. Published last October, the article has been viewed almost 15 000 times. I also created e-books from the article and they reached over 200 downloads since November 22, 2011. So why is this article so popular? Is it because it talks about RSA 8? Or because it covers an agile practice, the evolutionary architecture? Maybe there not enough enablement resources available on RSA. Maybe architecture is not covered properly by the agile community?
I'd like to have more feedback from the community. If you read this post, do not hesitate to contact me.
Success in agile development comes from teamwork. No matter which agile process you apply, collaboration is always at the heart of recommended best practices. Quality systems are also based on good design to make them easier to maintain and extend. The Better quality and agility with collaborative design
article demonstrates how Rational Software Architect Design Manager enhances collaboration on design activities.
Back from vacation.... During the holiday season, I had some time to read a couple of non-IT books, like Le bourgeois gentilhomme (The Middle-Class Gentleman). Molière wrote Le bourgeois gentilhomme in 1670. A key part of the play is when Monsieur Jourdain, the main character, discovers that he has being speaking "prose" all his life without knowing it (verse was more popular than prose at this time).
When I started my career as a software engineer (97), I used to consider myself as a lousy developer. I worked first with C++ and PoweBuilder before focusing on Java projects. No matter what the programming language was, it was always the same story. I had problems writing lines of code based on a written specification, while my colleagues seemed to be very productive. They were spending days coding features with no assistance, without even compiling their code. Remember that we are in 97-98. C++ and PowerBuilder are not interpreted languages, and the software specification is very often a verbose document. And most software development processes are waterfall.
My way of working was quite different. I used to write a few lines of code, to compile and test it immediately in order to verify that......it was not working as expected (usually with some ugly runtime error). Then I was refining the former piece of code to fix the error, and I was repeating this again and again until I was able to complete my tests successfully. Typically, I needed to test and rework my code several times per hours. Comparing myself to my more experienced teammates, I was ashamed of being such an ineffective developer.
Also, it was real difficult for me to apprehend the specification written by the business analysts. I was usually understanding the big picture, but not enough to be sure of the right piece of code to create. At this time, I was convinced that it was a result of my lack of experience. My colleagues seemed to be satisfied with the features assigned to them. They were working in isolation with just a specification document to help them.
Again, I had developed a specific technique to compensate for my inexperience: I was buying coffee all the time to the analyst team. I used to spend a lot of time (and money!) at the coffee spot with them, in exchange for their explanation. It was quite an expensive way of obtaining meaningful input, but I guarantee it helped me decipher the cryptic specifications. And after a few months, my regular “coffee discussions” were far more helpful than any document.
A couple of years later, I realized that my way of working was aligned with some agile practices. Just like Monsieur Jourdain, I was being agile for some time without knowing it. My daily (and expensive!) talks with business analysts, developers or DBAs were actually quite productive. And it was not uncommon to continue the discussion at my desk so that I can demo something. The different stakeholders were all providing early feedback to the feature I was trying to implement. And with my countless tests, I was actually improving the quality of my code, iteratively.
On the other hand, my teammate working in isolation were creating software disconnected from the business needs. End at the end of the time allocated for their development, they have never tested their code. What I was (jealously) seeing as an impressive way of writing code was actually a poor practice.
I am pretty sure that there are a lot of Monsieur Jourdain around us. Practitioners who leveraged agile practices far before agile became popular.
The good thing is that because agile is now mainstream, we no longer have to buy coffee for a discussion with stakeholders. Now it's part of the process, ..... for free.
Architectural analysis is a set of activities to build and improve the software architecture of a system. When conducted iteratively, this architectural thinking helps uncover and address issues during software development without requiring significant up-front architectural effort. Architectural analysis activities are crucial for every software-intensive system.
Despite what dogmatic agile development coaches might say, I believe that there is no successful software development without architectural analysis.
I had a strange conversation with an IT professional last week. To preserve his anonymity, let's call him Oleg.
(that's me): Hey Oleg, nice to see you ! How is it going?Oleg:
Pretty well, JL. I joined a new project two months ago. It's an agile team and I like it very much.JL:
Glad to hear that. What kind of project is it?Oleg:
We are developing a new solution to enrich our existing internet banking application. Our new component will integrate services from several departments and even business partners.JL:
Sounds like an interesting challenge. Are you working on the architecture of this new solution?Oleg:
No, we don't do architecture, we are an agile team.JL:
We focus on developing a set of services to enable the integration.JL:
Ok, I understand that your primary objective is to deliver working software but integration of services from different sources must not be easy. How do you define the structure of your component? How do you identify the different services needed? How to you mitigate risks?Oleg:
Well, it took two weeks before the project really started. Just the time to obtain the buy-in from the business sponsor and assemble the whole team. It was a great opportunity for me and some colleagues to start thinking about our new project. We addressed some of these questions at this time.JL:
I see... so you pictured the technical solution during the project warm-up. And how are you evolving your architecture during your sprints?Oleg:
Well, as I told you, it's an agile team. We do test-driven development and refactoring all the time, but we don't waste time on architecture.JL:
You mean that because you are an agile team, then you don't...THINK
Don't get me wrong. I work with brilliant people and we have brainstorming sessions all the time.JL:
Ok, so you are doing architectural activities, right?Oleg:
Well yes, but the client does not want to pay for architecture. So we don't really publicize this. We keep it secret in our war room and we bill our time on development tasks.JL:
I see. Architecture is really part of development sprints anyway, so you bill your time at the right place. Just curious, are you doing modeling at all?.Oleg:
Of course we do, because a picture is worth a thousand words. It helps us a lot during our brainstorming sessions. And we have a lot of short brainstorming sessions during the sprints to tackle new technical challenges uncovered. But again, this is not something we expose too much as the client does not pay for diagrams.
So what did Oleg tell me exactly? He stated that on his project, team members are not doing architecture because they are following an agile process. But then he explained that before their first development sprint, they spent some time to envision the architecture.
Oleg also told me that his team is not officially doing architecture during sprints. But he also confessed that they are hiding to create models, as if it is some sort of perversion. Their models or sketches are considered helpful for their just-in-time modeling sessions during sprints. It is how they refine the architecture of their software-intensive system over time.
So the good news is that Oleg's team is thinking about the new solution that they are developing (the bad news is that they seem ashamed of their architectural work).
Of course, you can not deliver a system if you keep thinking about it forever. Architectural work must be integrated to the development lifecycle. Architecture is intentional because you make deliberate decisions based on what you know when you start a project.
Architecture is also emergent because you always uncover new technical challenges during development sprints.
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.
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.:
- Tooling to support collaborative lifecycle management (backlog, sprint, real-time status)
- Centralize platform to share ideas and documentation.
- Tooling to enhance collaborative design management and development
Flextime and flexplace should lead collocated teams to consider some agile practices usually adopted by distributed team.
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
- P: Promote collaborative work that involves all team members
- R: Reduce risks and uncertainties
- A: Adhere to minimalism and simplicity principles
- G: Gather key elements to outline the architecture during your initial timed-boxed iteration
- M: Modify the design throughout the development lifecycle to adapt to emergent needs
- A: Address both functional and non-functional requirements
- T: Try out theoretical concepts and leverage past empirical experience
- I: Invest in known requirement instead of hypothetical future needs
- C: Concentrate on tasks that support the development team
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
JL), a member of the IBM Rational software group.
I want to make it clear that:
- What I say in the blog is representative of my views (and my views
- Anything about IBM and its products must be considered as unofficial
- The postings on this "Pragmatic
Architecture" site are my own and don't necessarily represent
IBM's position, strategies or opinions.