Peter Measures Blog

Facilitating: Encouraging assertiveness to resolve conflict

2007-10-29T15:26:00Z

As promised, but somewhat later than I was expecting to write this blog, I intend to answer some issues that Kevin Brady raised in his article Agile/Scrum does not get to grips with human psychology, namely:

People will always put their own interests ahead of the interests of the group.
People are self-interested
Karl Popper’s “First law of collective action”. You can never get more than 5 people to agree on anything.
The Project Managers /SCRUM MASTERs turned themselves into Project Administrators.
The project teams had in almost all cases been taken over by strong personalities leading to mini dictatorships.
Knowledge Monopolies.
Most of the talented young development staff were leaving
Clients fed up with never-ending, continuous involvement in IT projects

To me this list arises not from the development methodology used but rather in people's inability to communicate effectively their desires and preferences when a conflict arises. I think there are four ways in which to handle conflict:

Aggressive: Directly telling someone what it is you want or prefer without recognising the needs of others in order to win the argument. This can involve threatening, intimidating or humiliation.
Passive: Hoping to get what you want by hoping someone else will guess your needs
Passive Aggressive: to use subtle indirect techniques to get what you want or prefer including manipulation and emotional blackmail
Assertive: Directly telling someone what you want or prefer in a controlled fashion whilst recognising what they want and what they would prefer in order to negotiate a solution

When reviewing this list, it is obvious to me that assertiveness is the best way to resolve conflict, yet as so often in life, it is a technique that is so underused in everyday life (for example, I often tend towards the passive aggressive rather than assertive to get what I want). So why is this the case? For me it is because it takes courage to stick my neck out and say directly what I want as I fear humiliation, ridicule and rejection.

Often when I think about what Agile means I often think it is about flexibility, balance and being reactive, but none of these would be possible without strength. Like a good tight rope walker, gymnast or ballerina the core of there skill lies in their strength. So how does strength translate in software development? For me it is the strength required to assert oneself starting with me the Scrum Master.

As a Scrum Master I act as a facilitator between factions to ensure that progress is maintained and the project is delivered. In order to do this I need to assert the rules of the Scrum process in a fashion that is assertive and not aggressive. This involves me being genuine and having respect and empathy for the parties involved. To do this I like to remember the 4I's technique:

Introduce - Introduce the topic e.g. "When the team are interrupted with new requirements"
Impact - Describe the impact of the topic e.g. "the team are distracted from what they are working on in the Sprint"
Inform - Say what you want e.g. "I would prefer if new requirements are introduced at the sprint boundaries rather than in a sprint"
Incentivise - say why they benefit from the proposal "that way the team are not distracted and this is the best way to ensure that the most functionality is delivered for you"

In order not to appear aggresive, I try to remember to keep it impersonal by never saying "you" (apart from the incentivise part), keeping it as much about myself as possible and avoiding words like “should” and “must”.

The next thing I must do as a Scrum Master and facilitator is to encourage the parties to be assertive rather than aggressive, passive or passive aggressive. This may involve me asking quiet people their opinions, asking passive aggressive people what they want to achieve or by reminding aggressive people of the rights of others. This encourages equality across all parties so the various needs and preferences become the issue and not the personality of the parties involved. When the personalities have been removed creative thinking becomes the forerunner and a solution is almost always achieved. To do this I like to remind people of one or more of their (and others) "basic human rights", namely

I and other people have a right to be treated with respect
I and other people have the right to say no
I and other people have a right to get emotional
I and other people have the right to make mistakes
I and other people have the right to have feeling, convictions and opinions
I and other people have a right to change their mind
I and other people have the right to negotiate for change
I and other people have a right to ask for help and support
I and other people have a right to protest against unfair criticism or treatment
I and other people have the right not to know something

So how does this answer Kevin Brady's points above. I shall work through each one I say how I would like to deal with these as a Scrum Master.

