Review

The following is my quote from the front of the book:

“If Scrum and Agile were easy, everybody would be doing it! Now that so many are, this book is the virtual Agile coach I wish I had when I was on the early steps of my Scrum journey. Ilan is a world-class coach, and he has packed this book full of ideas and approaches to all of the common questions and issues that are bound to come up as you transform your world of work to Scrum.”

–Craig Smith, Agile coach and editor at InfoQ

The book is broken into 10 chapters, each with 3 shortcuts each. It is written in a very easy to read and laid back style and feels like you are having a conversation with Ilan. It’s organisation means you can read the book from cover to cover of ad-hoc as a reference. It is clearly written with the Scrum Master / Iteration Manager as the primary audience, although it is suitable for anyone on the Agile team.

The key concept I really liked in the book was the notion of a Chief Scrum Master. As organisations begin to scale, it is a necessary role that is not always taken seriously. The book also covers the notion of One Scrum Master = One Team and deals with the ramifications and alternatives to this setup in a reasonable amount of pragmatic detail.

There were a couple of areas I disagreed with, mainly from an hybrid Agile approach as opposed to Scrum

• protected sprint – Scrum talks about the idea of a protected sprint so that the team can focus. I can see some merit for new teams, but in this day and age of constant change I much prefer working on the next highest priority and the kanban approach to focussing on one-piece flow
• sprint lengths – Ilan mentions that “1 week is too short, 4 weeks is too long, leaving me sitting on the fence between 2 and 3 weeks”. I have had a lot of success with 1 week sprints, particularly in business teams. Also, with teams adopting kanban, I have found 1 week sprints a good starting point. I have had some mainframe teams argue that they need 3 week sprints, but I personally find them too long.
• creating and estimating tasks – Ilan writes “break the PBIs into more granular technical tasks and to estimate each task to the nearest hour”. I find this a complete overkill and much prefer to have nicely sized cards of no more than 3 days. That said. Ilan has some good strategies for splitting stories in the book that I completely agree with.
• tracking time – further in the book, it is written “before going home each day, everyone on the development team should adjust the remaining time for any tasks they had been working on that day to ensure that up-to-date data is being fed into the sprint burndown chart.” As per the above point, I find this to be in most cases a useless metric, particularly if you cannot get the estimates from everyone in the team. In this age of #noestimates, I personally see this as an administrative overkill.

Overall, this is a book that belongs on any Agile pratitioners bookshelf as a trusted advisor or useful reference. As you become more experienced, this is the book you will definitely hand-on and recommend to your more novice colleagues as they take on the Scrum Master role.

My full book review and interview with Ilan and Colin is available on InfoQ.

Summary

Here are my key notes from the book:

Shortcut 1: Scrum On The Pitch

• protected sprint allows the developers to completely fix their focus on what they committed to during the sprint planning session
• the idea of personal achievement is overshadowed by team achievement
• ScrumMaster protects the team from disruptive outside influences and removes issues that may be impeding development progress.
• Scrum promotes transparency as a core tenet

Shortcut 2: Fragile Agile

• Scrum is a framework not a method – Scrum is a framework of practices tied together by a small set of clearly defined rules
• a requirement should not be considered done unless it has met the quality requirements stipulated in the definition of done
• sprint zero – artificial term often used to describe the preliminary work that a team might undertake before it is ready to commence an actual sprint. The issue is inappropriate work is bundled into it that delays the starting of real sprints
• poor ScrumMaster selection – unilateral product or technical decisions, micromanaging task assignments, driving the team to put in regular overtime, or generally acting like a tyrant

Shortcut 3: Creative Comfort

• important to ensure that everyone is feeling energized and excited about coming to work
• teams are made up of individuals, and individuals still maintain a sense of self-worth and appreciate having their hard work recognized.
• when our value feels at risk, as it so often does, that worry becomes preoccupying, which drains and diverts our energy from creating value
• basics for the environment: plentiful whiteboard and wall space, plenty of light, open desk space for each team, ample chair space, small round discussion table, readily available large meeting rooms, do-not-disturb zones, private areas, buffering from the noisier elements of the organisation
• developers who are offered their choice of the latest and greatest equipment see it as the most wonderful benefit – keeping developers happy but also improving overall productivity!
• jelled teams are usually marked by a strong sense of identity . . . team members feel they’re part of something unique. They feel they’re better than the run of the mill.
• the more passionate people are about their projects, the more likely they are to fully engage in them each day
• include the developers in some of the early user story workshops so that they not only feel involved in the conception of the product but also get an early idea of what they will be expected to develop and why.
• a warm greeting in the morning, a sincere pat on the back for a task well done, and the feeling that you are part of a unique team can often be all that is required to maintain smiling faces.

