http://blog.scrumedge.com/ScrumEdge is an online collaborative scrum tool that allows scrum teams, ScrumMasters, and stakeholders to manage the Scrum lifecycle at the product and sprint levels.ennoreply@blogger.com (amoeen)Mon, 10 Oct 2011 11:11:54 PDTBlogger http://www.blogger.com191125http://creativecommons.org/licenses/by-nc-sa/2.0/http://creativecommons.org/licenses/by-nc-sa/2.0/http://creativecommons.org/images/public/somerights20.gifScrumSoftwareToolScrumedgeOnlinehttp://feedburner.google.comhttp://blog.scrumedge.com/2011/09/sm-po-cheatsheet-simple-guide-to.htmlScrumMastersProduct BacklogProduct OwnerEstimatesTeam MembersTipsRelease PlanningSprint RetrospectiveDaily Standupnoreply@blogger.com (amoeen)Fri, 02 Sep 2011 01:28:00 PDTtag:blogger.com,1999:blog-3727840331398241770.post-5794628342579990362<p><strong>By Edward Scotcher</strong></p> <p>This is a simple one page aide memoire that can be used to help explain the responsibilities of the role of Product Owner and Scrum Master. It's great to print off and hand out to people when you are explaining what the roles are and what the differences are between them. So next time you need to talk about these roles, you can use this as a basis for a simple discussion or presentation.</p> <p><strong>Scrum Master's Responsibilities</strong></p> <ul> <li>Responsible for helping the team deliver work to the Product Owner </li> <li>Makes sure the team can meet its commitments by removing any impediments they face, including Managing dependencies, escalating blockers that they cannot remove themselves </li> <li>Facilitates process &amp; meetings (eg Reviews, Stand Ups, Planning, Estimation, Scheduling, Prioritization) </li> <li>Makes sure the team is fully functional, productive and improving quality </li> <li>Shields the team from distractions and interferences (including the Product Owner) </li> <li>Enables close co-operation across all roles and functions, removes barriers </li> <li>Responsible for reporting progress, including producing standard outward-facing artefacts </li> <li>Manages Product Owners expectations of the team </li> <li>Responsible for keeping time and quality requirements</li> </ul> <p><a href="http://www.scrumalliance.org/articles/304-sm--po-cheatsheet" target="_blank">Continue reading this article</a>.</p> <div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/3727840331398241770-5794628342579990362?l=blog.scrumedge.com' alt='' /></div>2011-09-02T01:28:00.767-07:00http://blog.scrumedge.com/2011/08/how-pd-works-in-agile-team.htmlProduct OwnerTeam MembersTipsSprint Backlognoreply@blogger.com (amoeen)Fri, 26 Aug 2011 01:26:00 PDTtag:blogger.com,1999:blog-3727840331398241770.post-3220856472775359496<p><strong>By Dingshan Li</strong></p> <p>PD (Product designer) is very important role in software development. They will provide detail requirements specification and business workflow, UI workflow. In traditional software development process, PD will prepare the detail requirement design document before develop team start to make software design. This kind of process will work pretty well if the requirements are clear and relatively stable. Also, there are enough PD resources to make the complex documents. But most of time, we cannot figure out the whole requirements clearly at the start stage. And the scope change is often happen. Another factor is that PD always need to work on more than one product and it is very difficult for them to spend much of time to work out a detail design document. So, what can we do to deal with this kind of issues?</p> <p>Agile provides a methodology or framework for the team to develop software under the situation of changing scope. By focusing on high value requirement, separating the long lifecycle to be several short iterations and guarantee fully-test in each iteration, it can provide high-quality and expected software to the client. In this kind of framework, how PD works in the team? How they collaborate with others</p> <p><a href="http://www.scrumalliance.org/articles/301-how-pd-works-in-agile-team" target="_blank">Continue reading this article</a>.</p> <div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/3727840331398241770-3220856472775359496?l=blog.scrumedge.com' alt='' /></div>2011-08-26T01:26:00.086-07:00http://blog.scrumedge.com/2011/08/product-owner-on-one-page-overview-of.htmlStakeholdersScrumMastersProduct BacklogProduct OwnerTipsBurndown ChartsDaily Standupnoreply@blogger.com (amoeen)Fri, 19 Aug 2011 01:24:00 PDTtag:blogger.com,1999:blog-3727840331398241770.post-7348485119607348810<p><strong>By Roman Pichler</strong></p> <p>The following diagram summarises the product owner's responsibility together with the role's key activities and artefacts. </p> <p><img alt="The Product Owner on One Page" src="http://www.romanpichler.com/blog/wp-content/uploads/2010/11/PO_on_one_page1.jpg" width="600" height="760" /></p> <p><a href="http://www.scrumalliance.org/articles/302-the-product-owner-on-one-page" target="_blank">Continue reading this article</a>.</p> <div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/3727840331398241770-7348485119607348810?l=blog.scrumedge.com' alt='' /></div>2011-08-19T01:24:00.400-07:00http://blog.scrumedge.com/2011/08/land-that-scrum-forgot.htmlVelocityTeam MembersTipsContinuous Integrationnoreply@blogger.com (amoeen)Fri, 12 Aug 2011 01:21:00 PDTtag:blogger.com,1999:blog-3727840331398241770.post-4184419531555380348<p><strong>By Robert C. Martin</strong></p> <p>Scrum is a starting point. In fact, it’s a great starting point. But, as a framework rather than a full-blown methodology, Scrum is deliberately incomplete. Some things—such as the best technical practices to use—are left for individual teams to determine. This allows a team to create the best fit between their project and environment and an assortment of technical practices.</p> <p>While that selection of practices should belong to the team or organization rather than to a group of methodologists, the benefits of some practices are becoming so compellingly obvious that they warrant consideration by any Scrum team. But, too many Scrum teams become complacent after achieving some early productivity gains with Scrum. And they stop seeking ways to improve. Many fail to try the technical practices necessary for long-term success. In the following article, Robert Martin (perhaps better known as &quot;Uncle Bob&quot;) tells us why so many Scrum teams fail to sustain the promise of their early successes.</p> <p><a href="http://www.scrumalliance.org/articles/300-the-land-that-scrum-forgot" target="_blank">Continue reading this article</a>.</p> <div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/3727840331398241770-4184419531555380348?l=blog.scrumedge.com' alt='' /></div>2011-08-12T01:21:00.092-07:00http://blog.scrumedge.com/2011/07/heartbeats-pace-of-scrum-team.htmlScrumMastersVelocityTeam MembersTipsnoreply@blogger.com (amoeen)Fri, 29 Jul 2011 01:20:43 PDTtag:blogger.com,1999:blog-3727840331398241770.post-1255456061294054135<p><strong>By Rafael Nascimento</strong></p> <p>One of the challenges in the use of Scrum is to predict how much of functionality a team is able to deliver each sprint. Many try, in a vague attempt to create a metric, to assign a story point a certain amount of work to be delivered, rather than looking how a team play their roles and perform their deliveries. For example, a story point is equivalent to a CRUD with 8 fields that accesses a table in the database. This approach does not work, because a team is made up of people with different experiences, perceptions and problems (personal or professional). Individually and collectively, a team always has different emotional and technical characteristics&#160; from other teams. Team members never take the same time that members of Team B took to adapt to each other. Teams will never manage exactly the same conflict situations or have the same productivity. Finally, in sets filled by human beings, there may even be a statistical&#160; standard for productivity, but never an industry standard, accurate and predictable. There will always be a margin of error. Then comes a question for reflection: is it better to draft a plan and make your team follow this plan at any cost, in favor of a contract or corporate goal? Or would it be better to identify a target and track the performance and growth of your team, guiding it toward its mission, enjoying a harmonious, happy and highly productive environment, and make necessary adjustments to the project plan for the sake of your customers’ satisfaction, offering them transparency, with no surprises?</p> <p><a href="http://www.scrumalliance.org/articles/199-heartbeats" target="_blank">Continue reading this article</a>.</p> <div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/3727840331398241770-1255456061294054135?l=blog.scrumedge.com' alt='' /></div>2011-07-29T01:20:43.257-07:00http://blog.scrumedge.com/2011/07/ouija-board-estimation.htmlScrumMastersProduct OwnerPlanning PokerTeam MembersTipsUser Storiesnoreply@blogger.com (amoeen)Fri, 29 Jul 2011 01:21:07 PDTtag:blogger.com,1999:blog-3727840331398241770.post-7375539954196863752<p>During a recent training course I ran, one of the delegates made a joke about the nature of agile estimation in Scrum teams resembling a &quot;séance&quot;; whereby the team gathers around the table and stares at a number of user story cards expecting something unnatural to happen. How true!&#160; This gave me an idea for a different type of iterative estimation that I tried in practice with ‘Team Woodstock’.&#160; I sat the team around a table and wrote the Fibonacci sequence’s numbers “1,2,3,5,8,13” and a “?” on post-its around the table in the design of a Ouija board.&#160; Once everyone was sitting comfortably, had cleared their minds and entered a trance-like state the product owner read out the story and the team clarified the acceptance criteria.&#160; Then the story was placed in the middle of the table and each team member put one finger on the story – in silence. Without discussion or argument the story started to move towards the number which reflected its size, by the act of the team members pushing or pulling the story towards their chosen number.</p> <p><img title="Online Scrum Tool" alt="Online Scrum Tool" src="http://www.scrumalliance.org/system/photos/1/large/IMG_0393.JPG?1288705165" /></p> <p><a href="http://www.scrumalliance.org/articles/195-ouija-board-estimation" target="_blank">Continue reading this article</a>.</p> <div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/3727840331398241770-7375539954196863752?l=blog.scrumedge.com' alt='' /></div>2011-07-29T01:21:07.168-07:00http://blog.scrumedge.com/2011/07/agile-tools-vs-agile-books-value-of.htmlPlanning PokerTipsnoreply@blogger.com (amoeen)Fri, 01 Jul 2011 02:04:00 PDTtag:blogger.com,1999:blog-3727840331398241770.post-8035302477877966907<p><strong>By Paul Heidema</strong></p> <p>I have been working with Agile for a couple of years. At Berteig Consulting we are using Agile to run our small business. As such we try to use various tools to make our life easier. We have used CardMeeting for our cycles and tasks. I have tried using <a href="http://planningpoker.com/">PlanningPoker</a> for online estimation. It seems useful, but maybe our team is too small to make great use of it. I am also looking for other ways to manage the reflections and learning from each cycle.</p> <p>I have received an email from David Wolrich of CardMeeting that states: “Anyways, I rely on the trickle of news from legitimate organizations like yours to let users know that CardMeeting is still around, that I am still adding features, and to generate interest; thanks again.” So maybe some of you could try it and give him a shout. Much like other free applications on the net such as Drupal and Neo Office this one could become more robust and useful.</p> <p><a href="http://www.scrumalliance.org/articles/189-negotiating-scrum-through-a-waterfall">Continue reading this article</a>.</p> <div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/3727840331398241770-8035302477877966907?l=blog.scrumedge.com' alt='' /></div>2011-07-01T02:04:00.167-07:00http://blog.scrumedge.com/2011/06/scrum-gaming-addiction-how-scrum-is.htmlTeam MembersTipsSprint RetrospectiveDaily Standupnoreply@blogger.com (amoeen)Mon, 27 Jun 2011 02:03:00 PDTtag:blogger.com,1999:blog-3727840331398241770.post-9110297812120430058<p><strong>By Pete Behrens</strong></p> <p><img style="margin: 0px 10px 0px 0px; display: inline" align="left" src="http://trailridgeconsulting.com/images/blog/online_gaming.jpg" width="329" height="201" />There are few people in our Scrum Community who know personally the power of video games to engage people, and even create addictions to them. There are even some who have applied Scrum to creating those addictive online video games.</p> <p>This article is not about applying Scrum to gaming applications; rather, it is about the similarities Scrum has to the gaming world in what makes them so addicting. Video gaming is one of the largest growing markets in the world at $50B this year and is on target to be three times the music industry by 2014. This year alone, there was $8B spent on virtual goods in online gaming systems - a true market indeed.</p> <p>We can learn a tremendous amount from the viral and exponential growth of the video gaming industry. What makes these video games so interesting, engaging and addicting; and what can we learn about them in making our organizations more interesting, engaging, and even addicting?</p> <p><a href="http://www.scrumalliance.org/articles/196-scrum--gaming-addiction">Continue reading this article</a>.</p> <div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/3727840331398241770-9110297812120430058?l=blog.scrumedge.com' alt='' /></div>2011-06-27T02:03:00.191-07:00http://blog.scrumedge.com/2011/06/example-scrummaster-checklist.htmlScrumMastersProduct BacklogProduct OwnerTipsBurndown ChartsUser StoriesContinuous Integrationnoreply@blogger.com (amoeen)Fri, 24 Jun 2011 02:00:00 PDTtag:blogger.com,1999:blog-3727840331398241770.post-6907227402539390373<p><strong>By Michael James</strong></p> <p>An <strong>adequate</strong> ScrumMaster can handle two or three teams at a time. If you're content to limit your role to organizing meetings, enforcing timeboxes, and responding to the impediments people explicitly report, you can get by with part time attention to this role. The team will probably still exceed the baseline, pre-Scrum expectation at your organization, and probably nothing catastrophic will happen.</p> <p>But if you can envision a team that has a great time accomplishing things you didn't previously consider possible, within a transformed organization -- consider being a <strong>great </strong>ScrumMaster.</p> <p>A great ScrumMaster can handle <strong>one</strong> team at a time.</p> <p>We recommend one dedicated ScrumMaster per team of about seven, especially when starting out.</p> <p>If you haven't discovered all the work there is to do, tune in to your Product Owner, your team, your team's engineering practices, and the organization outside your team. While there's no single prescription, I've outlined some things I've seen ScrumMasters overlook.</p> <p><a href="http://www.scrumalliance.org/articles/194-an-example-scrummasters-checklist">Continue reading this article</a>.</p> <div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/3727840331398241770-6907227402539390373?l=blog.scrumedge.com' alt='' /></div>2011-06-24T02:00:00.309-07:00http://blog.scrumedge.com/2011/06/ouija-board-estimation-fun-technique.htmlScrumMastersProduct BacklogProduct OwnerPlanning PokerEstimatesTeam MembersTipsUser Storiesnoreply@blogger.com (amoeen)Mon, 20 Jun 2011 01:56:00 PDTtag:blogger.com,1999:blog-3727840331398241770.post-6112222600519367526<p><strong>By Paul Goddard</strong></p> <p>During a recent training course I ran, one of the delegates made a joke about the nature of agile estimation in Scrum teams resembling a &quot;séance&quot;; whereby the team gathers around the table and stares at a number of user story cards expecting something unnatural to happen. How true!&#160; This gave me an idea for a different type of iterative estimation that I tried in practice with ‘Team Woodstock’.&#160; I sat the team around a table and wrote the Fibonacci sequence’s numbers “1,2,3,5,8,13” and a “?” on post-its around the table in the design of a Ouija board.&#160; Once everyone was sitting comfortably, had cleared their minds and entered a trance-like state the product owner read out the story and the team clarified the acceptance criteria.&#160; Then the story was placed in the middle of the table and each team member put one finger on the story – in silence. Without discussion or argument the story started to move towards the number which reflected its size, by the act of the team members pushing or pulling the story towards their chosen number.</p> <p><img title="Scrum Tool" alt="Scrum Tool" src="http://www.scrumalliance.org/system/photos/1/large/IMG_0393.JPG?1288705165" /></p> <p><a href="http://www.scrumalliance.org/articles/195-ouija-board-estimation">Continue reading this article</a>.</p> <div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/3727840331398241770-6112222600519367526?l=blog.scrumedge.com' alt='' /></div>2011-06-20T01:56:00.241-07:00http://blog.scrumedge.com/2011/06/why-your-boss-boss-should-also-go-agile.htmlProduct OwnerTipsAgilenoreply@blogger.com (amoeen)Fri, 17 Jun 2011 01:54:00 PDTtag:blogger.com,1999:blog-3727840331398241770.post-5851353102638604936<p><strong>By Christine Crandell</strong></p> <p>Incremental software development methodologies can be traced all the way back to the 1950s, but it wasn’t until 2001 that “The Agile Manifesto” created a comprehensive and landmark account of agile development and why it’s a better, lighter approach to creating software faster.</p> <p>Ever since then, developers have been using agile methodologies to improve the speed and flexibility of software development through operational improvements, but most other groups within the same company have not adopted a similar philosophy.</p> <p>Conceptually we’ve bottled up agile as being for software developers, as if speed, flexibility, and complexity weren’t also issues held within every other departments of fast-paced software companies. When software developers are using agile methodologies, but nobody else is, developers become like the clique group of school kids who share a foreign language nobody else understands.</p> <p>This has caused us to limit the potential for agile frameworks, because they're only implemented operationally, but not strategically. It’s like a wooden boat full of rowers. They might have seamless coordination and full visibility into the work of their colleagues, but they can’t see the captain’s orders up on deck.</p> <p><a href="http://www.scrumalliance.org/articles/192-why-your-bosss-boss-should-also-go-agile">Continue reading this article</a>.</p> <div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/3727840331398241770-5851353102638604936?l=blog.scrumedge.com' alt='' /></div>2011-06-17T01:54:00.728-07:00http://blog.scrumedge.com/2011/06/getting-dirty-with-scrum.htmlScrumMastersWaterfallTeam MembersTipsDaily Standupnoreply@blogger.com (amoeen)Mon, 13 Jun 2011 01:52:00 PDTtag:blogger.com,1999:blog-3727840331398241770.post-4250359814815438879<p><strong>By Pat Guariglia</strong></p> <p>I have been the Scrum Master for this one team for several years. The other day I arrived a few minutes early to the room we use for our daily Scrum and sat down to gather my thoughts before the meeting. I was in the room by myself when I noticed all of the scuffing and marks on the walls.&#160; When we started using this room for our daily Scrum meetings, it was freshly painted and hardly used. Two years later, I am looking at the walls of a well-used room, a room that hosts our daily stand-up meetings… a room that gets dirty. </p> <p>Seeing the dirt on the walls reminded me of how tactile the whole Scrum process really is. In Scrum, you cannot be afraid to get dirty. You work with your hands, body and mind. When Scrum is done well, the team becomes a well-oiled machine that takes on a personality of its own. The seasoned Scrum team reacts organically to change and knows how to process it. </p> <p>Good Scrum involves taking yourself out of the virtual world and into the real world. Unlike other software methodologies (waterfall), Scrum is the framework that thrives on continuous hands-on experiences, plus tactile and verbal feedback. It works best when people are engaged and physically involved. Collocation, physical task boards, daily Scrum meetings, and customer collaboration all require the team to be there physically.</p> <p><a href="http://www.scrumalliance.org/articles/193-getting-dirty-with-scrum">Continue reading this article</a>.</p> <div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/3727840331398241770-4250359814815438879?l=blog.scrumedge.com' alt='' /></div>2011-06-13T01:52:00.503-07:00http://blog.scrumedge.com/2011/06/negotiating-scrum-through-waterfall-how.htmlWaterfallTipsnoreply@blogger.com (amoeen)Thu, 09 Jun 2011 01:51:59 PDTtag:blogger.com,1999:blog-3727840331398241770.post-2101447117974216629<p><strong>By Phil Southward</strong></p> <p>Negotiating a Scrum team through the often laborious processes required in a waterfall-based organisation without getting stuck between departmental snags or ensnared in the inexorable documentation eddies along the way is an arduous and, if I may be excused the pun, agile undertaking. Sitting out the umpteenth interdepartmental project sign-off meeting, a Scrum practitioner could be forgiven for thinking that the waterfall manifesto, if there was such a thing, would value:</p> <p>•&#160;&#160;&#160; Processes and tools over individuals and interactions. <br />•&#160;&#160;&#160; Comprehensive documentation over working software. <br />•&#160;&#160;&#160; Contract negotiation over customer collaboration. <br />•&#160;&#160;&#160; Following a plan over responding to change.</p> <p>In this clash of cultures, conflicts inevitably arise, yet if my experience in a couple of large (over 4,000 employees) waterfall-based companies is anything to go by, the two can be made to fit together. Somehow.</p> <p>First up. Work around the keepers of the waterfall manifesto by negotiating a change to the contents of the waterfall deliverables to make them more Scrum-like. Second. Alter the Scrum artefacts and definitions to fit with the waterfall world negotiated above. Finally, as a last resort when nothing else is possible, create all the required waterfall process documentation and deliverables, while running projects internally using Scrum. Successfully negotiating the waterfall will involve some combination of all three.</p> <p><a href="http://www.scrumalliance.org/articles/189-negotiating-scrum-through-a-waterfall">Continue reading this article</a>.</p> <div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/3727840331398241770-2101447117974216629?l=blog.scrumedge.com' alt='' /></div>2011-06-09T01:51:59.599-07:00http://blog.scrumedge.com/2011/05/have-initial-conversation-to-start.htmlStakeholdersScrumMastersProduct OwnerTeam MembersTipsnoreply@blogger.com (amoeen)Thu, 09 Jun 2011 01:49:41 PDTtag:blogger.com,1999:blog-3727840331398241770.post-5722673257816726142<p><strong>By </strong><strong>Rahul Sawhney</strong><strong> and Prashant Patel</strong></p> <p>The Baker Hughes Product Development Lifecycle starts with discovery and inception phases. The delivery teams start engaging with the customers during the inception stage. By the end of inception, business requirements are understood at a high level and stakeholders from different teams who will be involved in the project are identified. This is when discussions are held for selecting the appropriate solution delivery methodology.</p> <p>The choice of methodology impacts how the different stakeholders engage with the project. We have seen that in order to improve the chances of success for any project, the solution delivery methodology and the level of commitment needed should be understood upfront by all stakeholders. To that end, it is important that there is representation from multiple stakeholders, including but not limited to business, development, testing, agile coach, project management and resource management.</p> <p>The stakeholders should be aware of the agile methodology and scrum framework for having this conversation. It is beneficial if they understand the rigor agile brings with respect to solution delivery and how it is different from waterfall.</p> <p><a href="http://www.scrumalliance.org/articles/188-have-an-initial-conversation-to-start-an-agile-project">Continue reading this article</a>.</p> <div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/3727840331398241770-5722673257816726142?l=blog.scrumedge.com' alt='' /></div>2011-06-09T01:49:41.869-07:00http://blog.scrumedge.com/2011/06/scrum-team-puzzle-of-people-how-one-csp.htmlTeam MembersTipsnoreply@blogger.com (amoeen)Thu, 09 Jun 2011 01:47:56 PDTtag:blogger.com,1999:blog-3727840331398241770.post-3223372908012695867<p><strong>By Knut Kvarme</strong></p> <p>By definition a team comprises a group of people linked in a common purpose.</p> <p>It is my experience when I get involved in discussions regarding a new project, it soon becomes a conversation about the team and who you want to group together in order to deliver within the scope defined in the project assignment.</p> <p>After several years with the cross-functional team mantra at mind, I no longer think about my new team in terms of who (people). I rather think of a range of skills that I need in my team. After staffing my team I usally find that not all the skills on my list have been covered. And that’s perfectly fine! <br />Getting the team started and having an inspect and adapt approach in regards to the team coalition is my preferred approach. Sometimes the team steps up and gains the required skills. In those cases no further staffing is necessary.</p> <p>Other times my initial list of required skills might have been wrong, and we complete the team with adding people with other skills that I thought was needed. The big advantage of this inspect and adapt staffing approach is that the gained knowledge about the tasks in hand and the observation and understanding of the team, provides the answers on how to complete the staffing of the scrum team. <br />So, we have a complete team with the required skills. What now?</p> <p><a href="http://www.scrumalliance.org/articles/187-the-scrum-team-a-puzzle-of-people">Continue reading this article</a>.</p> <div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/3727840331398241770-3223372908012695867?l=blog.scrumedge.com' alt='' /></div>2011-06-09T01:47:56.871-07:00http://blog.scrumedge.com/2011/05/beware-of-meltdown-csp-shares-her.htmlScrumMastersTeam MembersTipsnoreply@blogger.com (amoeen)Tue, 31 May 2011 00:48:02 PDTtag:blogger.com,1999:blog-3727840331398241770.post-4317391220097840072<p><strong>By Carrie Schonhoff</strong></p> <p>It happens when you least expect it. At some point when a Scrum team is just forming (despite training, agreeing on team rules, and doing some team building), most teams experience a meltdown. The good news is that once the meltdown has passed, these same teams really start to understand the Scrum framework.&#160; </p> <p><strong>From Fear to Trust</strong></p> <p>This phenomenon is not unique to Scrum. I think it happens to all of us when faced with a change that we are not prepared for. I remember when my company changed its health insurance coverage and doubled the premium. I had a meltdown!&#160; I started thinking, “How could this happen?” “I had no idea!” “Why do we have to pay that much?” Once I talked to a couple of people and commiserated with them, I began to accept the fact that I had no choice and this was the way it was going to be from now on. I moved on. After I got over the initial shock, the changes from Human Resources didn’t seem as harsh – I understood that changes to benefits were a given.</p> <p>This is how it is with Scrum. We often react defensively as a kneejerk reaction to the changes Scrum brings. It challenges the way we’ve thought about not only projects, but how we have worked in the past as well. We're forced to confront the big picture we’ve been sheltered from, yet we find it hard to see it clearly. We aren't sure how to problem-solve. And now that no one is feeding us our tasks, we are supposed to think of what to do on our own. It can be overwhelming.&#160; </p> <p> <p><a href="http://www.scrumalliance.org/articles/185-beware-of-the-meltdown" target="_blank">Continue reading this article</a>.</p></p> <div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/3727840331398241770-4317391220097840072?l=blog.scrumedge.com' alt='' /></div>2011-05-31T00:48:02.365-07:00http://blog.scrumedge.com/2011/05/owning-agile-product-one-cspo.htmlProduct BacklogProduct OwnerTeam MembersTipsRelease Planningnoreply@blogger.com (amoeen)Tue, 31 May 2011 00:50:04 PDTtag:blogger.com,1999:blog-3727840331398241770.post-9026055585663357920<p><strong>By Edward Wehr</strong></p> <p>Being a product owner and having responsibility for a product's development using agile methods can be a bit overwhelming. Creating any product can be challenge. With a product being developed at the speed of agility, these challenges increase. Nothing is more frightening than feeling out of control while going at a high rate of speed. Let me reassure you, though, that it does get better. The first time you drive down that agile highway (even if you aren't yet going fast enough), it's scary. But with practice and a good understanding of what to watch for, driving an agile project becomes easier.</p> <p>Because training and certification for product owners is fairly new, I've included some wisdom I've gained from my time on the agile road, which includes guiding four different teams over the past several years.</p> <p><u>Priorities Are Priority One.</u></p> <p>What teams need most is a product owner who is able to prioritize the product backlog. This includes adjusting priority based on new information and juggling the team's needs for work against customer features. A product owner must understand and be willing to have the critical conversations with team members regarding stories (work) that are not direct customer features, yet will develop an architecture that will enable the team to achieve more work (higher velocity) in the future. Balancing all of these competing stories, and the emerging importance and changing priorities that come with them, is a constant struggle.</p> <p> <p><a href="http://www.scrumalliance.org/articles/181-owning-an-agile-product" target="_blank">Continue reading this article</a>.</p></p> <div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/3727840331398241770-9026055585663357920?l=blog.scrumedge.com' alt='' /></div>2011-05-31T00:50:04.594-07:00http://blog.scrumedge.com/2011/05/quest-for-high-performance-how-one-csp.htmlTeam MembersTipsnoreply@blogger.com (amoeen)Tue, 31 May 2011 00:51:17 PDTtag:blogger.com,1999:blog-3727840331398241770.post-4714570267308783331<p><strong>By Tom Reynolds</strong></p> <p>Over recent months I have been working with Lyssa Adkins to improve my coaching skills. One of our areas of focus has been team start-up and our expectation that we have for our teams to become high performing. In our work together, Lyssa shared some team start-up exercises to use with new teams. I had an opportunity to put some of these ideas into practice recently and want to share that experience with the Scrum community.</p> <p>Team start ups cover three areas:</p> <ul> <li>The process </li> <li>The team and individuals </li> <li>The project </li> </ul> <p>This article will focus on the work I did with the process. </p> <p>Starting a team off on the right foot is an essential part of building solid foundations for the team.&#160; Don’t skip this step. It’s true that start-up exercises take some effort and thought to prepare; however, the work that is put in at the start will pay dividends further down the line.</p> <p><a href="http://www.scrumalliance.org/articles/184-the-quest-for-high-performance" target="_blank">Continue reading this article</a>.</p> <div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/3727840331398241770-4714570267308783331?l=blog.scrumedge.com' alt='' /></div>2011-05-31T00:51:17.459-07:00http://blog.scrumedge.com/2011/05/my-journey-as-coach-how-i-came-to-be.htmlTipsnoreply@blogger.com (amoeen)Tue, 31 May 2011 00:53:07 PDTtag:blogger.com,1999:blog-3727840331398241770.post-2007260298590564422<p><strong>By Skip Angel</strong></p> <p>Helping others. That’s been my purpose in life at even an early age. When I saw somebody in need, I was there to help. When a fellow student didn’t understand an assignment or how to apply something new that they learned, I was usually there helping them figure it out. As a developer starting out my career, I often paired with other developers and worked through solutions, well before agile came into being. As a manager, the chance to mentor others and improve processes to make life easier for others was the parts of the job I enjoyed the most. I guess you could say I was destined to become a coach, it seemed to be part of my DNA.&#160; </p> <p>After learning and applying Scrum to an organization where I was the Chief Technology Officer, I realized that I needed to help other organizations as an external coach. Some thought I was crazy, giving up a key position in a stable company in very unstable times. Though there have been risks, the rewards that have come with coaching far outweigh them. I have been involved in both small and large organizations, with various size teams across many locations throughout the world. There is no better thrill than when a person comes up to me and says, “I now know what you have been talking to us about and I get it.” My goal for every company is to reduce the pain of delivering software and bring the fun back so people enjoy their jobs. My greatest joy is when my coaching makes a difference to the operations and bottom line of the business. It is these situations that drive me towards continual growth and improvement in my role. </p> <p><a href="http://www.scrumalliance.org/articles/182-my-journey-as-a-coach" target="_blank">Continue reading this article</a></p> <div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/3727840331398241770-2007260298590564422?l=blog.scrumedge.com' alt='' /></div>2011-05-31T00:53:07.065-07:00http://blog.scrumedge.com/2011/05/going-from-candidate-to-certified-scrum.htmlTipsnoreply@blogger.com (amoeen)Tue, 31 May 2011 00:54:02 PDTtag:blogger.com,1999:blog-3727840331398241770.post-5207130507521092357<p><strong>By Michael Vizdos</strong></p> <p>So you want to be a Certified Scrum Trainer. And to do that, you are entering into the candidate review process. Or maybe you’re just curious as to what it takes to earn the Certified Scrum Trainer designation. Wherever you are on your agile journey, I wanted to take a moment to give you my two cents on the new candidate review process from the CST perspective. We’ll talk about what the process is, what I’ve learned so far, and what it means (and doesn’t mean) for the Scrum community as a whole.</p> <p><strong>The Process Itself</strong></p> <p>First, please remember that certifications from the Scrum Alliance, whatever they are (CSM, CSPO, CSP, CSC, or CST), are really just the beginning of a journey for people who receive them.&#160; I received my initial CSM in 2004 with Ken Schwaber, and at the end of 2006 was designated as a CST (also granted by Ken Schwaber). The process has gone through many iterations over the years. While I have watched this happening, I have learned one thing -- the process will continue to evolve.</p> <p>It must. Over the past six months, the Scrum Alliance has been trying some new techniques for a person to become Certified Scrum Trainer (CST).&#160; The current process, called &quot;V8&quot;, is located at http://bit.ly/simple-CST-process-v8. Today, as long as you are a Certified Scrum Professional (CSP) you can follow the five-step process and apply to become a CST. The first part of this process requires the CST candidate to register a statement of intent and have two people from the current CST community vouch for their integrity and act as their champions through this process.</p> <p><a href="http://www.scrumalliance.org/articles/183-going-from-candidate-to-certified-scrum-trainer" target="_blank">Continue reading this article</a>.</p> <div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/3727840331398241770-5207130507521092357?l=blog.scrumedge.com' alt='' /></div>2011-05-31T00:54:02.182-07:00http://blog.scrumedge.com/2011/05/adopt-with-care-one-csm-8-step-approach.htmlTeam MembersTipsnoreply@blogger.com (amoeen)Tue, 31 May 2011 00:55:17 PDTtag:blogger.com,1999:blog-3727840331398241770.post-8793981588954790216<p><strong>By Prashant Pund</strong></p> <p>Do any of these statements sound familiar?</p> <p>“Sure, we're using agile methods. I mean, we aren't entirely sure, but we think we're agile.” <br />“Well, the team conducts daily scrums, so they must be agile.” <br />“I have been tense since this guy introduced Scrum. Every morning I have to give a status report. It’s really taxing.” <br />“This fellow read something on the Internet about Scrum and said, let’s start Scrum tomorrow. I'm not worried. It's just another fad to ride out.” <br />“I heard there is a change in our process. The Process Group person is here to explain the new process, something called Scrum.”</p> <p>If so, your organization likely is suffering from Scrum Mis-adoption Syndrome (SMS). SMS causes disinterest, failures to deliver, and profound distrust. The best way to treat it? Prevent it from happening in the first place.</p> <p>A successful Scrum adoption requires a profound transformation of the organization. This change will be felt at the team level, yes, but will ultimately affect all layers of the organization. This then begs the question, How can I, being at the level of PM/Lead, bring in such a transformation? Shouldn’t it come from the top? The answer is both Yes and No. Yes, because indeed the transformation needs to have buy-in and support from the top. No, because a top-down approach is not sufficient. As Mike Cohn puts it, “Change is not top-bottom <em>or</em> (emphasis added) bottom-up; it’s both.&quot; In view of this, here is the approach I suggest to those who are trying to transition to an agile methodology such as Scrum.</p> <p><a href="http://www.scrumalliance.org/articles/179-adopt-with-care" target="_blank">Continue reading this article</a></p> <p><a href="http://scrumalliance.org/" target="_blank"></a></p> <div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/3727840331398241770-8793981588954790216?l=blog.scrumedge.com' alt='' /></div>2011-05-31T00:55:17.076-07:00http://blog.scrumedge.com/2011/05/from-meager-beginnings-to-masterful.htmlStakeholdersScrumMastersProduct BacklogTeam MembersTipsnoreply@blogger.com (amoeen)Tue, 31 May 2011 00:56:48 PDTtag:blogger.com,1999:blog-3727840331398241770.post-6763593447302441717<p><strong>By Maria Matarelli</strong></p> <p>I’ve used Scrum on many software development and IT projects.&#160; In addition to the projects I was working on, I received a request to work on a role-advisory team tasked with analyzing the effectiveness of a specialized project role.&#160; This new team was pulled together with minimal allocations and replaced a full-time team that had just been disassembled due to budget cuts.&#160; Given the constraints and uniqueness of the project, we decided to use Scrum for our approach.&#160; It worked—flawlessly.</p> <p><u>Demanding Circumstances</u></p> <p>The going was uphill from the start.&#160; We were a team of ten, allocated to contribute only 20 hours per person over the entire calendar year.&#160; The team was just told, “Go.”&#160; Success was undefined and the scope was unclear.&#160; With a meager budget and minimal direction, we had to guide role development, training, knowledge sharing, and create a solution to provide overall direction to support more than 150 people.&#160; The only thing we knew for certain was that the requirements were bound to change as work progressed.</p> <p>As we discussed our options, it became more and more apparent Scrum was the right approach.&#160; The limited ingredients and project constraints were the perfect recipe for a self-directed team.&#160; Though we could have easily made the business case for additional funding, we were told from the beginning that “additional funding is not possible.”&#160; Any solutions we found would have to be found within the team itself.&#160; Frequent, incremental deliveries would help bring clarity to the project vision.&#160; Though only few of us had used Scrum outside of IT (and most of the team had never used Scrum at all) we felt it was the perfect solution for the constraints facing our team, constraints that probably sound familiar to many teams out there. </p> <p><a href="http://www.scrumalliance.org/articles/178-from-meager-beginnings-to-masterful-ends" target="_blank">Continue reading this article.</a></p> <div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/3727840331398241770-6763593447302441717?l=blog.scrumedge.com' alt='' /></div>2011-05-31T00:56:48.411-07:00http://blog.scrumedge.com/2011/05/are-we-headed-to-abilene-how-abilene.htmlTeam MembersTipsnoreply@blogger.com (amoeen)Tue, 31 May 2011 00:58:18 PDTtag:blogger.com,1999:blog-3727840331398241770.post-3931492233424735883<p><strong>By Badri N Srinivasan</strong></p> <p>Collaboration is an important aspect of any complex activity. On complex projects, a single individual cannot guarantee successful customer delivery—one that meets schedule, quality, cost, and other parameters. It takes a cohesive team.</p> <p>Scrum promotes these cohesive, self-organizing teams. Scrum teams are tasked with finding the most optimal way to accomplish the work. To do this, they make decisions ranging from how best to meet goals to who should work on which tasks. Reaching group consensus can be difficult. Some opinions are more dominant than others; some voices more hesitant to speak out. Even in agreement, true consensus might not exist. One manifestation of this is the Abilene Paradox.</p> <p><strong>Abilene Paradox Explained</strong></p> <p>The Abilene Paradox happens when a group of people collectively decide on a course of action that is counter to the preferences of any of the individuals in the group. This occurs because each member mistakenly believes that his own preferences are a contradiction to the group and, therefore, does not raise objections. When this happens, team members, in an effort not to &quot;rock the boat,&quot; don’t voice their thoughts, desires, or intentions.</p> <p><a href="http://www.scrumalliance.org/articles/177-are-we-headed-to-abilene" target="_blank">Continue reading this article.</a></p> <div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/3727840331398241770-3931492233424735883?l=blog.scrumedge.com' alt='' /></div>2011-05-31T00:58:18.465-07:00http://blog.scrumedge.com/2011/05/go-with-workflow-focus-on-process.htmlScrumMastersProduct BacklogProduct OwnerTeam MembersTipsnoreply@blogger.com (amoeen)Tue, 31 May 2011 00:59:19 PDTtag:blogger.com,1999:blog-3727840331398241770.post-7062403174704779015<p><strong>By Henri Stegehuis</strong></p> <p>I love my work. Implementing Scrum is fantastic. Every company I work with has different processes and cultures. Coaching teams in this drastic new approach we call Scrum is always fun (afterwards). Working with people, breaking traditional patterns in common sense, creating a physical/visible presence, and fostering honest communication is a roller-coaster experience. Every team is unique, every time surprising me with interesting reactions and sometimes unexpected results.</p> <p>In the past, some of these unexpected results have sprung from my attempts to explain the concept of a product backlog item (PBI). For teams raised in traditional development, the ins and outs of product backlog items can be difficult to grasp. When I talked with these teams about PBIs, I made the mistake of going into too much detail too early. I would start with the definition, explaining that a PBI is &quot;up to half of an A4 page describing a requested feature from a market point of view.&quot; This, while a correct description, opened the floodgates for the skeptics and perfectionists within the team, who asserted that there was no way they could write a complete product backlog item in that amount of space. We would get off track, and it would take me some time before I could refocus the team.</p> <p><a href="http://www.scrumalliance.org/articles/176-go-with-the-workflow" target="_blank">Continue reading this article.</a></p> <div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/3727840331398241770-7062403174704779015?l=blog.scrumedge.com' alt='' /></div>2011-05-31T00:59:19.262-07:00http://blog.scrumedge.com/2011/05/managing-myopia-with-release-burndowns.htmlTipsBurndown Chartsnoreply@blogger.com (amoeen)Tue, 31 May 2011 01:00:25 PDTtag:blogger.com,1999:blog-3727840331398241770.post-4693836967763066918<p><strong>By Pat Guariglia</strong></p> <p>The burndown chart is one of the staples of Scrum. Many of us use and love it. Its simplicity and straightforwardness makes it an effective tool for project teams, management, and for the passive observer. A well-displayed burndown chart is one of the greatest information radiators you can use. From time to time, however, project sponsors, functional managers, and others on the periphery misunderstand its purpose. They can sometimes view a project burndown as a short-sighted tool that fails to provide insight into how the project’s end date is affected when features and tasks are re-prioritized and/or moved out of an iteration to meet the sprint’s burndown target. Stakeholder education certainly mitigates the risk of this misconception, but introducing “whole” project burndown charts, or release burndowns, seals the deal for upper management.</p> <p>The effectiveness of my team’s burndown charts is demonstrated daily. Once I started using burndown charts regularly, I became a better ScrumMaster and communicator, plus my teams became more productive and predictable. I became almost proud of the success of using burndown charts on my projects and felt the need to talk about the charts and use them in presentations to upper management. This served me well and poorly at the same time.</p> <p> <p><a href="http://www.scrumalliance.org/articles/172-managing-myopia-with-release-burndowns" target="_blank">Continue reading this article.</a></p></p> <div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/3727840331398241770-4693836967763066918?l=blog.scrumedge.com' alt='' /></div>2011-05-31T01:00:25.144-07:00