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.
Great news in this OSLC world this month. Eclipse Lyo 1.0
is now available and IBM Rational Lifecycle Integration Adapters 1.0
has been released.
Eclipse LyoRational Lifecycle Integration Adapters
is an open-source initiative to make OSLC more meaningful and approachable. Lyo contains a Java toolkit for building OSCL applications (OSLC4J), an OSLC reference implementation, and an OSLC test suite (to measure your implementation compliance against OSLC specification). Lyo also provides documentation and samples to help people adopt OSLC.
is a set of adapters to facilitate integration between the IBM solution for Collaborative Lifecycle Management (CLM) and third party offerings such as HP ALM, Atlassian JIRA, and open source Git.
With Eclipse Lyo, it is easier to develop OSLC providers and consumers. With Rational Lifecycle Integration Adapters, it is straightforward to integrate heterogeneous lifecycle products (different products, from different vendors). And of course, OSLC continue to evolve to better support lifecycle integration. Check it out at http://open-services.net/
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/
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.
Blogging is not writing. It is just graffiti with punctuation.
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.
I have recently been designated an IBM developerWorks Contributing Author. As, they say, this is a "credential that represents your publishing achievements on developerWorks and the overall technical and educational value that your developerWorks contributions have provided, as recognized by industry colleagues."
I hope that the different articles that I wrote in the past have been useful for practitioners doing architecture, design, and development
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.