Shortcut 4: Masterful ScrumMaster

• begins with the natural feeling that one wants to serve, to serve first. Then conscious choice brings one to aspire to lead
• 7 abilities: leading without authority, bring about change without fear, be diplomatic without being political, behave selflessly without downplaying the role, protect without being overprotective, maintain technical knowledge without being an expert, be comfortable never finishing, next generation leadership
• ScrumMasters form part of a new generation of enlightened professionals. The role of the ScrumMaster is deep and complex and should never be seen simply as a laundry list of operational functions
• although not everyone can be a ScrumMaster, a ScrumMaster can be anyone

Shortcut 5: Rock Stars or Studio Musicians

• we prefer attitude over aptitude
• teammates are expected to step up to the plate and, if necessary, temporarily help carry any additional load in the same way that a fellow soldier will help stretcher a wounded comrade off the battlefield
• constant feeling of safety should be generated from the knowledge that teammates will be respectful even if they aren’t particularly enamored with an idea or opinion
• the effort you’re willing to contribute goes down the more times you hear “You’re wrong!”

Shortcut 6: Picking Your Team Line-Up

• consider many factors when running your own Scrum “draft pick,” including attitude, compatibility, skill sets, team size, ratio of functional specialties, shared resources, and workplace logistics
• everyone is a developer – Scrum views all development team members as equals and labels them accordingly with the collective title “developer.” – it is like being a medical specialist; irrespective of specialty, all specialists are still doctors
• Scrum team size – 5-7
• development team ratios – 3 programmers : 1 tester : 0.5 “deep specialist(s)”
• preferable to limit the work in progress and instead encourage as many developers as practicable to focus on completing a smaller number of PBIs
• in your next sprint planning meeting, agree that one specialist on the team will not work in that specialty for the duration of the sprint. The specialist can advise others who do the specialty work but cannot do the work personally
• have often found it unnecessary (from a requirement perspective) and unrealistic (from a budgeting perspective) to have deep specialists, such as database administrators, dedicated full time to a development team – treat the as consultants and trainers for the rest of the team
• one team = one ScrumMaster

Shortcut 7: Setting the Scrum Stage

• keep the team together for the duration of the project
• a reasonable assessment of startup cost (for a new team member) is therefore approximately three lost work-months per new hire
• work conducted in ad hoc space has got more energy and a higher success rate. People suffer less from noise and interruption and frustration
• sitting together is the most effective way I know to build empathy
• overtime should be the exception, not the rule – symptom of a serious problem on the project,” not simply business as usual
• big believer in initially running a pilot project. I recommend this approach even if the business is champing at the bit to roll Scrum out en masse
• as an industry we have enough evidence that Scrum works; what individual organizations need to learn is how to make Scrum work inside their organizations

Shortcut 8: Plan the Sprint, Sprint the Plan

• by collectively resetting the goals for the upcoming sprint every few weeks, the team can start afresh rather than remain stuck on a seemingly endless treadmill of ongoing work
• ensure that the product owner (with relevant assistance) not only has determined the next priority requirements for the upcoming sprint but also has fleshed them out in just enough detail to allow the developers to get started
• 1 week is too short, 4 weeks is too long, leaving me sitting on the fence between 2 and 3 weeks
• don’t fall into the trap of believing that those who are dedicated full time to the sprint will be able to spend their entire working day on sprint-related tasks
• 7 Ps – proper planning and preparation prevents piss-poor performance

Shortcut 9: Incriminating Impediments

