Agile Coaching: A Multi-modal Approach

By Grant Beck, Plaster Group Agile Solutions Director

A few weeks ago, I attended a gathering of Scrum masters to discuss Agile best practices and the various challenges we were encountering with the adoption or execution of scrum. One Scrum Master I spoke with mentioned to me that he was an Agile Coach. An Agile coach is someone who helps teams and individuals with the transition to Agile and become high functioning by modeling and teaching Agile principles and techniques. Having taken some course work in coaching myself, I was curious what he thought it meant to be an Agile Coach. He said he ran the Scrum ceremonies, maintained the burn-down chart, and removed obstacles so the team could be productive. Making sure the team knew the responsibilities of each scrum role was also something for which he said he was accountable. I responded that I didn’t see how that was different than being a Scrum Master, but he really didn’t have a good response. A Scrum Master might employ some coaching techniques, but how is that different than being an Agile Coach? What are the competencies that a good Agile Coach should possess beyond the skills of a Scrum Master?

Continue reading “Agile Coaching: A Multi-modal Approach”

Gartner’s 2014 Magic Quadrant for Business Intelligence and Analytics Platforms

cube made up of smaller metal cubes representing a information management tool for SharePoint content migration

A few days ago Gartner released its 2014 Magic Quadrant for Business Intelligence and Analytics Platforms. This year Gartner revised the Completeness of Vision axis to reflect the fact that addressing both of the following continue to elude all vendors:

  • Business users’ requirements for ease of use to discover and visualize data
  • Enterprises’ IT-driven requirements, such as enterprise features for governance, administration and scalability

For 2014’s emphasis, Gartner added the following tool requirements:

  • Geospatial and location intelligence
  • Embedded and embeddable analytics
  • Business user data mashup and modeling
  • Support for big data sources

…and depreciated the following capabilities:

  • Scorecards – now combined with dashboards
  • Predictive and Prescriptive Analytics now moved to new “Magic Quadrant for Advanced Analytics Platforms”

As a result:

  • Tableau, QlikTech, Good Data, and Pentaho made the most progress in 2013, advancing on both the Completeness of Vision and Ability to Execute axis
  • Microsoft lost top place in the Ability to Execute to Tableau and Qlick
  • IBM remained the leader (SAS is a very close second) in the Completeness of Vision

Transitioning from Waterfall to Agile

by Grant Beck, Plaster Group Agile Solutions Practice Director


Our client approached Plaster Group with a desire to undergo a transformation from Waterfall software development to Agile methodology. Prior to reaching out to Plaster Group, our client’s functional teams had grown disenchanted and frustrated with their BI and project management process. The continuous churn resulting from Waterfall methods was too open ended, and the lack of predictability and clear setting of expectations had a strong negative impact on employee morale. Additionally, team members expressed difficulty communicating with the business regarding missed deadlines and spent increasing amounts of time sourcing back-end data and developing user requirements without presenting any customer facing results. Overall, our client reported a sense of poor collaboration between the business and project teams, resulting in missed delivery deadlines, incomplete projects, and, consequently, unhappy customers.


Plaster Group’s Agile Solutions consultants met with managers, leads, and development personnel to understand the current development cycle first-hand, with a key strategic emphasis on understanding the current organizational structure, hindrances in the completion of previous projects, stakeholder expectations, and employee willingness to adopt Agile.

Using this information, Plaster Group consultants became advocates for the transition to Agile, providing group and individual training to personnel as needed and leading several project teams through Agile development, providing one to one coaching as needed during the process, and growing an internal team of Agile evangelists through project success. Specific focus was given to coaching both business leadership and Agile development teams on communicating with one another to reach consensus about work priorities, user requirements, deliverables, project milestones and timelines.


Plaster Group led project teams and senior leadership through the enterprise wide methodological transition. Plaster Group was essential in providing:

