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
Continuous Integration (CI) and Continuous Delivery (CD) are practices to help agile teams produce and test working increments. In ALM and Agile ALM, teams are relying on CI and CD to support their iterative, incremental approach, and to get feedback on the product under development on a regular basis.
Yesterday, IBM announced the acquisition of UrbanCode. UrbaneCode Software focuses on continuous delivery and will extend IBM's DevOps strategy.
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
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/
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
[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.