Posts Tagged ‘Scrum’

Claiming PMI PDUs for Your Scrum Training

August 9th, 2011

As you PMPs know, you need to continue to learn and progress to keep your PMP designation.  The good news is that your CSM and CSPO training probably qualify as PDUs with the PMI.  I say probably because it is the PMI that decides, not me!  ;>)

The process to claim your PDUs is pretty straightforward.

Go in into your PMI profile and go into claim PDUs
Use category 4
Select whatever areas of the PMBOK you think the ScrumMaster training covered – knowledge areas/industries/etc
Put in RippleRock, LLC as the provider

RippleRock address:

RippleRock, LLC
9465 Counselors Row
Suite 200
Indianapolis, IN 46240-6423
Phone – 863-949-4420

You can claim 14 PDUs for a 2 day class.

It will be reviewed by the PMI and approved – usually this happens in a day or two, sometimes immediately.

Tags: , , ,
Posted in Scrum | Comments (0)


March 25th, 2010

LONDON, INDIANAPOLIS, Mar. 26, 2010 – RippleRock recently recruited industry veteran trainer and Agile Coach Rod Claar. Rod is an internationally recognized leader in the area of software development. His special focus is on large teams and projects to increase the velocity of software development through coaching, training, and consulting. He has spent considerable time in the classroom training on Design Patterns, Test Driven Development, Scrum, and Agile Methodologies. Not only does Rod speak to all levels of an organization effectively, he also spans many technologies in the Application Lifecycle Management (ALM) space to take advantage of software tools to increase visibility and productivity of teams. By combining methodologies and tools along with world-class training, Rod is a powerhouse of experience and wisdom. His witty sense of humor and gaming theory is also a pleasure to work with. “Rod’s passion, caliber and experience are a huge asset to our team, really strengthening our hand for our mission of enabling better software. I am absolutely delighted to be working with Rod!” said Founder Colin Bird. The Company along with partner Microsoft® are assisting customers with services ranging from training to technical implementation of best practices to reduce cost and improve quality.


RippleRock formed in 2009 with the mission to assist customers drive dramatic improvements in their software development capability. The Company applies expertise across the full lifecycle; facilitating organizational transformation to enable Agile practices, all the way down to improving engineering practices within the teams.

The team at RippleRock has a strong track record in the Agile space, coming together from various organizations in the industry to bring together a new company unheard of in the Agile consulting space. As a specialist in this area, the Company also offers access to the most experienced Agile coaches, trainers and consultants with a particular mix of skills required to work with people, process, organizations and tools.

RippleRock has bases of operation in the UK and US and travel to Europe and India as part of engagements.

Tags: , ,
Posted in About Rod | Comments (0)

Agile’s Impact on Product Development

December 11th, 2009

Agile and it’s various implementations, including Scrum, while most often discussed in software development circles, can correctly be classified as Product Development methodologies. Most of the time the product being developed has software as a major component, but they are products developed to solve a problem or make a job easier or more efficient. When we think about products in this broader context we can often identify some impacts on product management rooted in the Agile practices and thought process. We need to understand these impacts to be prepared to mitigate them and propel the organization to the next level.

The first and most obvious is the impact of faster release cycles. There are many things that Agile teams do to achieve faster release cycles, but the primary driving reasons are faster return on investment and quicker feedback. In my experience the product management team are often not prepared for the high level of interaction that the Agile team will demand. Even if they had prepared well in traditional terms, the depth of detail that will be required by the Agile team will outpace the product management team and make it harder for them to prepare the vision and business capability plan for the next release. When the development team delivers early with fewer problems and the product managers are not ready to reload the team poor decisions on what to do next often result. Then scrambling to fill the gap the desired feedback can be passed over leading to more bad decisions. The cycle is almost unstoppable without a significant change in product management and market research practices.

The next common goal of an Agile team is continuous shippablity. An organization delivering more reasonable scope, quality higher and a robust base of automated tests, sooner or later someone will ask why we can’t just ship it to meet a new market, for a special customer or to beat the competition. This is like having a 225 m.p.h. car and trying to get it up to speed wearing a blindfold. You might get lucky, but more often you will be off the road very quickly. A few years ago when working at a software company, sales asked us to adapt our product to a different market. The engagement was a total disaster. We did not take time to understand what this new market wanted. Our brains were tuned to our normal market and could not understand the context and the paradigms in place in the new market.