Agile Advocacy 
● Communicated the benefits of adopting Agile methods to project teams both in terms of augmenting and improving their workflow and allowing for more efficient, complete delivery to the customer
● Built project teams, and offered training and coaching in Agile delivery to all personnel, ensuring the capability of project teams to continue utilizing Agile methods enterprise wide after Plaster Group’s disengagement

Employee Empowerment 
● Empowered delivery teams to embrace the Agile model, feel safe in giving sprint estimates, and executing the work to which they had committed in planning the sprint 
● Special attention was given to fostering social, collaborative project teams capable of managing dynamic project life-cycles and embracing changing user requirements as a normal and coveted result of the development process

Sprint/Scrum Management 
● Worked with senior leadership and project teams to plan sprints, set expectations, designate roles, groom backlogs, serve as Scrum Masters in mitigating conflict and risks to sprint objectives, and provide individual mentorship to employees on the expectations and efficient and effective utilization of Agile methods
● Served as a mediator between the business and the project teams, communicating user requirements, objectives, and corporate status to personnel, preventing user requirements from changing mid sprint, and asking questions of the business from a technical perspective to assist the project team


Since adopting Agile, our client has witnessed notable improvement in project delivery. Incremental delivery has resulted in a quicker realization of ROI, and encouragement of changing requirements has allowed the business to be responsive to changes in business need and priority. As such, customer satisfaction is on the rise. In addition, business leaders report renewed faith in delivery teams, and a notable improvement in employee morale, largely due to the increased communication and collaboration established via sprint cycles, the successful deployment of solutions every three weeks, and the bi-directional trust stemming from the Agile method.

Agile Open Northwest 2014 Recap

Plaster Group Agile consultants Shama and Grant had a great time time last week at the Agile Open Northwest conference. This year’s open space conference covered the gamut of Agile-related topics and provided an engaging environment for lively discussion. The session topics included:

  • Managing Stakeholder & Executive Expectations
  • The Role of an Agile Manager
  • Teaching Pairing
  • Designing Programming Languages for Agile
  • When Management Threatens to Kill Agility
  • Adaptive Execution + Any Planning = Agile
  • Thus Sayeth the Oracle
  • CREATE Quality Code (Cohesion, non-Redundant, Encapsulation, Assertiveness, Testability, Explicit)
  • Stuck? Root Cause Analysis
  • Legacy Code
  • How to be an Awesome Project Manager
  • Measuring Team Productivity
  • Agile: the Day After…
  • Visualizing Teams
  • Project Planning in an Agile Environment
  • CFDs
  • Agile Resumes and Interviews
  • Lean Feature Experimentation
  • End-to-End Quality & Other Challenges with Agile at Scale
  • Managing Requests Without a Product Owner
  • The 5 Rules of Learning
  • What Happens When we Focus on Everyone’s Needs
  • Why Cycle Time Distribution Looks Like it Does & How we Can Use it
  • Seeding Agile in a Reluctant Team
  • Working Remotely with an Otherwise Co-located Team
  • Good People are Made, not Bought
  • Avoiding Orthodoxy


Agile Open has graciously provided summaries of many session topics, complete with photos of any brainstorming and notes that took place during the discussion. This is a great resource if you are looking for Agile conversation-openers, need a quick reference after participating in the conference, or were unable to attend. Visit session notes and pictures on the AONW website by clicking here.

The Role of Project Manager in an Agile Environment

by Shama Bole, Sr. Agile Consultant

The traditional role of a Project Manager (PM) is becoming obsolete – or at least evolving – in the world of Agile software development, and Project Managers must adapt in order to be effective. Often it is simply a matter of ‘doing whatever needs to be done’ to get or keep the project moving.

A client manager made an interesting comment to me – that she loved working with me because I didn’t draw a line in the sand about what constituted my job and what did not. When our client first determined that they wanted projects run Agile, I embraced the methodology and in the process discovered a renewed love for my PM role. I truly enjoy the principles that underlie working Agile. It’s not just another recipe to be followed because it is the flavour of the month, but rather it aligns with my working style and personal philosophy – my personality, if you will. But most PMs have been steeped in the more traditional waterfall methodology that is in contradistinction to Agile, with the latter’s emphasis on iterative development, incremental delivery, self-managing teams and attendant artifacts.

