Blogs - Tags - pragmatic urn:lsid:ibm.com:blogs:entries282015-02-12T13:38:38-05:00IBM Connections - Blogsurn:lsid:ibm.com:blogs:entry-43fb6c7a-2439-4ae0-af69-d98bad2cef39Now that 2014 has started…jl.marechaux060001NWA6activeComment Entriesapplication/atom+xml;type=entryLikes2014-01-16T08:49:15-05:002014-01-16T08:49:15-05:00<p dir="ltr">
This year, I hope I will have more time to dedicate to this blog. When I started as Worldwide Technical Enablement Lead in February 2013, I had to focus a lot on my new role, and I mostly posted on internal IBM blogs and on an internal community of practice that I am leading.</p>
<p dir="ltr">
Now that the dust has settled a bit, I may have more opportunities to share through this blog. I will also continue to contribute to IBM communities, both internal and public ones, such as <a href="https://www.ibm.com/developerworks/mydeveloperworks/groups/service/html/communityview?communityUuid=c914709e-8097-4537-92ef-8982fc416138" target="_blank">the&nbsp;DevOps&nbsp;Community</a>, <a href="https://jazz.net/" target="_blank">Jazz.net</a> or the <a href="http://www.ibm.com/developerworks/training/learning-circle/" target="_blank">Rational&nbsp;Learning&nbsp;Circles</a>.</p>
This year, I hope I will have more time to dedicate to this blog. When I started as Worldwide Technical Enablement Lead in February 2013, I had to focus a lot on my new role, and I mostly posted on internal IBM blogs and on an internal community of practice...00657urn:lsid:ibm.com:blogs:entries-8c054795-1eba-4290-80af-3c3e2ab27479Pragmatic Architecture and agile ALM2015-02-26T19:38:29-05:00urn:lsid:ibm.com:blogs:entry-3838e258-d4b9-4819-bdd8-1f1bbcda95eeTen minutes to start working on the Cloud with JazzHubjl.marechaux060001NWA6activeComment Entriesapplication/atom+xml;type=entryLikes2013-10-30T11:31:33-04:002013-10-30T11:31:33-04:00<p dir="ltr">
You want to start a software development project on the Cloud? You have no money? You want to collaborate easily with a team?</p>
<p dir="ltr">
JazzHub is the solution for you. Read this <a href="http://www.ibm.com/developerworks/rational/library/jazzhub-project/index.html" target="_blank">Project&nbsp;kickoff&nbsp;on&nbsp;JazzHub&nbsp;article</a> to understand how&nbsp;an agile team can start using JazzHub to collaborate efficiently on a new development.</p>
<p dir="ltr">
And guess what?. JazzHub is free for public projects, and free for private projects through 2014 is you register by Dec 31, 2013.</p>
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&nbsp;kickoff&nbsp;on&nbsp;JazzHub&nbsp;article to understand how&nbsp;an...001406urn:lsid:ibm.com:blogs:entries-8c054795-1eba-4290-80af-3c3e2ab27479Pragmatic Architecture and agile ALM2015-02-26T19:38:29-05:00urn:lsid:ibm.com:blogs:entry-accf25a2-6039-4c76-ba0c-db5a429d759bSAFe: Get on the (agile) trainjl.marechaux060001NWA6activeComment Entriesapplication/atom+xml;type=entryLikes2013-07-12T15:43:41-04:002013-07-12T15:49:40-04:00<p dir="ltr">
&nbsp;<br class="Apple-interchange-newline" />
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.</p>
<div dir="ltr" style="text-transform: none; text-indent: 0px; letter-spacing: normal; font: 12px Arial, Verdana, sans-serif; white-space: normal; color: rgb(34,34,34); word-spacing: 0px; -webkit-text-stroke-width: 0px">
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.</div>
<div dir="ltr" style="text-transform: none; text-indent: 0px; letter-spacing: normal; font: 12px Arial, Verdana, sans-serif; white-space: normal; color: rgb(34,34,34); word-spacing: 0px; -webkit-text-stroke-width: 0px">
&nbsp;</div>
<div dir="ltr" style="text-transform: none; text-indent: 0px; letter-spacing: normal; font: 12px Arial, Verdana, sans-serif; white-space: normal; color: rgb(34,34,34); word-spacing: 0px; -webkit-text-stroke-width: 0px">
Here comes SAFe, the Scaled Agile Framework. And guess what ? Architecture is part of the framework. I like it! Looking at the<span class="Apple-converted-space">&nbsp;</span><a href="http://scaledagileframework.com/" target="_blank">SAFe&nbsp;big&nbsp;picture</a><span class="Apple-converted-space">&nbsp;</span>, the first thing that you will notice is that there are three different levels: Team, program, and portfolio. Let&#39;s have a look at the architecture in those levels from an architecture standpoint.</div>
<div dir="ltr" style="text-transform: none; text-indent: 0px; letter-spacing: normal; font: 12px Arial, Verdana, sans-serif; white-space: normal; color: rgb(34,34,34); word-spacing: 0px; -webkit-text-stroke-width: 0px">
&nbsp;</div>
<h3 dir="ltr" style="line-height: normal; text-transform: none; font-variant: normal; font-style: normal; text-indent: 0px; letter-spacing: normal; font-family: Arial, Verdana, sans-serif; white-space: normal; color: rgb(34,34,34); word-spacing: 0px; -webkit-text-stroke-width: 0px">
Team level</h3>
<div dir="ltr" style="text-transform: none; text-indent: 0px; letter-spacing: normal; font: 12px Arial, Verdana, sans-serif; white-space: normal; color: rgb(34,34,34); word-spacing: 0px; -webkit-text-stroke-width: 0px">
&nbsp;</div>
<div dir="ltr" style="text-transform: none; text-indent: 0px; letter-spacing: normal; font: 12px Arial, Verdana, sans-serif; white-space: normal; color: rgb(34,34,34); word-spacing: 0px; -webkit-text-stroke-width: 0px">
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 &nbsp;main architectural concepts at the team level are the Spikes, the NFRs, and the Refactoring.&nbsp;</div>
<div dir="ltr" style="text-transform: none; text-indent: 0px; letter-spacing: normal; font: 12px Arial, Verdana, sans-serif; white-space: normal; color: rgb(34,34,34); word-spacing: 0px; -webkit-text-stroke-width: 0px">
&nbsp;</div>
<ul dir="ltr" style="padding-bottom: 0px; text-transform: none; text-indent: 0px; padding-left: 40px; letter-spacing: normal; padding-right: 40px; font: 12px Arial, Verdana, sans-serif; white-space: normal; color: rgb(34,34,34); word-spacing: 0px; padding-top: 0px; -webkit-text-stroke-width: 0px">
<li>
The notion of<span class="Apple-converted-space">&nbsp;</span><strong>spike<span class="Apple-converted-space">&nbsp;</span></strong>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.</li>
<li>
<strong>Non-Functional Requirement</strong><span class="Apple-converted-space">&nbsp;</span>(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.</li>
<li>
<strong>Refactoring<span class="Apple-converted-space">&nbsp;</span></strong>is another important architectural concept. It may be used to reduce the technical debt or to address emerging design needs (including new NFRs)</li>
</ul>
<div dir="ltr" style="text-transform: none; text-indent: 0px; letter-spacing: normal; font: 12px Arial, Verdana, sans-serif; white-space: normal; color: rgb(34,34,34); word-spacing: 0px; -webkit-text-stroke-width: 0px">
&nbsp;</div>
<div dir="ltr" style="text-transform: none; text-indent: 0px; letter-spacing: normal; font: 12px Arial, Verdana, sans-serif; white-space: normal; color: rgb(34,34,34); word-spacing: 0px; -webkit-text-stroke-width: 0px">
&nbsp;</div>
<h3 dir="ltr" style="line-height: normal; text-transform: none; font-variant: normal; font-style: normal; text-indent: 0px; letter-spacing: normal; font-family: Arial, Verdana, sans-serif; white-space: normal; color: rgb(34,34,34); word-spacing: 0px; -webkit-text-stroke-width: 0px">
Program level</h3>
<div dir="ltr" style="text-transform: none; text-indent: 0px; letter-spacing: normal; font: 12px Arial, Verdana, sans-serif; white-space: normal; color: rgb(34,34,34); word-spacing: 0px; -webkit-text-stroke-width: 0px">
&nbsp;</div>
<div dir="ltr" style="text-transform: none; text-indent: 0px; letter-spacing: normal; font: 12px Arial, Verdana, sans-serif; white-space: normal; color: rgb(34,34,34); word-spacing: 0px; -webkit-text-stroke-width: 0px">
SAFe introduces the concept of the Agile Release Train (ATR), where the ATR<em><span class="Apple-converted-space">&nbsp;</span>&ldquo;is to the program what an iteration is to the team&rdquo;</em>. To put it simple, a train delivers features in a release, at a regular cadence.&nbsp;</div>
<div dir="ltr" style="text-transform: none; text-indent: 0px; letter-spacing: normal; font: 12px Arial, Verdana, sans-serif; white-space: normal; color: rgb(34,34,34); word-spacing: 0px; -webkit-text-stroke-width: 0px">
&nbsp;</div>
<ul dir="ltr" style="padding-bottom: 0px; text-transform: none; text-indent: 0px; padding-left: 40px; letter-spacing: normal; padding-right: 40px; font: 12px Arial, Verdana, sans-serif; white-space: normal; color: rgb(34,34,34); word-spacing: 0px; padding-top: 0px; -webkit-text-stroke-width: 0px">
<li>
An<span class="Apple-converted-space">&nbsp;</span><strong>architectural feature</strong>&nbsp;is the technical aspect of a system that is needed to support a business functionality. &nbsp;Over time, architectural features may evolve into NFRs.</li>
<li>
With architectural features implemented in a program, the enterprise incrementally builds an<span class="Apple-converted-space">&nbsp;</span><strong>architectural runway</strong>. Instead of big up-front architecture, agile teams develop the technology platforms &nbsp;to support business needs during each release.</li>
<li>
At the program level, the<span class="Apple-converted-space">&nbsp;</span><strong>System Architect<span class="Apple-converted-space">&nbsp;</span></strong>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.</li>
</ul>
<div dir="ltr" style="text-transform: none; text-indent: 0px; letter-spacing: normal; font: 12px Arial, Verdana, sans-serif; white-space: normal; color: rgb(34,34,34); word-spacing: 0px; -webkit-text-stroke-width: 0px">
&nbsp;</div>
<h3 dir="ltr" style="line-height: normal; text-transform: none; font-variant: normal; font-style: normal; text-indent: 0px; letter-spacing: normal; font-family: Arial, Verdana, sans-serif; white-space: normal; color: rgb(34,34,34); word-spacing: 0px; -webkit-text-stroke-width: 0px">
Portfolio level</h3>
<div dir="ltr" style="text-transform: none; text-indent: 0px; letter-spacing: normal; font: 12px Arial, Verdana, sans-serif; white-space: normal; color: rgb(34,34,34); word-spacing: 0px; -webkit-text-stroke-width: 0px">
&nbsp;</div>
<div dir="ltr" style="text-transform: none; text-indent: 0px; letter-spacing: normal; font: 12px Arial, Verdana, sans-serif; white-space: normal; color: rgb(34,34,34); word-spacing: 0px; -webkit-text-stroke-width: 0px">
The portfolio level is where the enterprise defines its vision, its business strategy. &nbsp;High priority investment themes are implemented through agile programs to achieve business results.</div>
<div dir="ltr" style="text-transform: none; text-indent: 0px; letter-spacing: normal; font: 12px Arial, Verdana, sans-serif; white-space: normal; color: rgb(34,34,34); word-spacing: 0px; -webkit-text-stroke-width: 0px">
&nbsp;</div>
<ul dir="ltr" style="padding-bottom: 0px; text-transform: none; text-indent: 0px; padding-left: 40px; letter-spacing: normal; padding-right: 40px; font: 12px Arial, Verdana, sans-serif; white-space: normal; color: rgb(34,34,34); word-spacing: 0px; padding-top: 0px; -webkit-text-stroke-width: 0px">
<li>
<strong>Architectural epics</strong><span class="Apple-converted-space">&nbsp;</span>are large technology initiative at the portfolio level. New epics are continuously identify to improve the technology platforms that deliver business functionality.&nbsp;</li>
<li>
The<span class="Apple-converted-space">&nbsp;</span><strong>Enterprise Architect</strong><span class="Apple-converted-space">&nbsp;</span>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<span class="Apple-converted-space">&nbsp;</span>to manage architectural epics.</li>
</ul>
<div dir="ltr" style="text-transform: none; text-indent: 0px; letter-spacing: normal; font: 12px Arial, Verdana, sans-serif; white-space: normal; color: rgb(34,34,34); word-spacing: 0px; -webkit-text-stroke-width: 0px">
&nbsp;</div>
<div dir="ltr" style="text-transform: none; text-indent: 0px; letter-spacing: normal; font: 12px Arial, Verdana, sans-serif; white-space: normal; color: rgb(34,34,34); word-spacing: 0px; -webkit-text-stroke-width: 0px">
&nbsp;</div>
<div dir="ltr" style="text-transform: none; text-indent: 0px; letter-spacing: normal; font: 12px Arial, Verdana, sans-serif; white-space: normal; color: rgb(34,34,34); word-spacing: 0px; -webkit-text-stroke-width: 0px">
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 &nbsp;at the team level, agile team can keep using Scrum or other agile frameworks.</div>
<div dir="ltr" style="text-transform: none; text-indent: 0px; letter-spacing: normal; font: 12px Arial, Verdana, sans-serif; white-space: normal; color: rgb(34,34,34); word-spacing: 0px; -webkit-text-stroke-width: 0px">
&nbsp;</div>
<div dir="ltr" style="text-transform: none; text-indent: 0px; letter-spacing: normal; font: 12px Arial, Verdana, sans-serif; white-space: normal; color: rgb(34,34,34); word-spacing: 0px; -webkit-text-stroke-width: 0px">
With SAFe, architecture is back in the game, and architectural activities are no longer hidden.<span class="Apple-converted-space">&nbsp;</span><span style="font-size: 14px"><strong>Pragmatic architects, the agile world can be SAFer with you</strong></span>. So don&#39;t miss the train!</div>
<p dir="ltr">
<br class="Apple-interchange-newline" />
&nbsp;</p>
&nbsp;
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...002175urn:lsid:ibm.com:blogs:entries-8c054795-1eba-4290-80af-3c3e2ab27479Pragmatic Architecture and agile ALM2015-02-26T19:38:29-05:00urn:lsid:ibm.com:blogs:entry-26de5d04-55b4-441f-90d4-5b0f3d2b4569Design on a diet for agile teamsjl.marechaux060001NWA6activeComment Entriesapplication/atom+xml;type=entryLikes2013-06-20T15:41:07-04:002013-06-21T10:06:11-04:00<p dir="ltr">
Earlier this month, Dan Leroux and I delivered a session at the Innovate 2013 conference. Our objective was to cover two different aspects:</p>
<ol dir="ltr">
<li>
How <strong>architecture &amp; design</strong> fits in an agile environment (such as a team using Scrum)</li>
<li>
How one team in the IBM lab is applying <strong>light design principles</strong> to develop a product</li>
</ol>
<p dir="ltr">
Back from Orlando, I created a <em>prezi </em>with some of the information that we presented during the conference<em>.(<span style="color:#008000;">Click the image to launch the presentation</span>)</em></p>
<p dir="ltr">
&nbsp;</p>
<p dir="ltr">
&nbsp;</p>
<p dir="ltr">
<a href="http://prezi.com/gkdtbur_2dhn/?utm_campaign=share&amp;utm_medium=copy" target="_blank"><img alt="Design on diet" src="https://www.ibm.com/developerworks/community/blogs/jlmarechaux/resource/BLOGS_UPLOADED_IMAGES/prezi-design-diet-small.jpg" style=" display:block; margin: 1em 1em 0pt 0pt; float: left;" /></a></p>
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 &amp; design fits in an agile environment (such as a team using Scrum)
How one team...002669urn:lsid:ibm.com:blogs:entries-8c054795-1eba-4290-80af-3c3e2ab27479Pragmatic Architecture and agile ALM2015-02-26T19:38:29-05:00urn:lsid:ibm.com:blogs:entry-e5e21b12-89cd-4dbd-abd5-83ceda17d4c3I am speaking at Innovate 2013jl.marechaux060001NWA6activeComment Entriesapplication/atom+xml;type=entryLikes2013-05-13T20:48:03-04:002013-05-13T20:48:03-04:00<p dir="ltr">
In June, &nbsp;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) &nbsp;will be used to illustrate the approach.</p>
<p dir="ltr">
I am honored to co-present this session with Dan Leroux, Distinguished Engineer at the IBM Lab.&nbsp;</p>
<p dir="ltr">
If you are interested in attending the session at the conference, here are the details</p>
<ul dir="ltr">
<li>
<strong>Session</strong>: 2131A</li>
<li>
<strong>Title</strong>: Design on a Diet! A Lightweight Design Process</li>
<li>
<strong>Room</strong>:&nbsp;Dolphin - Northern A1 &nbsp;</li>
<li>
<strong>Date/time</strong>: Wed, 5/Jun, 08:30 AM - 09:30 AM &nbsp;</li>
</ul>
<p dir="ltr">
<a href="https://www.ibm.com/developerworks/community/blogs/jlmarechaux/resource/BLOGS_UPLOADED_IMAGES/Innovate2013_Speaking_banner_600x100.jpg" target="_blank"><img alt="image" src="https://www.ibm.com/developerworks/community/blogs/jlmarechaux/resource/BLOGS_UPLOADED_IMAGES/Innovate2013_Speaking_banner_600x100.jpg" style=" display:block; margin: 1em 1em 0pt 0pt; float: left;" /></a></p>
<p dir="ltr">
&nbsp;</p>
<p dir="ltr">
&nbsp;</p>
<p dir="ltr">
&nbsp;</p>
In June, &nbsp;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...001488urn:lsid:ibm.com:blogs:entries-8c054795-1eba-4290-80af-3c3e2ab27479Pragmatic Architecture and agile ALM2015-02-26T19:38:29-05:00urn:lsid:ibm.com:blogs:entry-79bb7640-b0e2-402a-9286-b9b5ea74d3daInformationWeek webcast - Follow-up on Q&A questionsjl.marechaux060001NWA6activeComment Entriesapplication/atom+xml;type=entryLikes2013-02-05T20:57:34-05:002013-02-06T08:32:53-05:00On 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&amp;<wbr />A session for lack of time are listed in this blog entry:<div> </div><div align="center" sizcache="25" sizset="136"> <a href="http://ibm.co/YBKtVc"><strong><font color="#ff0000">http://ibm.co/YBKtVc</font></strong></a></div><div />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&amp; A session for lack of time are listed in this blog...001301urn:lsid:ibm.com:blogs:entries-8c054795-1eba-4290-80af-3c3e2ab27479Pragmatic Architecture and agile ALM2015-02-26T19:38:29-05:00urn:lsid:ibm.com:blogs:entry-7ad64e04-f15f-4a54-8e94-2a64d2d405adAgile Development: Three Pillars of Successjl.marechaux060001NWA6activeComment Entriesapplication/atom+xml;type=entryLikes2013-01-29T21:26:51-05:002013-01-29T21:26:51-05:00<div> </div><div>On January 22, I co-presented an InformationWeek webcast with <span style="background-color: rgb(255, 255, 255); color: rgb(85, 85, 85); font-family: Tahoma, Verdana, Arial, 'Helvetica Neue', Helvetica, sans-serif; font-size: 13px; line-height: 1.5;">Vishy Ramaswamy. the architect of the </span><font color="#555555" face="Tahoma, Verdana, Arial, Helvetica Neue, Helvetica, sans-serif" size="2"><span style="line-height: 19px;">Design Management Server. The webcast was mostly an informal discussion where Vishy and I shared our opinions on four different topics.</span></font></div><div><ol><li><span style="line-height: 1.5;">What is <b>Agile Architecture</b> and what is the difference between this approach and conventional design and development practices?</span></li><li><span style="line-height: 1.5;">What is a recommended practice for <b>just enough traceability</b> across the life cycle?</span></li><li><span style="line-height: 1.5;">What are the kind of architectural and design expressions suitable for <b>&quot;just enough&quot; design</b>?</span></li><li><span style="line-height: 1.5;">How do we still support generating or creating<b> formal models</b> from the <b>informal expressions</b>?</span></li></ol></div><div><span style="line-height: 1.5;"> The replay and the slides are available on--demand from the InformationWeek website at </span><a href="https://www.techwebonlineevents.com/ars/eventregistration.do?mode=eventreg&amp;F=1005386&amp;K=CAA1AC">https://www.techwebonlineevents.com/ars/eventregistration.do?mode=eventreg&amp;F=1005386&amp;K=CAA1AC</a>.<span style="line-height: 1.5;"> </span></div><div>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. </div>
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...001763urn:lsid:ibm.com:blogs:entries-8c054795-1eba-4290-80af-3c3e2ab27479Pragmatic Architecture and agile ALM2015-02-26T19:38:29-05:00urn:lsid:ibm.com:blogs:entry-e837a508-acaa-4a1f-8a5a-ba704c29ca3aThe three pillars of Pragmatic architecturejl.marechaux060001NWA6activeComment Entriesapplication/atom+xml;type=entryLikes2013-01-23T19:30:06-05:002013-01-23T19:34:01-05:00
<div>Yesterday, I was co-presenting an InformationWeek webcast on <b>Agile Development: Three Pillars of Success</b>. 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 <a href="https://jazz.net/products/design-management/">Design Manager</a> product.</div><div><br /></div><div>During the Q&amp;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:<i> “What should we pay attention to when we try to adopt agile architecture practices on our projects?”</i></div><div> </div><div><span style="line-height: 1.5;">When I started this blog, I used the following description (from </span><a href="http://bitly.com/Sg2FQe">http://bitly.com/Sg2FQe</a><span style="line-height: 1.5;">) to define what Pragmatic Architecture is:</span></div><img alt="image" src="https://dw1.s81c.com/developerworks/mydeveloperworks/blogs/jlmarechaux/resource/BLOGS_UPLOADED_IMAGES/pragmatic_small.jpg" style=" display:block; margin: 1em 1em 0pt 0pt; float: left; position:relative;" /><div> </div><div> </div><div> </div><div> </div><div> </div><div> </div><div> </div><div> </div><div> </div><div> </div><div> </div><div> </div><div> </div><div> </div><div> </div><div> </div><div> </div><div>To summarize a bit, I would say that the<b> three pillars of pragmatic architecture</b> are:</div><div><ul><li><span style="line-height: 1.5;">Team collaboration</span></li><li><span style="line-height: 1.5;">Evolutionary design</span></li><li><span style="line-height: 1.5;">Simplicity</span><span style="line-height: 1.5;"> </span></li></ul><div> </div></div>
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...002782urn:lsid:ibm.com:blogs:entries-8c054795-1eba-4290-80af-3c3e2ab27479Pragmatic Architecture and agile ALM2015-02-26T19:38:29-05:00urn:lsid:ibm.com:blogs:entry-f2545c1e-9bc7-4a2c-9b61-be7995215ac5ALM and agile design: Part 4 – Agile design to support iterative developmentjl.marechaux060001NWA6activeComment Entriesapplication/atom+xml;type=entryLikes2013-01-07T17:15:42-05:002013-01-07T17:18:05-05:00
<div><i>[Previously on ALM and agile design.....</i><a href="https://www.ibm.com/developerworks/mydeveloperworks/blogs/jlmarechaux/entry/alm_and_agile_design_part_3_sprint_planning_and_design_information2?lang=en">Part 3 - Sprint planning and design information</a><i>]</i></div><div><br /></div><div>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.</div><div>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.</div><div><br /></div><div><b><font color="#4169e1">Sketches for ideation and problem solving</font></b></div><div>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, <b>a picture is worth 84 words</b>. It is not 1000, but it is not that bad!</div><div>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.</div><div>During a development sprint, the team can have a need for a quick design activity. The <b>“design in a flash” </b>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.</div><div><br /></div><div><b><font color="#4169e1">Designs as input to development activities</font></b></div><div>When design information is available (sketches or others), agile team members can reuse it to better understand the tasks they have to complete.</div><div>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 <b>design will provide other key information</b> such as the relationship with existing components, the interfaces, or the technology to use.</div><div><br /></div><div>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 <b>coherent</b> and <b>resilient architecture</b>, which is key to <b>agility</b>..</div>
[Previously on ALM and agile design..... Part 3 - Sprint planning and design information ] During sprints, agile teams focus on development to deliver working software. Developers examine user stories to implement business needs. They also consider language...001303urn:lsid:ibm.com:blogs:entries-8c054795-1eba-4290-80af-3c3e2ab27479Pragmatic Architecture and agile ALM2015-02-26T19:38:29-05:00urn:lsid:ibm.com:blogs:entry-b5217cac-b294-498e-836f-2593351e0765ALM and agile design: Part 3 – Sprint planning and design informationjl.marechaux060001NWA6activeComment Entriesapplication/atom+xml;type=entryLikes2012-12-17T14:17:07-05:002012-12-17T14:17:07-05:00[Previously on ALM and agile design.....<a href="https://www.ibm.com/developerworks/mydeveloperworks/blogs/jlmarechaux/entry/alm_and_agile_design_part_2_release_plans_iterations_and_design2?lang=en">Part 2 – Release plans, iterations, and design</a> ] <br /><br />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.<br />During sprint planning, design information can be used for three different purposes.<br />First, to <b>assess the technical feasibility</b> 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.<br /><br />Second, design information is used to identify the <b>tasks to implement the sprint stories</b>. 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.<br /><br />And last but not least, agile team can leverage design resources to <b>evaluate the development effort.</b> If the team is using the planning poker technique, design information will help choose the right card.<br /><br />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)
[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...002093urn:lsid:ibm.com:blogs:entries-8c054795-1eba-4290-80af-3c3e2ab27479Pragmatic Architecture and agile ALM2015-02-26T19:38:29-05:00urn:lsid:ibm.com:blogs:entry-90ff0940-f030-4074-a076-bda497cb60e2Agile ALM...a teaser videojl.marechaux060001NWA6activeComment Entriesapplication/atom+xml;type=entryLikes2012-12-14T17:22:53-05:002012-12-17T12:52:01-05:00
<div> </div><div>Interested in <b>agile ALM</b> and <b>collaborative architecture</b>? Check the video at <b><a href="https://www.youtube.com/watch?v=O70P8IpV0oY">https://www.youtube.com/watch?v=O70P8IpV0oY</a></b>. It will only take <b>3:20 minutes</b> of your time.</div><div>Then read the related article published on developerWorks and tell me more about the <b>pragmatic architecture</b> approach that you have adopted in your agile projects.<br />Share your experience! </div>
Interested in agile ALM and collaborative architecture ? Check the video at https://www.youtube.com/watch?v=O70P8IpV0oY . It will only take 3:20 minutes of your time. Then read the related article published on developerWorks and tell me more about the...001379urn:lsid:ibm.com:blogs:entries-8c054795-1eba-4290-80af-3c3e2ab27479Pragmatic Architecture and agile ALM2015-02-26T19:38:29-05:00urn:lsid:ibm.com:blogs:entry-4d431e13-8908-4a4f-b7bf-33d319e58351Agile Tour 2012 – Big success in Montrealjl.marechaux060001NWA6activeComment Entriesapplication/atom+xml;type=entryLikes2012-11-28T09:14:02-05:002012-11-28T09:21:24-05:00
Just back from <a href="http://agilemontreal.ca/agile-tour-2012/">Agile Tour 2012</a>, a conference held in Montreal (Canada) on November 24.<br />Ok, it was not a long trip as the conference center is probably at less than 2 miles from home. <br /><br />This year, I was a member of the organizing committee. Quite an experience which started around March, an initiative led by the <a href="http://agilemontreal.ca">Agile Montreal community</a>.<br /><br />Key facts and figures from the conference:<br /><ul><li><span style="background-color: rgb(255, 255, 255);">Sold out event: <b>500 </b>registered attendees</span></li><li><span style="background-color: rgb(255, 255, 255);"><b>23 </b>speaking sessions or workshops, 7 parallel tracks</span></li><li><span style="background-color: rgb(255, 255, 255);"><b>2</b> word-class keynote speakers</span></li><li><span style="background-color: rgb(255, 255, 255);"><b>12</b> members on the organizing committee. Not that much for such a big event</span></li><li><span style="background-color: rgb(255, 255, 255);">About <b>16 </b>volunteers came to help out (thanks a lot guys!)</span></li><li><span style="background-color: rgb(255, 255, 255);"><b>500+ </b>lunchboxes... wow... a lot of food. Unfortunately, I don't know how many gallons of coffee were consumed.</span></li><li><span style="background-color: rgb(255, 255, 255);"><b>17</b> sponsors. Definitively helps to pay for the 500 lunchboxes</span></li><li><span style="background-color: rgb(255, 255, 255);">My day started at <b>4:30 am</b>. Way too early!</span></li><li><span style="background-color: rgb(255, 255, 255);">My speaking session was at <b>3:30 pm</b>. Way too late when you get up at 4:30 am :-)</span></li><li><span style="background-color: rgb(255, 255, 255);">The conference ended at <b>5:00 pm</b> but a lot of people decided to keep the discussion going during the evening cocktail.</span></li></ul><br />People I talked too during the conference are not interested in the &quot;agile dogma&quot;. They value <i>&quot;pragmatic agility&quot;</i>, agility applied to their specific context. Sometimes it means <u>governance</u>, sometimes <u>ALM</u>, sometimes <u>lean</u> software development. <br /><br />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.
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...101370urn:lsid:ibm.com:blogs:entries-8c054795-1eba-4290-80af-3c3e2ab27479Pragmatic Architecture and agile ALM2015-02-26T19:38:29-05:00urn:lsid:ibm.com:blogs:entry-05da4c7f-4ed0-4728-b51c-e2e23d2f7548I am speaking at Agile Tourjl.marechaux060001NWA6activeComment Entriesapplication/atom+xml;type=entryLikes2012-11-16T10:55:55-05:002012-11-16T10:55:55-05:00I 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.<br /><div>Here is a teaser.....I hope it will prompt people to attend the session.</div><div> </div><i>&quot;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.</i>&quot;<br /><br /><b>What someone can expect to take away from the presentation?</b><br /><ul><li>Discover Pragmatic Architecture: Agile concepts applied to architecture in an ALM environments</li><li>Understand how architecture and design information is used throughout an agile ALM cycle </li><li>Comprehend how tools can support agile ALM and design tasks</li></ul><br /><b>Table of content</b><br /><ul><li>ALM and agility</li><li>Pragmatic Architecture</li><li>Case study: An agile ALM scenario</li><li>Summary</li></ul><p>Interested?..... Take a look at the <a href="http://agilemontreal.ca/agile-tour-2012/">Agile Tour 2012 (Montreal) page</a> for further information.<br /></p><br />
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. &quot;The session explains how Pragmatic...001205urn:lsid:ibm.com:blogs:entries-8c054795-1eba-4290-80af-3c3e2ab27479Pragmatic Architecture and agile ALM2015-02-26T19:38:29-05:00urn:lsid:ibm.com:blogs:entry-1ed5d3bb-ab42-48ae-8178-bd6ed613fa5ePragmatic architecture for agile ALMjl.marechaux060001NWA6activeComment Entriesapplication/atom+xml;type=entryLikes2012-11-02T19:32:23-04:002012-11-02T19:32:23-04:00<br /><a href="http://www.ibm.com/developerworks/rational/library/agile-application-lifecycle-management/index.html">Pragmatic architecture for agile Application Lifecycle Management</a> 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). <br />Architecture &amp; 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.<br /><br />Read more <a href="http://www.ibm.com/developerworks/rational/library/agile-application-lifecycle-management/index.html">here</a>....
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...001684urn:lsid:ibm.com:blogs:entries-8c054795-1eba-4290-80af-3c3e2ab27479Pragmatic Architecture and agile ALM2015-02-26T19:38:29-05:00urn:lsid:ibm.com:blogs:entry-373ae624-f979-46fe-b829-c10589db66dfEclipse Foundation and Agile methodologiesjl.marechaux060001NWA6activeComment Entriesapplication/atom+xml;type=entryLikes2012-10-24T11:29:04-04:002012-10-24T11:29:04-04:00<div>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).</div><div> </div><div>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. </div><div>As a result, you can access documentation on <b>XP</b>, <b>Scrum</b>, or <b>OpenUP </b>online.</div><div><ul><li><a href="http://epf.eclipse.org/wikis/scrum/">http://epf.eclipse.org/wikis/scrum/</a></li><li><a href="http://epf.eclipse.org/wikis/xp/">http://epf.eclipse.org/wikis/xp/</a></li><li><a href="http://epf.eclipse.org/wikis/openup/ ">http://epf.eclipse.org/wikis/openup/ </a></li></ul><div> </div><div>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/<br /></div></div>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...001537urn:lsid:ibm.com:blogs:entries-8c054795-1eba-4290-80af-3c3e2ab27479Pragmatic Architecture and agile ALM2015-02-26T19:38:29-05:00urn:lsid:ibm.com:blogs:entry-a29dd559-db00-4c2f-b832-b62ef503c118Agile teams, requirements, and cognitive sciencejl.marechaux060001NWA6activeComment Entriesapplication/atom+xml;type=entryLikes2012-10-20T17:53:32-04:002012-10-20T18:00:55-04:00
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.<br />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.<br /><br /><div>Let's take a simple example. On the following diagram, here is the requirement:<i> &quot;Connect the nine dots with four straight lines, without lifting the pencil&quot;</i>.</div><div> </div><div><div align="center"> <a '="" href="https://www.ibm.com/developerworks/mydeveloperworks/blogs/jlmarechaux/resource/BLOGS_UPLOADED_IMAGES/9dotssquare.jpg
" target="_blank"><img alt="image" src="https://dw1.s81c.com/developerworks/mydeveloperworks/blogs/jlmarechaux/resource/BLOGS_UPLOADED_IMAGES/9dotssquare.jpg" style=" display:block; margin: 1em 1em 0pt 0pt; float: left; position:relative;" /></a></div> </div><div> </div><div> </div><div> </div><div> </div><div> </div><div> </div><div> </div><div> </div><div> </div><div> </div><div>You've got it? Bravo! <br />If you don't, read the requirements one more time. Take your time. Need some help to find the solution? Click <a href="https://www.ibm.com/developerworks/mydeveloperworks/blogs/jlmarechaux/resource/9dotssquare-solution.jpg ">here</a>.....<br /><br />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. <br /><br /><b>So what can we learn from this? </b><br /><br />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.<br /><br />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.<br />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.</div><div> </div>
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...001133urn:lsid:ibm.com:blogs:entries-8c054795-1eba-4290-80af-3c3e2ab27479Pragmatic Architecture and agile ALM2015-02-26T19:38:29-05:00urn:lsid:ibm.com:blogs:entry-6dc46adc-81d1-41f0-88f4-b173d3ccf31eAgile Tour Montreal 2012 - Program is being finalizedjl.marechaux060001NWA6activeComment Entriesapplication/atom+xml;type=entryLikes2012-09-27T22:35:05-04:002012-09-27T22:47:37-04:00
<div>The Agile Tour is a series of conferences on Agility in 15 countries, making it the single most important event in agility worldwide.</div><div>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).<br />Agile Tour 2012 will present 22 sessions or workshops on various topics such as:<br /><ul><li>Agile development, design, and architecture</li><li>Coaching and mentoring</li><li>Cultural changes and agile adoption</li><li>Agile management</li><li>Games and simulations</li></ul>and more...<br />We will also have two amazing keynote speakers, two visionary leaders in their respective domain.<br /><br />For further information, go to <a href="http://agilemontreal.ca/agile-tour-2012/">http://agilemontreal.ca/agile-tour-2012/</a></div>
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...001134urn:lsid:ibm.com:blogs:entries-8c054795-1eba-4290-80af-3c3e2ab27479Pragmatic Architecture and agile ALM2015-02-26T19:38:29-05:00urn:lsid:ibm.com:blogs:entry-9b15831e-3bb7-438a-9fd5-97b6e4585b2cALM and agile design: Part 2 – Release plans, iterations, and designjl.marechaux060001NWA6activeComment Entriesapplication/atom+xml;type=entryLikes2012-05-11T20:43:18-04:002012-10-15T09:48:43-04:00
<div>[<i>Previously on ALM and agile design..... </i><a href="https://www.ibm.com/developerworks/mydeveloperworks/blogs/jlmarechaux/entry/alm_and_agile_design_part_1_the_pragmatic_architect?lang=en">The pALMatic architect</a>]<br /><br />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. </div>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.<br /><br />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.<br />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.
[ 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...101484urn:lsid:ibm.com:blogs:entries-8c054795-1eba-4290-80af-3c3e2ab27479Pragmatic Architecture and agile ALM2015-02-26T19:38:29-05:00urn:lsid:ibm.com:blogs:entry-92f4da94-f8e0-4b37-86a2-c889a9c90021ALM and agile design: Part 1 - The pALMatic architectjl.marechaux060001NWA6activeComment Entriesapplication/atom+xml;type=entryLikes2012-04-13T10:46:33-04:002012-10-15T09:48:16-04:00
<i>Today I am starting a series on ALM and Agile design (probably 4 or 5 different posts in the coming weeks).</i><br /><br />A
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. <br />In
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
satisfaction.<br /><br />Design management is a key building block in ALM.
The pragmatic architects do not work in isolation (read more on <a href="https://www.ibm.com/developerworks/mydeveloperworks/blogs/jlmarechaux/entry/about_pragmatism_in_architecture3?lang=en">Pragmatism in architecture</a>)
. Those completing
architecture and design tasks want to understand the business needs
(requirement &lt;--&gt; design). They also have to make sure that the
design supports the implementation of the solution (design &lt;--&gt;
code). And design is eventually validated by some tests to validate its
quality (design &lt;--&gt; tests).<br />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
change management. <br /><br /><div>The <a href="https://www.ibm.com/developerworks/mydeveloperworks/blogs/jlmarechaux/entry/about_pragmatism_in_architecture3?lang=en">pragmatic </a>architect is also a <b>pALMatic </b>architect:<b><br /></b><ul><li><b>A</b>: <i>Adapt </i>to changing requirements and new technical challenges</li><li><b>L</b>: <i>Link </i>design to other lifecycle artifacts (requirement, test, code, changes)</li><li><b>M</b>: <i>Manage </i>design information to help other ALM stakeholders<br /></li></ul></div><div> </div><div>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. <br /></div>
Today I am starting a series on ALM and Agile design (probably 4 or 5 different posts in the coming weeks). A
bit like humans, software-intensive systems are conceived, come to
life, grow, evolve, do their job to contribute to business goal
achievements,...001915urn:lsid:ibm.com:blogs:entries-8c054795-1eba-4290-80af-3c3e2ab27479Pragmatic Architecture and agile ALM2015-02-26T19:38:29-05:00urn:lsid:ibm.com:blogs:entry-542037db-26d0-4c0c-8a21-090f20eb30ecALM and agilityjl.marechaux060001NWA6activeComment Entriesapplication/atom+xml;type=entryLikes2012-03-30T09:52:35-04:002012-05-25T10:25:04-04:00
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.<br /><br />The <a href="https://www.ibm.com/developerworks/mydeveloperworks/blogs/ambler/entry/agile_scaling_model?lang=en">Agile Scaling Model</a> 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.<br /> <br />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.<br /><br />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 ! <br />
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...001429urn:lsid:ibm.com:blogs:entries-8c054795-1eba-4290-80af-3c3e2ab27479Pragmatic Architecture and agile ALM2015-02-26T19:38:29-05:00urn:lsid:ibm.com:blogs:entry-2020d216-ffdc-4dbd-8ac1-64c7021ac029The most-loved articles about Rational software from 2011jl.marechaux060001NWA6activeComment Entriesapplication/atom+xml;type=entryLikes2012-02-17T13:01:56-05:002012-02-17T13:04:12-05:00
On February 14th has been published the list of the <a href="http://www.ibm.com/developerworks/rational/library/top-10-2011.html">most-loved Rational articles in 2011</a>. Even if I am not sure what “most-loved” means here (can you really be in love with a technical paper??), I am glad to see that the one I wrote on architecture with RSA 8 is on the list. (<a href="http://www.ibm.com/developerworks/rational/library/define-application-architecture-rational-software-architect-1/index.html">http://www.ibm.com/developerworks/rational/library/define-application-architecture-rational-software-architect-1/index.html</a>) <br /><br />But I must that this popularity raises a couple of questions. Published last October, the article has been viewed almost 15 000 times. I also created e-books from the article and they reached over 200 downloads since November 22, 2011. So why is this article so popular? Is it because it talks about RSA 8? Or because it covers an agile practice, the evolutionary architecture? Maybe there not enough enablement resources available on RSA. Maybe architecture is not covered properly by the agile community? <br /><br />I'd like to have more feedback from the community. If you read this post, do not hesitate to contact me.<style type="text/css">
&amp;amp;lt;!--
@page { margin: 0.79in }
P { margin-bottom: 0.08in }
A:link { so-language: zxx }
--&amp;amp;gt;</style>
On February 14th has been published the list of the most-loved Rational articles in 2011 . Even if I am not sure what “most-loved” means here (can you really be in love with a technical paper??), I am glad to see that the one I wrote on architecture with RSA 8...001408urn:lsid:ibm.com:blogs:entries-8c054795-1eba-4290-80af-3c3e2ab27479Pragmatic Architecture and agile ALM2015-02-26T19:38:29-05:00urn:lsid:ibm.com:blogs:entry-8d43711d-17e2-4e31-9f45-99965f17ee8bBetter quality and agility with collaborative designjl.marechaux060001NWA6activeComment Entriesapplication/atom+xml;type=entryLikes2012-01-18T14:34:58-05:002012-01-27T14:23:01-05:00
Success in agile development comes from teamwork. No matter which agile process you apply, collaboration is always at the heart of recommended best practices. Quality systems are also based on good design to make them easier to maintain and extend. The <a href="https://jazz.net/library/article/771">Better quality and agility with collaborative design</a> article demonstrates how Rational Software Architect Design Manager enhances collaboration on design activities.
Success in agile development comes from teamwork. No matter which agile process you apply, collaboration is always at the heart of recommended best practices. Quality systems are also based on good design to make them easier to maintain and extend. The Better...001104urn:lsid:ibm.com:blogs:entries-8c054795-1eba-4290-80af-3c3e2ab27479Pragmatic Architecture and agile ALM2015-02-26T19:38:29-05:00urn:lsid:ibm.com:blogs:entry-e02c340f-dd74-4f78-b1aa-6f73fa2cce68Mr Jourdain may have been an agilistjl.marechaux060001NWA6activeComment Entriesapplication/atom+xml;type=entryLikes2012-01-09T09:38:52-05:002012-01-18T14:00:16-05:00
<blockquote>Back from vacation.... During the holiday season, I had some time to read a couple of non-IT books, like <a href="http://en.wikipedia.org/wiki/Le_Bourgeois_gentilhomme">Le bourgeois gentilhomme</a> (The Middle-Class Gentleman). Molière wrote <i>Le bourgeois gentilhomme</i> in 1670. A key part of the play is when <i>Monsieur Jourdain</i>, the main character, discovers that he has being speaking &quot;prose&quot; all his life without knowing it (<a href="http://en.wikipedia.org/wiki/Verse_%28poetry%29">verse </a>was more popular than <a href="http://en.wikipedia.org/wiki/Prose">prose </a>at this time).<br /><br />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.<br />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.<br /><br />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.<br />Again, I had developed a specific <i>technique </i>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. <br /><br />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.<br />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. <br /><br />I am pretty sure that there are a lot of <i>Monsieur Jourdain</i> around us. Practitioners who leveraged agile practices far before agile became popular.<br />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, ..... <b>for free</b>.<br /><br /></blockquote>
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 ,...001536urn:lsid:ibm.com:blogs:entries-8c054795-1eba-4290-80af-3c3e2ab27479Pragmatic Architecture and agile ALM2015-02-26T19:38:29-05:00urn:lsid:ibm.com:blogs:entry-948d10d1-e228-4f56-8e2c-6eab6cf5fa3fThe importance of (agile) architecture and designjl.marechaux060001NWA6activeComment Entriesapplication/atom+xml;type=entryLikes2011-12-14T08:53:24-05:002012-01-18T14:02:42-05:00
Architectural analysis is a set of activities to build and improve the software architecture of a system. When conducted iteratively, this architectural thinking helps uncover and address issues during software development without requiring significant up-front architectural effort. Architectural analysis activities are crucial for every software-intensive system.<br />Despite what dogmatic agile development coaches might say, I believe that there is no successful software development without architectural analysis. <br /><br /><div>I had a strange conversation with an IT professional last week. To preserve his anonymity, let's call him Oleg. </div><div> </div><font color="#191970" style="color: rgb(0, 0, 205);">JL</font> (that's me): Hey Oleg, nice to see you ! How is it going?<br /><font color="#ff8c00" style="color: rgb(139, 0, 0);">Oleg: </font>Pretty well, JL. I joined a new project two months ago. It's an agile team and I like it very much.<br /><font color="#0000cd">JL:</font> Glad to hear that. What kind of project is it?<br /><font color="#8b0000">Oleg:</font> We are developing a new solution to enrich our existing internet banking application. Our new component will integrate services from several departments and even business partners.<br /><span style="color: rgb(0, 0, 205);">JL:</span> Sounds like an interesting challenge. Are you working on the architecture of this new solution?<br /><span style="color: rgb(139, 0, 0);">Oleg: </span>No, we don't do architecture, we are an agile team.<br /><span style="color: rgb(0, 0, 205);">JL:</span> ??!!?........ (speechless....)<br /><span style="color: rgb(139, 0, 0);">Oleg:</span> We focus on developing a set of services to enable the integration.<br /><span style="color: rgb(0, 0, 205);">JL: </span>Ok, I understand that your primary objective is to deliver working software but integration of services from different sources must not be easy. How do you define the structure of your component? How do you identify the different services needed? How to you mitigate risks?<br /><span style="color: rgb(139, 0, 0);">Oleg:</span> Well, it took two weeks before the project really started. Just the time to obtain the buy-in from the business sponsor and assemble the whole team. It was a great opportunity for me and some colleagues to start thinking about our new project. We addressed some of these questions at this time.<br /><span style="color: rgb(0, 0, 205);">JL:</span> I see... so you pictured the technical solution during the project warm-up. And how are you evolving your architecture during your sprints?<br /><span style="color: rgb(139, 0, 0);">Oleg:</span> Well, as I told you, it's an agile team. We do test-driven development and refactoring all the time, but we don't waste time on architecture.<br /><span style="color: rgb(0, 0, 205);">JL:</span> You mean that because you are an agile team, then you don't...<b>THINK</b>?<br /><span style="color: rgb(139, 0, 0);">Oleg:</span> Don't get me wrong. I work with brilliant people and we have brainstorming sessions all the time.<br /><span style="color: rgb(0, 0, 205);">JL: </span>Ok, so you are doing architectural activities, right?<br /><span style="color: rgb(139, 0, 0);">Oleg:</span> Well yes, but the client does not want to pay for architecture. So we don't really publicize this. We keep it secret in our war room and we bill our time on development tasks.<br /><span style="color: rgb(0, 0, 205);">JL:</span> I see. Architecture is really part of development sprints anyway, so you bill your time at the right place. Just curious, are you doing modeling at all?.<br /><span style="color: rgb(139, 0, 0);">Oleg:</span> Of course we do, because a picture is worth a thousand words. It helps us a lot during our brainstorming sessions. And we have a lot of short brainstorming sessions during the sprints to tackle new technical challenges uncovered. But again, this is not something we expose too much as the client does not pay for diagrams.<br /><br /><div>So what did Oleg tell me exactly? He stated that on his project, team members are not doing architecture because they are following an agile process. But then he explained that before their first development sprint, they spent some time to <i>envision the architecture</i>. <br />Oleg also told me that his team is not officially doing architecture during sprints. But he also confessed that they are hiding to create models, as if it is some sort of perversion. Their models or sketches are considered helpful for their just-in-time modeling sessions during sprints. It is how they <i>refine the architecture</i> of their software-intensive system over time.</div>So the good news is that Oleg's team is thinking about the new solution that they are developing (the bad news is that they seem ashamed of their architectural work).<br />Of course, you can not deliver a system if you keep thinking about it forever. Architectural work must be integrated to the development lifecycle. Architecture is intentional because you make deliberate decisions based on what you know when you start a project.<br />Architecture is also emergent because you always uncover new technical challenges during development sprints.
Architectural analysis is a set of activities to build and improve the software architecture of a system. When conducted iteratively, this architectural thinking helps uncover and address issues during software development without requiring significant...001548urn:lsid:ibm.com:blogs:entries-8c054795-1eba-4290-80af-3c3e2ab27479Pragmatic Architecture and agile ALM2015-02-26T19:38:29-05:00urn:lsid:ibm.com:blogs:entry-73765afa-79f2-4dd5-9ea8-0d383783c65bMyth: Architecture and Agilityjl.marechaux060001NWA6activeComment Entriesapplication/atom+xml;type=entryLikes2011-12-07T21:38:48-05:002012-01-18T13:58:07-05:00
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.<br /><br /><b>Myth #1: Architecture is not an agile practice.</b><br />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.<br />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.<br /><br /><b>Myth #2: Agile teams don't do modeling</b><br />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.<br /><br />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.
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...001574urn:lsid:ibm.com:blogs:entries-8c054795-1eba-4290-80af-3c3e2ab27479Pragmatic Architecture and agile ALM2015-02-26T19:38:29-05:00urn:lsid:ibm.com:blogs:entry-9b244dcb-871b-46fa-88d6-616027226a0aFlextime and flexplace. You may be more distributed than you think.jl.marechaux060001NWA6activeComment Entriesapplication/atom+xml;type=entryLikes2011-11-29T14:03:33-05:002012-01-18T13:53:33-05:00
Distributed teams are often defined as teams with members in different offices, cities, or countries. Compared to collocated teams, they need more disciplined approaches to address the specific communication and collaboration challenges that they are facing. But geographically distribution is not the only factor to consider. Some collocated teams may fail in their agile endeavors because they do not their working environment. <br /><br />Let's take the (fictitious) example of SatoriGeeks, a small company specialized in innovative solutions for the finance industry. They have a team of 6 people to develop their current solution. They all work at the SatoriGeeks office in Montreal, Canada. They have an open space to sit together for better collaboration, they have scheduled daily meetings for better progress status. They have also adopted a whole team approach with cross-functional people to maximize project success. <br />What can go wrong with this small collocated team? Their working environment may actually be more complex than it appears at first glance.<br /><br />Marie, the product owner, is often visiting customers to understand their concerns. On a typical week, it is rare to see her at her desk. Simon, a team member, had a new baby girl last year. To balance work and family life, he is working from home twice a week. Rachel has flexible working hours (she lives in the Montreal south shore and tries to avoid peak hours to cross the bridge). Thomas had a knee injury playing tennis a couple of months ago. Since the beginning of the project, he must visit the physiotherapist twice a week during working hours. And he works from home when the knee hurts to much.<br />So for many good reasons, key members of the team are not always able to meet in the same workspace. Communication is affected, collaborative work is not as effective as it used to be. The team should consider itself as a distributed team because they have flexible working hours.<br /><br />Flextime and flexplace has become mainstream in many organizations. It is too often considered as an human resources matter only, although flexible working hours affect project teams. Even if they are small and collocated, teams like SatoriGeeks would benefit from a more disciplined agile process to facilitate collaborative.:<br /><ul><li>Tooling to support collaborative lifecycle management (backlog, sprint, real-time status)</li><li>Centralize platform to share ideas and documentation.</li><li>Tooling to enhance collaborative design management and development</li></ul><br />Flextime and flexplace should lead collocated teams to consider some agile practices usually adopted by distributed team.
Distributed teams are often defined as teams with members in different offices, cities, or countries. Compared to collocated teams, they need more disciplined approaches to address the specific communication and collaboration challenges that they are facing....002002urn:lsid:ibm.com:blogs:entries-8c054795-1eba-4290-80af-3c3e2ab27479Pragmatic Architecture and agile ALM2015-02-26T19:38:29-05:00urn:lsid:ibm.com:blogs:entry-341a7b8a-7715-489c-a683-35843294baf7About pragmatism in architecturejl.marechaux060001NWA6activeComment Entriesapplication/atom+xml;type=entryLikes2011-11-18T13:03:23-05:002012-04-12T09:11:40-04:00
<b>\'prag-me-ti-zem\:</b> a practical approach to problems and affairs.<br /><br />In software engineering, <b>architecture </b>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. <br />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 <b>YES</b>. It is where pragmatism comes into play.<br /><br />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. <br />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.<br /><br /><br />Your goals during <b>p.r.a.g.m.a.t.i.c</b> architectural activities<br /><ul><li><b>P</b>: Promote collaborative work that involves all team members</li><li><b>R</b>: Reduce risks and uncertainties</li><li><b>A</b>: Adhere to minimalism and simplicity principles</li><li><b>G</b>: Gather key elements to outline the architecture during your initial timed-boxed iteration </li><li><b>M</b>: Modify the design throughout the development lifecycle to adapt to emergent needs </li><li><b>A</b>: Address both functional and non-functional requirements</li><li><b>T</b>: Try out theoretical concepts and leverage past empirical experience</li><li><b>I:</b> Invest in known requirement instead of hypothetical future needs</li><li><b>C</b>: Concentrate on tasks that support the development team</li></ul><br />As architects, we must value <b>pragmatism and practical experience</b> over dogmatism and theory.<br /><br />
\'prag-me-ti-zem\: 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...207577urn:lsid:ibm.com:blogs:entries-8c054795-1eba-4290-80af-3c3e2ab27479Pragmatic Architecture and agile ALM2015-02-26T19:38:29-05:00urn:lsid:ibm.com:blogs:entry-ffc4a10b-d77f-45a8-b1a0-04c84a3ac918Disclaimerjl.marechaux060001NWA6activeComment Entriesapplication/atom+xml;type=entryLikes2011-11-13T14:43:32-05:002011-11-29T23:04:25-05:00
<p style="margin-bottom: 0in;">The posts in this blog are written by Jean-Louis Marechaux (aka
<b><wbr />JL</b><wbr />), a member of the IBM Rational software group. </p><div id="css-entry" sizcache="26" sizset="96"><wbr />
<div><wbr /> </div><wbr />
<div><wbr />I want to make it clear that: <br /><wbr /></div><wbr />
<div sizcache="26" sizset="96"><wbr />
<ul sizcache="26" sizset="96"><wbr /><li><wbr />What I say in the blog is representative of my views (and my views
only).<wbr />
</li><li><wbr />Anything about IBM and its products must be considered as unofficial
information.<wbr />
</li><li sizcache="26" sizset="96"><wbr />The postings on this &quot;<wbr /><a href="../../jlmarechaux/?lang=en"><wbr />Pragmatic
Architecture</a><wbr />&quot;<wbr /> site are my own and don't necessarily represent
IBM's position, strategies or opinions.</li></ul></div></div>
The posts in this blog are written by Jean-Louis Marechaux (aka
JL ), a member of the IBM Rational software group.
I want to make it clear that:
What I say in the blog is representative of my views (and my views
only).
Anything about IBM...001039urn:lsid:ibm.com:blogs:entries-8c054795-1eba-4290-80af-3c3e2ab27479Pragmatic Architecture and agile ALM2015-02-26T19:38:29-05:00