In both of these scenarios what is missing is more information about the customer and how they use the product. Traditional market research can deliver the answers, but it takes a lot of time and generally a lot of money. Some products can support the cost of the market research, but many medium to small organizations cannot afford formal market research. Trying to go to market without having the knowledge of how customer will use the product can sink even the best product.

What is required are techniques to get the market research to make good product planning decisions in pace with the development team. The Agile planning cycles of iteration, release, vision, roadmap and portfolio need to match up with processes that answer the questions about near-term product improvements, product evolution and other markets.

If we could lower the cost of market research and product planning while still delivering valuable and accurate results, we would have a better shot at delivering the best value to our customers as fast as possible. This is the true promise of Agile.

Recently I had the opportunity to attend Luke Hohmann’s Innovation Games® Consultant Master Class in San Ramon, California at the Chevron campus. The class was held in Chevron’s Innovation Space and attended by 20 or so of the smartest Agilests on the planet. This class was aimed at helping this group of world-class consultants understand how Innovation Games® can be used to deliver cost-effective market research for the Agile team.

Luke is a great facilitator and this two days was packed with great concepts and practices. He and his company is on a mission to restore the concept of serious games to business. The idea of serious games was all but destroyed by computer games and online gaming. Serious games are still fun but have a purpose.

Luke told us that “Innovation Games® are serious games that power innovation by enabling you to better understand your customers”.

With the knowledge and skills gained from this class we will immediately start offering a new course “Innovation Games® for Agile Teams”. This course will contain some lecture but will be predominantly discussion and hands-on exercises to help you understand how Innovation Games® can be used by Agile organizations to help provide the right vision and feature set to the development team and in turn your customers.

Agile teams who employ Innovation Games® find some of the dull and repetitive practices of Agile comes alive in a fun and engaging way. Scenarios might include:

  • Using Product Box to identify customer requirements.
  • Using Speed Boat to improve retrospectives.
  • Using Buy A Future to prioritize the product backlog.
  • Planning a project using Remember the Future.
  • Clarify the release plan with Prune the Product Tree.
  • Understanding how your product is used through Me and My Shadow and Start Your Day.

Each student will receive a copy of Luke’s book Innovation Games: Creating Breakthrough Products Through Collaborative Play.

Course Outline

  • Overview of Innovation Games®
  • Customer Collaboration
  • Continuous Planning
  • Portfolio Prioritization
  • Product Backlog Prioritization
  • Strategic Planning
  • Release Planning
  • Agile Retrospectives


All members of an Agile team are invited to join us with a focus on product planning and management.


Standard – 1 day.

Extended – 2 day with more game played by participants.


The course is available for on-site delivery and will be offered as a public course.

For more details see or call 530-SCRUM-42.

Tags: , , ,
Posted in Misc | Comments (0)

Scrum is a flexible process!

June 10th, 2009

You might be thinking that my title would get a response from Homer Simpson (Doh!), but too many teams try to do Scrum or Agile in a rigid and prescriptive way.  There are a couple of main reasons that I see this. The first is the desire for new teams to “do” Scrum right when they are new to Scrum.  I resemble that feeling!  On my first Scrum project (several years ago) I defended the process against change rather than being open to process change.  Oh well, we all have to learn somehow!

Change for the sake of change is not a good thing.  Any process change should be driven from retrospective discussions and the desire to reduce or eliminate impediments.  What is holding your team and product back?  What was the root cause of the problems you encountered?  The team should discuss these issues and pick one or two top issues and agree to work on them and try to find solutions to them.  If that means changing Scrum, then CHANGE SCRUM!

The other major cause I see of process rigidity is on teams and projects that are large and complex enough to require an electronic system for tracking work items, making distributed team communication easy to find and use and reporting out status and progress.  There are a lot of tools out there and any tool, used to drive the team and project, can strip agility from your organization.  However nearly all teams have some distributed component and we all know that the last simple project was done in 1959!  This means that almost all teams and project need a system to help manage the project.

