Estimation and Meeting Sprint Commitments

In this episode of SoundNotes, Dave Prior and Derek Huether respond to a couple questions from students who have taken a LeadingAgile CSM and/or CSPO class over the past couple months. Here are the questions they will address in this short video podcast:

Question 1:

My team seems to have a problem with estimating and understanding the estimating concepts. The team members are accustomed to traditional waterfall projects and estimating everything in units of time. How can I help them understand estimating, but continue to complete the sprints with no PBIs (Product Backlog Items) rolling over to the next sprint?

Question 2:

I have a team lead who is skeptical of scrum, especially metrics related to the process. He doesn’t think carryover matters from sprint to sprint as long as we’re “creating value” and getting the program priorities completed. Any advice on how to convince him that metrics can be a tool for good, and that the sanctity of the sprint commitment matters?

Failure Pattern in Scrum

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. To clarify, on a delivery team level, I see the Scrum Framework as a solid method for managing product development. But what about Scrum in the context of the entire delivery organization?  Using both The Three Things You Need To Know To Transform Any Sized Organization and my model, I look at Scrum in a broader context. I can see a potential failure pattern.

Scrum failure pattern

What is the failure pattern I see in Scrum?

My model will segment any system into 5 areas: Clarity, Commitment, Ritual, Progress, and Habit. The gaps that I will note below are those things not mentioned in the Scrum Guide.

Gap 1: Clarity

What does the structure of the organization look like (Portfolio, Program, Product) above the Scrum Team? We need a shared understanding.  What does the governance of the organization look like (Budget, Dependencies, Risks, Quality,…) above the Scrum Team? What are necessary metrics and tools of the organization above the Scrum Team?  Some organizations are very large and heavily distributed.  How will you measure the health of the entire delivery system?

Gap 2: Commitment

In Mike's 3-things talk, he calls this accountability. Given the broad applicability of my model, I prefer to call it commitment.  Commitment can be any resource. So, what money and time may be required for Scrum training of all leadership and Scrum teams within an enterprise?  What money and time may be required for procurement, installation, and training of tooling used to manage and report on the health of the delivery system? Lastly, we need agreement from the Leadership team to follow the Scrum Framework (or more particularly respect that the Scrum team is following it).

Gap 3: Progress

As I noted in my post on Productivity Patterns, if you lack progress, you lose momentum. If you lose momentum (or should I be so bold to say velocity or throughput), you will lose commitment to the system. Those who are funding the efforts (those outside the Scrum team) need to know progress is being made in a way that is important to them.  What is the Time to Value?  Is the Scrum team predictable on a release level (Release Burndown/Burnup chart)?  Are we even building the right things? (Product Fit) Are we building things right? (Quality)

Gap 4: Rituals

Rituals can be event or meetings, as part of your system of delivery. First, let's start with product vision.  Scrum teams have a horizon of a few weeks (the sprint).  Vision is viewed or realized in months, quarters, or years. Read the Scrum Guide and you won't see Vision mentioned once.  Also absent from the the Scrum Guide is the notion of portfolio or release planning.  Unless you have a delivery capability that allows you to release at the end of every sprint, I can't champion release planning enough.  In addition to that, good portfolio planning ensures we have a balanced system of delivery and ensures we have capacity to make commitments against a roadmap.

Gap 5: Habit

Given the rituals I outlined above, you should make it a habit to have periodic Vision Reviews, regularly scheduled Portfolio Planning/Reviews, and ensure you're consistently doing your Release Planning.

Conclusion

I'm not suggesting you abandon Scrum. But after you look at the highlighted gaps I listed above, in a system of delivery larger than a single Scrum team, you should consider more than what is in the Scrum Guide.

10 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 

5 Qualities of a Good ScrumMaster

First, a Servant Leader is an empathetic listener and healer. This self-aware steward is committed to the growth of people. Second, a Coach can coach the other team members on how to use Scrum in the most effective manner.  Third, the Framework Champion is an expert on how Scrum works and how to apply it. Next, the Problem Solver protects the team from organizational disruptions or internal distractions or helps remove them.  Last, the Facilitator is a neutral participant who helps a group of people understand their common objectives and assists them to achieve these objectives.

5 Qualities of a Bad ScrumMaster

First, the Boss has the ability to hire and fire others.  Second, the Taskmaster myopically focuses on assigning and tracking progress against tasks. Third, a Product Manager is responsible for managing schedule, budget, and scope of the product. Next, if you are Apathetic you lack interest in or concern about emotional, social, or spiritual well being of others.  Last, the Performance Reviewer is responsible for documenting and evaluating job performance.

Summary

While you may call yourself a ScrumMaster, understand that people who understand Scrum are going to have expectations.  If you have any of the bad qualities that I listed above and in the infographic, maybe you should find someone else to do the job.

---

This was originally published on LeadingAgile Field Notes with permission of Derek Huether. See the original article here.

---

Scrum Alliance & Star Trek

Max 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 ChipChick.com

Refine Your Process If You Must Deviate From It

As 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.

Regards,

Derek

Management Team Wants Versus Needs

Maslow

Mike 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

Today 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:  http://ezinearticles.com/?expert=John_Reiling

Starting Is Easy; Finishing Is Hard

I once saw (via video podcast) a wise man (Jason Calacanis) say "starting is easy; finishing is hard." When he said that, it was a moment of absolute clarity for me.  I'm not saying he verbalized the meaning of life.  He did state, however, what I've often conceptualized but was never able to verbalize.

What Jason stated in 6 words is what I've seen many colleagues struggle with.  Who doesn't have projects and tasks to complete and deadlines to meet?   I've tried multitasking, thinking it would make me more efficient.  I've tried using a productivity pyramid.   All I did was start more tasks, not finish more.  That's the key right there.  It doesn't matter how many things you start if you never finish them.

The solution to my past problems has been the use of kanbans, referring to them as information radiators.  These information radiators were large billboards strategically placed around the office so anyone could passively see the status of the current project.  You could see what the highest priority was, what was currently being completed, and what was being delayed.

I believe the key to those successes was in the ability to visualize our work.  Everyone knew exactly what they needed to complete and everyone else knew if it was getting done.  People were not allowed to go on to ancillary activities until their assigned tasks were completed.  Another important facet of the kanban, we limited our work-in-progress.  This forced-focus on limited tasks and constant feedback loop is very powerful and very productive.

If you would like to read my complete guest post at the Personal Kanban website, on how I visualize my work and FINISH it (don't forget the comments), just follow the [link].