Certified Scrum Coaching Application - Ed Willis PDF Print E-mail
Written by Ed Willis   
Sunday, 19 September 2010 13:32

Below is most of my successful Certified Scrum Coach application - I've removed the employer-specific references and the testimonials from former customers (I haven't obtained their approval to publish them this way).  I'm posting this to the site so you can get a glimpse into the process of attaining this certification.

Certified Scrum Coach (CSC) Application

This application is intended for individuals who are applying for the Scrum Alliance Certified Scrum Coach certification credential. The completed application should represent your Scrum coaching experience, skills and competencies. The information you provide should be quite thorough and therefore, it may take you several hours to complete it. Give yourself plenty of time and review the entire application before entering your responses.

To complete the application, use Microsoft Word to enter your responses into this document. The text entry boxes will expand to contain your full response. Keep your responses clear and concise but make sure you address the entire question or topic. You may reference or include other documents with your application package that present your qualifications.

 

Send questions regarding this application to This e-mail address is being protected from spambots. You need JavaScript enabled to view it .

Submit your completed application package, including two client references to This e-mail address is being protected from spambots. You need JavaScript enabled to view it .

Section 1. Definitions

(a) Scrum Coaching

Scrum coaching is defined as an engagement with one or more organizations/teams during which the coach acts as a mentor or facilitator for those teams to improve their understanding and application of Scrum to reach their stated objectives. The engagement includes one-on-one and team mentoring, process facilitation, organizational development, alignment consultation, and interaction with all levels of leadership within an organization. It may also include mentoring in methods related to the effectiveness of Scrum, principles described in the Agile Manifesto, Lean principles, and Extreme Programming practices.

(b) Client Organization

A client organization is any organization that engages a Scrum Coach to increase its effectiveness through the use of Scrum. This includes the employer of the Scrum Coach working within his or her organization to improve the organization’s effectiveness through Scrum – referred to as an internal Scrum Coach; and clients who contract an external Scrum Coach consultant for specific client engagements to improve organizational effectiveness – referred to as an external Scrum Coach.

Section 2. Applicant Contact Information

Name:  Ed Willis
Company:
Address:
Phone Number:
Fax Number:
Email:  This e-mail address is being protected from spambots. You need JavaScript enabled to view it
Application Date:  March 16, 2010

Section 3. Coaching Service Characteristics

Purpose: To explain the characteristics surrounding where, when and how you provide Scrum coaching. The answers to these questions do not impact your eligibility; rather, they are for informational purposes only.

1. In what spoken languages do you provide Scrum coaching?

I have provided Scrum coaching solely in the English language.

2. In what regions of the world do you provide Scrum coaching?

I have provided Scrum coaching in multiple sites in Canada.

3. What percentage of your work time do you spend performing Scrum coaching for clients? (Refer to the definition in Section 1a.)

My allocation to Scrum coaching has varied considerably over the years – leaving aside brief intervals between customers, I would say it has varied anywhere from 10-20% of my time to 50-75% of my time. Currently I would say that I spend about 30% of my time on Scrum coaching.

4. Do you plan to provide Scrum coaching internally for your employer, externally as a coaching consultant to other organizations, or both?

I already provide Scrum coaching to my employer – I will certainly continue to do so. I would like to explore the possibility of helping organizations beyond my current employer in the future.

5. What is your motivation for becoming a Certified Scrum Coach?

I have been very committed to Scrum at my current employer – becoming a Certified Scrum Coach is partly about my desire to expand my work in Scrum to other organizations and partly about my desire to make clear to my current and future customers the depth of my commitment to Scrum.

Section 4. Prerequisites

Purpose: To provide evidence that you have met the CSC application prerequisites. These include holding a current CSP certification and active contribution on behalf of the Scrum community.

6. What is the date of your Certified Scrum Practitioner (CSP) Certification?

March 12, 2010

7. Describe your contributions to the Scrum community within the past five years by providing information on any of the following topics that apply to you:

a. Participating in Scrum Gatherings, Agile conferences or other Scrum-related events.

Other than the odd visit to the Agile Ottawa meetup, I haven’t been very involved in the public Scrum community. I have been, however, extremely active in the Scrum community within my company. I don’t want to over-state my involvement but I think it’s fair to say I’m a major contributor to the current state of affairs regarding Scrum at my company. The first Scrum projects in the company were internal tools projects that I started, scoped and mentored. One of them delivered a lifecycle workbench tool used to define the lifecycles to be used on projects (along with their specific commitments on a per phase basis) in accordance with our ISO9001 quality management system – the main motivation behind this project, though, was to bring lifecycle tailoring from the conceptual to the real. Our quality system allowed for all sorts of lifecycles but the procedures for doing so were pretty cryptic and hence no one actually used them (well, we did for our first Scrum projects :). The tool we developed in that pioneering Scrum project brought lifecycle selection and tailoring ”to the masses” and the effects were dramatic. Prior to the initial releases of this tool, the only Scrum projects were the ones I was involved with. After it, a steady and increasing number of projects started doing Scrum. Currently the growth curve of agile projects is increasing at an exponential rate. My team not only did tools development though, we also developed Scrum training and process assets and provided coaching services. We leveraged those to first provide Scrum templates and work aids, along with hands on coaching to support teams trying to get started. Eventually the scope of deployment became broad enough that a centralized tool started to make sense. It was my team that worked with stakeholders across the company to select Rally and it was those same people who deployed and supported adoption of it in R&D. Similarly, all the initial Scrum coaches came out of my group – although we’ve since developed a Scrum coaching authorization process that allows for any interested and competent party in the company to join the ranks of Scrum coaches. Lastly it was our team that developed and delivered Scrum training – similar to coaching, we’ve developed an authorization program which lets any qualified employee become a company Scrum trainer. You can see some of the effects of this wider program of coaching, training and tools and process support in the graph "Agile Projects Over Time".Agile Projects Over Time

“Project Central” is the lifecycle workbench tool I mentioned earlier. We’re hoping our Rally deployment will be the next “red x” on the curve above :)

So in sum I think it’s fair to say that I haven’t been very involved outside of my employer but have been central to the Scrum community within it.

b. Serving as an active member of one or more committees or working groups in the Scrum Alliance.

I have only recently become a member of the Scrum Alliance – my focus previously was entirely on the large and growing Scrum community at my company.

c. Publishing a book or article on a Scrum-related topic.

I have published a few articles on varying development topics – including those relevant to Scrum:

Review: "Scaling Lean & Agile Development", by Craig Larman and Bas Vodde on O’Reilly.

Requirements Development Techniques and Agile Projects also on O’Reilly.

This article, The CMMI in 2500 words or less, is the first in an envisioned set of articles relating the CMMI and Scrum and Agile thought.

My other articles on O’Reilly can be found here.

I’ve also co-authored a research paper in data mining here.

d. Making significant contributions to shared Scrum knowledge through participation in an active online venue such as a message board, blog or electronic magazine.

I think these two are the best examples I have to share:

Review: "Scaling Lean & Agile Development", by Craig Larman and Bas Vodde

Requirements Development Techniques and Agile Projects

e. Serving as a Scrum mentor for others in the Scrum community outside of your organization.

This, in fairness, I haven’t done. My focus has been almost exclusively within the large and growing community in my company.

Section 5. Coaching Experience