People will always put their own interests ahead of the interests of the group. - I really do not agree with the "always" in this sentence, we are social creatures who work together to achieve our disparate goals. However if someone is repeatedly putting their interests ahead of the delivery, the Scrum Master should assert themselves with this person to remind them of the rights of the other team members or groups. It may even be necessary to remove them from the process altogether.
People are self-interested - And? This is somewhat obvious, but as above, someone who only puts their interests first may need to be reminded of other people’s rights.
Karl Popper’s “First law of collective action”. You can never get more than 5 people to agree on anything -As a Scrum Master I try to keep the team size to between 5-9 individuals. I also recognise that the various skill set will focus on different areas so that overall agreement can be made in Sprint planning for example .
The Project Managers /SCRUM MASTERs turned themselves into Project Administrators. - I have found this in both Scrum and waterfall projects. As a Scrum Master I would remind myself of my duty as "process owner" and as such all the administrative duties fall on the Product Owner and the Team in the Scrum Process.
The project teams had in almost all cases been taken over by strong personalities leading to mini dictatorships. - Teams will often develop with a leader, which is usually a good thing, however, a good leader listens to his troops and if this is not happening then the Scrum Master should intervene to ensure that the team members do assert themselves and they are not bullied.
Knowledge Monopolies. This can definitely happen on Scrum projects, with people sticking to their "comfortable" silos. As a Scrum Master I would encourage some pair programming but I admit this would be a little passive agressive.
Most of the talented young development staff was leaving - probably because no one was listening to them. As a Scrum Master I want to ensure that everyone is heard by encouraging all the team that the input is valuable.
Clients fed up with never-ending, continuous involvement in IT projects. Good sounds like an ideal project! As a Scrum Master I want to encourage the Product Owner to take full responsibility for the direction of the project on a day-to-day basis.

The plan is useless; it's the planning that's important.

2007-07-24T11:56:00Z

General Eisenhower said that "The plan is useless; it's the planning that's important." How I understand this quote is that the General knew that even with all the planning he participated in, some people would end up on the wrong beaches, there would be a loss of some critical supplies, and many soldiers would face life-threatening obstacles that were never imagined in the planning process. However, he knew he had created an ongoing planning process that was understood by his people that would allow them to recognize and address the most seemingly insurmountable problems. I think that if the General could successfully pull off this planning process to win a war, surely we can do this in our everyday jobs.

I am writing this blog to explain my thoughts on why I think the Agile project planning process (Release plans) are more effective than Waterfall projects plans. Here I make reference to PRINCE2 as a waterfall methodology as this is a process I am familiar with. I note here that PRINCE2 is not necessarily a Waterfall methodology, rather a process for managing and planning any project, but it is often used to deliver projects with the Waterfall approach of design up front in mind.

I also wish to address three specific issues raised in the following article.

http://www.claretyconsulting.com/it/comments/agile-scrum-fails-to-get-to-grips-with-human-psychology/2006-08-17/

Namely, Agile

[is not based on] Commercial production decisions are based on rational expectations.
[that] Resource Management had vanished.
Each of these [Agile] organisations had differing development approaches [within the same IT department] and tools from project to project.

Anyone not familiar with Agile planning and is interested can get an excellent introduction to this topic by reading Agile Estimating and Planning by Mike Cohn. Here I will stick to the Scrum estimating and planning process described in Agile Project Management with Scrum by Ken Schwaber (except for the use of story points and velocity which I think greatly enhance the Scrum planning process).

As with any project a Scrum project cannot start without a business case, funding and an aspirational set of requirements for the project. In Scrum this set of requirements is called the Product Backlog which is an estimated and prioritised list of requirements that are written as goals (the what, not the how) and preferably with defined acceptance criteria. These Product Backlog items are then grouped into four week iterations (or less) based on business value (high priority, low cost) and architectural importance that could be completed by a certain team size (which includes analysis, development, documentation and testing). This grouping into iterations gives what is called the Initial Release Plan as it is the first estimate of what could be delivered by when. As emphasised by Mary Poppendieck and Tom Poppendieck in Lean Software Development in the chapter on Waste, the art of gaining maximum benefit from software resources is to release it as early as possible and do it as often as possible. Until software is being used it just costs a lot with no benefit, so I try to champion this view when forming the Initial Release plan.

As part of this planning exercise the types and numbers of resource needs to be determined. To do this and to support the business case a basic understanding of the technologies to be used also needs to be determined. This will not only be driven by the business requirements, but also the IT department’s strategic requirements around, including tool selection and architectural guidelines.