I’m a white board and sticky type of agilest.   Give me a team room with white boards and a bunch of multicolored stickys and I’m a happy camper!  Why? Because I know that the white board and stickys are NOT the project, the people and the conversations they have with each other are the project and the white boards and stickys are used to drive those conversations and track the work.

However for most teams and most organizations, my agile dream project just does not exist and trying to force it to be is foolishness.  Most organizations are going to need a tool.

What makes a good Scrum / Agile tool?

1) It must not have a fixed process flow.  The team must be able to tweak the process to fit their culture and organization.

2) It must be simple enough to enable not get in the way.  The team must drive the project rather than the tool.

3) It must produce status and progress reports that are customizable and accessible to the business.  Feedback is the process that keeps Scrum / Agile on
track in a world of changing priorities.  Having status and progress reports that truly inform the stakeholders and project sponsors of where the project is drives the prioritization process to meet business needs.

4) The process must have a business value driven approach.  In other words the project management tool must drive business value and make business value delivery clear to the team and stakeholders.  If a tool is a bottom-up project management tool, the team is building the trees at such a high rate of speed that the forest of business value is totally obscured.

How the team uses the tool and how the tool allows the team to focus on delivering business value is the main critical issue.  A tool must be flexible.

This week Daptiv released Daptiv Scrum that can be used in conjunction with their popular Daptiv PPM product.  These tools allow companies to manage and track all their work in one centrally visible source.  This allows the business to see the benefits of an agile process.  After configuring the system to match the process at the organization the team and management can be comfortable knowing that the team is driving the product rather than the tool.  Along with the standard Scrum roles of Product Owner and Scrum Master you can create custom roles to meet your need for engineering leadership, release management, configuration management and other custom role.

One of the biggest advantages of Daptiv Scrum is the ability to easily manage a story driven product backlog.  Priority changes are done via drag and drop right in the product backlog.

Daptiv Scrum also gives you the reporting artifacts you need to manage the scrum process: Sprint Burndown, Release Burndown, Sprint Summary including calculated velocity, Sprint Tracking, and Features by Product Category. They’re all here.

However one of the best advantages is the ease of setup and maintenance.  Built on a web model, Daptiv delivers automatic updates via the web which frees your team from updates and configuration issues.  This ISO 27001 Certified organization provides your team with the security, redundancy, uptime, maintenance and new features so your organization can focus on delivering business value.

For more information about Daptiv Scrum see their web site at <a href=”Daptiv.com”></a> See the press release at <a href=””></a> .

Oh! I almost forgot!  Play the <a href=”” target=”_blank”>Escape from Scrum Island</a> game!

Tags: , , , ,
Posted in Misc | Comments (0)

The Role of the Product Owner

May 28th, 2009

There has been a lot written about the role of the Product Owner in Scrum over the years and it seems to me that in the last month or so the question has received a lot of attention in blogs, twitter and other social media.

teachI don’t think there is a “best practice” answer. Let’s look at what we do know and then see if we can find an answer.

The goal of the Product Owner must be to deliver the right business value. To do this they engage the team(s) to create solutions that deliver the business value. The Product Owner is listening to and evaluating the needs of the stakeholder community. They must have a great business sense and understand their market and customers. They must understand what is technically possible. From all this input they deliver a stream of input to the team about what the priorities are. They are constantly updating this information and evaluating the output of the team to check it for completeness and correctness.

While the team has the same goal of delivering business value, their problem space is much different. In all but trivial domains and projects this requires a team approach. Team building is not about money. Ask Yankees owner George Steinbrenner! Team building is not about technology or computers. Team building is about people. However the problems faced by the team in delivering the solutions is about technology.

The team takes direction (course) from the Product Owner, but the Product Owner cannot work in the engine room of the Scrum ship! It is not that they are not qualified (they may not be) , it is just that their primary role is so important and time consuming they would be neglecting that duty if they did.

The team must take the direction (course) from the Product Owner. Their work demands their complete attention.

We know all this. The real question is how do we best create the communication and feedback that the Product needs so that the business can be successful and thrive? Scrum provides a great starting point. Lean helps us understand the product view and the flow of business value.