Purpose: To illustrate your experience as a coach. You must have experience as a Scrum coach with at least 1,500 hours of coaching over the previous five years to qualify for the CSC credential. Respond to each of the following questions with clear and concise personal examples.

8. How long have you been serving as a full- or part-time Scrum coach?

My experiences with coaching Scrum start in June 2006. I have been involved as a part-time Scrum coach with the odd short break every since. So nearly four years.

9. Have you received any formal training in business or professional coaching? If so, provide details. List any other coaches or trainers that you have worked with as a mentor, mentee or colleague. Briefly describe the nature of those collaborations.

I have no formal training in coaching. I have worked with a plethora of other trainers and coaches though:

Mentors:

Mentors One and Two were probably the biggest mentors I’ve had. Neither was versant in Scrum or agile per se but were rather trainers and coaches for things like ISO9001, the CMMI, engineering lifecycles, technical review and Joint Application Development. A lot of my style comes from watching them though – they were both very engaging speakers who kept training sessions lively and participatory. In hands on coaching, they were both very customer-focused rather than practice- or theory-focused and so normally would teach a method but also end up solving problems for their customer along the way. I’ve tried hard to do the same in my work.

Mentor Three is a member of our corporate Software Engineering Training group – they were a great partner to us in developing the Scrum training. We knew Scrum but they knew training, adult learning and instructional design. It was an awesome partnership for all of us. Mentor Three reviewed my first Scrum training sessions and provided detailed comments to help improve my performance. She also asked that I (and all the other Scrum trainers) read “Crash and Learn” by Jim Smith, which I found to be a very practical and useful aid in improving my performance as a trainer. I pull out a few tips to focus on before each Scrum training offering I teach.

Colleagues:

I think there’s a pretty fuzzy line between colleagues, mentors and mentees in practice. I’ve learned from all of the people below and have hopefully shaped their practices in return. Certainly we’ve all worked together in one capacity or another. Most of them have worked for me at one time or another but that certainly doesn’t imply a one-way direction for learning :)

Colleague One is a current corporate Scrum trainer and someone who probably learned a lot of what he knows about Scrum from me but he’s paid me back in spades, I assure you, in influencing how I work with coaching and training customers. He’s got a wonderfully supportive and participatory approach that customers gravitate to. I’ve learned a lot from him.

Colleagues Two and Three are two people that joined my group at about the same time. They’ve since done most of the work in developing our Scrum training offering and in defining our authorization processes. I came to Scrum more from eXtreme Programming, whereas they were more versant in current Scrum thinking. My practice was renewed by my involvement with them.

Colleague Four is the manager I transitioned the tools teams to. He and I have enjoyed a very mutually beneficial relationship over a couple of companies now. We’ve shaped each other’s views on Scrum and engineering over the years in many ways.

Colleagues Five, Six, Seven and Eight are my colleagues as corporate Scrum trainers. Some of them I’ve helped evaluate in the authorization process. Some I’ve bounced ideas off of (and vice versa). Some have been partners on projects or coaching engagements.

Colleague Nine and Ten and I formed a de facto Product Owner support group, as each of us has been one at one time or another. Colleague Ten transitioned into Product Ownership from a position I had to leave due to the needs our managing our growing group. So with her I think it’s fair to say that I mentored her a bit – although her outward focus was something I learned from. My weakness as a Product Owner is to be too inward-focused. Colleague Nine brings a foundation in usability to his work as Product Owner that I’ve tried to bring to my own practice.

11. What are your client organization’s primary reasons (motivations, issues, etc.) for your engagement as a Scrum Coach?

Most commonly, they come to Scrum out of curiosity and a desire for improvement or through the belief that it will help them with specific problems – common examples of the latter include quality issues and problems meeting commitments. My first job in such cases is to make sure they make an informed decision – so making clear what they’re getting into, how long it will take and what they should expect as tangible benefits from it. From there, my customers are looking for help in bootstrapping the process – either they want to have their best chance of success in deploying Scrum in its entirety or they are interested in putting together a plan for rolling out Scrum incrementally. Either way, they see value from working with someone who has done this before a few times. That’s solely from the perspective of the manager who is reaching out to me for help. From the perspective of the team members, Product Owners and Scrum Masters I work with in coaching probably the biggest motivations they have in securing my involvement is to ensure they get the opportunity to really fulfill their role and to give them a good chance of doing reasonably well out of the chute.

12. List two particular challenges or obstacles, and lessons learned as you have encountered them during your Scrum coaching. Select one and describe how you responded to it then and how would you address it differently today.

The first challenge I’d cite is identifying candidates for the Scrum roles. I had some early successes coaching Scrum by acting as the pilot team’s ScrumMaster – that worked only because I’d already identified an eager candidate ScrumMaster who wanted me to show them how to do it for a sprint or two before taking over. In later coaching engagements I tried to do the same but it didn’t work out so well because no candidate ScrumMaster really emerged. I don’t normally do coaching this way now – I get the team to nominate their ScrumMaster and then ride shotgun with them but it’s them doing it from day one. This ensures that the team doesn’t come to depend on me being there (a false deployment and certainly a failure in coaching).

Another problem I’ve seen more recently concerns thinking of Scrum deployment in terms of projects. Deploying Scrum on a project makes sense from most people’s expectations of what a pilot means, but leads to the problem of the project ending. What happens then? Do they carry on with Scrum or not? Would they even have a good idea how to do so to manage their work during the time between projects? Anymore I try to work with my customers to think in terms of deploying Scrum to their team and think of their projects as being stuff the team is working on. That gives them a solid grounding in the use of Scrum to manage their work overall rather than tying it to any particular project.

13. Beyond Scrum basics, what would your client organizations or engaged teams say they have learned from you regarding the application of Scrum in their organization? Describe two things they would list.

They would certainly say that I have helped them reconcile their Scrum deployments and ISO9001 in a manner that addressed the latter’s requirements while still affording them the former’s benefits.

They would also say that I have been helpful in teaching them effective estimation techniques, such as ideal time estimation as it is described in “Planning Extreme Programming”, by Beck and Fowler and Story Point estimation and release planning, as they are described in Mike Cohn’s books.

14. Quantify two results or benefits your client organization achieved as a result of your Scrum coaching (for example, improved quality by reducing defects by 24%).

The benefits I can describe were quantified at the global organizational level. For sure I had a lot to do with them but it’s not fair to say they’re wholly attributable to my coaching. I ran a survey of Scrum team members drawn from across my company’s Software organization – some were my coaching customers and some weren’t. That survey probed the Scrum value proposition and the effect of Scrum on product quality. The results were as follows:

Percentage who agreed or strongly agreed that Scrum helped the team's …

  • Ability to remove impediments blocking progress: 90%
  • Accountability: 88%
  • Productivity: 83%
  • Morale: 75%
  • Ability to meet commitments: 73%
  • Ability to deliver a functional product earlier: 65%
  • Percentage who agreed or strongly agreed that Scrum help the team …
  • Find defects earlier: 88%
  • Fix defects earlier: 80%
  • Improve product quality: 73%


The other global effect we saw was an improvement in the Scrum team’s ability to resolve defects in a timely manner. 62.3% defects on Scrum projects are resolved within four weeks of being raised, as opposed to 55.9% for other projects.
Defect Rates Agile vs Non-Agile
15. Describe two coaching techniques and/or tools you have employed that have been particularly effective and explain why (for example, planning poker). Describe a situation in which one of these two techniques or tools was not effective or had an unexpected result.