A waterfall project will also go through a similar planning exercise. In the PRINCE2 methodology this is done in two phases, Start-up Project and Initial Planning where the business case is defined or verified, a quality plan is produced and a high level plan that is broken down into a number of stages. Again this will involve resource planning and certain decisions about the use of technology.

So far, these sound reasonably similar, but they are some key differences that should not be overlooked.

The Scrum Release plan is broken down into fixed length iterations where a PRINCE2 Stage can be any length
In Scrum each sprint targets producing something that is production quality, i.e. it could be picked up and implemented in the real world “tomorrow”. PRINCE2 stages do not have stipulation and could produce artifacts that, on their own, hold no value in their completed state.
The technical design in a Scrum project may be a lot more high level than that of a Waterfall project. As suggested in Lean Software Development, Agile projects try to make decisions as late as possible. This could also be the case in PRINCE2 but in many Waterfall projects the technology is often decided to quite a detailed level up front (as getting it right up front is the basis for Waterfall). A SCRUM project may start with a choice of technologies to be used, that could all satisfy the business and technology requirements.

I think the key here is that both Waterfall and SCRUM project plans, if done properly, allow commercial production decisions to be based on rational expectations. I hope this is enough to convince you that condition 1 is met by both methodologies at least at the start of the project.

Similarly, both involve an initial resource plan so item 2 is also addressed (at least at the start of the project).

I also think item 3 has been addressed in full, regarding organisations having differing development approaches within the same IT department and tools from project to project. I would suggest that either there was a lack of strategic direction within the IT departments or it was felt within those departments that no form of strategic direction is required in an Agile organisation. Personally I think this is a mistake, and a balance must always be struck between the business and technology requirements. Ken Schwaber makes specific reference to this in Project Management with Scrum when discussing multiple Scrum projects. The first sprints are concerned with getting the technology and operational structure right for multi-team development whilst still demonstrating some business value. In Lean Software Development in the diagram of the Agile value chain also describes the need for this initial architecture.

The heart of a Scrum project is the Sprint. A sprint starts with Sprint planning where the Product Owner (the person responsible for delivering business value) collaborates with the team (those tasked with delivering the Sprint) to agree which Product Backlog Items can be delivered in the Sprint. (Note that this may be different from the Initial Release Plan due to further understanding of the requirements.) Having agreed this, the Team identifies and estimates the tasks that are required to produce an increment of developed and tested code in the Sprint. This list of tasks is called the Sprint Backlog. The Sprint then starts and the team assesses the Sprint Backlog on a daily basis including revising time-to-go or creating unforeseen tasks or deleting redundant tasks. This is communicated in the Sprint burndown chart which plots the time to go against the number of days in the Sprint. This gives a clear indication to the team of how the team is progressing against the plan. At the end of a Sprint the team demonstrates their increment of functionality to the major stakeholders and feedback is given. This may identify additional requirements or items where functionality that did not meet expectations or may result in the realisation that certain requirements have become redundant. The Product backlog is updated according to what was delivered which gives a new estimate to go. It also gives an idea of the velocity the team is working at. This is either done on a Product Burndown Chart which plots Sprints against effort remaining, and/or by calculating the velocity which I calculate as

Velocity (story points per unit man day/hour) = Story points in Sprint DIVIDED BY man hours/days dedicated to Sprint

Note, that for these purposes, the story point can be considered as the original man-time estimate made when the Product Backlog was created. This information can be used to re-assess initial Release Plan to gain an improved estimate of what can be delivered when. It will prompt questions such as

can we go-live early, we better get the production hardware ready a month early?
Oh my god we are never going to get this done in four months, maybe we should extend the go-live date now or reduce the scope of the project so that the majority of the business case is delivered on time?
Should we change the resource profile?

The point is that the Release Plan is constantly evolving with each Sprint. This is based on, what I believe to be the best metric in software development and that is amount of working, acceptable code delivered. This again is a principle that supports the Agile Manifesto: Working software is the primary measure of progress.