• anything impeding your team’s progress becomes the number-one priority for the ScrumMaster to tackle
• impediments – meetings of large magnitude, illness, broken builds, issues with the tools of the trade, unreliable supplier, unrefined product backlog, absent or unempowered Product Owner, incentive schemes focussed on the individual
• impediment ConTROL – Confirm, Triage, Remove, Outline, Learn
• an obstruction that has stopped progress on a particular task but hasn’t necessarily slowed down overall progress (a block) versus an obstruction that is slowing down the team’s sprint progress (an impediment)
• you want clear visibility of all blocked tasks, irrespective of how temporary the block may be – spin the corresponding sticky-note 45 degrees

Shortcut 10: Structuring Stories

• an epic story is a user story that will take more than one or two sprints to develop and test
• not necessary to have detailed user stories for every requirement only the top-priority items that are going to be worked on in the next one or two sprints
• key is that stories should be written so that the customer can value them
• if you can split a story into smaller ones and it is possible to independently prioritize them, it makes sense to treat them as actual stories rather than tasks
• technical stories are things that need to get done but that are uninteresting to the customer, such as upgrading a database, cleaning out unused code, refactoring a messy design, or catching up on test automation for old features.

Shortcut 11: Developing the Definition of Done

• DoD becomes the governing agreement that guides all developmental activities, clearly stating what is required for a piece of work to be categorically classified as “done”
• we should be regularly inspecting and adapting the DoD
• acceptance criteria or DoD – comes down to whether the requirement is applicable to every user story or to a smaller subset of stories
• be realistic and get the ball rolling with a minimally acceptable DoD that everyone can live with

Shortcut 12: Progressive Revelations

• inspect and adapt the user stories under development on a day-to-day basis throughout the sprint
• typically a hands-on demonstration of the work requiring verification/validation, it usually occurs at the desk of the applicable developer

Shortcut 13: Relating to Estimating

• estimate to make trade-off decisions and help set goals
• relative estimation applies the principle that comparing is much quicker and more accurate than deconstructing
• determine the effort required to complete a PBI using three factors: complexity, repetition, and risk

Shortcut 14: Planning Poker at Pace

• the issue when using Fibonacci numbers is that people can get into the bad habit of equating 13 points to 13 hours, for example
• some teams adopt more abstract classifiers, such as T-shirt sizes – requires the extra step of mapping to a numeric value to enable forecasting during release planning
• ScrumMaster acts as the facilitator throughout and is not involved in the actual estimation
• Reestimation should be required only when a whole class of PBIs suddenly becomes smaller or larger
• important to circulate a small number of reference PBIs that correspond to the point levels in the card deck
• typically advocate removing the big cards (20, 40, 100, infinity) as well as the ½ card from the Planning Poker deck – fewer options equals less analysis paralysis
• group of PBIs will inevitably rely on some of the same important research or technical plumbing – underlying work should be incorporated into the estimation of only one of the PBIs, not into all of them

Shortcut 15: Transitioning Relatively

• identify the smallest user story in the product backlog and designate it to be the initial ½-point story – this approach can certainly work, and it seems straightforward on the surface, but the reality is that it can end up taking considerably more time than you might expect
• map historical work to the new point scale system – identify, sort and stack, sizing up, subclassify, final filter

Shortcut 16: Bah! Scrum Bug!

• an issue is a problem that occurs during the sprint and is tightly coupled to a user story – not a product backlog item
• bug is a bug only if it is identified after a user story has been completed and accepted by the product owner – type of product backlog item
• unless a user story meets the definition of done, it might as well not exist as far as the customer is concerned

Shortcut 17: We Still Love The Testers!

• loss of identity fear – lose QA identity, lack of skills, won’t get support they need
• testers think in alternative problem-solving patterns that are, generally speaking, mutually exclusive to the way programmers think
• pair testing (when a tester pairs up with a programmer) is potentially even more powerful because there is additional scope to encourage functional skills transfer
• there will always be the need for manual exploratory testing that no level of automation is able to replicate

Shortcut 18: Automation Nation

