Modified on by jl.marechaux
Part 2: Using automated build as part of the development activities
As described in the first part of this blog, the Agile ALM solution can be configured with a few simple steps to provide automated builds to agile teams.
Let's explore how my agile development team can leverage builds during Sprint execution.
To implement a new story, I can adopt a “Test First” approach and start with the creation of JUnit test cases. It helps me test my new classes, but it also provides automated tests that I can include in builds.
In agile projects, continuous integration is a recommended practice to ensure that code developed by individuals does not conflict other parts of the application.
\With RTC, before I deliver a change set, I can verify that the new code will not affect the integrity of the application. Classes in an “Outgoing” change set are copied to my repository workspace on the server, but are not delivered to the development stream yet.
At this point, I can request a Personal Build. The use of personal builds is a way to validate changes and integration before the artifacts are delivered to the comon streams. Errors are identified before they impact the rest of the team.
If the build fails, I can explore the information provided by RTC and the build engine to understand the problem. At this point, no one else in my team will see the errors.
When my Personal Build completes successfully, I am ready to deliver my changes to the Stream shared by the whole team. All members will now be able to see the new capabilities that I have developed. Any team member can request a build anytime. And Agile ALM team can configure the environment to launch build on a predefined schedule.
Rational Team Concert provides different ways to support continuous builds as described above. One simple option is to leverage the Jazz Build Engine. RTC provides sample build files that you can customize to meet you specific needs.
Here is a build.xml example that you can download and review. The build compiles the code, runs the test, writes logs, creates archive files for dowload and publishes all the results on a centralized RTC dashboard.
Modified on by jl.marechaux
Part 1: Set up and configure the Agile ALM environment for automated builds
The IBM Rational solution for Agile ALM provides the environment to support teams in their day to day activities throughout an agile ALM projects. One key aspect of agility is to develop incrementally. A product increment is created at the end of each Sprint to demonstrate the new functionalities to the stakeholders.
In this example, I am using Rational Team Concert (RTC) and a project based on the Agile ALM solution (JKE – Mobile Banking) to explore the continuous builds capability. The overall process is the following
Find source code in RTC source control
Build using Apache Ant
Publish build results in RTC
Preparing the environment for automated builds
When a Project Area is created using the Scrum/Agile ALM process template (link to Agile ALM solution), a Stream and a Component are automatically generated.
Because the Agile ALM solution leverages the concept of Team Area, the first thing is to make sure that you have a stream for your team. You can create a specific stream, or change the ownership of the default stream. The point is that the steam must be owned by the Team Area (Agile Mobile Team), otherwise team members will not be authorized to deliver code.
With a stream and a component, you have the bare minimum to manage your source code. Now you want to be able to build efficiently your application on a regular basis.
In this example, I will use the Jazz Build Engine to take care of the build tasks. The Jazz Build Engine is an optional component of RTC that you can install and use (see help
for further information on installation)
For automated builds in my Agile ALM project area, I need to create a JTS user with permissions to conduct build tasks.
The new SysBuild user must have access the project repository, so it is added as a Project Area member. And to be able to run automated build, this user must be assigned to one of the Agile ALM team roles. Here I select “Development Team Member”.
To isolate the build process from the other tasks, it is recommended to use a dedicated workspace. So I create one, whose owner is SysBuild.
Defining the build assets in RTC
Now that the environment is ready for builds, I can define the elements in my project for automated build. I am using the RTC Eclipse client as creation of build elements is not supported in the web interface (in RTC 4.0.5)
I first create a Build Engine (jke.agile.dev.engine). As shown below, I want to reuse the Jazz Build Engine, but I have other option such as Hudson/Jenkins or BuildForge.
Then I need a Build Definition. Again, there are many options but I want the Ant- JazzBuild Engine template. Because I want to build my application from the Jazz Source Control, I select the Jazz Source Control option in the Pre-Build dialog.
Now that the build definition is created (jke.agile.dev), I can configure it according to my needs.
On the Overview tab, I add the build engine that I created earlier (jke.agile.dev.engine).
On the Schedule tab, I select days and hours for automated build.
On the Properties tab, I specify a couple of properties to use in my build tasks
On the Jazz Source Control tab, I select the workspace to reuse for builds, and the location to load the source file
The Ant tab contains the location for my ant build file.
This build definition is ready to be used in my Agile ALM project. I now need to start the build engine.
I have created a batch file that contains the following instructions:
jbe -vm "D:\Tools\IBM\CLM-Releases\TeamConcert404\jdk\bin\java" -repository https://localhost:9443/ccm -userId build -pass build -engineId jke.agile.dev.engine
At this point, anyone from the Agile Mobile team can request a build from the RTC Eclipse client or from the web interface.
Because I am using specific Ant tasks in my Ant script, build results are automatically published and accessible to the whole team.
Next time, I will explore how the Agile ALM team can leverage builds during their development activities (Part 2: Using automated build as part of the development activities)
Modified on by jl.marechaux
IBM Rational Solution for Agile ALM Release 2 is now available!
The IBM Rational Solution for Agile ALM is for teams seeking a solution for agile software development adoption and automation. This solution brings together our core agile product, IBM Rational Team Concert™ (RTC), practices, and supporting assets to help agile teams maximize the value they can achieve through agile development using Scrum.
The IBM Rational Solution for Agile ALM makes it easy to adopt and automate Scrum. Governance is "baked in" with tool automation defined by the template, while in-context guidance advises the team what to do next. The solution directly supports key Scrum artifacts (Product Backlog, Sprint Backlog) and events (Sprint Planning, Daily Scrum, Sprint Reviews and Retrospectives) in an integrated environment that maximizes transparency, collaboration and productivity.
The following are the core solution assets and links to where they can be accessed, free of charge:
Recorded demos: Short recorded demos (< 5 minutes each) that describe the key features of the solution.
Technical solution: The latest Agile ALM with Scrum RTC process template with in-context Scrum practice guidance, role-based dashboards, customized plans and common tasks help teams get started.
Technical solution enablement: Free scenario, demos and tutorials can help all Scrum roles on a team to learn how to quickly implement and use the IBM Rational Solution for Agile ALM.
Agile enablement: Social learning community, including a learning roadmap, forums to asks questions or share ideas and experiences and an experts zone to find peers, SMEs and leaders.
if you wonder how to be agile in an ALM context or if you want to engage with other agile practitioners, visit the DevOps community forum
Modified on by jl.marechaux
Earlier this week, I posted a blog entry about Learning Circles so that people are aware of this new initiative.
Here I want to explain a little bit more what learning Circles contains. As I said before, a learning circle is a collaborative environment to learn the basics about a technology or a product. Because it relies on social learning, you can find subject matter experts, graduates or leaders within the community and start a discussion with them (Experts and Leaders page).
Another important aspect of a learning circle is the learning roadmaps it contains. This is where you will find educational materials to gain specific competencies. A learning circle will help you meet different learning objectives throughout specific learning roadmaps
Depending on the learning circle you are interested in, you may find a variety of learning roadmaps, such as:
Basic Awareness: Articulate concepts and benefits of a solution
Install and Config: Set up and customize and environment with one or more products
Basic Usage: Use the product in a simple scenario
Demonstrate Value: Demonstrate the value of the product and its features
Additional Competencies: Deeper dive usage of a solution, troubleshouting
The picture below represents the different learning roadmaps and their objectives.
I guess you can’t read, so go to http://bit.ly/1dHf3lh to explore the Learning Roadmap tree (animated presentation).
And start using the Learning Circles to gain skills in your area of interest.
Modified on by jl.marechaux
From this collaborative community, you can gain basic competencies on some IBM offerings. It’s simple and easy. Just like a “all you can eat buffet”, educational material is placed in a public area, and you select what is appealing to you.
Feed you appetite for learning with our "All You Can Eat Buffet".
You are new to a specific IBM offerings? No problem! In Learning Circles, you will find simple educational material to understand better the value proposition of a product or its basic usage to address business problems.
And to maximize your learning experience, you also have access to other students or to subject matter experts through discussion forums.
The Rational Solution for Agile ALM
is for customers looking to adopt Rational Team Concert (RTC) throughout the development of their Agile ALM projects. The solution is free to customers (and RTC is free for up to 10 developers).
The Agile ALM solution Release 2 is compliant with RTC 4.0.5, and is consistent with the latest version of the Scrum Guide published in July 2013. With this new release, we have improved the following assets:
Process template: The Agile ALM Scrum process template has been refined to better support agile teams (preconfigured projects, dashboards and widgets). In-context guidance is accessible from work items (rich text mouseover).
Practices: The Agile ALM practices now contain guidance to perform activities with RTC (Tool Mentors).
Tutorials: The tutorials have been streamlined to focus on key activities first. Optional activities are clearly identified. The tutorial workbooks can be used for self-enablement or during a workshop.
Demonstration: Short recorded demos are available to show how RTC is used throughout an Agile ALM project.
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.