We get the best feedback from working software over documentation, says Alistair Cockburn when commenting recently on the Agile Manifesto.
And while some look at enterprise use of Lean UX to make us more customer focused with feedback loops, what can we do instead to make Scrum at scale more user-centred? How can we better leverage its powerful P-D-C-A learning loops at scale as an integral part of continuous delivery?
And check out Steve Granese’s awesome sketchnote of the presentation!
— Steven Granese (@sgranese) August 7, 2016
Is your team dysfunctional? Is their behaviour likely headed down a path that will destroy their productivity and collaboration? If they are, what are the war in signs and, importantly, what can you do to help mitigate their behaviour?
Asimov’s Laws of Robotics help man and machine get along. So, where are the laws that stop teams from hurting themselves either by action or inaction?
This presentations looks at the Gottman Method – a psychological research-based approach to creating stronger relationships – and an example of its use with Asimov’s Laws of Robotics to deal with agile team dysfunction, strengthen collaboration and help build happier teams.
Lyssa Adkins has a well-known coaching model amongst agile professionals. I saw it last year when I was at Agile 2015 in DC.
When I saw Lyssa presenting this model in a role play session up on the stage, though, I was struck by what I saw. Having a psych background, I saw her helping someone to resolve pain in the example what was presented to the person on stage. Immediately, I rushed to jot down what was in my mind.
What are the 8 Elements of Agile Coaching
Recently, at Scrum Australia, Mia Horrigan (ZXM Agile Coach) presented her experience as a “Scrum Mum” and described the pattern we’re now using to frame our coaching. The model is based on 8 elements:
- Mentor – Develops ‘how to’s
- Consultant – Develops frameworks
- Coach – Develops and sets shared goals
- Counsellor – Develops structures to resolve disfunction
- Change Agent – Focusses on embedding change
- Facilitator – Supports a formal outcome without advice
- Lean Leader – Develops people
- Trainer/Teacher – Focuses on skills development through instruction
Unlike Lyssa’s model, we’ve done away with the domain elements of technical, business and transformation mastery, and instead developed additional ‘hats’ as part of a contingency-based coaching model after Feidler’s work on contingency-based leadership. This enables the model to apply to any domain whether the coach has a technical background or whether the coach is coaching in technical, design or business environment.
In aligning with Alistair Cockburn’s new thinking around the Heart of Agile and Shu Ha Ri Kokoro we’re proposed that the 8 elements make up the Ri stage with Kokoro as the Elite Agile Coach stage where coaching competencies and behaviours simply boil down to:
- Listening with empathy
- Asking deep questions
- Empowering people
- Enabling people to act
- Reinforcing agile behaviours
- Increasing insight
Using the Model
Out of recent teams’ Retrospectives on client site, I’ve been gathering the coaching group together and looking at the problems, issues and capability growth opportunities we’ll tackling next Sprint or two. These go into the coaches’ Retrospective, where we assess the root cause, determine which coaching element out of the 8 best applies to the context, and then which coach has the greatest strength in that area. That coach then leaves to plan and remedy and/or support the issue at hand.
Rather going on gut feel, this model has given our coaches a language they can use for discussion as not only a shared way of addressing issues but also to recognise strengths in each other’s coaching styles.
As an Agile Coach and Chief Scrum Master responsible for 8 teams in a service delivery program, when things went wrong, I found it really tempting to get in and try to patch and fix things, direct the teams and make decisions for the Scrum Masters and Product Owners. In this type of role, I drew heavily upon my Program Manager background and found that when things were going wrong, I would fall back into directing teams what to do, sorting out issues for them and making decisions. I spend my life as a soccer mum outside work hours and now I found at work I had ultimately become the “Scrum Mum”.
At the recent Scrum Australia conference in Melbourne, I presented my lessons learnt on how to evolve from this Scrum Mum anti-pattern towards Agile coaching using a contingency based approach depending on the environment of the team/s. This approach helps guides the team through coaching and mentoring towards self organisation, empowerment and cultural change.
In this presentation I highlighted different scrum master maturity models and demonstrated how at an enterprise level, the Scrum Mum is an anti-pattern that isn’t sustainable or scaleable and whilst the team/s may be successful in the short term due to the heroic efforts of the Scrum Mum and a few good individuals, this anti- pattern will ultimately lead to stagnation by the teams
When making the decision to adopt an agile method like Scrum, invariably the question about existing roles arises. In particular, I find that the question of “where do my project managers fit in” is one asked most often.
Comparing Project Manager and Product Owner/Product Manager roles
While the Project Management and Product Owner roles are quite different in their focus, there are many similarities between them.
|Project Manager||Product Owner/
|Primary concern||Create “a temporary endeavour undertaken to create a unique product, service, or result” ||Create a framework built on the need for a product to “satisfy a want or a need” |
|Focus||When will it be delivered?||·Why are we delivering it and to whom?|
|Schedule driven||·Value driven|
|Plan creates the cost, schedule, estimates||Valued features drive estimates and then schedule|
|Try to predict what users need||Find out what users want and adapt to their evolving needs|
|Optimise utilisation of team members through phase based and sequential activities||Team self-organises to optimise its work Sprint to Sprint supported by a Scrum Master|
The function of good project management doesn’t go away
In Scrum, the gaps between a Project Manager and a Product Owner are filled by other roles.
Scrum projects eliminate the role of the project manager, but that doesn’t mean a team can get rid of the work and responsibilities of that role. Since self-organizing teams are at the core of Scrum, a great deal of the responsibility previously shouldered by the project manager is transferred to the Scrum team.
Without a project manager to assign tasks to individuals, team members assume the responsibility of selecting tasks themselves.
– Mike Cohn 
Whether you’re title is Project Manager or Program Manager the tasks you normally do day-to-day don’t go away when your organisation transitions to Scrum, but the focus of why the project is being done does change. Suddenly, delivery becomes about continuous delivery of value. For business, stakeholders and end-users this transformation provides better outcomes for everyone.
– – –
 Project Management Institute (2004). A Guide to the Project Management Body of Knowledge: PMBOK Guide. 3rd Edition. Newtown Square, Pennsylvania, Project Management Institute, p. 5.
 Kotler, P., Armstrong, G., Brown, L., and Adam, S. (2006) Marketing, 7th Ed. Pearson Education Australia/Prentice Hall.
 Cohn, M (2016) Which course is right for me? Online at: https://www.mountaingoatsoftware.com/training/roles/project-manager