Ideal time estimation has been a real staple of Scrum deployments for us. I always say in training that Scrum is like an engine – you can drive it in whatever direction you like. You can drive Scrum towards higher quality or towards higher productivity or towards better success against commitments (among likely many other examples). For us, that last one is the one most, if not all, teams end up doing first. They value - and their management values – the team being able to commit to specific things and then deliver them on time. Using ideal time estimation and measured velocity in ideal hours per sprint to size sprint backlogs has been extremely effective in helping teams build challenging plans that nonetheless leave them able to deliver against their commitments. Far better, in my experience, than teams that use story point velocity to size sprint plans do. This is primarily due (in my opinion) to the effects of the Central Limit Theorem – when we grab a handful of stories and build a sprint plan based on their summed story points, we have so few stories that one or two of them being under- or over-estimated can lead to drastic problems with our sprint plan. When we use ideal time estimation for the sprint backlog, the number of tasks is so high that the Central Limit Theorem helps us out – the over- and under-estimated tasks will tend to balance each other out and we end up with a plan that’s much more likely to reflect what we’re capable of accomplishing.

Note that I’m a huge proponent of story points when used to do release planning and forecasting – I just don’t think they’re particularly effective in helping the team decide what work it can accomplish in a sprint and so a team that wants to improve its ability to make and meet commitments would be wise to use ideal time applied to sprint tasks instead. Story point velocity based release plans have been absolutely critical to driving Scrum adoption at my company, in fact. Our company is very time to market driven and so approaching senior managers with the traditional schedule risk based plans (e.g. “here are our most likely, most optimistic and most pessimistic forecast release dates”) is largely a non-starter. They absolutely do not want to hear anything remotely probabilistic about the release date. The story-point velocity based release plan, however, puts us in the position of telling them that the release date is fixed and instead we speak of our most likely, most pessimistic and most optimistic amount of functionality available on that date. And that’s a hugely more palatable story for them. You can almost feel the tension go out of the room :)

User stories themselves have also been very useful for us in many of our Scrum teams. They’ve helped us quickly put together product requirements without bogging down the process with what Cockburn calls “complete-ism”. Deferring the details until the story has been selected for the upcoming sprint has also been singularly useful. But user stories haven’t been a panacea for us. Some of our projects are nearly “cookie cutter” variants of previous projects. For those, the team could see no possible value to taking their existing project milestones and requirements and rewriting them as stories – and nor could I. For them, we agreed to use their existing high-level work item structures but sequence and plan them using sprint planning and release planning.

16. Describe two skills you have found to be useful in your coaching practice and explain why (for example, listening). Describe a situation in which you applied one of these skills.

I think I’ve developed good facilitation skills after my experience in coaching JAD and Scrum, and in being a ScrumMaster and Product Owner. As a coach, facilitation is absolutely critical – you’re not solving the team’s problems yourself but rather are working with the team to help them solve them themselves. Facilitation is critical to making that happen. People trying a new method will frequently be reluctant to speak up or otherwise draw attention to themselves – especially the typically introverted software development team members I normally work with. Effective facilitation will show the team (as opposed to telling them) that the process will not work well without their input, and will draw out of the team their best insights while making everyone feel that the Scrum meetings are a safe place for them to speak their minds. Along the way, effective facilitation will show some team members - perhaps for the first time - how an effective working meeting really works. I hope I bring this skill with me on every coaching engagement I’m on but one case that comes to mind for me involved a team that, while being reasonably successful with Scrum given how long they’d been at it, was still very much of a functional mindset. Testers did testing work and developers did development. We got to a point in one sprint where overall progress looked ok (i.e. on the burndown chart), but when you drilled into the details, it was clear that the developers were way ahead and the testers were way behind. I brought this up in a manner that made it as matter of fact as possible – “We’re not going to be as successful as we could be in this sprint given our current trajectory. Can we look at ways to shuffle some of the work around to improve the situation?” They were really reluctant to go down this path to be honest. It took a lot of fairly careful facilitation to bring out of them a consensus that failure wasn’t really the most appealing option available to them. Ultimately they decided to get some of the developers to help with some of the testing work while getting the testers to act as reviewers of that work. A start :)

I’ve been a developer, architect, test manager among other roles on software projects. That broad base of engineering background is really useful in coaching Scrum because it helps me prompt discussion if the team gets stuck. It can also help when working with a team to set reasonable targets for itself in defining its initial definition of done. Lastly, knowing a lot about how software is developed can be helpful in assessing whether or not the new team members are engaging the process well – i.e. because you can sense when people aren’t talking about something they probably should be.

Section 6. Scrum Knowledge Area Assessment

Purpose: To demonstrate your knowledge of Scrum and your ability to clearly explain it to others. The following questions cover a limited range of knowledge areas related to Scrum. Respond to each of the following questions with clear and concise examples.

17. Compare and contrast Scrum with three other Agile and/or non-Agile software development methods. Examples include Extreme Programming (XP), Lean principles and the Rational Unified Process (RUP), etc.

eXtreme Programming

XP prescribes a more end-to-end process encompassing not just roles, project management, quality, validation and requirements development disciplines as Scrum does but also engineering practices like continuous integration, collective code ownership, refactoring, pair programming, unit testing, “the simplest design that could possibly work” and so on. One huge (IMHO) omission in XP is that it does not explicitly leverage the iterative lifecycle as a framework for process improvement as Scrum does through the retrospective practice. IME, the iterate/reflect cycle in Scrum is where most of the value from it derives, long-term. That this is absent in XP is surprising. Mind you, I supposed I shouldn’t be overly surprised – the early writing on Scrum, such as Agile Software Development with Scrum, by Schwaber and Beedle also does not mention a retrospective practice :)

Lean

From the perspective of a software development team, lean thinking leaves even more unspecified than Scrum does. Where Scrum is prescriptive on project management practices, lean lets you “roll your own” here as well. Basically lean provides you with a set of principles – how you realize them is a function of your own insights and the local conditions in which you find yourself. Some principles include “eliminate waste”, “build integrity in”, and “decide as late as possible” – those are good ones to look at. Each aligns well with Scrum practices – the short sprint cycle and retrospective are tailor-made to eliminate waste. “Build integrity in” echoes the Scrum notion of the “potentially shippable product increment”. “Decide as late as possible” echoes Scrum release planning and the delay of the detailed conversation about stories until the last responsible moment. So lean and Scrum are complementary. One way to look at it would be to say that Scrum provides a concrete framework for deploying a lean-compatible development cycle.

Staged Delivery

Here I’m referring to the lifecycle described by Steve McConnell in the lifecycle chapter of “Rapid Development”. In a nutshell, do traditional requirements development, analysis and architecture up front and then iterate over chunks of the design and implementation work. The motivations are primarily to provide better visibility into product quality (because you’re aligning your verification work with the iterative releases) and progress against planned schedule (because an iterations was either on time and had the expected functionality or it wasn’t). I mention this method mainly because it was how every single large system was developed that I had anything to do with prior to Scrum.