• if your programmers are using TDD as a mechanism to write their tests, then they are not only creating a great regression suite, but they are using them to design high-quality, robust code
• functional testing is also often called acceptance testing. Perhaps one day we will call it user story testing, as the idea is to be able to test and automate the full end-to-end functionality of a particular user story
• integration testing is all about ensuring that new functionality is able to play nicely with the broader ecosystem and not just in isolation
• performance testing is to measure the operation of the product when under pressure, typically brought about by increasing the number of users and/or increasing the amount of data processing required
• recommend running a secondary build in the development environment (traditionally known as the nightly build) that is triggered manually and less frequently. The difference between the CI build and the secondary build is that the latter should be given the luxury of time, and therefore, it can include the full set of tests (including all of the heavier functional and UI tests that take significantly longer to run
• should configure registry settings, initialize database schemas, set up web servers, launch processes—everything you need to build and test your software from scratch without human intervention
• while continuous delivery makes every build releasable to users, continuous deployment actually releases every change to users (sometimes multiple times a day)
• Scrum does not say that you must release at the end of every sprint, but it does say that you should do everything possible to have something releasable at the end of a sprint
• just start somewhere –  recommend that if you are new to automation, you allocate a percentage of your sprint capacity to chipping away at it

Shortcut 19: Metrics That Matter

• use them only for good, not for evil
• good metric – used as a signal to help the team identify roughly where things are at and, more importantly, as a guide to help the team inspect and adapt its processes to improve over time
• evil metric – used as an inflexible indicator for micromanaging an individual’s performance over time and, more importantly, for beating people up and killing morale
• meaningful metrics – sprint burndown, enhanced release burndown, sprint intereference, remedial focus

Shortcut 20: Outstanding Stand-Ups

• GIFTS – good start, improvement, focus, team, status
• stand-up ambassadors – act as observers in the other groups to pick up on any potential contention and/or lessons
• if you notice a team member addressing the ScrumMaster without making eye contact with anyone else, a tip is to start slowly turning around or looking up at the ceiling
• daily scrum is a simple concept, but without care it can quickly turn into a daily mess

Shortcut 21: Taming the Task Board

• colorful, sticky-note-adorned board has almost become the symbol of Scrum
• visceral “ceremony” of this movement really appeals to our natural sense of achievement because of the visual recognition of work completed

Shortcut 22: To-Dos for your Sprint Reviews

• sprint review is rarely simple, and in fact, I consider it to be the most delicate session to facilitate
• nothing is more embarrassing than so-called technology experts unable to get the projector to work before the session even begins
• demo of the sprint’s completed work should act as a prompt to encourage a two-way conversation between the business and the Scrum team
• team should demonstrate only stories that meet the definition of done
• acknowledge any suggestions made (no matter how outlandish they might sound) by writing them down on the whiteboard or index cards

Shortcut 23: Retrospective Irrespective

• irony is that this session is most valuable when the pressure is on and/or when things aren’t running as expected
• without an atmosphere of openness, you will never get to the heart of issues; without courage, the team won’t be willing to confront problems head on; without respect, the team won’t present criticism in a constructive fashion; and without focus and commitment, the team won’t care enough to resolve the issues
• recommend a relaxed setting such as a coffee shop, a break room (if you have one), or even the kitchen area
• focus areas – communication, processes, scope, quality, environment, skills
• ensure that all improvement suggestions are documented, but aim to tackle no more than a few issues
• circles technique employs an affinity mapping variation, bubbles technique requires each person to document on paper the three most urgent issues that he or she feels should be focused on pair and keep bubbling up the top 3 issues

Shortcut 24: Risk Takers and Mistake Makers

• to successfully implement Scrum, we must overcome a range of fears
• spend your time and effort helping those who are already enthusiastic
• the few bad eggs are often the ones who are most afraid of exposure
• Scrum turns software development into an open book where mistakes are clearly visible
• when openly discussing mistakes and vulnerabilities is the forging of closer bonds between team members

Shoprtcut 25: Perception is Reality

• you have a role as the ScrumMaster to keep the sponsor from blowing a gasket
• reinforce the positive changes that are occurring while also gauging the sponsor’s current perception of how the project is going
• sponsors become less upset when confronted with problems if they are involved in the resolution
• take the sponsor on a “Tour of the Task Boards” now and again
• never say no is a lesson that I have learned over time

Shortcut 26: Our Lords and Masters

• Chief ScrumMaster – facilitator of the ScrumMaster Community of Practice – training and coaching, challenge existing behaviours, provide and maintain tools, define and refine metrics, help establish communities of practice, ensure consistency, coordinate teams, ongoing Scrum promotion, developing the approach, company-level education, aligning the teams DoD, continual process improvement via Collective Retrospectives, impediment escalation, HR for the ScrumMasters, creating a physical environment conducive to Scrum
• ScrumMaster – process improvement, impediment management, diplomacy, coaching, managing change, maintaining the DoD, maintainin effective communication, updating artifacts, faciliating workshops, faciliating Scrum activities

Shortcut 27: Morphing Managers in the Matrix

• requires visionary leadership that is genuinely interested in encouraging continuous improvement as opposed to playing politics
• intra-organizational coordination, logistical planning, scheduling, and tracking are massive roles and ones that are nicely suited to the traditional project manager
• the manager in Scrum is less of a ‘nanny’ to the Team and more of a mentor or ‘guru,’ helping them learn, grow and perform

Shortcut 28: Scrum Rollout Reckoning

• you are either doing Scrum or not – it is binary
• Scrum is not a mechanical process… it is so reliant on people and culture that even with fantastic quantitative results, the introduction of Scrum may have caused such upheaval that too many people are unhappy and that is not good for Scrum’s long-term survival
• Benefield and Deemer used a simple survey based on the following six criteria: How much the team got done in 30 days; Clarity of goals—what the team was supposed to deliver; Collaboration and cooperation within the team; Business value of what the team produced in 30 days; Amount of time wasted, work thrown out, cycles misused; Overall quality and “rightness” of what the team produced
• Comparative Agility – teamwork, requirements, planning, technical practices, quality, culture, knowledge creation
• 3 questions – are your clients happier, are your team members happier, are your stakeholders happier

Shortcut 29: Eyes on the Prize

• development team has no top-down command-and-control authority that tells the team how to do its work. Instead, a cross-functionally diverse team of people organize themselves in the most appropriate way to get work done
• self-organization needs to be grown and nurtured in a particular environment with distinct boundaries, or it risks spreading wildly out of control
• ScrumMaster should assist management in the selection of team members to ensure that the team has the natural predisposition to self-organize and work together as one
• ScrumMasters should not become obsolete – impediments are never predictable, perfection is impossible

Shortcut 30: Shortcut to the Final Level

• if you remain disciplined, follow the Scrum rules, and adhere to the key practices, then, at the very worst, Scrum will act like a mirror, helping you to uncover the dysfunctions that caused the project to fizzle
• three words to remember from the book: transparency, inspection, adaption
• A Scrum adoption should be seen as a big collection of small experiments, wrapped up in a big experiment
• convince every single person in your organization that “agility needs to be seen as a business strategy and not just something the IT guys do

So what were the results for round 1?

When round 1 is conducted, almost all cards are voted to be best aligned with the role of the Project Manager. The following were the behaviours/activities there were not voted to be a Project Manager’s:

• Deliver the work right
• Deliver value
• Quality focused
• Is 100% allocated full time
• Delivers the right work
• Challenges the norm
• Encourages learning culture
• Mentors team

Which left the Project Manager with the following behaviours/activities:

• Facilitates meetings
• Primary stakeholder is Sponsor
• Primary stakeholder is the team
• Primary stakeholder is customer
• Sustainable pace focussed
• Coaches issues
• Manages ability to deliver outcomes
• Removes roadblocks
• Trains approach
• Resolves issues
• Enables rather than controls
• Makes decisions
• Handles people issues
• Directive, provides answers now
• Has budgetary control
• Ensures benefits realisation
• Delivery focused
• Supports approach

My thoughts on the round 1 results

The following were my thoughts on the results for round 1:

• I thought it was interesting that it was the team and not the PM that was perceived to challenge the norm. Is this an admonition from PMs that they don’t push back on unrealistic timeframes or goals?
• The PM’s primary stakeholder is considered the team, the customer and the sponsor… all at the same time. This question was deliberately worded to force a ‘x over y’ response and yet there was a strong drive for all three roles to be the primary focus for the PM. The conflict between these roles is inevitable and in my belief this is the key weakness of the non Agile environment model – one of these roles will win out over the other two and in my experience, it is unfortunately not the team nor the customer that wins.
• I was somewhat surprised that PM’s felt that facilitating meetings was a core behaviour/activity. I normally would have thought this would have gone to the Business Analyst role but it could depend on how you interpret the question and what facilitation means.
• I was very surprised on the sustainable pace response. I believe there is a gap here of what PMs believe to be true versus reality. When push comes to shove, most PMs I know would push the team to work extra hours/weekends to get a project over the line. I know that there are many of you who are good PMs that don’t do this, but the majority would.
• Additionally I was very surprised that a PM would be coaching issues. Again this may come down to an interpretation of the term “coach” but I am using it in the purest sense that of ‘not providing answers, but instead asking questions to the team so that they themselves reflect to reach enlightenment on the issue’. I’m sorry, but I actually don’t think I have ever seen a PM do this.
• Likewise I’ve never seen a PM train anyone.
• Enables benefits realisation is a tricky one. I do believe that PM’s care for and look out for benefits realisation, certainly very much at the start of a project, but as the project progresses and trade offs begin to be made it is the better of the PMs out there that deliberately report and get validation to the trade off of benefits against time. That said, few PMs stick around long enough to see the actual benefits realised which I believe is sub-optimal as they are not receiving feedback on how well or not they hit the mark on delivery (to me delivery is more than just dates, cost and scope).

What were the results for round 2?

When round 2 was completed, the Scrum Master was given:

• Facilitates meetings
• Coaches issues
• Enables rather than controls
• Primary stakeholder is the team
• Removes roadblocks
• Mentors team

The team were given:

• Delivery focused
• Sustainable pace focused
• Deliver the right work
• Deliver the work right
• Is 100% allocated full-time
• Delivers value
• Quality focused
• Supports approach
• Challenges the norm

Split very evenly between both the Scrum Master and the team were:

• Manages ability to deliver outcomes
• Resolves issues
• Trains approach
• Makes decisions
• Encourages learning culture

The Product Owner was given:

• Primary stakeholder is customer
• Ensure benefits realisation
• Directive, provides answers now

The following were put into the category of “Other”:

• Handles people issues

And lastly, the Project Manager had:

• Has budgetary control

The following was questionable as to where it belonged (if anywhere):

• Primary stakeholder is Sponsor

My thoughts on the round 2 results

The following were my thoughts on the results for round 2:

• What is most clear in this transition are two things, firstly the Project Manager is left with only one responsibility and the rest have been quite evenly spread between three roles – the Scrum Master, the team and to a lesser extent the Product Owner.
• Secondly, there is the separation of primary stakeholders against role. The Scrum Master has the team, the team has the Customer and no one is left looking after the Sponsor. I don’t think this is necessarily correct and would imagine that the Product Owner has the Sponsor’s back, but this would likely also have a conflict against the Customer’s needs. What do you think – in an Agile world, who has the Sponsor (the supplier of money) as their primary stakeholder? In an Agile world should a “Sponsor” exist and if not where does the money come from?
• I love that in an Agile world it becomes everyone’s responsibility to guide others (trains approach), encourage learning, resolve issues and make decisions. Some may argue ‘what if the team disagrees between themselves on an approach’? This doesn’t mean that it goes to a vote for the decision, it means that the team works through the pro’s and con’s and becomes more aware of the depth and breadth of the issue. A leader will always step up for the decision, but it is only done after a more collective understanding is reached.
• Sustainable pace is probably the hardest issue to balance in an Agile environment. There will always be a push from the Product Owner and management to go faster and harder, especially if there is the ‘frozen middle’, a layer of management that does not understanding the essence of Agile. Dates are commonly still unrealistic for many teams and this leads to the inevitable push to work longer hours. Now with the Scrum Master accountable to the team they will likely be the first to push back against this, but the pressure can be immense. For my two cents I have sometimes given in on having a short burst of extra hours, never longer than a month. But let me be clear, I do not believe it helps the team in the long run, nor do I believe it is a good idea due to the impact it has on the quality of the product. This has been proven many times in studies and I have seen the results of even a month of bursting and what it does. Just don’t do it.
• It is interesting that the Product Owner is seen to be directive and provide answers now, but if you think about it, to some extent that is what we are asking them to do. We want them to give us a quick resolution on a question so that we can meet our goals.
• Handles people issues was shifted out as it was now likely being handled by a Team Leader.
• And lastly, the budget problem. If a PM is only left with handling the budget then is it really a role? There is a huge shift towards “Feature teams” – teams that do not form and disintegrate on a project by project basis. In essence work is broken to fit into them rather than teams being formed to fit the work. This results in teams that only go through the Forming-Norming-Storming phase once at their initial creation or subtle dynamic change. The individuals in the team know each others strengths and weaknesses and most importantly they have a fixed team cost. If all work in the organisation is broken down to features that are implementable by the product feature teams then the problem of funding for software development really just boils down to one fundamental question – “What is the most highest value work that this product feature team can be working on?” Then it becomes a somewhat simplified matter of watching the cycle time for the product backlog and seeing the lead time for features to determine if more feature teams are required for that product, or less. In essence, it takes the problem from being a project issue to being a operational issue.

Final thoughts

For those Project Managers out there that are believers in “Theory Y” there is unlikely to be much of a negative impact on you when you shift into an Agile environment. You are already a supporter of empowered teams and consequently this transition should feel very natural and in a lot of respects will result in a better work life balance for yourself as your old duties get spread more when you take on either the Scrum Master or Product Owner role.

But for those Project Managers who align more strongly with “Theory X” then there are some tough choices for you ahead in your future. You can choose to find work in an alternative organisation that isn’t about to go down the Agile path anytime soon. There are still plenty such organisations out there, but be aware that over the next ten years the number of these will likely shrink.  You may not be able to run forever. You can try to hide. You may be lucky and not have a good number of Agile Coaches in the organisation who will spot you and elevate your “Theory X” ways to management. PMOs are great hiding grounds, until they are wiped clean.

Or you can change. It won’t be easy, in fact, it will be months and months of hard work, but you may find an enjoyment and peace that you never experienced before when you make this leap of faith.

For the “Theory X” managers, let me leave you with this parting quote and good luck on your journey.

It is difficult to get a man to understand something when his salary depends upon his not understanding it. Upton Sinclair’s Dictum

So I created the Behaviours And Responsiblities Game, or BARG for short.

Let’s go into how it works:

1. Setup enough voting cards for everyone in the room. There are four voting cards for each person: Team, Other, Scrum Master and Project Manager
2. Round 1 kicks off with only using the Team, Other and Project Manager voting cards. Headers match these cards on a wall. Preset cards are read out of behaviours and responsibilities that are commonly encountered in project teams and the voters are encouraged to nominate which role predominantly performs the role or exhibits the behaviour. Round 1’s key context is that of an environment that is not Agile. It could be waterfall, it could be RUP, it could be pure common sense.
3. As each behaviour/responsibility is called out the card is placed against the role with the highest number of votes. If you have more than 40 minutes than feel free to use additional time to discuss variances where they are quite opposed. Cards can sit between two roles to show the varying opinion.
4. Round 2 is kicked off with exactly the same set of behaviours and responsibilities. New headers are placed for all four roles which now includes the Scrum Master. It is also recommended to include a Product Owner role. Round 2’s key context is that of an environment that is Agile.
5. Step 3 is repeated again.
6. Take time now to compare the results between the non Agile environment and the Agile environment. Walk through any placements you disagree with but take care not to move any placements.

The cards that I included:

• Facilitates meetings
• Primary stakeholder is Sponsor
• Sustainable pace focussed
• Coaches issues
• Manages ability to deliver outcomes
• Primary stakeholder is the team
• Removes roadblocks
• Trains approach
• Resolves issues
• Enables rather than controls
• Makes decisions
• Handles people issues
• Directive, provides answers now
• Has budgetary control
• Primary stakeholder is customer
• Ensures benefits realisation
• Delivery focussed
• Is 100% allocated (full time role)
• Deliver the right work
• Challenges the norm
• Quality focussed
• Deliver the work right
• Delivers value
• Mentors team
• Encourages learning culture
• Supports approach

Bring along a few blank cards and feel free before starting round 2 to ask if any key behaviours or responsiblities for the Project Manager have been missed. I found that I had missed in retrospect two:

• Plans timeline
• Reports to steering committee

So what were the results? Stay tuned, I will post in a week or so. But in the meantime, predict what you think occurred – what shifted where? What didn’t have anyone accountable for it? What was no longer needed?