“But isn’t that just doing mini-waterfalls?”, asked a recent attendee at one of our Agile Essentials courses.
Scrum requires the team do all the same type of activity they used to do in a Waterfall environment — analysis, design, build and testing their product. I showed the person the faster feedback cycles and the anti-patterns of waterfalling Sprints, but it still wasn’t enough for her.
What I needed was a side-by-side comparison that illustrated how each of these two methods handled different aspects of project management and delivery.
|Schedule driven||Value driven|
|Plan creates the cost, schedule, estimates||Valued features drive estimates|
|Development is phase based and sequential||Development is iterative and incremental|
|Focus is predictive||Focus is adaptive|
|Demonstrate progress by reporting on activity and stage gateways||Demonstrate progress by delivering valued features every two weeks|
|Product quality at the end after extensive test/fix activities||Quality is built in with upfront standards|
|Batches are large (frequently 100%)||Optimises smaller, economically sensible, batch sizes for speed of delivery of valued features|
|Critical learning applies on one major analyse-design-build-test loop||Leverages multiple concurrent learning loops|
|Process is tolerant of late learning||Work is organised for fast feedback|
|Handovers between analyse-design-build-test phases with knowledge stored in documents||Cross-functional team with knowledge of the product invested in the whole team through shared experiences|
For me, the main difference in comparing the two methods is:
- Scrum is value driven, where the plan is formed around the question “what is the most valuable item we can deliver today”
- Waterfall produces a plan from which costs, schedule and estimates are created
If I wanted to deliver value to clients and stakeholders, Scrum is the method I would choose.
In my previous post on Business Analysts as Specilaist Team members within a Scrum team noted, individual team members may have specialised skills and areas of focus, however accountability to deliver the Sprint work belongs to the Scrum development team as a whole.
The whole team is responsible – whether its support for testing built into the features or more people testing, it is not done until it is done. Testers within a Scrum development team help ensure that the right product is getting created and that the product is being made right.
The tester would support the Product Owner by:
- Writing/reviewing acceptance criteria for each product backlog item (user story)
- Write/review testing scenarios for the user stories
- Meeting with clients and business to establish what is needed, what they are wanting to achieve and how that may impact current systems, processes and users
- Creating test cases
- Automating test cases
- Executing acceptance criteria
- Smoke test UI/regressions (previous sprint).
- Exploratory testing to find bugs that no automated test will ever find
- Pairing on development to improve understanding of the code
Scrum teams are intentionally small. Most have a high ratio of developers to testers. Even though that can account for most of your testing time, successful teams have flexible members and testers should have a willingness to step outside their circle of comfort.
Before the Sprint begins, testers can help the team by validating the product (looking at the design and talking through the feature to make sure it makes sense), identifying product risks and system risks before they become issues and making sure that the feature will support test automation.
During implementation, testers make sure the tests are getting written from the start. The best way to do that is to meet with the developer and product owner before any work is done so that the tester can provide their input for what will be tested and also start working on BDD/TDD scenarios for testing to make sure all acceptance criteria are verified and reflect end user’s behaviour and interaction with the system.
Testers help the team to understand what the system state is at the beginning, the trigger for the test, and the criteria for the test with enough detail to know which business rules are being tested. Writing the code behind the tests, such as step definitions for “Given, When, Then” cucumber scenarios, will help the team get to ‘done’ but also help them understand what is happening when the step runs.
Pairing on development and testing strengthens both team members. With people crossing disciplines, they improve understanding of the product, the code, and what other stakeholders find important.
Whilst individuals within a Scrum development team may have specialist skills and areas of focus, accountability to deliver the Sprint work belongs to the Development team as a whole.
In Scrum, there is no business analyst role; instead the business analyst works as part of the development team and utilises their specialist skills to help their peers refine the product backlog. As a team member within the Scrum development team, business analysts play an important role: They usually act as the link between the business and IT, helping to discover the user needs and the solution to address them.
As backlog refinement is a team effort in Scrum, analysts working on the team take on additional responsibilities, for instance, working closely with the testers or the technical writer. As a business analyst on the team, they would be expected to pick up new skills, broaden their expertise, and be open to work in new areas.
The business analyst would support the Product Owner by:
- helping write/define product backlog items (user stories)
- researching the background for user stories
- meeting with clients and business to establish what is needed, what they are wanting to achieve and how that may impact current systems, processes and users
The business analyst would contribute to the development team by:
- hunting out buried documentation about the system being modified
- assisting with the preparation of wireframes
- writing and quality assuring test cases
- writing copy and getting sign off for it
- Completing design and functional documentation
Business analysts can be instrumental team members on an agile project as they can help shift the emphasis from writing about requirements to talking about them. On traditional projects, analysts tend to be intermediaries between team members, but on a Scrum project, the analyst as a development team member is the facilitator of the team and product owner discussion.
As a team member, an analyst’s first priority is to achieve the goals of the current sprint. This is in contrast to looking ahead and forecasting as he or she is used to. An analyst on a Scrum team will assist in testing and answering questions (or tracking down answers) about features, and participating fully in all regular sprint meetings.
The Team chooses how best to accomplish their work, rather than being directed by others outside the team. Business Analysts are often included in Scrum cross functional teams as these teams will have all the competencies needed to accomplish the work without depending on others not part of the team in order to optimise flexibility, creativity and productivity.
Whilst Scrum Teams are self-organising and empowered, at scale, the Master Scrum Master (i.e. Chief Scrum Master) provides coordination and alignment to support teams’ delivery. In Government, this role is crucial to ensure that alignment not only across the teams, it also needs to be in line with program and portfolio strategic intentions for that government agency and in line with wider whole of government initiatives as such as the digital transformation to provide simpler, clearer and faster public services.
The Master Scrum Master role is a recent concept in government. I have been a Master Scrum Master on a number of transformation projects across large government agencies and have had to explore some of the unique challenges of scaling in government including:
• Scaling from a team of eight backend developers to eight teams of 100 people across the three platforms with six external vendors on separate government contracts/SLAs
• Introducing scrum roles into a government structure that are traditionally based on levels of hierarchy with associated HR and PMO reporting
• Dealing with expectations that Agile teams will still meet work schedules driven by internal and external Waterfall teams outside of the sprint planning process
• Working within Gateway signoff processes driven by upfront detailed level design
So, how can we address these challenges?
The Master Scrum Master plays a vital role in addressing challenges of scaling in government in three critical ways:
1. Coordination of Integration to meet shared goals: As a contractor or vendor into government agencies, often it is hard to navigate the landscape and projects and programs of work can become caught up in “noise”. This is where the Master Scrum Master as owner of the process and integration can help as their focus on tactical delivery of the implementation, can help those new to government or the agency, to understand the integration points and then work with these vendors and contractors to gain a better understanding of lead times, dependencies, capabilities and capacities external to the team, to work together to support the small batch sized product increments.
2. Facilitating collaboration: As a Master Scrum Master of a government service delivery teams, I found patterns such as “Scrum of Scrums” and its counterpart the “Product Owners Council” were useful in ensuring collaboration and integration coordination across the teams and facilitate an effective escalation process. For example, these patterns were key to cementing the Scrum Masters and Product Owners relationship to put the focus on business value and working together towards achieving the goals for the Product Increment rather than working in team silos or formal sections/divisions.
3. Focus on Continuous Improvement: The Master Scrum Master requires a very different mindset to a traditional program manager as the Master Scrum Master needs to be a servant leader who coordinates all the team’s efforts to facilitate program level processes and execution, escalate impediments, manage risk, and drive program-level continuous improvement through Inspect/Adapt feedback loops.
I’ve been working with a number of government agencies as they look to Agile methodologies to help them implement their digital transformation strategies. Governance is key to these implementations as the governance framework needs to describe the functional lines of responsibility and accountability.
It is important to recognise that, because a Release train is a construct, the governance framework is explicitly designed to support the outcomes of that construct. As such, it is independent of the organisational hierarchy and therefore must also contextualise these new Agile roles and the responsibilities of all those involved in the Release Train.
Team members need to know what decisions are within their domain and which need to be escalated. In our Release Trains, we want to optimise for fast, decentralised decision making as any decision that must be escalated to a higher level introduces delay (waste) and inhibits flow however within the government agencies we also needed to acknowledge that some decisions are strategic, critical and far reaching across the enterprise and therefore need to be centralised.
Decentralised Decision Making
Decentralised decisions tend to be those decisions that need to happen frequently, are often time-critical (e.g. acceptance of a Sprint Goal at the end of Sprint Planning or acceptance of User Stories as “Done” in Sprint Review), and do not have significant economies of scale. The responsibility for these team-level decisions typically resides with the Product Owner (for decisions regarding the team’s work, scope and quality) or with the Scrum Master (for decisions regarding execution of work aligned with the Scrum process).
Centralised Decision Making
Strategic decisions, those that are infrequent, long lasting and have significant economies of scale, are made at a higher level of management. In the Release Train, the responsibility for these decisions typically resides with the Product Manager (for decisions regarding the scope and boundary of the work for the Agile Release Train and its quality) and Release Train Engineer (for decisions regarding execution of work across the Agile Release Train), with the ultimate level of accountability residing with the Program Director and then the Portfolio Executive.
- A single point of responsibility for the success of the Train – This provides clarity of leadership, management and timeliness of decision-making during the product increment.
- Service delivery is focused on business value – Placing the delivery of business value at the heart of the product increment.
- Separation of delivery ownership and product ownership – To focus on delivery of business outcomes and prevent decision-making forums, such as the Release Management Group (RMG), from becoming just a status report meeting focused on technical issues.
- Separation of project governance and organisational structures – To reduce the number of project decision layers, since the project decision path does not follow the organisational line of command.
To achieve its goals, this Release Train is comprised of the following three structures:
|Directing||Release Management Group||Accountable for the direction and management of the Train within the constraints set out by the Program’s mandate.|
|Managing||Release Train Engineer and Product Manager||Responsible for the day-to-day management of the Train within the constraints set out by the RMG, typically encompassing time, cost, quality, scope, risk and benefits.|
|Delivering||Scrum Team/s||Responsible for delivering the products to an appropriate quality within a specified timescale and cost.
Responsible for planning and producing products.