Scrum is similar to this in some superficial ways – the iterative construction and verification mainly seem similar, but also the improved visibility into quality and schedule progress. Scrum drives this visibility earlier in the lifecycle because it does not wait for complete requirements or architecture to start developing working software. Beyond this, though, the similarities end. Staged Delivery projects are open to new requirements really only at the beginning of the project. Once requirements are baselined, scope change is formally controlled (in the sense that most requests for change will be laboriously and vociferously refused :)), so the Scrum benefits of letting the project adapt to new information as it arrives are largely absent. Also replanning in the event of schedule slippage in a staged delivery project is painful – a typically very large plan must be revised to account for the slip and any required corrective action. Not fun or easy. In Scrum the long-range plan is a light-weight thing and is never communicated as the hard and fast thing that the staged delivery plan is. Planning on staged delivery projects is typically the domain of the project manager (perhaps in concert with development managers) – normally the benefits derived from Scrum’s team planning practices (better, more complete and better estimated plans) would not be seen. Lastly, process improvement practices are not normally part of Staged Delivery projects beyond a “lessons learned” at the end of the project – a far cry from Scrum’s intense and relentless improvement cycle.

18. Identify three types of feedback that exist in a Scrum project. For one of those types of feedback, discuss its value, who benefits from the feedback and how they benefit, and how this feedback might be misused or lead to negative results?

The daily stand-up provides feedback to the team regarding its performance against the sprint plan. The value provided is early warning if the team is starting to fall short of its plans, which allows the team to make any required corrections (replanning to accomplish the committed product backlog items, dropping one or more product backlog items from the sprint or canceling the sprint in the worst case). The team benefits from this information because it allows them to recognize they have a problem when there’s still some time to take corrective action. The Product Owner benefits from this feedback because it lets him know how the team is doing in implementing the selected product backlog. The ScrumMaster benefits because the daily stand-up also allows him to get a feel for how the team is doing – are they still enthusiastic, are they overly tired, etc.

The feedback in the daily stand-up can easily be misused if it is used – perhaps by an ill-trained ScrumMaster or Product Owner – to chastise the team for falling behind or to demand overtime to remedy the situation. If this is permitted to happen, the team will withdraw from the process almost immediately – this would almost certainly be the death knell of the Scrum deployment in any realistic sense.

The demo provides the team feedback on the product that is used to refine future plans.

The retrospective provides feedback on the development process and is used to drive improvement of it.

19. Identify three upper management challenges commonly encountered while introducing Scrum. For each, describe an approach to address the challenge.

Larger organizations will almost always have some element of multi-site development on their projects. Scrum values high bandwidth face to face communication and calls for co-located teams. In truth, though, nearly every team I’ve coached has been geographically distributed – an upper manager will see this as a potential showstopper. The truth is that not having co-located teams is a weakness (as it would be in any development methodology) but it does not require us to take our Scrum bat and ball and go home if we can’t use co-located teams. We need to face the problem head on – to the extent possible, align teams on single sites, make efforts to be inclusive to team members on different sites (e.g. using teleconferencing, being respectful of local time variances) and building plans for getting the team together from time to time.

Scrum’s emphasis on team self-management can be a bitter pill for traditionally trained Project Managers and can be perceived as a threat to PMOs. “Practices for Scaling Lean & Agile Development” by Craig Larman and Bas Vodde suggests roles on the Product Ownership team for these people. For us, we’ve found homes for some of these people as ScrumMasters also, but this can be pretty risky in practice because Project Manager and ScrumMaster are really two very different things. For larger projects, Project Managers may find good use of their skills at the Scrum of Scrums level in coordinating between Scrum teams and providing overall status at that level. But managing the threat these people and groups feel can certainly be tough – that fear will manifest itself as pushback on the deployment plans for Scrum at the upper management level. The best way to get beyond it is to start small and be inclusive of these people and very proactive about finding suitable roles for them (as their individual merits suggest) – and in so doing show them that successful Scrum deployment does not drive a nail into their coffins :)

Likely the single biggest challenge most larger organizations will face in deploying Scrum at scale is addressing functional silos: separate test and development organizations and separate product management and development organizations, in particular. These divisions have historically been the source of much friction between these groups – so adversarial relationships between development and test organizations and “contract” relationships between product management and development are examples of what I’m talking about. Solving this problem can be very, very tough – to be honest, if the relationships between these groups were strained enough, I might be tempted to counsel a senior manager to defer Scrum deployment (particularly large scale deployment). That said, it’s never really come to that in my experience. In general the recipe for getting around this is the same in all cases – solicit support from the different organizations in the form of their commitment to support a cross-functional Scrum team. Then work hard for that team to help ensure it’s a rousing success. So show them that their fears and concerns aren’t borne out in reality while demonstrating the benefits of Scrum by showing them happening “in the wild”. Nothing brings people to the table like success :)

20. Identify three Scrum enablers to cultivate in an organization to promote a successful adoption (for example, collaborative environment, automated build environment, etc.). For each, describe its importance.

Scrum is simple enough conceptually but people do definitely benefit from training on it. Having a forum for them to do some tire-kicking on the process and ask questions before they’re neck-deep in it goes a long way to building their confidence in the approach. An organizational commitment to training is an important enabler.

An organization putting its money where its mouth is with respect to collaborative environments is critical for most large scale deployments – letting people travel if they need to, paying for bandwidth to support remote conferencing, paying for conference calling to let people collaborate when they’re not co-located, etc – all of these will provide an environment that optimizes for higher-bandwidth communications and will provide Scrum a good opportunity to show its value.

Not necessarily from day one, but an organizational commitment to automated testing is pretty important. I like to say that a team does not have to have test automation in place on day one of a Scrum deployment – but it needs to have a plan for test automation in place on day one. Scrum’s short iterations will complicate regression testing if the growing set of regression test cases is always executed manually – eventually the team will have to decide to skip some of its test cases to honor the sprint end date. That’s a position you don’t want to put them in – so being able to get started on test automation or leverage existing test automation frameworks shortly after deploying Scrum is very important to long-term success with Scrum.

21. Identify three indicators of sub-optimal performance or dysfunction that might appear in a daily Scrum. What approaches can be taken to address them?

People appearing to be reluctant to talk – especially if the team is behind on its sprint plan. This is normally indicative of a team that’s afraid of failure or afraid of being blamed for being behind. It’s critical at that juncture to work with the team to help them understand that the stand-up is largely for their benefit. It allows them to see what the rest of the team is working on, where they could use some help and how the team is doing against its commitments. No one’s going to yell at them at the daily stand-up for falling behind – if they discover that they are falling behind, it’s time for much more discussion, not less :) Show them how to leverage the feedback of the daily Scrum to determine corrective action to recover the sprint – once they see that happen once, they’ll see how the stand-up is their tool and how they can use it.

People not showing up for the daily stand-up – this happens sometimes especially in the early days of a Scrum deployment. What it normally signifies is a team member that has been pulled off onto other work, a poor understanding of the value of the daily stand-up (for example, when a team member just sends status updates to the ScrumMaster by email) or a general reluctance to engage the process. In each of these cases, I would start by asking the person involved why they’re not showing up – first and foremost, it’s important to know what their thinking is. If it’s the first cause, then working with the ScrumMasters to find a way to ease the demand on the person’s time is the thing to do. If the project at hand is important, then it should be important enough to warrant that person’s involvement. The latter two causes both benefit from one-on-one coaching to either explain the purpose of the standup in the hopes that the person will see its importance or to expose the root causes of their reluctance to engage the process – that last point to encourage them to give the process a chance. Odds are after all that if they try it they will end up liking it :) In my experience, the process largely sells itself – once you get people to try it.

