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)
Modified on by jl.marechaux
No, Maul is not a new framework for agile practitioners. Read a bit further and you will understand what I mean here. It may ever been easier for you if you have some knowledge about rugby (rugby is not a web framework, it is a sport!). After all, the Scrum framework took its name from the game of rugby.
As defined by the International Rugby Boad (IRB), “a scrum is formed in the field of play when eight players from each team, bound together in three rows for each team, close up with their opponents so that the heads of the front rows are interlocked. This creates a tunnel into which a scrum half throws the ball so that front row players can compete for possession by hooking the ball with either of their feet.”
The same IRB explains that “A maul begins when a player carrying the ball is held by one or more opponents, and one or more of the ball carrier’s team mates bind on the ball carrier. A maul therefore consists, when it begins, of at least three players, all on their feet; the ball carrier and one player from each team. All the players involved must be caught in or bound to the maul and must be on their feet and moving towards a goal line.”
In rugby, the primary objective it to ground the ball in the opponents' in-goal (then a "try" is scored). But there are many different techniques to achieve this goal.
At first glance, scrums and mauls may seem similar, but the major difference is regarding who holds the ball. In a scrum, there is no ball carrier and players are no authorized to handle the ball. The ball “belongs” to the whole team until the scrum is over.
The approach is different in a maul. Someone grabs the ball and (try to) keep it while others from the teams help him move toward the opponent's in-goal.
Why am I talking about scrums and mauls in rugby? Well, I was having a discussion with colleagues recently about task allocation during a Sprint. The Scrum Guide is not very clear about tasks ownership. Task allocation is not really addressed, and the self-organized team commits to complete a set of item by the end of the sprint.
Nevertheless, there is a section in the Professional Scrum Master open assessment
that clearly states that Sprint backlog items are never owned by an individual, but by the entire Development Team.
If no one owns a specific task, it looks like a scrum in rugby where team members know what they have to do as a group. They move forward, they collaborate, they progress toward their common objective, but no player grabs the ball.
I have been working in distributed teams the last 5 years. My teammates are in multiples geographies, in different time zones. In such an environment, teams may find it easier to assign tasks to individuals. This is an easy way to know precisely who does what, even if your team is not always in a single project room.
With tasked assigned to team members during a sprint, the approach seems to be more the one of a maul. Someone owns a task (the ball), and everyone is helping the task owner to achieve the objective.
What about you? In your organization, in your agile projects, are you seeing more often the scrum approach (no task assigned, the team “owns” the tasks) or the maul approach (tasks are assigned, and the task owner is helped by teammates). If you had to vote and choose one approach, which one would you prefer? Which one would best support your agile team: Scrum, or Maul?
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/
About 10 days ago, I blogged on the new Design Management 4.0 release. If you want to experiment with design management, you can download the DM 4.0 trial edition
Now to gain skills on DM 4.0, wouldn't it be cool to have access to some training material?
Guess what.... ? DM 4.0 contains a free self-paced training to help you adopt the product in your environment. The training includes:
- Training lessons (4 modules in the Information Center) to gain skills on DM capabilities
- Hands-on exercises (8 labs in a workbook) to experiment with key DM features
Again, this is free. Yes, you heard me...FREE! So you cannot miss this opportunity to learn through hands-on labs.
This new version contains many enhancements to the 3.x release, in particular the integration with CLM 2012
. CLM and DM can share the same centralized server and repository. The common administration console provides a single interface to manage users, roles, permissions, licenses, and lifecycle projects.
Design Management capabilities include reviews, comment, document generation, impact analysis, configuration management, lifecycle traceability and many other features for effective collaborative design management.
With the addition of DM 4.0, CLM 2012 provides a comprehensive environment for agile Application Lifecycle Management (ALM): requirements management (RM), design management (DM), quality management (QM), and change & configuration management (CCM). All natively integrated using the Open Services for Lifecycle Collaboration (OSLC) standard.
With CLM 2012 (including DM 4.0), teams can link designs to requirements to ensure that technical solutions are aligned with business needs. All team members and stakeholders can easily access design information during development sprints. They collaborate on design activities and are involved in design reviews. They leverage dashboard mashups to gather information on requirements, designs, tests and changes. Application delivery is facilitated with access to real time planning. Reaction to change is improved with lifecycle traceability and impact analysis.The centralized environment provides live reports on the development team to reflect the activity and trends of the team. All the information collected during a project is used to improve the team dynamic and fine-tune the ALM platform for better productivity.
In-context collaboration, real-time planning, lifecycle traceability, development intelligence and continuous improvement: 5 imperatives for effective ALM that CLM 2012(with DM 4.0) supports.
Go to jazz.net for more information on new DM 4.0 features. https://jazz.net/downloads/design-management/releases/4.0?p=news
If you want to be a speaker at AgileTour Montreal, hurry up, you've got until Sept 12 to submit your presentation proposal. In you are in the Montreal (Canada) area, this is a great opportunity to share you experience on agile practices.
In July, Todd Dunnavant and I presented at the Good Design is Good Business
, a virtual, online conference for both clients and IBMers.
We talked about the collaborative design management capabilities (DM
) that are being added to the IBM Rational offering.
Design Management (DM) is an ALM discipline that integrates software and systems design into the lifecycle. DM extends ALM disciplines such as requirements management, change & configuration management, and quality management.
The presentation material is now available online. It covers lifecycle integration, in-context collaboration, and lifecycle traceability.
Later this year, we plan to have more in-depth sessions on Design Management & ALM. Stay tuned....And join the Good Design is Good Business community group
to be notified about future webcasts.
For the 4th consecutive year, the Agile Tour
) will stop in Montreal this Fall. With more than 450 attendees last year, the Montreal conference is the right place to meet Agile experts and practitioners.
For the first time this year, I am part of the conference organizing committee. I am very excited about it! I hope we will prepare a high quality and unforgettable event.
FYI, the call for speakers
is now open. So if you happen to be in Montreal (Canada) on November 24 and you want to share your Agile experience, do not hesitate to submit a proposal.Agile Tour Montreal conference
- Where: Montreal, Canada
- When: November 24, 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 !
If you ever worked in a project where a scaling factor applies (see the scaling factors description
), you know that an appropriate tooling can help a lot. To deliver a software-intensive system, agile teams need to collaborate efficiently in a complex environment. In many cases, a white board with sticky notes is not enough, so teams adopt specific tools according to their needs for iteration management, test automation, or continuous integration (just to name a few).
If you have experience in software-intensive system delivery, you also know that when your tool set is not adapted to the needs of your team, it becomes a barrier to adopting agile practices. Agile is a highly collaborative approach to software development. If your different tools are not integrated, you are wasting time managing the links between project assets manually instead of focusing on creating working software. I have seen many projects using spreadsheets or wiki pages to compensate for the lack of integration between their development tasks, business needs, design assets, and quality management systems. It is a time consuming and error prone process. And when you need to figure out the impact of a changing requirement on a piece of code, it takes hours where it should only take minutes.
Open Services for Lifecycle Collaboration (OSLC
) is an open community creating specifications for integrating tools. These specifications allow conforming independent software and product lifecycle tools to integrate their data and workflows in support of end-to-end lifecycle processes.
With OSLC, your team can link elements from your defect tracking tool, your requirements management tool, your test management tools, and your design management tool. You may argue that traceability already exists with tooling platforms provided by some vendors. True. But what if you have a task tracking tool from vendor A and a test management tool from vendor B? Then integration no longer exists, or relies on some proprietary mechanisms. Do you really want to restrain your options to one unique vendor.
OSLC specifies a minimum amount of protocol to allow independent tools to work together relatively seamlessly. You can have quality management tools from vendor A and decide to use requirements tools from vendor B. Both will be integrated if they comply to OSLC. And later one, you will also be able to acquire another OSLC tools from vendor C without compromising your lifecycle integration.
So how does OSLC help agile team? Simply by enabling integration between lifecycle tools. If your team members must collaborate, your tools must work together too. Integrated tools help agile teams react quickly to changes and deliver software frequently.
(Watch the IBM OSLC video on YouTube for more details: http://www.youtube.com/watch?v=B2vqL8fujgE
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.
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.
Experienced Agile teams working on software-intensive systems conduct architectural analysis activities to mitigate technical risks and build better solutions. As a picture is worth a thousand words, those teams leverage diagrams for better agility. It is really efficient to share ideas and lead brainstorming sessions.
To create those diagrams, I can use a napkin, I can prefer a dashboard, or I can choose Rational Software Architect V8 (RSA) sketches. Why would I use RSA? I could think of four different reasons: easiness, collaboration, documentation, and flexibility.Reason #1: Easiness
RSA sketches are easy to create. There is no learning curve on RSA sketches. They use simple and informal notation, just like I do when I draw a diagram on a whiteboard.
Reason #2: Collaboration
Whiteboards are good, but not good enough when you need to collaborate with an extended team. How do you share your draws with people you collaborate with. The project stakeholders, the clients, the remote resources? Ok, you can always take a picture and share it. But what happens when you need to work again on the diagram later? Do you try to work on the picture file or you create the diagram again. It is not really practical nor efficient.
With RSA, you create sketches, you have them in your repository, and you can use them anytime, even through a web conference. You can collaborate efficiently with your local teammates and with external stakeholders. And of course, you can modify the sketches over and over again.
(I will write another post soon on how you can collaborate a step further with models on a shared repository)Reason #3: Documentation
I know, documentation in Agile projects is not popular. We need to focus on working software. But this is where RSA sketches are useful. I create them, they are stored in my repository, the history of changes is kept. It is the basis for light documentation. I can focus on my development activities.Reason #4: Flexibility
What can I do with a sketch on a whiteboard? I can look at it. I can erase or add elements. I can take a picture of it. And that's about it.
Now what can I do with an RSA sketch?
I can of course look at it, or add and remove elements. I can save it as a picture file (see, no camera needed this time).
I can also arrange the sketch appearance applying predefined or custom layouts (grid, hierarchical, horizontal....). This is always a challenge with a whiteboard diagram. You start the drawing and when you need to add more items, you have no space. Then you start writing so small than it become difficult to read.
With RSA, I can also link sketches to other sketches. Or create sketches form sketches elements. Then my diagrams are linked together, and a simple click opens the source or the target element. Really convenient to brainstorm at a high level first, before creating more precise diagrams for the most complex part of my solution.
Another nice RSA option is to convert my sketches into UML elements. So if I am using UML in my project, I can start with informal sketches and convert them when I need a more formal notation. Traceability between sketches and UML models is automatically created. I can even decide to mix informal sketches elements and UML elements in the same diagram.
RSA sketches are easy and flexible. They can support my Agile development and enhance my team collaboration. For further information on RSA sketching capabilities, see the free agile sketching training component on http://goo.gl/wGYtF
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.