Failure Pattern in Scrum

No Comments

I recently spoke at a corporate community of practice event.  My session presented a useful model to identify indicators within a system to predict its failure. First, we started by applying the model to everyday systems everyone could relate to.  Next, I asked the attendees to map a system of their own. As I walked them through my model step by step, I used Scrum as my example system. Upon completion of the worksheet (see my completed sheet below), attendees were able to see if there were any “gaps” in their systems. The gaps provided an indication that a respective system was at risk of failure. Read More…

Categories: Agile, Productivity, Scrum Tags: Tags: ,

10 ScrumMaster Qualities

No Comments
scrummaster qualities

A ScrumMaster is one of the three key roles of the Scrum Framework. Ken Schwaber and Jeff Sutherland conceived the Scrum process in the early 90’s. With so many years having passed, you’d think organizations would better understand good ScrumMaster qualities. More noteworthy, they should know qualities of a bad ScrumMaster.

Because of this, I created a simple infographic to focus on both good and bad qualities of ScrumMasters.  I’ve noticed, as organizations begin to scale, roles and responsibilities begin to blur. People may be asked to take on ScrumMaster responsibilities.  Do you have the right qualities?

View and download the free infographic:  10 ScrumMaster Qualities  Read More…

Categories: Agile, Scrum

Scrum Alliance & Star Trek

No Comments

Live Long and ProsperMax Keeler tweeted that the new Scrum Alliance director is new to Scrum.  I went over to the Scrum Alliance website and I see they have selected Donna Farmer as the new Managing Director.

Beginning October 1, 2010, Farmer will lead the non-profit organization, working with the staff and Board of Directors to realize the organization’s vision and mission.

Lately, there seems to be some turbulence in the Scrum world, after Tobias Mayer resigned from his SA staff role as creative director and renounced his SA certifications of CSM, CSP, and CST.  He then wrote a scathing blog post on the whole thing.  I’ve also read an email response to his post by the Scrum Alliance, over at the Agile Scout website. The whole situation was really quite disheartening.

I empathize with Tobias and what he went through.  I empathize with the Scrum community, as it evolves and tries to navigate through constant change.

But, let’s go back to what Max tweeted about.  Max sent me a link to the source (if it stops working let me know).  Farmer admits to being new to Scrum.  Even though she is, should it matter?

My analogy is the latest incarnation of Star Trek.  When I heard J.J. Abrams was going to be the Director of the movie, I was shocked.  How could the franchise do this to us!?  Abrams admitted he wasn’t even a fan of Star Trek.  This was blasphemous to hear.  How could anyone but a fan direct a Star Trek movie?

Well, though Abrams wasn’t a fan, he took the franchise in a new direction and made a pretty damn good movie.  I’m not saying Farmer is going to be a savior for the Scrum Alliance but I want to give her the benefit of the doubt.

I will continue to be optimistic about the future of the Scrum Alliance and the Agile Alliance until someone like Ken Schwaber or Alistair Cockburn publish something that counters the very principles they stand for.

So, before we pass judgment on Donna Farmer, let’s all get a extra-large popcorn and see how this plays out.

May the Scrum Alliance live long and prosper.

Graphic from

Refine Your Process If You Must Deviate From It

No Comments

Do you really need documentationAs I mentioned in my post yesterday, Seeing Value From The Customer Perspective, if you think you need to deviate from a documented or understood process, rewrite or refine your process to account for the deviations. Merriam-Webster defines process as a series of actions or operations conducing to an end.  If you are unwilling to modify your process, the deviation is unworthy of being done.

I’ve had a vendor tell me they didn’t need to document their processes because they were agile.  (Notice the lack of an uppercase A in Agile).  Leveraging Agile concepts does not mean a lack of documented process.  IF the customer tells me they see the greatest value in delivering documentation, what is this vendor going to respond with?  Sorry, we won’t deliver value?  If you use Waterfall, you may be used to generating more paper.  You have to consider documentation on a case by case basis.  Some customers have legitimate needs for documentation and other have wants.  Now go back and read that last sentence again.  Needs…Wants…