People reporting no progress for several stand-ups consecutively is another example of suboptimal or dysfunctional performance. In my experience, there are two main reasons this happens. One, people are blocked on some impediment that they’re for some reason reluctant to report. Two, people have been pulled away from working on the project for some reason (and not telling the team that this has happened). Either way, exposing the impediment is critical, as is working with the ScrumMaster to clear it.

Section 7. Scrum Coaching Competencies and Skills Applied in Practice

Purpose: To augment the relevant parts of your resume that support why you are qualified to coach Scrum teams and organizations. A CSC represents a critical learning path for those seeking to better understand and apply Scrum in their organizations. Due to the non-prescriptive Scrum framework and the dynamic nature of organizations, Scrum Coaches find themselves in a variety of settings requiring varying competencies and skills. Qualified candidates display a balanced competence across a wide range of skills. Complete each of the following with a clear and concise description supported by two specific personal examples. For each example, describe the situation, what you did, and the outcome.

(a) Advisory and Consultation

Scrum Coaches advise and consult with a client organization that is using, or is considering using, Scrum. The coach’s advice enhances and speeds the self-discovery process—it should not replace it. They understand and respect the nature of a client-consulting relationship, whether they are internal or external to the organization. They have experience in engaging multiple teams and roles within and across organizations. They have strong interpersonal skills, can communicate clearly, and can relate to technical and business roles at various leadership levels.

22. Describe two specific examples of how you have applied your advisory and consultation skills and competencies in a Scrum coaching engagement.

I once worked with an organization whose job it was to port and integrate existing software on new targets and then resolve any defects until the product attained a releasable state. From a Scrum point of view, there were all sorts of problems to worry about. At least these were running through my mind:

The team was comprised entirely of developers so was completely non-cross-functional.

The work assumed a large number of defects remaining undiscovered for most of the lifecycle.

They did not do feature work per se which made product backlog definition difficult to envision.

Because the discovery of defects was essentially continual, planning and prioritization were difficult in the extreme because at any moment a new defect might be found that overturned the plan.

That said, the team was very interested in pursuing a Scrum path. I kind of poked around behind the scenes to find out where the limits were in this – the essential function of the team would not be possible to alter. Their job really was to integrate existing software not written by them and then fix defects in it. Also the prioritization of these defects happened a minimum of a couple of times a week and sometimes daily – and that wasn’t going to change either.

What I did with the team was basically lay the principles of Scrum out before them and ask them what they thought the best course of action was. For example, I talked about the notion of achieving releasable product in whatever slice of work they did in a sprint and asked if that was a goal they wanted to embrace - which they did. Given that, I asked them how best to accomplish it. They suggested reaching out to the sibling test organizations to find people interested in joining their Scrum. We did so and formed a cross-functional team. But the biggest problems lay ahead of us in prioritization.

Given that their work was 100% fixing bugs in accordance to an almost continually shifting prioritization, creating a product backlog didn’t make a lot of sense. The defect tracking software listed nearly everything they had to work on - the problem was that it grew continually and was reprioritized frequently. We talked it over and decided not to pursue a product backlog at that point. Their initial sprints were planned with specific defects listed as product backlog items and then broken down into sprint backlog tasks. There were a few problems with this approach though. Let me give you just two. Firstly, if they hadn’t investigated the defects at all, it was very hard for them to do task breakdown and estimation on them. Secondly, priorities could shift during the sprint due to the triage process – so things they prioritized highly in the planning session could be deprioritzed or supplanted by other defects. And they needed to respond to the new priorities. Ultimately, it was in the retrospectives where we came up with a new approach. The team objectives were really about how many bugs they got through. The management structure used aggregate defect information to make release decisions – and changing this wasn’t what they were asking me to do. Getting through sheer numbers of defects really was what they were being asked to do. So instead of committing to fixing specific defects and doing task breakdowns and effort burndowns to support that, they opted to do a bug burn-up and commit just to resolving a specific target number of defects. Sounds small but it had a large effect for them. It gave them a shared goal to work towards – so when it got close to the end of the sprint and they hadn’t reached their goal, people would naturally start working much more closely to help one another get bugs closed. In some ways, the resulting iterative structure looked like an iterative chunking of items delivered in a kanban style. The sprint structure itself became relevant mainly for its ability to set defined and timeboxed goals and – most importantly – to define the periodicity of their iterative reflect/improvement cycle. That last point is really where they got all the value. In the four or so sprints I worked with them, they never failed to meet their defect total target but the improvement cycle drove their ability to resolve defects ever higher. Whereas the groups had managed to 3.5 defects resolved per person per week for about a year, the team (within those four sprints) started setting their targets higher and higher still – that just based on their own observation that they were beating the targets by wide margins. To me this achievement is all theirs though – it was their novel implementation of a process consistent with agile principles (given what was within their ability to change) that delivered value to them rapidly.

I mentioned them earlier, but the Project Central team was a pretty interesting case. Some of the people on the team worked for me and some did not. In total, “testers” came from one organization, “developers” from another, the ScrumMaster from a third and the Product Owner from a fourth – and my most visible contributions to the project were mainly as a developer. But both the Product Owner and the ScrumMaster (and really the team as well) were all very new to Scrum and so likely my most important contributions to the team were as a coach. Some of the problems we encountered in the early going included things like:

Product Owner not sure how far to dive into the design work with the team.

The team members feeling very defined by their roles – “I’m a developer, not a tester” and so on.

ScrumMaster struggling with leaving some aspects of their project management past behind them in this new role.

Scrummerfall-like development process within the sprint.

In the end, and I think you’ll find at least one of my references seconding this, it was less through quoting the canon of Scrum and more through presenting these problems to the team itself and asking them how best to solve them that we ended up getting beyond them. So questions like these helped the team arrive at better choices themselves:

“If the Product Owner owns the product backlog and prioritization, then what authority do you think the team should have?”

“What benefits does Earned Value within a sprint offer us that we’re not currently getting out of our Burndown chats? How would we use it?”

“The Product Owner really wants us to fit this item into this sprint. We’ve got the development resources to do it but are short testers. Is there really no way we can find to do that item this sprint?”

“Testers are complaining they are not busy early in the sprint and way too busy at the end. Is there any way we can smooth out the demand for testing work during the sprint?”

To be honest, the team didn’t always pick stuff I was thrilled with but I could nonetheless support their choices. For what it’s worth, many times my reservations were groundless in the end. When all is said and done, though, the fact that they got to chart their own course was probably as important as where they ended up.

(b) Facilitation

Scrum Coaches facilitate client adoption, implementation, and learning of Scrum. They facilitate effective and efficient meetings. They engage individuals in various roles and stakeholders in critical discussion and in building consensus. They leverage conflict resolution strategies in resolving differences and removing organizational impediments. They maintain a non-biased, third-person viewpoint in client engagements so they can see multiple sides of an issue. They observe verbal and non-verbal communication and aid isolation of root problems from the exposed symptoms.

23. Describe two specific examples of how you have applied your facilitation skills and competencies in a Scrum coaching engagement.

