- Team collaboration
- Evolutionary design
Pragmatic Architecture, DevOps, and Cloud Computing
jl.marechaux 060001NWA6 Tags:  pragmatic architecture clm alm-sig agility-at-scale agile rational alm agileadopt 11,113 Views
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 product.
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:
jl.marechaux 060001NWA6 Tags:  alm-sig agileadopt pragmatic agility-at-scale alm clm architecture agile rational 9,426 Views
Earlier this month, Dan Leroux and I delivered a session at the Innovate 2013 conference. Our objective was to cover two different aspects:
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)
jl.marechaux 060001NWA6 Tags:  alm-sig pragmatic clm agile rational agileadopt safe architecture scrum agility-at-scale 9,265 Views
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.
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.
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.
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!
jl.marechaux 060001NWA6 Tags:  architecture agileadopt alm-sig agility-at-scale clm rational pragmatic alm agile 7,101 Views
[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)
jl.marechaux 060001NWA6 Tags:  architecture rational clm agility-at-scale alm pragmatic agileadopt agile alm-sig 6,497 Views
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
jl.marechaux 060001NWA6 Tags:  agility-at-scale rational clm alm-sig agileadopt agile 5,953 Views
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.”
Take a look at this video to understand what a scrum looks like: http://www.youtube.com/watch?v=9AnEYJSY7x8
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.”
Again, a small video to understand mauls: http://www.youtube.com/watch?v=Io2R4XZC29k
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?
jl.marechaux 060001NWA6 Tags:  rational architecture pragmatic agileadopt alm agile alm-sig webcast clm agility-at-scale 5,946 Views
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.
The replay and the slides are available on--demand from the InformationWeek website at https://www.techwebonlineevents.com/ars/eventregistration.do?mode=eventreg&F=1005386&K=CAA1AC.
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.
jl.marechaux 060001NWA6 Tags:  agility-at-scale rational pragmatic safe architecture agileadopt alm-sig scrum agile clm 5,542 Views
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.