tag:blogger.com,1999:blog-76916632446419349982024-03-13T08:36:24.843-07:00Agile Project ManagementAgile is more than a method, it’s a mind set...Patrick Merghttp://www.blogger.com/profile/07635669876248376487noreply@blogger.comBlogger21125tag:blogger.com,1999:blog-7691663244641934998.post-2954664020135305762014-09-18T09:05:00.002-07:002014-09-18T09:05:45.205-07:00Agile FatigueAgile is an excellent development methodology, responsive to business changes with quick turnaround and highly visible results. The concept is in widespread use, particularly in software development, but having implemented Agile almost from the inception of eXtreme Programming I've seen issues arise related to people being on Agile teams for extended periods of time. These can be mitigated or even avoided entirely if you know what to look for. I call the problem 'Agile fatigue'.
<br />
Burnout is the most prevalent symptom of Agile fatigue. The pace of an Agile project is unrelenting. Unlike Waterfall and associated development methodologies there are very few built-in times for team members to catch their collective breath and celebrate milestones. To help combat burnout, try a few of these techniques:
<br />
<ul>
<li> Set your own team goals, publicize them, and celebrate when you achieve them
</li>
<li> Move people among teams whenever possible to change the scenery, so to speak
</li>
<li> Report and celebrate small victories (see <a href="http://ivybay.com/index.php?option=com_content&view=article&id=104:a-few-words-about-traditions-and-appreciation-in-your-team&catid=43:program-management-blog&Itemid=72">Tanya's excellent tips</a> on ways to do this)
</li>
<li> Set a periodic 'down' iteration/sprint where everyone can work on something they'd like to do (or rotate that ability amongst the team members). You'll get some interesting research, something to look forward to for the team members, and a break while still working.
</li>
</ul>
<b>Meandering</b> happens when people start on tasks/user stories but don't finish them. They might even agree to the goals for the day and end up working on some interesting bug that was far down the priority list. Sometimes this is related to burnout, sometimes you see it when the project manager or ScrumMaster is away for a while, sometimes people just are bored and distracted. The best solution is to have a hard and fast rule about taking on more than a certain number of user stories (usually 1, not more than 2) unless one of the assigned stories has been officially been blocked. To enforce the rule, the project manager/ScrumMaster will have to unassign the offending user stories (past the limit) as soon as they're picked up to get people back on track.<br />
<br />
<b>Stagnation</b> materializes when people get so caught up in the short burst nature of the sprint user stories that they don't improve their skills or acquire new ones (hard skills and/or soft skills). Watch for stagnation carefully, since it can be a little hard to spot. Periodically assign user stories that stretch a team member's skills, even if there's someone else on the team who already has the skills. Create some 'administrative' user stories to send people off to pick up a new skill that *might* be needed in upcoming user stories (people like to use their new skills and your project might get a nice shot in the arm). Finally, periodically ask in wrap-up meetings or daily meetings what new technologies, techniques, or processes the team members think might have a place in the project or be worth a try/evaluation.<br />
<br />
<b>The daily stand-up turns into a grind.</b> This may take a little more work on the part of the project manager/ScrumMaster. First, be sure you're keeping the meeting to the shortest time possible - it's 'stand-up' for a reason. If it's over 15 minutes something is wrong. The agenda is quite fixed - what did you finish, what do you plan, what are your blockers, so don't veer off the agenda (set separate meetings if needed so it doesn't get confusing). If two people need to discuss a strategy or a blocker, send them off to do it after the meeting (don't use the whole team's time). If someone runs too long every day talk to them in private and get them to make their part shorter. You may want to schedule something just a little longer once a week if you have a team that wants to deal with process issues, etc., more often than once an iteration, but get the stand-up part of the meeting done first to avoid any confusion about the format. Most importantly, make the meeting fun whenever you can. Bring something to eat, start with a joke, look again at <a href="http://ivybay.com/index.php?option=com_content&view=article&id=104:a-few-words-about-traditions-and-appreciation-in-your-team&catid=43:program-management-blog&Itemid=72">Tanya's post</a> about small victories.<br />
<br />
Finally, you might encounter <b>a secret move back to waterfall</b>. When this happens, everyone keeps working within the general agile structure and the team often doesn't realize what's going on. Symptoms include user stories that drag from sprint to sprint, user stories that are too big or broken down inappropriately, lack of or improper use of epics, and QA/Test organizations falling behind because they are handed too much functionality all at once. Don't let the team con you into waiting 'until the next big function' because it's 'too much trouble/delay/work' to fix the problem immediately. The whole team - and the whole project - will continue to suffer until the issue is fixed. You may have to deal with denial (after all, the team isn't moving this direction with intent, they're moving back to a methodology that's comfortable to them) and you'll certainly have to put up with a bit of whining, but steady the course and it will work out. (And be sure to celebrate when things are back on track!)<br />
<br />
Want more? Check out the <a href="http://ivybay.com/index.php?option=com_content&view=category&id=43:program-management-blog&Itemid=72&layout=default">Project Management blog</a> on <a href="http://www.ivybay.com/">IvyBay</a><br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://3.bp.blogspot.com/-14TaQbWOUms/VBsCH6Jr8yI/AAAAAAAAACQ/6Xab9yvrW8I/s1600/IMG_9135prv_lo_res.jpg" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" src="http://3.bp.blogspot.com/-14TaQbWOUms/VBsCH6Jr8yI/AAAAAAAAACQ/6Xab9yvrW8I/s200/IMG_9135prv_lo_res.jpg" /></a></div>
<br />
<br />
<br />
<br />
Unknownnoreply@blogger.com1tag:blogger.com,1999:blog-7691663244641934998.post-78504564895641693832014-03-23T06:50:00.007-07:002014-03-23T06:56:33.632-07:00<h3>
<span style="text-align: justify;"><span style="font-family: Verdana, sans-serif;">I
was recently asked 3 questions about working with remote software development
teams, the questions were specifically about quality issues</span></span></h3>
<div class="MsoNormal" style="text-align: justify;">
<i><span style="font-family: Verdana, sans-serif;"><br /></span></i></div>
<div class="MsoNormal" style="text-align: justify;">
<span style="font-family: Verdana, sans-serif;"><b><i>1)
Why customers get poor-quality software while working with remote software
development teams?</i></b></span></div>
<div class="MsoNormal" style="text-align: justify;">
<span style="font-family: Verdana, sans-serif;">Being successful with remote
teams requires a level of maturity that many organizations lack. Often there
are no documented standards, no processes, no vision, and so on… This leads to
delays, quality issues and general frustration with the remote team. Generally
the problem is not the remote team, it’s the customer.</span><br />
<span style="font-family: Verdana, sans-serif;"><br /></span></div>
<div class="MsoNormal" style="text-align: justify;">
<span style="font-family: Verdana, sans-serif;"><b><i>2)
According to your experience, if you could distinguish three key reasons of
poor software quality, what would they be?</i></b><o:p></o:p></span></div>
<ul type="disc">
<li class="MsoNormal" style="text-align: justify;"><span style="font-family: Verdana, sans-serif;">Product requirements that are
unclear and/or poorly documented.<o:p></o:p></span></li>
<li class="MsoNormal" style="text-align: justify;"><span style="font-family: Verdana, sans-serif;">A weak product owner or a product
owner that will not work off hours to remain in contact with the remote
team.<o:p></o:p></span></li>
<li class="MsoNormal" style="text-align: justify;"><span style="font-family: Verdana, sans-serif;">Not taking into account cultural
differences, both location and company cultures can have a big impact on
team dynamics.<o:p></o:p></span></li>
</ul>
<div class="MsoNormal" style="text-align: justify;">
<span style="font-family: Verdana, sans-serif;"><b><i>3)
Could you give customers a practical piece of advice, what they should pay
their attention to in order to avoid low software quality?</i></b></span></div>
<div class="MsoNormal" style="text-align: justify;">
<span style="font-family: Verdana, sans-serif;">Always check for understanding
when reviewing the product backlog. Since your product owner can’t be there
with the team you have to fill the void with documentation, mockups, and
conference calls. Spend the extra time to prepare these artifacts one sprint
ahead of development and review them with the remote team leads. Get your
stories clear ahead of the sprint and a lot of trouble goes away. Insist on
frequent demonstrations and good software process. Be very sure the team is on
the same page.</span><span style="font-size: small;"><o:p></o:p></span></div>
Patrick Merghttp://www.blogger.com/profile/07635669876248376487noreply@blogger.com0tag:blogger.com,1999:blog-7691663244641934998.post-23298001200982330412010-05-31T20:57:00.001-07:002010-05-31T20:57:22.268-07:00Out of Iteration Software Bugs<p>I did a presentation last week at an Agile event and during the Q and A session one of the questions was about “out of iteration bugs”. Specifically how are they handled? Good question, not all the bugs found in a software project will come from QA activities. It is inevitable that the users are going to find something with the software that needs to be fixed and or changed. What to do?</p> <p>In most cases the issue is treated like any other backlog item to be prioritized and addressed in an iteration. Depending on the severity / priority rating of the issue, the product owner can weigh the cost of fixing the bug now or having the Agile team complete a different user story. It’s just a matter of cost/benefit tradeoff of where the Agile team’s resources are spent.</p> <p><a href="http://lh3.ggpht.com/_CdddE_HIlTQ/TASFHVRNamI/AAAAAAAAAwE/StM4TvTa9uk/s1600-h/Support%5B9%5D.gif"><img style="border-bottom: 0px; border-left: 0px; display: inline; border-top: 0px; border-right: 0px" title="Support" border="0" alt="Support" src="http://lh6.ggpht.com/_CdddE_HIlTQ/TASFIGm9lYI/AAAAAAAAAwI/eqqP9q0ozdU/Support_thumb%5B7%5D.gif?imgmax=800" width="532" height="480" /></a></p> Patrick Merghttp://www.blogger.com/profile/07635669876248376487noreply@blogger.com3tag:blogger.com,1999:blog-7691663244641934998.post-23988849882439425552010-05-03T19:31:00.001-07:002010-05-03T19:31:17.719-07:00To Squawk or not to Squawk<p>The daily standup meeting is one of the core concepts of Scrum. In the meeting the team members talk about just three things:</p> <ul> <li>What I did yesterday</li> <li>What am I doing today</li> <li>What are my impediments</li> </ul> <p>And that’s it…   However, the teams that I see can’t keep it that simple, there is always some banter ( a good sign of team happiness ) and extended discussion on what is going on that may derail the team or another team member.  If the discussion goes on for more than a few minutes we table the discussion for right after the standup.  While it’s important to keep the standup moving its more important not to squash communication.</p> <p>Who should participate? Anyone who is involved or interested in the project.  Who should actually talk?  Only the folks directly involved in working on the backlog.  The other participants should keep their thoughts to themselves until they get a chance to talk to the Scrum Master away from the team.  </p> <p>Now I’m going to break the rule, one last thing at the end of the standup I want to know if there are any announcements.  This is a time for individuals that are close to the project but not working on the Product backlog to give the team any information that is valuable for the team.  Usually I limit who can give announcements to a very few trusted individuals.</p> <p>Daily Stand-ups.. keep them simple fast and open to the team.</p> Patrick Merghttp://www.blogger.com/profile/07635669876248376487noreply@blogger.com6tag:blogger.com,1999:blog-7691663244641934998.post-56982053184062583072010-03-01T21:26:00.001-08:002010-03-01T21:28:30.706-08:00Agile and Team Motivation - Goals<p>I recently started a series based on an Esther Derby Amplify discussion about how to demotivate a team. Esther mentioned in her discussion that unclear and changing goals are a big demotivator for a software development team. Besides agreeing whole heartedly my first thought when reading her discussion is how a good Agile implementation combats these demotivators. Let’s see how Agile methodologies thwart some of these potential demotivators for software development teams.</p> <p>But first, a high level review of some key Scrum concepts; The Prioritized Product Backlog, the Sprint Backlog, and the Sprint Planning Session. </p> <p>The Product Owner prioritizes the Product Backlog to identify the highest priority / value product features to be delivered by the Agile software development team.  By viewing the Product Road Map and the Product Backlog the Agile software development team can get a fairly clear idea about the project’s long term goals.  </p> <p><a href="http://lh3.ggpht.com/_CdddE_HIlTQ/S4yhj0n7RZI/AAAAAAAAAv0/sPP2Uk0-WRc/s1600-h/image%5B10%5D.png"><img style="border-bottom: 0px; border-left: 0px; display: inline; border-top: 0px; border-right: 0px" title="image" border="0" alt="image" src="http://lh4.ggpht.com/_CdddE_HIlTQ/S4yhkxfoEQI/AAAAAAAAAv8/Y1iTf-bAGOc/image_thumb%5B6%5D.png?imgmax=800" width="554" height="354" /></a> </p> <p><b>Scrum and Goal Stability / Clarity</b></p> <ul> <li> <p>The Product Road map is created by the product owner to provide a long term view of the product vision.</p> </li> <li> <p>The Product Backlog provides a view of the desired functionality expressed as user stories. The Product Owner prioritizes the user stories to place the highest value user stories to the top of the Product Backlog.</p> </li> <li> <p>The Sprint Planning Session and the Sprint Backlog; The Scrum team conducts a Sprint Planning Session in which the Scrum team selects from the Product Backlog a set of user stories and then commits to complete the selected user stories in the next Sprint. </p> </li> <ul> <li> <p>It’s important to note that once the Sprint commitment is agreed upon by the Scrum team, the contents of the Sprint cannot be changed by someone outside the Scrum team.</p> </li> </ul> <li> <p>Every day the Scrum Master conducts a Standup meeting with the Agile software team to review progress against the Sprint commitment. Using burn down charts the team can see if they will complete the user stories and meet the commitment (goal) of the Agile team.</p> </li> <li> <p>Once the Sprint completes, the Agile team demonstrates the completed code to the product owner to validate that the Agile software development team delivered what was expected by the Product Owner.</p> </li> </ul> <ul></ul> <p>In the Scrum / Agile environment, the team can see all aspects of the project, from the macro level Road Map to the micro level of the individual task. The Scrum team members set their own commitments on what they can deliver and are responsible to deliver on their commitment. It’s reassuring for the software development team to know they won’t be thrashed with constant change. It’s also very satisfying for an Agile software development team to deliver functionality on time, demonstrate it, and have the product owner validate that the developed user stories are what was expected.</p> Patrick Merghttp://www.blogger.com/profile/07635669876248376487noreply@blogger.com6tag:blogger.com,1999:blog-7691663244641934998.post-58701262208094311002010-02-14T17:11:00.001-08:002010-02-14T17:53:11.618-08:00Agile and Team MotivationEsther Derby makes some good points <a href="http://estherderby.amplify.com/2010/02/01/want-to-motivate-people-to-work-hard/">here</a> about how to demotivate a team. What struck me about her points is that they are exactly opposite to how a good Agile software development team works.<br />
<blockquote>Esther wrote<em> “What demotivates people? Bureaucracy, unclear goals, constantly shifting goals, micromanagement, punishment for delivering accurate by unwelcome status (to name a few).”</em></blockquote>How does an Agile team differ from this? I’ll start a whole series of articles to review these demotivators and how Agile teams avoid and address these issues.Patrick Merghttp://www.blogger.com/profile/07635669876248376487noreply@blogger.com1tag:blogger.com,1999:blog-7691663244641934998.post-80649517259981673462009-10-16T14:12:00.000-07:002009-10-16T14:23:48.572-07:00Use Cases in an Agile Project<span style="font-family: Verdana, sans-serif;">Use cases in an agile project? You bet, use cases are perfect to augment user stories as use cases can give more context to the person reading them. Use cases can also be used by the product owner to check for user story gaps in the product back log. Writing use cases often spawns alternative use case flows as new functionality is uncovered. As these alternative flows are written by the product owner new user stories should be written so that the functionality discovered in the use cases can be added to the product backlog.</span><br />
<br />
<span style="font-family: Verdana, sans-serif;">However, the timing of when use cases are written is important. Let’s say your product backlog has 50 user stories, you would not write use cases for every user story. Only the high priority user stories are candidates for use cases. Writing use cases for low priority user stories in your product backlog just adds waste and overhead to your project.</span>Patrick Merghttp://www.blogger.com/profile/07635669876248376487noreply@blogger.com3tag:blogger.com,1999:blog-7691663244641934998.post-89744734532988980982009-09-13T07:50:00.000-07:002009-09-13T07:50:19.539-07:00Innovation PresentationI saw this presentation on LinkedIn today and wanted to share. <br />
<br />
<div style="text-align: left; width: 425px;"><object height="355" style="margin: 0px;" width="425"><param name='movie' value='http://static.slideshare.net/swf/ssplayer2.swf?doc=understand-innovation-23947&stripped_title=understand-innovation-in-5-minutes' /><param name='allowFullScreen' value='true'/><param name='allowScriptAccess' value='always'/><embed src='http://static.slideshare.net/swf/ssplayer2.swf?doc=understand-innovation-23947&stripped_title=understand-innovation-in-5-minutes' type='application/x-shockwave-flash' allowscriptaccess='always' allowfullscreen='true' width='425' height='355'></embed></object></div>Patrick Merghttp://www.blogger.com/profile/07635669876248376487noreply@blogger.com1tag:blogger.com,1999:blog-7691663244641934998.post-27413822065592239292009-03-30T19:33:00.000-07:002009-03-30T19:34:48.013-07:00Failing Fast is a Good Thing<span style="font-family:verdana;">One of the benefits of switching to agile project management methodologies is the opportunity to fail fast. As a point of comparison, think about how waterfall projects work. The business requirements are assembled into a software specification. The software development team reviews the specification, creates the design and builds the software product. (I know this is an oversimplification) Some months later the software development team proudly shows the customer the software application in all its glory. </span><br /><span style="font-family:verdana;"><br />History has shown that this moment is often a moment that is less happy than expected. Some part of the software specification was not delivered as the customer wanted, or it was delivered as the customer wanted, but it’s really the wrong thing. Bottom-line, the software project or a part of the software project failed late. Ouch… It’s going to be expensive to fix…<br /><br />Agile methodologies by the way they work encourage failures very early in the project. With agile project management methodologies, there are frequent software product demonstrations to the product owner. Typically at the end of each sprint / iteration the software development team demonstrates the software build to the customer. Here’s the chance to let the product owner catch parts of the software project that are off course and make corrections as needed. It is much easier and cheaper to make a change on three weeks worth of software development after a sprint than six months worth of software development at the end of a waterfall project.<br /><br />Show your software to the product owner, let them find problems and fix them. It’s better to have a software project fail fast resulting in small changes than fail late</span> and have a big mess.<br /></span>Patrick Merghttp://www.blogger.com/profile/07635669876248376487noreply@blogger.com0tag:blogger.com,1999:blog-7691663244641934998.post-4668725844014827762009-03-14T07:40:00.000-07:002009-03-14T07:43:42.839-07:00User Story Format Thoughts<span style="font-family:verdana;">Recently I posted about a common user story format. I’m starting to see more and more discussion about this user story format and how some feel that it is too constrained. One proposal was to swap the value and actor sections. I’m trying to figure out an example of how to write this, hence my problem with this format. It does not seem natural and I really don’t see the value.</span><br /><span style="font-family:verdana;"><br />One of the great concepts of Agile is to inspect and adapt. While right now I don’t see value in changing the standard user story format, it does not mean that there won’t be a day when someone proposes a better way or writing user stories. When that day comes, I’ll inspect the new format and perhaps adapt.</span>Patrick Merghttp://www.blogger.com/profile/07635669876248376487noreply@blogger.com1tag:blogger.com,1999:blog-7691663244641934998.post-69636251235640439602009-03-01T20:49:00.000-08:002009-03-02T05:17:35.986-08:00Communicating Agile<span style="font-family:verdana;">Here’s a surefire way to fail with your Agile implementation. Ignore the other parts of the business that are used to dealing with schedule driven projects. It’s not enough to get the project team onboard with Agile, you need to spread the word and sell Agility to as many people as you can.<br /></span><br /><span style="font-family:verdana;">Go on “Agile Tours” and give multiple presentations about your Agile Team and how you are working to reduce waste and speed the delivery of working code. Of course short presentation won’t be enough to cover Agile Methodologies in much detail, but do talk about the benefits of customer interaction, process inspection, use stories, communication, UAT and so on. </span><br /><span style="font-family:verdana;"><br />Take the time to build the trust that what you are doing is correct and is the right thing for the business. Plus in today’s economy you are focusing valuable resources on the highest priority items and will deliver results sooner, who won't want to hear about that?</span>Patrick Merghttp://www.blogger.com/profile/07635669876248376487noreply@blogger.com0tag:blogger.com,1999:blog-7691663244641934998.post-44897721934604066632009-02-15T16:16:00.000-08:002009-02-15T16:21:24.912-08:00Agile Thinking – Enhance Personal Productivity<span style="font-family:verdana;">It’s a tough world right now, most organizations are being asked to get more done with less. In an earlier post I talked about MoSCoW ratings as a way to prioritize user stories. MoSCoW ratings can be used to prioritize many things. Prioritizing tasks with MoSCoW ratings in a to-do is list is just one way of using Agile thinking to boost personal productivity.</span><br /><span style="font-family:verdana;"><br />When I am overwhelmed I use MoSCoW to prioritize personal tasks.</span><br /><span style="font-family:verdana;"></span><br /><span style="font-family:verdana;"><strong>M</strong> - MUST do this task. In this context MUST is similar to Steven Covey’s Important / Urgent Quadrant. Schedule time to handle this task now.</span><br /><br /><span style="font-family:verdana;"><strong>S</strong> - SHOULD do this task. The world won’t end if it is not done today. But it’s a task that if it does not get done could lead to problems. This task should remain in your personal task backlog (to do list). <br /></span><br /><span style="font-family:verdana;"><strong>C </strong>- COULD do this task. This task is neither urgent nor important now. This task could remain in your personal task backlog (to do list) or be delegated.<br /></span><br /><span style="font-family:verdana;"><strong>W</strong> - WON'T do this task. Doing this task won’t move the project forward or provide any value. Delete this task.</span><br /><br /><span style="font-family:verdana;">We can’t add more hours in the day but we can spend the time we do have on the right things By looking applying MoSCoW ratings to tasks and responsibilities, you can make sure you are focused on the right priorities and remove waste by not spending time on needless tasks.</span>Patrick Merghttp://www.blogger.com/profile/07635669876248376487noreply@blogger.com2tag:blogger.com,1999:blog-7691663244641934998.post-74823409655565440202009-02-04T13:42:00.000-08:002009-02-07T07:32:54.704-08:00User Acceptance Tests - Test for Success and Build Confidence in Your Agile Team<span style="font-family:verdana;font-size:100%;">Getting users stories from your product owner is one of many ways software requirements are conveyed to the agile team. However there is one key companion to the user story, the user acceptance test. The user acceptance test closes the cycle by providing the criteria the product owner will use the test the user story. The agile team can use both the user story and user acceptance test together to ensure they understand requirements from the product owner. </span><br /><span style="font-family:verdana;font-size:100%;"></span><br /><span style="font-family:verdana;font-size:100%;">Just as when writing user stories, sometimes the product owners need help with writing user acceptance tests. It’s common to have a QA engineer assist in the process of writing user acceptance tests. I recommend using a QA engineer to make sure the software tests are clear of ambiguity. </span><br /><span style="font-family:verdana;font-size:100%;"></span><br /><span style="font-family:verdana;font-size:100%;">At the end of the sprint, the agile team demonstrates the completed user stories to the product owner and validates success by executing the user acceptance tests. This software product demonstration confirms to the product owner that the software meets the requirements specified via user stories.<br /><br />Running a software product demonstration and passing all the user acceptance tests is a big confidence builder for the team and the product owner. </span><br /><span style="font-family:verdana;font-size:100%;"></span><br /><span style="font-family:verdana;font-size:100%;">User Story + User Acceptance Test = Clearer understanding of what the product owner wants and how the agile team can test for success. </span>Patrick Merghttp://www.blogger.com/profile/07635669876248376487noreply@blogger.com1tag:blogger.com,1999:blog-7691663244641934998.post-49398273004763563022009-01-25T20:55:00.000-08:002009-01-25T21:03:19.359-08:00User Stories and And…<p><span style="font-family:verdana;">In an earlier post I talked about the three elements of a good user story, who, what, and why. The word “and” does not belong in one of these elements. If you are not familiar with the three elements of a user story, read this post “</span><a href="http://patmerg.blogspot.com/2008/12/user-stories-and-3-things-that-make.html"><span style="font-family:verdana;">User Stories and the 3 things that make them complete</span></a><span style="font-family:verdana;">” before proceeding. </span></p><span style="font-family:verdana;"><p>Check out this user story, can you spot the potential problem?<br /><br />Daytime and nighttime customers want to add products to a shopping cart and checkout so they can select and purchase products.<br /><br />The example is an awkward and big user story that covers a lot of functionality. The “what” section covers multiple pieces of functionality, the word “and” is your indication that the story is too big. This user story may be so big that the functionality may not be completed in a single sprint.<br /><br />The example user story needs to be two separate user stories to show a separate user goal “what” per user story.</p><ol><li>As a customer I want to add products to a shopping cart so I have a container for the products I want.</li><li>As a customer I want to check out so I can purchase products I want.</li></ol><p>Each of the above user stories is a viable user story that can be ranked and implanted independent of the other. So look out for the word “and” in the “what” section of a user story as a warning that the user story is too broad.</span> </p>Patrick Merghttp://www.blogger.com/profile/07635669876248376487noreply@blogger.com0tag:blogger.com,1999:blog-7691663244641934998.post-34428521834468829022009-01-05T19:32:00.000-08:002009-09-30T11:15:44.405-07:00User Story Prioritization - Part 1<span style="font-family:verdana;">Prioritizing the product backlog is an important step to make sure the agile software development team is focused on the correct set of user stories. The initial product backlog can consist from a few user stories to several hundred. Trying to prioritize several hundred user stories is a huge task that can be simplified by using MoSCoW ratings.<br />
</span><br />
<span style="font-family:verdana;">MoSCoW ratings defined:<br />
<strong>M</strong> - MUST have this feature – the product will fail to meet needs without this<br />
<strong>S</strong> - SHOULD have this feature – an important feature that has an acceptable work around<br />
<strong>C</strong> - COULD have this feature – wish list item<br />
<strong>W</strong> - WON'T have this feature at this time – might move to Must, Could or Should in the future.<br />
</span><br />
<span style="font-family:verdana;">Product owners and business folks seem to understand this approach and find it easier to deal with a large product backlog by using MoSCoW ratings.<br />
</span><br />
<span style="font-family:verdana;">Once a user story is MoSCoW rated only the Must user stories need to be prioritized. The rest of the user stories are not MoSCoW rated high enough to warrant the effort to do a numerical prioritization. That said, MoSCoW ratings on user stories can change over time, what was once a Must can become a Could or Should and so on…<br />
</span><br />
<span style="font-family:verdana;">Assigning a user story a MoSCoW rating is a quick and dirty way to quickly narrow down on what is important to deliver to make the product a success.</span>Patrick Merghttp://www.blogger.com/profile/07635669876248376487noreply@blogger.com1tag:blogger.com,1999:blog-7691663244641934998.post-70718619671781866632008-12-29T21:06:00.000-08:002009-09-30T11:37:53.245-07:00User Stories and the 3 things that make them complete<p><span style="font-family:verdana;">A really good user story will have <a href="http://blog.mountaingoatsoftware.com/?p=24">three things </a>to make them useful and complete</span></p><ul><li><span style="font-family:verdana;">Who</span></li>
<li><span style="font-family:verdana;">What</span></li>
<li><span style="font-family:verdana;">Why<br />
</span></li>
</ul><span style="font-family:verdana;">I’ve seen so many user stories that have the Who and What nailed, but they miss the Why. Adding the Why seems to be the hardest part, but it’s so useful for prioritization and for stakeholder understanding.</span><br />
<span style="font-family:verdana;"><br />
</span><br />
<span style="font-family:verdana;">So what are these user story elements?<br />
</span><br />
<ul><li><span style="font-family:verdana;">Who = the primary actor. The Who can be generic like customer, user or specific such as specialized user of a system. The Who can also be a non user such as a server; I’ll give an example later.</span></li>
<li><span style="font-family:verdana;">What = the action the primary actor wants to take. </span></li>
<li><span style="font-family:verdana;">Why = the value or the reason the primary actor wants to do the action.<br />
</span></li>
</ul><p><span style="font-family:verdana;">When writing user stories I’ll use standard phrases to ensure the completeness of the user stories</span></p><ol><li><span style="font-family:verdana;">“As a” to identify the Who</span></li>
<li><span style="font-family:verdana;">“I want to” to identify the What</span></li>
<li><span style="font-family:verdana;">“So that” to identify the Why<br />
</span></li>
</ol><p><span style="font-family:verdana;">So let’s write a few user stories as examples</span></p><ol><li><span style="font-family:verdana;">As a customer (who) I want to add items to a shopping cart (what) so that I can purchase them (why)</span></li>
<li><span style="font-family:verdana;">As a server (who) I want to receive well formed xml (what) so that I can process XML without errors (why)</span></li>
</ol><p><span style="font-family:verdana;"><br />
As I write this I found some proposals to switch the </span><span style="font-family:verdana;">Who, What Why</span><span style="font-family:verdana;"> to </span><a href="http://www.infoq.com/news/2008/06/new-user-story-format"><span style="font-family:verdana;">Why, Who, What</span></a><span style="font-family:verdana;font-size:85%;"><span style="font-size:100%;"> to provide the business value up front. It’s an interesting</span> idea to try when you write your user stories.</span></p>Patrick Merghttp://www.blogger.com/profile/07635669876248376487noreply@blogger.com1tag:blogger.com,1999:blog-7691663244641934998.post-39559906330482950932008-12-20T17:27:00.000-08:002008-12-29T21:14:06.314-08:00Getting Started with Agile Project Management<p><span class="Apple-style-span"><span class="Apple-style-span" style="font-family:verdana;"><span class="Apple-style-span" style="font-size:x-small;">I've recently read some discussions about how to get started with Agile Project Management. Its not hard to get started with Agile, however Agile project management is hard to sustain if you are not prepared for the issues that will arise. From personal experience there are a few things to tackle before adopting Agile Project Management. These ere education, training, finding a coach, and just getting </span></span><span class="Apple-style-span"><span class="Apple-style-span" style="font-family:verdana;"><span class="Apple-style-span" style="font-size:x-small;">started. </span></span><span class="Apple-style-span" style="font-family:verdana;"><span class="Apple-style-span" style="font-size:x-small;">The education part is pretty easy, there are some really good books that cover Agile Project Management and User Stories.</span></span></span></span></p><p><b><span class="Apple-style-span" style="font-family:verdana;"><span class="Apple-style-span" style="font-size:x-small;">Books</span></span></b><span class="Apple-style-span" style="font-family:verdana;"><span class="Apple-style-span" style="font-size:x-small;"> -I've read all of these Agile Project Management book and use them as a reference.<br /></span></span><span class="Apple-style-span" style="font-family:verdana;"><span class="Apple-style-span" style="font-size:x-small;"></span></span></p><ul><span class="Apple-style-span" style="font-family:verdana;"><span class="Apple-style-span" style="font-size:x-small;"><br /></span></span><span class="Apple-style-span" style="font-family:verdana;"><span class="Apple-style-span" style="font-size:x-small;"></span></span><li><a href="http://www.amazon.com/gp/product/073561993X?ie=UTF8&tag=patrmerg-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=073561993X"><span class="Apple-style-span" style="font-family:verdana;"><span class="Apple-style-span" style="font-size:x-small;">Agile Project Management with Scrum</span></span></a><span class="Apple-style-span" style="font-family:verdana;"><span class="Apple-style-span" style="font-size:x-small;"><img style="BORDER-RIGHT: medium none; BORDER-TOP: medium none; MARGIN: 0px; BORDER-LEFT: medium none; BORDER-BOTTOM: medium none" height="1" alt="" src="http://www.assoc-amazon.com/e/ir?t=patrmerg-20&l=as2&o=1&a=073561993X" width="1" border="0" /></span></span></li><span class="Apple-style-span" style="font-family:verdana;"><span class="Apple-style-span" style="font-size:x-small;"><br /></span></span><span class="Apple-style-span" style="font-family:verdana;"><span class="Apple-style-span" style="font-size:x-small;"></span></span><li><a href="http://www.amazon.com/gp/product/0131479415?ie=UTF8&tag=patrmerg-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=0131479415"><span class="Apple-style-span" style="font-family:verdana;"><span class="Apple-style-span" style="font-size:x-small;">Agile Estimating and Planning</span></span></a><span class="Apple-style-span" style="font-family:verdana;"><span class="Apple-style-span" style="font-size:x-small;"><img style="BORDER-RIGHT: medium none; BORDER-TOP: medium none; MARGIN: 0px; BORDER-LEFT: medium none; BORDER-BOTTOM: medium none" height="1" alt="" src="http://www.assoc-amazon.com/e/ir?t=patrmerg-20&l=as2&o=1&a=0131479415" width="1" border="0" /></span></span></li><span class="Apple-style-span" style="font-family:verdana;"><span class="Apple-style-span" style="font-size:x-small;"><br /></span></span><span class="Apple-style-span" style="font-family:verdana;"><span class="Apple-style-span" style="font-size:x-small;"></span></span><li><a href="http://www.amazon.com/gp/product/B001E0IAF2?ie=UTF8&tag=patrmerg-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=B001E0IAF2"><span class="Apple-style-span" style="font-family:verdana;"><span class="Apple-style-span" style="font-size:x-small;">User Stories Applied</span></span></a><span class="Apple-style-span" style="font-family:verdana;"><span class="Apple-style-span" style="font-size:x-small;"><img style="BORDER-RIGHT: medium none; BORDER-TOP: medium none; MARGIN: 0px; BORDER-LEFT: medium none; BORDER-BOTTOM: medium none" height="1" alt="" src="http://www.assoc-amazon.com/e/ir?t=patrmerg-20&l=as2&o=1&a=B001E0IAF2" width="1" border="0" /></span></span></li><span class="Apple-style-span" style="font-family:verdana;"><span class="Apple-style-span" style="font-size:x-small;"><br /></span></span></ul><p><b><span class="Apple-style-span" style="font-family:verdana;"><span class="Apple-style-span" style="font-size:x-small;">Certification</span></span></b><span class="Apple-style-span" style="font-family:verdana;"><span class="Apple-style-span" style="font-size:x-small;"> - </span></span><span class="Apple-style-span" style="font-family:verdana;"><span class="Apple-style-span" style="font-size:x-small;">The Certified Scrum Master certification class is a great way to get some exposure to Scrum and learn about some common issues that beginners run into. Its even better to send several people on the team to the CSM class.</span></span></p><p><b><span class="Apple-style-span" style="font-family:verdana;"><span class="Apple-style-span" style="font-size:x-small;">Coaching</span></span></b><span class="Apple-style-span" style="font-family:verdana;"><span class="Apple-style-span" style="font-size:x-small;"> - Agile is hard, get an Agile Coach to guide you through the first project or at least the first few sprints. The value of the knowledge transfer and guidance will far outweigh the cost of the coach. The coach will know from experience what problems happen with new agile teams and can guide the team through the trouble spots</span></span></p><p><b><span class="Apple-style-span" style="font-family:verdana;"><span class="Apple-style-span" style="font-size:x-small;">Just Get Started</span></span></b><span class="Apple-style-span" style="font-family:verdana;"><span class="Apple-style-span" style="font-size:x-small;"> - I remember the very first step we took to adopt Agile Project Management. The development team was in a conference room with the product owner, we wrote 12 user stories and prioritized them. The simple step of getting requirements via user stories and prioritizing them into the product backlog was an eye opening experience for the team. At once the software development team understood what was important to the product owner and the product owner better understood what the software development team could do in the time period for the project. In the world of Agile this is a very simple step but it was the first crucial step to change the way the software development team interacted with the product owner. So, go read some books, get certified and take your first steps, its worth it. </span></span></p>Patrick Merghttp://www.blogger.com/profile/07635669876248376487noreply@blogger.com1tag:blogger.com,1999:blog-7691663244641934998.post-24560163145893960232008-12-14T11:32:00.000-08:002008-12-29T21:15:10.147-08:00Agile and User Interface Mockups<span style="font-family:verdana;font-size:85%;">Some people will argue that user interface mockups smell of big planning and have no place in agile, I disagree. Let’s face it; it’s hard for a product owner to communicate to the software development team how a software product should look and work without pictures.<br /><br />A product owner that has screen mockups to work with has a powerful tool to elaborate user stories. Pictures enhance collaboration and understanding by giving the software development team an alternate method of receiving software product requirements from the product owner.<br /><br />From a QA perspective, the mockups serve as a guide for testing the user interface to ensure that the user interface is developed as requested by the product owner.<br /><br />It gets tricky though when the user interface mockup illustrates product functionality covered by several user stories. The one easy way around this is to just add the user story number to the mockup and use themes.</span>Patrick Merghttp://www.blogger.com/profile/07635669876248376487noreply@blogger.com2tag:blogger.com,1999:blog-7691663244641934998.post-42581950948779971242008-12-02T06:28:00.000-08:002008-12-29T21:15:24.396-08:00Focused delivery of value<span style="font-family:verdana;font-size:85%;"><span style="font-size:100%;">Isn’t that what it’s all about? I was writing something else today about aligning resources and part of what I wrote was “focus resources on the high value deliverables for quick impact and realization of value”. Anything that gets in the way of this is a negative and removes value from o software development project. It seems so basic. In a nut shell this one sentence describes the goal of using agile project management methods.</span> </span>Patrick Merghttp://www.blogger.com/profile/07635669876248376487noreply@blogger.com0tag:blogger.com,1999:blog-7691663244641934998.post-71143292980034636382008-11-23T07:51:00.000-08:002008-12-29T21:15:46.134-08:00Agile Project Management for Globally Distributed Teams<p><span style="font-family:verdana;"><strong>What’s the perfect Agile team size?</strong> The typical Scrum team size is 5-7 people in one location with a dedicated product owner. This model has been proven out time after time. However, expand the team to 4 project managers, 50 people around the world, three different outsource vendors, three different languages, umpteen time-zones, a multitude of contractors, a team of product owners and you have a challenge. Standard, by the book Scrum will not work and we already know by experience that waterfall does not work.</span></p><p><span style="font-family:verdana;"><strong>What to do?</strong> Pick the best out of multiple project management methodologies and tailor a process that works for you. The goals are still the same, fast development, customer involvement, frequent feedback, and reduced waste. I’ve seen lots of experts write about standard scrum in small teams. I don’t see much written about large agile teams. </span></p><p><strong></strong><span style="font-family:verdana;"><strong>Scrum, What works for Globally Distributed Teams </strong><br /></span></p><ul><li><strong></strong><span style="font-family:verdana;">User Stories </span></li><li><span style="font-family:verdana;">Short Sprints </span></li><li><span style="font-family:verdana;">Test automation </span></li><li><span style="font-family:verdana;">A commercial web based Agile PM tool </span></li><li><span style="font-family:verdana;">Burn down charts </span></li><li><span style="font-family:verdana;">Multiple Scrum Masters </span></li><li><span style="font-family:verdana;">Customer involvement </span></li><li><span style="font-family:verdana;">Prioritized product backlog</span></li><li><span style="font-family:verdana;">Scrum of Scrums</span></li></ul><p><span style="font-family:verdana;"></span></p><ul><br /><span style="font-family:verdana;"></span></ul><p><span style="font-family:verdana;"><strong>Scrum, What does not work for </strong><strong>Globally Distributed Teams:</strong> </span></p><ul><li><span style="font-family:verdana;">Daily standup meetings for the entire team </span></li><li><span style="font-family:verdana;">A single product owner </span></li><li><span style="font-family:verdana;">Sticky notes for user stories </span></li><li><span style="font-family:verdana;">Developers adding tasks</span></li></ul><br /><br /><p><span style="font-family:verdana;"><strong>Things to try:</strong> (I have and it works) </span></p><ul><li><span style="font-family:verdana;">A product owner team </span></li><li><span style="font-family:verdana;">Three sprints per user story<br /></span></li><ul><li><em><span style="font-family:verdana;">User story definition </span></em></li><li><em><span style="font-family:verdana;">User story development </span></em></li><li><span style="font-family:verdana;"><em>User story QA/Test Automation/UAT</em><br /></span></li></ul><li><span style="font-family:verdana;">Dedicated System Architects </span></li><li><span style="font-family:verdana;">Multiple Project Managers - Scrum Masters </span></li><li><span style="font-family:verdana;">Predefined tasks per user stories </span></li><li><span style="font-family:verdana;">Multiple interacting scrum teams </span></li><li><span style="font-family:verdana;">Be flexible with your approach</span></li><br /><br /></ul>Patrick Merghttp://www.blogger.com/profile/07635669876248376487noreply@blogger.com0tag:blogger.com,1999:blog-7691663244641934998.post-30321972403479953382008-11-22T12:13:00.000-08:002008-12-29T21:15:57.774-08:00Agile Project Management<span style="font-family:verdana;">Agile Project Management is growing in popularity as a method to more tightly involve the customer in the process of delivering a software product. Agile project management processes are a way to remove waste from all levels of product development and deliver value at a reduced cost.<br />The goals I had when introducing Agile were; fast development, customer involvement, frequent feedback, and reduced waste/cost. </span><br /><span style="font-family:verdana;"><br /><strong>Fast development:</strong> Achieved by delivering focused/concise user reviewed and approved user stories written in natural language thus reducing rework and waste. (</span><a href="http://jeffsutherland.com/scrum/2005/03/scrum-evolution-type-b-and-c-sprints.html"><span style="font-family:verdana;">Type B /C Sprint</span></a><span style="font-family:verdana;">) Overlapping and concurrent sprints with defined teams doing specialized work keeps the development team pipeline full. It also keeps the customer involvement very high.<br /><strong></strong></span><br /></span><span style="font-family:verdana;"><strong>Customer involvement:</strong> Customer involvement is key to Agile, without frequent customer interaction the value gained by constant customer inspection and validation is lost.<br /></span><br /><span style="font-family:verdana;"><strong>Frequent feedback:</strong> An important agile process is short development cycles (three week iterations) with a demonstrable build at the end of each iteration. These builds are used to demonstrate functionality to the customer for approval or rejection. It’s much easier to change a three week cycle than a nine month development effort.<br /></span><br /><span style="font-family:verdana;"><strong>Reduced waste/cost:</strong> The agile process reduces cost and waste at many different levels. An important part of Agile is the frequent prioritization of user requirements to make sure the development team only focuses on what will be valuable to the customer. Prioritizing requirements results in a product that has immediate value without the clutter. Long term the result is lower product complexity and support costs. </span>Patrick Merghttp://www.blogger.com/profile/07635669876248376487noreply@blogger.com1