<?xml version="1.0" encoding="utf-8"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title>Disqus - Latest Comments for jmazloum</title><link>http://disqus.com/by/jmazloum/</link><description></description><atom:link href="http://disqus.com/jmazloum/comments.rss" rel="self"></atom:link><language>en</language><lastBuildDate>Wed, 30 Sep 2015 01:04:56 -0000</lastBuildDate><item><title>Re: When to stop holding retrospectives?</title><link>http://apr.staging.wpengine.com/notesfromatooluser/2011/11/when-to-stop-holding-retrospectives.html#comment-2281304664</link><description>&lt;p&gt;Another issue is that retrospectives that are not well facilitated tend to use all the timebox with poor results. I believe a 5 minutes retrospectives which leads to actionable and committed action items is more useful than a 2 hours one full of wishful thinking and not many actionable items and where 20% of the attendees speaking 80% of the time. &lt;br&gt;For many times I have seen, retrospectives and coming up with action items to improve their own work is a very unnatural thing to them. So the key for me is to avoid the "not again another meeting" phenomena and really make sure it is a way to be sure the team improves. Let's not forget that "progress" is  one of the biggest motivating factors for knowledge workers (arguably even more than "purpose" for many people).&lt;br&gt;Another point is also to make sure the retrospectives do not forget the "elephant in the room", the large problems that do not change sprint after sprint but that really impede the teams productivity. So just a follow-up on how to improve on those big issues and have good committed action items is often better than a lengthy meeting on small issues.&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">jmazloum</dc:creator><pubDate>Wed, 30 Sep 2015 01:04:56 -0000</pubDate></item><item><title>Re: Agile PM Is Not Project Management</title><link>http://blog.softwareprojects.org/agile-pm-is-not-project-management-33.html#comment-6745287</link><description>&lt;p&gt;Hi,&lt;/p&gt;&lt;p&gt;Interesting opinion and I mainly agree.&lt;br&gt;As you know, Scrum is currently the mostly used Agile development framework. It focuses on team organization (self-organization actually) rather then on precise Engineering practises. In the basic Scrum training (Certified Scrum Master), we learn that project managers do not exist in Scrum. &lt;br&gt;Their role and responsibilities are spread between the self-organizing development team, the Scrum Master and the Product Owner.&lt;br&gt;Therefore, the Project Manager of Scrum projects should just accept that he is not a project manager anymore and embrace his new role which is more likely to become a Scrum Master or a Product Owner depending of his skills and affinities. It is a tough change. &lt;br&gt;Therefore, in real Agile/Scrum development organizations, project management is present, effective and efficient but clearly implicit since the Project Manager as a role itself should just not exist.&lt;br&gt;It is much more simple and honest to define new roles then try to recycle an old one.&lt;/p&gt;&lt;p&gt;Julien.&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">jmazloum</dc:creator><pubDate>Sun, 01 Mar 2009 11:55:15 -0000</pubDate></item></channel></rss>