In a waterfall project using PRINCE2 a stage plan will be drawn up during the previous phase. Although this may be done in conjunction with the team, the project manager owns the plan. The project manager then tracks the project against this plan getting regular updates (which can be daily) of time spent and time to go. The project manager will try to deliver the stage within certain constraints called tolerances and if he/she fails to do so an exception plan will be created to reflect the new timeframe or cost and resource profile. The exception plan can be for the Stage and where necessary the overall Project Plan. At the end of a phase the stage boundaries process is implemented to review overall project progress and the plan.

Again similarities can be drawn between Stages and Sprints but there are some clear differences that need to be understood:

Sprints are of defined length (apart from in extremely exception circumstances where a sprint could be stopped) where as stages can vary in length due to an exception plan
Sprints deliver an increment of shippable functionality whereas Stages may not. A Stage may produce a functional requirements document or a technical design.
The project manager owns the Stage plan in PRINCE2 whereas the team own the Sprint Backlog

Again, if implemented properly both Scrum and PRINCE2 satisfy both item 1 (Commercial production decisions are based on rational expectations) and item 2 (Resource planning) throughout the project lifecycle. They are both planning processes adapting to plans.

So why do I think Scrum release plans are better that Waterfall project plans? This comes down to following factors:

Waterfall encourages getting the plan right up front. If a waterfall project is not going to plan, people being human, will sometimes attempt to keep things to the original plan if they feel their reputation is at stake. This will lead to a “head in the sand” approach to delivery, where delivering to the original plan must be achieved at all costs, resulting in a lot of issues being pushed to the very last phase in the project often resulting in an unexpected delay in go-live right at the end of the project. I think when this occurs Commercial decisions are being based on anything but rational expectations. Conversely, if your stakeholders are groomed properly they have different expectations set and are more willing to accept hiccups and wins as they are seeing working code every four weeks in a Scrum project. I am not saying the “head in the sand” approach does not occur on Agile projects, I would say I have run two of these where through contract or stakeholder belligerence the scope is fixed as well as the timescale resulting in the very same issues as found on waterfall projects when the “head in the sand strategy” is adopted.
In Scrum, the team own their own plan for the iteration whereas a project manager owns the plan in most (if not all) waterfall projects. The distinction may seem arbitrary, but I am strongly in favour of the team owning the plan, even if I can feel a little in the dark sometimes about what is going on. When I have managed both Scrum and non Scrum projects I have found that team members can give very poor estimates to go just because either they do not want to have to think about it or are scared to give bad news, often resulting in late notification of delays. By placing ownership and responsibility for the Sprint Backlog within the team, the team tend become better time managers and are less worried about giving bad news. I think the reasons for this is are that the team learns the value of monitoring their time to-go when they need to deliver something in four weeks and are more honest to the team where previously they would have to explain themselves to a perceived superior. (I must confess, however, that getting the team to use the Sprint Backlog in the first place is a difficult exercise, as this is an additional responsibility that would have traditionally sat with the project manager and can be mistaken for an administration overhead by team members.)
The Scrum release plan process targets the highest business value early, whereas Waterfall projects often have a fixed scope (a defined product in PRINCE2) so that this business focus can be lost. Imagine a project that is going to take twice as long as originally expected. The Agile project allows for high value code to be released on time with a second release later or with abandonment of lower priority requirements. A Waterfall project plan does not have this flexibility and could be abandoned due to overspend without any business value being derived at all.
The Scrum release plan process is based on a more effective metric – working code. All elements of the delivery are being measured from the first sprint. The analysis, development, test and documentation is all performed in a sprint. If your going to get a surprise in Agile regarding estimates it is usually going to surface in the first two or three sprints usually well in advance of the release date. Waterfall metrics tend to use measures derived from other projects and are therefore not attuned to the nuances of the specific project. If functional design overruns then development is likely to overrun by the same % factor. This may not always be the case.
Reduction in number of non-critical artifacts. Although PRINCE2 focuses on products and not tasks, Waterfall does imply a design up front process. This means that documentation is created to inform future phases, but may have little use when the project is completed. Agile favours working software over comprehensive documentation. This does not mean that Agile projects do not produce documentation, but the documentation is minimised. This means, from my experience anyway, that when coding from day 1 is the focus, this leads to more functionality for less money.
Agile planning brings together the business and technology arms of a project in the same room to conduct its planning and to review the outputs regularly. This gives both parties a feeling of control over the outcome of the project because they can debate what is wanted versus want can be delivered on a regular basis. Waterfall projects can tend to show the business a plan up front and a set of requirements that the business is told it must (try to) stick to and show there commitment to this by signing the requirements off as a complete statement of their requirement. In most cases divergence from the plan will occur, either through the business realising that what they asked for was not actually what they needed, or the project is just harder or easier to deliver than was expected so the project undergoes an often laborious change control process to the “contract” that was made at the beginning. As the change control process is written in paper I find a lot of resentment builds up between parties as neither side feels they are being properly understood. I find that face to face direct communication tends to resolve these issues but only if people are brave enough to assert themselves.