I once worked with a sibling organization that did measurement work – so quality measures deployed on servers and published through emailed reports. They wanted to deploy Scrum mainly because their planning processes were very ad hoc and subject to much volatility – the team was having trouble meeting its commitments and team members were pretty frustrated. One significant issue for them was that some of their work did not appear to be amenable to up front planning. They had maintenance work on the measurement servers which, when they went down, had to be done pretty much immediately. Over the course of a couple of sprints, I facilitated discussions in the retrospectives that helped them choose one solution after another until they arrived at a reasonable way to handle the situation – ultimately what worked best for them was measuring the amount of time they spent on this demand-driven work and then remove it from their capacity in sprint planning. But along the way, they had solutions that didn’t work so well for them – like building a plan for specific tasks they thought they would be asked to do (which didn’t work because they were incomplete) and building “dummy” tasks of about the size they thought the demand-driven work would consume over the sprint (which made the stand-ups confusing and clouded the interpretation of the burn-down chart). The solution they arrived at wasn’t so important and neither frankly was the problem. The key was showing them how the retrospective cycle could be leveraged to bring out the insights of the team and solve their problems – I think my facilitation skills played a part in making this plain to them.

I was recently asked to facilitate a user story workshop for a tools project. The participants did not know much about Scrum or user stories so I first spent some time describing user stories, INVEST as a set of criteria for evaluating them and just enough of a Scrum overview to make clear how the outputs of the workshop would be used. For what it’s worth, I wrote about this workshop in this article. Then I and the Product Owner walked them through the (existing) set of roles and I worked with them as a group to define a couple of user stories relevant to the theme of the workshop. From there, the development of the user stories happened in a very parallel manner, with participants writing them as they thought of them, reading them aloud and then sticking them to a wall. As they went, they put stories on top of one another if they thought they were close enough to warrant possible consolidation. During this phase, my main contributions were to answer any questions that arose considering the work and I also tried to prompt the participants a bit by asking about areas of the subject matter that they’d yet to explore or calling their attention to particularly novel stories other participants came up with. When the group had run out of ideas, I facilitated the group work to decide what to do with the stories identified for possible consolidation. Throughout I tried to keep the atmosphere light, casual and fun but also focused. In the end we got a great set of stories out of the exercise and the participants were universally happy with the outcome and the process they participated in to get there.

(c) Agile Leadership

Scrum Coaches exemplify a servant leadership style. They lead by example, role modeling situations and behaviors for their clients. They challenge command and control behaviors. They listen more and speak less. They accept and reflect on feedback. They value the ideas and opinions of others. They guide leaders and practitioners in fostering a learning and adaptive environment, participative management, mutual influence, and empowered cross-functional and self-organizing teams. They value honesty, integrity, and accountability.

24. Describe two specific examples of how you have applied your Agile leadership skills and competencies in a Scrum coaching engagement.

That notion of servant leadership is probably nowhere better exemplified than in the typical Scrum coaching engagement. In my experience I’ve really only had two groups come to me wanting vanilla Scrum right out of the chute (both were very successful for what it’s worth) – most groups come to me though with more complicated requests:

They fear Scrum or a pushback about adopting Scrum and so want to find ways to get started in a smaller manner.

They have problems in their local environment that they can’t address immediately that make one or more Scrum practices difficult to do.

They are under the gun on their projects and so, while they’d like to deploy Scrum, they’re worried about injecting too much change in their teams during a difficult time.

Those are the realities of Scrum coaching :)

I’ll tell you one story that’s interesting because it ends in what certainly felt like failure. A manager asked me to help them deploy Scrum. One of his teams went whole hog and never looked back - a real success story. The other team pushed back almost immediately. Because I was asked to get involved with him at his manager’s request, he felt he was being railroaded. Because the other team was seeing such success, he resented any comparison to them. The first thing we did was try to find ways to put him and his team more squarely in the driver’s seat – this shouldn’t be something being done to them but rather should be something they were doing. But it was a tough sell. Ultimately, I think the manager was motivated by a concern of looking like he was unsupportive rather than looking at it from the perspective of what was best for his team. So when we asked him what problems he was hoping to solve or what opportunities he saw that Scrum might help with, he probably told us more what we wanted to hear than what he really felt. But he answered that fostering collaboration and team work were his biggest concerns. And so we saw the sprint planning, stand-ups, retrospective and demo practices as being key ones to get started with and suggested these to them. They agreed to work with us to try these but ultimately really didn’t pursue these with much gusto. When we saw this, we again tried to put them in the driver’s seat, asking them what had gone well and what they saw as interesting opportunities we could work together on. In the end, I think the relationship got off to such a poor start that it never really recovered. But every step of the way, we tried to put him and his team in charge and position ourselves as helpers in achieving the vision they came up with – which is very much in the style of servant leadership, in my opinion even if in this case it was not particularly successful.

The story I related in question 22 above about the integration and bug fix team would not have been successful without this style of coaching in my opinion. If I’d come into that team with a firm picture of what they had to do, they would have either followed what I suggested and thus ended up with a particularly suboptimal deployment of Scrum or told me to get lost (I’d have hoped for the latter :)). By keeping their needs and their experiences on the front burner at all times and by gently directing them to see Scrum practices as a means to an end rather than as an end in and of themselves, I think I helped them find their own way – certainly not a vanilla application of Scrum but one they got a lot of value from that’s in keeping with the values and principles of Scrum.

(d) Organizational Development

Scrum Coaches enhance the client’s existing skills, resources, and creativity. They ask powerful questions to guide client discovery and transformation. They recognize that the client learns best through application, not lecture. They are an organizational change agent, understanding the cultural and structural interdependence between the organization and Scrum. They differentiate organizational impediments exposed by Scrum from those caused by it.

25. Describe two specific examples of how you have applied your organizational development skills and competencies in a Scrum coaching engagement.

Similarly here I’ll open this with a story about how I screwed this up :) At one time, my tendency was to coach teams by acting as their ScrumMaster for a while until someone expressed an interest in taking over the job, at which point I’d work to transition them into that role. And to be honest, I had some success doing it that way – the customers liked it because they didn’t have to feel like they were sticking their necks out until they’d become really comfortable with the method and I liked it because I felt like they were getting off to a good start. But then I ran into a team where no one ever stuck their neck out – no one wanted to be the ScrumMaster. But they were happy enough with Scrum and more than happy to have me act as their ScrumMaster. That’s when I realized that my approach was in actuality working against the goal of organizational transformation – some teams had overcome this problem but that didn’t make it a good approach. The team I was working with really struggled when I tried to wean them off me acting as ScrumMaster – I’m not trying to imply I was such a good ScrumMaster, mind you, but rather am pointing out the significance of the mistake I’d made. They weren’t ready to fly solo. Since that lesson, I’m hard-pressed to coach a team in this manner. I normally ask for someone to step forward as the ScrumMaster (and then do everything in my power to ensure that that person has a short and happy road to success). The approach I normally take today is intended to ensure organizational transformation in the teams I work with because I’m working with them to learn by doing right from day one. Recall above I wrote about developing and delivering Scrum training – I don’t normally push teams to take training immediately on deciding that they want to try Scrum. If they want to, then I certainly make it available. But I don’t insist on it. And it’s precisely for the reason implied in this section’s question that I do this – people will learn better and faster by doing Scrum than by being trained in it (in general).