The process of planning a product release must include input from the team. Sprint planning is a cooperative process between the Team and the Product Owner.

The daily stand-up is a Team meeting that is core to team building. Scrum tells us that the product management team can listen to this meeting, but it is the Team’s meeting. If I were a Product Owner, I would be at the daily stand-up if at all possible.

The Sprint review and demo are about the Team getting feedback from the Product Owner and anyone interested. If I were on a team I would NEVER go into a Sprint review without knowing what the Product Owner thought of the Sprint output.

The Sprint retrospective is a Team meeting. This meeting is primarily focused on team building and process refinement. This needs to be a private Team meeting.

Can the Product Owner be a benefit to the Team in the daily process of developing the solution? That depends. How much time do they have? How well do they understand the technology? How well do they work within the Team? No one can know the answers to these questions without observing the Product Owner and the Team.

Will the Product Owner be a helpful, accepted and valuable member of the Team? That depends.

Can the Product Owner deliver the stream of information and decisions to the team with a high level of accuracy? That depends.

With all these unknowns, I don’t believe that anyone can say how any particular Product Owner and Team will be able to work together best without some first-hand knowledge. When I’m acting as the Agile Coach, I suggest that the Product Owner start out somewhat restrained in their interaction with the Team while the Team figures out how to be a team. I’m not saying that they should not be available and should not speak up when there is an issue. I coach them to not inject themselves into the Team. As the Team matures and as the Product Owner gets accustomed to their new role this may change, but any change that I recommend will be to improve specific process and communication issues.

The Scrum Master, if they have the experience, can and should help with this. However new organizations would do well to get an experienced Agile Coach to help with this and the other issues of being more Agile and delivering more business value.

Tags: ,
Posted in Misc | Comments (0)

Technical Debt From the Originatior

May 14th, 2009

Ward Cunningham coined the term “Technical Debt”. This concept is so important for enterprise sustainability. He has published a great video on the topic. All Agile Coaches should keep this handy!

Tags: ,
Posted in Misc | Comments (0)

Business Value Must Drive!

April 21st, 2009

I follow a couple of Scrum and Agile related user groups.  Mainly I’m looking for the problems that people are asking about and if I have something unique to offer,  I will respond. 

A couple of days ago an admited first time poster to one of the Scrum groups posted a question that is pretty common.  They are new to Scrum and had done very well in the first 3 months and had seen a significan improvment in productivity.

They were working from a single product backlog with 6 developers on the team.  Then they got two additional “side projects” that have to be completed in 10 weeks.  He asks how to allocate the team and organize the sprints.  Like I said, nothing new here!

He askes if he should break the team up into three small teams or combine the three backlogs and work on the items through the priorities of the combined backlog.

As I read this, I thought to myself  “this guy is thinking about the right stuff”.  Depending on the relative priority between the three projects either of his suggestions would have been fine and he notes that to split up the working team would not be a good thing.  His instincts were very good.

Then this morning I read a reply from one of the leaders in the community.  I won’t flame that person here, because I like and respect them, but I have to admit, I think they are leading this poor guy astray!

Their suggestion was to keep the teams together and rotate though the projects on an iteration by iteration cycle.  Like this:

Iteration 1: project 1
Iteration 2: project 2
Iteration 3: project 3
Iteration 4: project 1
Iteration 5: project 2

They went on to say that he could not finish all three projects if they take more than a couple of iterations each, but at least they would know NOW that nothing will be delivered in 10 weeks.

This is so wrong!  What is the priority between the projects?  There MUST be one that is most important.  Working on three projects at once probably means three late projects and no business value is delivered until much later.

Pick the most important project and deliver the smallest set of stories that deliver business value.  Then go on to the next and then the next.

The delivery of business value early is what should drive the prioritization of work in any team.  No team ever has enough people to do everything that the business can think of.  Rather than delaying everything, concentrate on what is most important and deliver that as quickly as you can. 

Portfolio management  should be about business value delivery, not spreading the work out and keeping stakeholders at bay.

<a href=”” target=”_blank”></a>

Tags: , , ,
Posted in Misc | Comments (0)

SEO Powered by Platinum SEO from Techblissonline