As a Project Manager, my tasks include the traditional:

  • Project Financials & Financial/Portfolio Reporting
  • Status Reporting
  • Project Governance
  • Identification of missing roles/resources and resolution/escalation of same
  • Business stakeholder communication
  • Issue/Risk communication/resolution/escalation – removing blockers
  • Project Planning
  • Change Management

As a Scrum Master (SM), I’m also responsible for:

  • Ensuring the team adheres to its processes (and all that entails in terms
    of artifacts and meetings)
  • Resolution/escalation of inadequate or ill-defined user stories – ensuring
    Product Owner accountability
  • Removing barriers and shielding the team from external interference

Conventional wisdom suggests that the Project Manager and Scrum Master roles are in conflict, owing to the PM role being one of “command and control” and the SM persona being very much that of a “servant leader”. I have always seen myself as that servant leader since, not being a technical expert or a SME, my job is to keep the project on track and remove blockers to progress. Either as a PM or a SM, I serve the team. The area where one might identify a potential conflict is where, as Project Manager, I protect the interests of the product owners (primary stakeholders) and project goals, whereas in the Scrum Master role I protect the core/delivery team from all outside interference. But to put a combative slant on these roles is to assume a zero-sum game (with the Product Owner and delivery team at odds) rather than a collaborative venture that provides optimal results for all.

I don’t think command and control is a sustainable mode of operation. As has been proven with Agile, the best possible outcomes result from the team organizing and managing itself. This may be perceived as threatening to some in the project management community because it suggests a diminishment of the PM role. I am currently combined PM/SM on three projects and purely PM on a fourth, with my role on that fourth project being to manage tasks and obstacles that fall outside of the sprint (e.g. data acquisition from source/transactional systems), and I do not feel it is a diminished role; having a Scrum Master take on daily project activities frees me up for other projects and to take on more. That said, the combined PM/SM role is often attractive to managers and clients because it obviates the need to hire a separate Scrum Master.

One area that frequently struggles with the transition to Agile is that of project financials. Funding for an Agile project would be in iterative chunks, feeding directly into value of throughput for the Business by the delivery team. I have heard this referred to as a “factory” model, suggesting an assembly line approach to development – this isn’t wholly inappropriate given that so much of Lean and Agile grew out of manufacturing. Budgets for projects are arrived at with an estimation approach that is still rooted in the world of waterfall-run projects (I have had interesting conversations with personnel in Finance when providing administrative details such as what is the “In Service” date for an Agile project). However, one of my projects that is run Agile is currently in the fifth phase of development – this suggests that delivery of previous requirements has bred trust between the product owner and project team to the extent that they have renewed our funding based on the product owner’s confidence that we will meet his changing requirements and provide what he needs to stay competitive and efficient. It’s not a blank cheque, but it comes close to a factory model.

In line with the challenge just mentioned, Product Owners are constantly desirous of knowing how much scope may be accomplished given what is left in the project budget. I actually find that I have a better grasp on the realities of what we can and cannot deliver within budget using an incremental delivery approach. In my PM/SM hybrid persona, I use Release Planning as well as team velocity and burn rate to provide the product owner with such an estimate. My caveat to the product owner is always that release planning activities take the core team away from delivering user stories, so that is a trade-off that the Business needs to make. This usually discourages the product owner from constant demands along these lines!

For Project Managers who have relied on a highly structured model that imposes timelines as drawn up by a long term project plan with dire repercussions to follow if said plan is violated, working Agile or sharing the Scrum Master role may seem quite incompatible; traumatic, even, based on what I’ve witnessed at times. The good news is that adapting to Agile gives new life to a discipline at the crossroads of alternative pathways for software development, allowing PMs to re-invent ourselves and stay continuously relevant to the art of Project Management.