Basically that is a very long winded way of saying I believe that Agile projects and therefore the planning process allows for greater flexibility to change and a better balance between business and technology than the planning processes for Waterfall projects. Just because Agile does not try to get everything right up front it does not mean that the Agile planning process is any less effective than the Waterfall planning process. The difference is it is just more accepting of the fact that plans are never perfect (as human being are never perfect), and there is a need to be agile when you are finding a difference between reality and the plan. I wonder what General Eisenhower would have thought about this?

AGILE /SCRUM fails to get to grips with Human Psychology?

2007-07-19T16:20:00Z

I recently read the following article by Kevin Brady on Agile/Scrum does not get to grips with human psychology. The core theme of this article was that Agile forgets the human factor, specifically

People will always put their own interests ahead of the interests of the group.
People are self-interested
Commercial production decisions are based on rational expectations.
Karl Popper’s “First law of collective action”. You can never get more than 5 people to agree on anything.

The core theme of this article was that Agile forgets the human factor, specifically

People will always put their own interests ahead of the interests of the group.
People are self-interested
Commercial production decisions are based on rational expectations.
Karl Popper’s “First law of collective action”. You can never get more than 5 people to agree on anything.

The discussion then proceeds to highlight some examples of why Agile projects may fail, namely

The Project Managers /SCRUM MASTERs turned themselves into Project Administrators.
The project teams had in almost all cases been taken over by strong personalities leading to mini dictatorships.
Knowledge Monopolies.
Resource Management had vanished.
Having had a taste of freedom the dictators were a hateful and aggressive bunch when asked about their managers /SCRUM MASTERS
Most of the talented young development staff were leaving
Each of these organisations had differing development approaches and tools from project to project.
Clients fed up with never-ending, continuous involvement in IT projects

When working on Agile projects I have definitely come across some of these issues, however I think these could also affect projects being delivered under other project methodologies as well. The Burgen Blog addresses similar issues in a direct and humorous way. (You will have to go to Tuesday the 19th June 2007 as the title is unfortunately named so I cannot enter the URL for it).

My take on this is that no project methodology, Agile or Waterfall, counters all these issues through the application of the process. I believe that many of these issues result from a failure in human to human communication and a misunderstanding of the SCRUM planning process. However I strongly believe that Agile projects is more akin to human nature/psychology than Waterfall development because Agile favours individuals and interactions over processes and tools and this is defined at the very heart of Agile in the Agile Manifesto.

As a useful exercise for myself and in a the hope that someone out there may find this useful I thought I would address the arguments above in a series of Blogs to illustrate how I would deal with these issues (or would have liked to deal with them in hindsight). These breakdown into two main topics that I believe are crucial to being an effective Scrum Master:

Facilitating: Encouraging assertiveness to resolve conflict which I intend to address the following items

People will always put their own interests ahead of the interests of the group.
People are self-interested
Karl Popper’s “First law of collective action”. You can never get more than 5 people to agree on anything.
The Project Managers /SCRUM MASTERs turned themselves into Project Administrators.
The project teams had in almost all cases been taken over by strong personalities leading to mini dictatorships.
Knowledge Monopolies.
Most of the talented young development staff were leaving
Clients fed up with never-ending, continuous involvement in IT projects

"The plan is useless; it's the planning that's important." where I intend to argue the case that Agile does deal with the following effectively.

Commercial production decisions are based on rational expectations.
Resource Management had vanished.
Each of these organisations had differing development approaches and tools from project to project.

Finally I may decide to demonstrate how I think Agile and particularly Scrum is a very human process by comparing it to the psychological model called the Process of Change (if I can find a reference to this on the internet).