For my second example I’d like to look at organizational transformation in a larger sense. On one of the first Scrum coaching engagements I ever had, the deployment of Scrum went like gangbusters. The team took to it quickly and started piloting their own ship authoritatively in short order. Senior management noticed the positive changes in the group and slowly started standardizing on Scrum in that larger organization. Given that the company as a whole operates under ISO9001 and the existing processes for that group were certainly not at all Scrum-like, there were weird schisms in the group. Some paid lip service to Scrum while doing waterfall-like things and some did Scrum while paying lip-service to ISO. In the end, the inconsistent messages were delaying the organizational transformation the group was hoping to undertake. My role in helping resolve the situation was a series of little things really. I was part of the team that delivered training and coaching to that group and so helped teach Scrum and (especially) clear up misunderstandings about it that were preventing some from embracing the method. I also helped the group redefine its ISO process maps to account for their use of Scrum. I helped them marry their Scrum projects to the ISO quality management system in a way that ensured they were in good standing from an ISO point of view while being able to avoid feeling the need to hide the fact that they were doing Scrum. Similarly, I helped them define an agile change management process that affected a reasonable compromise between senior management’s need to have some over-sight over their project portfolios and the teams’ need to chart their own course. In this way, the larger organization and I worked together to build a set of defined processes that put Scrum front and center while being satisfactory from an ISO point of view – that and the one on one work we did with their people helped move the organization from a waterfall shop to one that was agile through and through.

Section 8. Scrum Coaching Competencies and Skills Assessment

Purpose: To provide evidence of your ability to apply your Scrum knowledge and coaching skills to a new situation. Choose ONE of the following hypothetical scenarios and respond to each of the questions that follow the selected scenario. For each question provide a clear and concise response.

Scenario # 1: Scrum Team Tune-up

The founding member of an Agile team has expressed concern that the team has not internalized the Agile philosophy despite using the Scrum format for a year. One particular problem has been identified – that the team consistently falls short of its Sprint goal and carries work forward. The team questions the benefits of the Agile process. The team has not had any formal training or coaching. You are invited to attend a week of daily standup meetings to help diagnose issues and suggest improvements.

The daily meeting takes around 30 minutes and includes 20 people sitting in various locations, some near and some distant. They converse via a telephone conference line. It appears that all eyes are focused on a time tracking tool that includes burnup and burndown charts. Two voices dominate the call: the project manager and the Agile founder. Each team member answers the question: “What did you work on since the last meeting?” This information may or may not have been entered into the tracking tool. If not, the leaders remind the team members that they must do this. The leaders also quiz each member on how their time was spent, if the work is fitting into the estimate and if not, why not. There is little talking between team members on the call.

1. What opportunities for improvement can you identify in this scenario?

Quite a few :)

Although the team is understandably questioning the value of agile given this difficult experience, they need to understand that what they are seeing is a dysfunctional application of Scrum – likely the quickest way to explain the difference would be to get them into training (of some form) so they can get some idea of what Scrum is really trying to do and why.

Not meeting the sprint goal is demoralizing and is indicative of something wrong in the process. This should be the rare exception rather than the rule. Normally this indicates poor planning practices (including Product Owner pressuring the team, poor sprint backlog development and poor estimation) or interference with the team during the sprint (including scope changes, feature creep and revectoring team members to other work). Either way, failing to meet the sprint goal needs to be addressed.

The stand-ups are a mess.

The team is far too large – normally you want to stay close to the magic team size of 7 +/- 2 people. They’re miles beyond that.

Unsurprisingly, the stand-ups take far too long – 30 minutes rather than being time-boxed to 15 minutes to let people get on with their work.

Stand-up attendance is partially local and partially remote – if the team is in fact all co-located, then they should meet together – the stand-up is for them to talk to one another!

Even though the stand-ups are going long, they’re not accomplishing their intended purpose – only one of the three stand-up questions is being answered: what did you do since the last stand-up? The fact that they are not talking about what they’re doing next or about impediments they’re encountering makes me suspect that either they are not really operating as a team at all or that they are using some other forum to talk to one another about what they are working on – either way, they’re certainly not using the stand-up for this.

Focusing solely on the tool suggests that the Daily Scrum has devolved into a micromanagement progress tracking meeting. This is symptomatic of the problems noted above. Whether or not the tasks have been updated going into the Daily Scrum is not particularly important – at a guess, the main concern here is to try to get the overly long meeting over sooner. But that’s best accomplished by better enacting the Daily Scrum practice itself rather than by putting pressure on the team to update their tasks in advance of the meeting.

The series of dialogs between team members and the leaders in the Daily Scrum rather than a more open discussion suggests a command and control process rather than the teamwork we’d hope to encourage in Scrum. The interrogation of each team member on how they spent their time and whether or not the work was respecting the original estimates is symptomatic of this problem also but is a deeper problem as well. If team members are being grilled on how they spend their time, this will erode a sense of trust and respect that Scrum demands.

Focusing on the accuracy of the task estimates loses the forest for the trees – in Scrum tasks and task estimates are mainly a means, not an end in themselves. The sprint backlog and estimates are a way for the team to learn how to develop the selected product backlog and to establish for itself that there is a solid reason to believe that it can be developed within the sprint duration. Whether or not any particular task is happening within its original estimate is not important (and not useful).

The roles in this example seem unclear. We have a project manager. Presumably this is not a person who understands the ScrumMaster role – if they are intended to fill that role, then they should understand it better and start to fulfill it. Given the context above, this person is certainly not doing so today. Also it’s not clear who the Product Owner is or even if there is one.

It’s not clear who the agile founder is. Is this a coach? If so, then they need some coaching themselves as they’re not doing much to teach Scrum to this team. If not, then they should, at a minimum, be encouraged to respect the Daily Scrum by not speaking during it.

2. How would you approach determining the root cause of the consistent productivity shortfall?

First and foremost, it’s not clear that the problem is a productivity shortfall. At a guess, it is not – productivity may be low for other reasons (e.g. low morale) but looking at the problem as a productivity shortfall is likely not the best way to address the situation.

To directly answer the question though, the first thing I’d do is put the team in the driver’s seat. I’d ask them why they were failing to accomplish their goals – I’d use the retrospective to do this, partly because that’s what it’s for and partly because I’d aim to try to focus the discussion in a more concrete manner, which talking just about the most recent sprint would help with. Given the environment they have today, I’d be prepared to be more active than normal in the retrospective – I’d ask many questions about their problems to help the team arrive at root causes (e.g five whys). For sure I’d want them to work through at least the possibilities enumerated above (poor sprint planning practices or interference during the sprint), but really I’d have two objectives here – one, to help the team solve its immediate problem of missing its goals and two, to get them started down the road of operating as a true Scrum team. I’d want them to start to have the confidence to talk about their problems without fear of reprisal or of being countermanded. I’d want them to start identifying their own solutions and start leveraging the sprint framework to act as a test bed for their own improvement ideas.

One thing I would suggest to them though is to do some form of product backlog estimation – e.g. story points – so that team performance can at least be quantified. That will help establish whether or not a performance problem exists (or recurs) in the future. For example, knowing that velocity dropped in a sprint that did not meet its goals will lead the team to wholly different correction ideas than would a sprint that failed with team-norm velocity but an overly aggressive plan.

3. To whom and in what manner would you share your suggestions for improvement?

Here again we’ve got a wonderful opportunity to further transition the group to a Scrum team – I’d share my suggestions for improvement mainly with the team. But I’d avoid having too many – it’s probably more important that they start making these kinds of decisions for themselves than it is that they find “perfect” decisions right now. Put another way, my suggestions aren’t as important as theirs are. To be honest though, there are some hints of organizational dynamics in the scenario that suggest that not all problems can be addressed in this open manner (at least not at this point in their development). In particular, the problems with the project manager and the agile founder will likely require some intervention – and the team may not feel empowered to do anything about them. This is a great opportunity, though, for a coach to help. I’m not part of the organization and so will be able to intervene in this case without the same fear of long-term negative outcomes that the team would feel. What I’d do initially though is just meet with the project manager and agile founder one on one to further explain Scrum to them and help illuminate their possible roles in it to make clearer what behaviors they’d have to change.

4. How would you go about determining which improvements to implement and how to implement them?

I wouldn’t – I think this is a trick question :) I’d help the team determine for itself what the highest priority improvements to work on would be and then I’d help them build a plan in the coming sprint to deliver something of value to customers while simultaneously improving its processes (so the “how” of improvement implementation is driven by the sprint planning session). Doing both is key though. Alright – if you held a gun to my head and made me confess what my hope would be for them, I’d say I’d really hope they’d try to make a plan they can deliver on in the next sprint. For sure there are lots of things they could work on given the details of the scenario, but from personal experience, I can say that getting them into a mode of delivering successfully against what they committed will help immeasurably. Being successful helps cure many, many ills, so focusing on rational planning and leaving the team to do its work during the sprint would certainly be things I would support and encourage them to do. But the choices are theirs.

5. What approaches would you take to move the team to a point of owning the changes?

Success helps quite a bit here also. A motivated, high morale team will naturally move to greater ownership of both the work it does and the process by which it does it.

Beyond this, solving the roles problem will help – if we can get someone understanding and doing the ScrumMaster role, that will help enormously as it’s that person who is there to help the team do Scrum effectively. Similarly for the Product Owner. But understanding the roles is not a problem limited to the ScrumMaster and Product Owner roles. I like to say about Scrum that if you’re doing it well, everyone ought to be getting something out of it. The team needs to understand what their “rights” are in the Scrum process also – knowing this will help them react well when someone tries to violate the canon. So the team members would be expected to understand that being revectored during a sprint is incorrect – they should stick up for themselves and/or turn to the ScrumMaster for help in pushing back. But they should absolutely not silently do what they’ve been told. Similarly, working with the team to encourage them to understand that it’s their process, their improvements and their problems will help them own the changes going forward.

A lot of the remainder of owning the changes will depend on what they are. For example, if the team had particularly poor sprint planning processes, then encouraging them to enumerate the mistakes they tend to make and then review future sprint plans against this list would be something I’d suggest – but if and only if it was something they wanted to do themselves (as opposed to someone doing this to them).
Scenario # 2: Introducing Scrum to a Multi-team Distributed Project

A team of 40 people have been assembled for a project to do a major revision to a large back-end system. The team has been divided into five sub-teams. Each team consists of a few employees in one office in the United States and a few contractors in another office in Asia. The project manager wants to adopt Scrum with Agile engineering techniques. The project manager has chosen a six week Sprint length to allow sufficient time for integration testing of inter-team dependencies. The teams will transition to Scrum one at a time. Two teams have completed three Sprints with no formal training. The project manager defines the backlog for each team and establishes high level story estimates. Technical leads on the two Scrum teams have been making the task breakdowns and estimates.

You have been invited to help coach this team. The team has expressed some uncertainties in applying the Scrum model:

· The system has no user interface. It only interacts with a few upstream systems and a large number of downstream systems. The team is having some trouble defining the backlog and planning the client demonstration.

· The system cannot be deployed in increments. The plan is for a one-time cutover for all of the downstream systems. The team is questioning the appropriateness of the Scrum model of iterative development with frequent deliveries.

· The ScrumMaster is concerned that the client and area manager expect a commitment from the team that the work will be completed by the cutover deadline that has already been announced.

1. What are some advantages and disadvantages of the six-week Sprint length in this scenario? How would you talk to the team about alternate Sprint lengths?

2. What alternatives do you see for demonstrating this system to the client? How would you present alternatives to the team?

3. What are some consequences of the one-time deployment assumption? How would you lead the team in defining ways to mitigate those consequences?

4. What suggestions do you think would help make this phased Scrum adoption plan succeed?

5. What level of team empowerment do you perceive from this scenario? Would you seek to change it? What desired state can you define? How would you help move the team to that state?


Scenario # 3 Adopting Scrum Across the Organization

A medium sized organization has decided to implement Scrum as its preferred software development process. At this time, there is no single required process in the company. Many projects are completed using some informal processes including ad-hoc implementations of Waterfall, XP and RUP. The Chief Information Officer (CIO) wants only one process framework implemented and Scrum holds the most promise in the company’s domain, which is characterized by a rapidly changing market.

The CIO wants to know how the organization can implement Scrum in the shortest possible time. The CIO sets a target of 400 projects involving 2,000 developers to be converted in 12 months. There is resistance from many project managers and technical leads who believe in their preferred process models. There are many developers who work in silos with no formal process at all. In the culture of this organization a team is considered to be a loosely aligned group of engineers who are assigned to two or more projects at the same time.

1. Would you recommend a gradual adoption process or an organizational-wide cutover? Why? What do you think of the proposed timetable?

2. What organizational and cultural changes would help the process change?

3. What steps would you recommend to accomplish this changeover?

4. How would you define your role in this engagement? What mechanisms would you propose to mitigate potential risks to the organization and the adoption program?

5. What approaches might you take to bring the resistant managers and leads into alignment with the CIO in this initiative?

Section 9. References

Purpose: To list individuals who have relevant knowledge of your coaching skills. Ideally, references should represent client organizations that have benefited from your coaching services. It is important that you understand that by listing contact information below, you are granting the Scrum Alliance and its assigned volunteer reviewers the right to contact your references for the purpose of collecting information relevant to the evaluation of your qualifications as a CSC. You must provide at least two references. Each reference must speak to your qualifications as a coach. References must use the CSC Reference Form available on the Scrum Alliance website at http://www.scrumalliance.org/resources/439.

26. Please list the individuals who have submitted a letter of reference on your behalf.

  • Reference Name
  • Company
  • Email
  • Phone
  • Coaching Timeframe

 

Section 10.Feedback

Purpose: To obtain your feedback on the CSC program and the application process. Your feedback is important to us. We practice Scrum in the creation and ongoing support of these programs and assess your feedback in future updates to the program and application process.

27. Please provide us feedback about the CSC program and this application process. Are the questions clearly stated and relevant? Are there additional questions you would like to see on future applications? Are the requirements adequate to qualify only experienced and professional individuals that will be highly-valued by future client organizations? Provide your comments regarding this application process.

The biggest thing I’d suggest is that doing this process via a written form is probably not that great an idea. The applicants will struggle to understand what it is that each question is intended to expose and the evaluators of the applications will struggle to get a handle on what the applicant really knows and understands. Given that the form is intended to take several hours to fill in and probably quite a lot of time to evaluate, I’d suggest a more effective use of everyone’s time – and also likely a higher fidelity evaluation process – would be had if this process was done as an interview.


[ewillis1]This includes working with senior management to understand and accept agile, revising the Quality Management Structure to support it.


Last Updated on Wednesday, 13 October 2010 18:41