I personally like to go light on documentation.  What I need and what the customer needs are usually two different things.  That being said, I like to understand the rules (governance) before I start anything.  The Microsoft Visio document I included in my last post was a good example of a high level governance (functional flowchart) document. After completing the flowchart, I then detail each activity in a separate document.  What is the input and output?  Is there a formal deliverable associated with the activity? The idea behind the separate document is you won’t need the flowchart to describe the process.  For those who have successfully navigated a SOX audit, you know what I’m talking about.  But I digress.  The flowchart activities I documented are not groundbreaking.  The process in this case is an Agile Scrum process with a few defined quality assurance decisions points.  You do not need to go into the Nth degree to understand this process.  Identify some touch points where the vendor and customer interface.  Identity some decision points.  That’s it!

I’ve done these flowcharts for several customers.  I’ve created them for both Waterfall and Agile development approaches.  If you’re looking for a free Microsoft Visio template, which you can edit at will, you can download it here. I zipped it to make downloading easier.  If you’re looking for other free templates or worksheets to use on your project or program, you can download them there.

What do you think?  To document or not document.  That is the question. I welcome your comments or feedback.



Management Team Wants Versus Needs

No Comments

maslowMike Cottmeyer of Leading Agile wrote an excellent post, posing a question: Why wouldn’t a management team embrace a set of methodologies so focused on giving them what they need the most?

I took a few minutes to digest the question and then compared it to my prior experiences implementing Agile on a management level.  Though I have seen the desire of a management team to embrace Agile, allowing more value to be delivered, I also saw them take pause and throw up roadblocks. At the moment they believed the top-down command and control structure would be weakened by bottom-up empowered teams, delivering value suddenly didn’t appear to be as important. Though I appreciate the necessity of a management team to provide strategic vision, I believe tactical implementation should be left to those outside the group. The hierarchy of wants, not needs, for the management team differs from the implementation team, if we want to admit it or not.

The key question asked is why wouldn’t a management team embrace a set of methodologies or approaches so focused on giving them what they need the most? My answer is I believe it is because delivering value is NOT necessarily what they WANT, it is what they NEED.

My First Year In A Directive PMO


directive_pmoToday I realized I’ve been supporting and advising a Federal Government PMO for a whole year.  Prior to that, I was the Manager of Software Engineering at an online company that had recently gone public.  I was the sole PMP (Project Management Professional) and  sole Agile Evangelist. Upon my leaving that company, I told my superiors they really needed a PMO if they wanted to offer consistent results, measurable improvements, and increase stakeholder satisfaction.  It was hard at first to shift gears, away from a private profit-driven organization, to Federal governance-driven organization.  At the private company, it was all “being creative” to meet unrealistic goals set by those not versed in best practices.  Since there were no other PMPs, I felt like the lone sheriff in the Wild West.  Now that I’m dealing with the government, I’m surrounded by other PMPs.  There is policy, process, and governance.  Everyone knows their jobs very well.  They know best practices.

So you can differentiate the type of PMO I work in compared to others, I’ve included the 3 basic types below with their definitions.

There are 3 basic types of Project Management Office (PMO) organizations are [1] supportive, [2] controlling, [3] directive.

1. Supportive PMO generally provides support in the form of on-demand expertise, templates, best practices, access the information and expertise on other projects, and the like. This can work in an organization where projects are done successfully in a loosely controlled manner and where additional control is deemed unnecessary. Also, if the objective is to have a sort of ‘clearinghouse’ of project management info across the enterprise to be used freely by PMs, then the Supportive PMO is the right type.

2. Controlling PMO has the desire to “reign in” the activities – processes, procedures, documentation, and more – a controlling PMO can accomplish that. Not only does the organization provide support, but it also REQUIRES that the support be used. Requirements might include adoption of specific methodologies, templates, forms, conformance to governance, and application of other PMO controlled sets of rules. In addition, project offices might need to pass regular reviews by the Controlling PMO, and this may represent a risk factor on the project. This works if a. there is a clear case that compliance with project management organization offerings will bring improvements in the organization and how it executes on projects, and b. the PMO has sufficient executive support to stand behind the controls the PMO puts in place.

3. Directive PMO goes beyond control and actually “takes over” the projects by providing the project management experience AND resources to manage the project. As organizations undertake projects, professional project managers from the PMO are assigned to the projects. This injects a great deal of professionalism into the projects, and, since each of the project managers originates and reports back to the Directive PMO, it guarantees a high level of consistency of practice across all projects. This is effective in larger organizations that often matrix out support in various areas, and where this setup would fit the culture.

Definition Source: