Steve Garnett's Blog

New Blog Address

2005-02-07T16:59:00Z

Hello,

All my blogging will now take place at the following address: http://businessagile.blogspot.com

See you there,

Steve

Emotional Intelligence: A Key Element of Scrum

2005-02-04T10:25:00Z

Best Wishes to you all in 2005...

Maturity and growth... Have you ever considered how we develop and which of our attributes are the most difficult to cultivate. We all grow physically without effort (providing we eat well), we all mature economically because without economic maturity we remain dependent on others and cannot achieve our goals, our intelligence quotient develops as we mature through our experiences, skillsets and knowledge.

For the more pedantic readers I will cede the point that a certain percentage of these elements are based on our genetic make-up and environmental influences, but hopefully you will understand the point I'm making.

These growth attributes are either forced on us or are natural. The one growth attribute we do not necessarily need to develop is our Emotional Intelligence.

Higgs & Dulewicz (1999), define Emotional Intelligence as "Achieving one's goals through the ability to manage one's own feelings and emotions, to be sensitive to, and influence other key people, and to balance one's motives and drives with conscientious and ethical behaviour."

Goleman (1998), further described emotional intelligence as being about:

Knowing what you are feeling and being able to handle those feelings without having them swamp you;
Being able to motivate yourself to get jobs done, be creative and perform at your peak;
Sensing what others are feeling, and handling relationships effectively

Emotional Intelligence has been proven by researchers to provide significant benefits to organisations, and high levels of emotional intelligence within the individual is a key differentiator for professional advancement and success with organisations. Organisational benefits include:

Improved leadership
More effective handling & resolution of disputes
More effective development of team working
Improved negotiations
More cost-effective decision making
Better quality problem-solving & decision-making

The Scrum team is an organisation (albeit a small one) and all Scrum teams would improve their capacity if they could recognise the benefits above. Within traditional software development projects we do not necessarily feel that we need to fully interact and gel as a team. The strategists and business analysts initiate and pass onto developers and testers, then to support and maintenance (at the helicopter level).

All these roles do not necessarily need to interact on a day-to-day basis. Within these projects the roles are not necessarily integrated as a team working in the same room, so the emotional intelligence capabilities are not a NECESSITY, rather they are a 'nice to have'.

Scrum suggests the use of cross-functional teams, pulling people with different roles, skills, perceptions and cultures together in a room and getting production software built every 30 days.

This has a large impact on culture, team structures, and how we interact with people. The more effective we are at communication and interaction, the more effective we will be as team members.

Emotional Intelligence as defined by Higgs & Dulewicz (1999) consists of seven specific components:

Self Awareness

Awareness of one's own feelings and the ability to recognise and manage these feelings in a way which one feels that one can control. This factor includes a degree of self-belief in one's ability to manage one's emotions and to control their impact in a work environment.

Emotional Resilience

The ability to perform consistently in a range of situations under pressure and to adapt one's behaviour appropriately. The facility to balance the needs and concerns of the individuals involved. The ability to retain focus on a course of action or need for results in the face of personal challenge or criticism

Motivation

The drive and energy to achieve clear results and make an impact: and to balance both short and long term goals with an ability to pursue demanding goals in the face of rejection or questioning.

Interpersonal Sensitivity

The facility to be aware of, and take account of, the needs and perceptions of others when arriving at decisions and proposing solutions to problems and challenges. The ability to build from this awareness and achieve 'buy-in' to decisions and ideas for action.

Influence

the ability to persuade others to change a viewpoint based on the understanding of the position and the recognition of the need to listen to this perspective and provide a rationale for change.

Intuitiveness

The ability to arrive at clear decisions and drive their implementation when presented with incomplete or ambiguous information using both rational and 'emotional' or insightful perceptions of key issues and implications.

Conscientiousness

The ability to display clear commitment to a course of action in the face of challenge and to match 'words and deeds'; in encouraging others to support the chosen direction. The personal commitment to pursuing an ethical solution to a difficult business issue or problem.

So... Hopefully you'll have recognised that these are key competencies that would be useful for all team members. How to develop these competencies is another question. There are a number of Emotional Intelligence Questionnaires available that help us to recognise both our strengths and weaknesses and from these assessments we can work on areas of improvements and focus on changing our behaviours.

As with most things agile, the reasoning is clear and simple... the implementation is the difficulty.

Agile Approaches & Transformational Leadership

2004-12-20T15:15:00Z

Being a Scrum practitioner and an “evangelist” of agile practices, I cannot help but notice the parallels between Agile approaches and recent leadership theory.

Key themes that exist within Scrum when you’re living it, are the self-organisation of the team, the role of Scrum master as a facilitator or service provider, and the product owner establishing and driving the vision of the solution.

These themes provide a fundamentally different environment for teams to exist in compared to more traditionally structured projects.

Transformational leadership as defined by Bass & Avolio is concerned with three distinct leadership traits:

Charismatic/Inspirational - inspiring and aligning others by providing a common purpose allied with optimism about the ‘mission’ and its attainability

Intellectual Stimulation – encouraging individuals to challenge the status quo, to consider problems from new or unique perspectives and to be innovative and creative

Individualised Consideration – a genuine concern for individuals’ feelings, aspirations and development. They pay special attention to each individual’s needs for achievement and growth, they coach and mentor. Followers are treated differently and equitably.

Conversely Bass & Avolio describe Transactional Leadership as being concerned with:

Contingent Reward – encouraging specific performance and behaviours by making rewards contingent on delivery

Management by Exception – only intervening actively when a delegated task or function is failing to conform to expectations

The transformational elements abounded within the last project I was engaged in, and I believe it is through following the rules of Scrum that both the social and physical environments can be created that foster these traits.

Many Agile guru’s have been expounding the benefits of agile approaches. Through the studies of Bass & Avolio (1996) they made the following conclusion:

Transformational leadership has significantly greater impact than transactional leadership on the organisation, and produces the following advantages:

Higher commitment, effort, performance and job satisfaction of followers
Lower levels of stress and burn out
Greater employee innovation, harmony & good citizenship
Improved financial performance of organisations

Coincidentally, if I had to summarise the benefits of agile approaches it wouldn't be far away from these four points.

Transformational leadership is not something you can learn overnight, nor can it be taught. But… for those wanting to get the four key benefits I’ve detailed above, you could do a lot worse than following the Scrum methodology.

Scrum helps to create the environment within which a team (with supportive leadership) can grow and attain those benefits.

How Adopting Agile Approaches Increases Business Value

2004-11-23T17:27:00Z

I believe that adopting a scrum approach to project delivery provides the following benefits:

Higher levels of business buy-in
Higher levels business involvement
Clearer alignment of functionality to business value
Higher levels of adoption
Better ROI

Now... for clarity, I'd like to point out that I have created business cases before and hope I will continue to do so for agile projects. I've used ROI, with discounted cashflows, NPV and IRR and even the Benefits Management process designed by Cranfield Business School. But... often the traditional delivery approaches do not help the team to maintain a focus on the business case throughout the lifecycle of a project.

Often once the requirements have been stated, the business moves into the "pay and pray" stage, where they hope that in about 6 months time they'll get what they asked for. Agile approaches have in-built processes that ensure a constant focus on business value.

and now I'll tell you how...

Scrum is focussed on delivering increments of shippable software every 30 calendar days. In my experience, the impact on the business stakeholders and user group of seeing quality software delivered every 30 days (one 30-day iteration is called a sprint) is immense... http://www.controlchaos.com/about/

Picture the scene... It's the programme kick-off meeting, the steering group, user group and entire programme team are assembled and you are presenting the project business case, objectives, structure, ways of working and plan. Then you say, "and the first delivery will be in 19 working days."

I was not short of a few sceptical faces that morning...

However, 19 days later, I was in front of the same audience showing the working software. Now we'd only built about 8 pages, but they were of production quality. The functionality enabled the user to search for and view product information and provided on-line help. This functionality was built using .NET technology integrating to an IBM AS-400 mainframe.

The impact of delivering this one "sliver" of production code was astounding. Suddenly the user group could see that we were really building this stuff straight away, and from the end of sprint 1 until live date, we had significant levels of business buy-in and involvement. Far more than I have ever experienced using traditional, waterfall methodologies.

Now scrum also uses a Product Backlog. A product backlog is a list of high level business requirements prioritised purely on a business value basis. So what's so new about that? ... Nothing.

What is new, is that because we are delivering full production code at the end of every sprint, we can measure our expected business return directly against cost far more precisely. AND... at this point assess the outstanding functionality, and either change direction, de-scope because the outstanding functionality has low business value, or continue with the project as it is.

This gives us clearer alignment of functionality to business value. Because of the incremental approach, the closure of requirements every 30 days, and the ability to more granularly relate business value to requirements, the value of the project is transparent to all stakeholders.

At the end of each sprint the sliver of functionality is made available to the business users to review and feedback on. Feedback is classified as an enhancement or bug, but the real value is that the business users are iteratively reviewing and directing the design of the solution as the project progresses. By the time the solution moves into production,
potentially 8 months later, adoption levels are far higher than those of traditional project approaches.

Finally, scrum approaches give you a better return on your investment. Firstly, the teams are more productive see http://blogs.conchango.com/stevegarnett/archive/2004/11/19/297.aspx. But from a business perspective, the incremental completion of the highest priority requirements by the project team, means you will always be maximising your investment, because the team will always be building the stuff the business has prioritised as the greatest value.

In my experience, using scrum has really benefitted the business stakeholders because change is embraced, only valuable functionality is built (and this is picked by the business), and superfluous requirements are not built which reduces waste (Lean software development) http://dotnetjunkies.com/WebLog/darrell.norton/articles/4306.aspx

Breaking the Iron Triangle: Project Manager v Scrum Master

2004-11-19T16:19:00Z

As a PM my general approach to initiating projects has been to build a Project Initiation Document (PID – Prince). A PID details the project objectives, initial scope, organisational structure, roles & responsibilities, deliverables, project processes (lines of communications, risk management, issue management, change control), plans, costs and timelines.

And starting an agile project I would still identify most of the above and ensure it is clearly communicated to all stakeholders.

But… I have learnt that adopting a scrum approach changes two fundamental things for a project manager:

· The Iron Triangle

· The Role of Project Manager

The iron triangle of cost, time and scope (or quality) is typically the responsibility of the project manager to manage. Hopefully tolerance levels have been set for each element of the triangle, and if the tolerance level is about to be breached or is broken, the project manager escalates their issues to the project board or steering group.

Previously on traditional projects I owned and was responsible for this triangle and reported to the project board if any risks or issues were likely to break the tolerance levels.

In a traditional project a deliverable-focused approach to planning is used (Prince = configuration plan), whereby all the intermediate work products and “pieces” of the solution are identified and a plan drawn up to show the route to delivery usually utilising a gantt chart or network diagram. From which timelines, resources, and costs can be identified and critical path analysis and risk management conducted.

Now scrum doesn’t throw this all away… rather we open out the Iron Triangle and share responsibility across the team, and recognise that no matter how well we plan the project, things will change, and problems will occur.

So… lets open out the Iron Triangle and make time and cost fixable for a set period, say 4 weeks.

So the resources I’ve identify for the project will work for 4 weeks together which will cost a fixed price…

Now, let’s not set the scope as fixed, but accept that scope is variable within this part of the project.

The amount of work and quality of deliverables achieved within the fixed cost/time axis will depend on people… it will depend on the team’s productivity and practices. Let’s break the iron triangle that is established at the beginning of the project, and instead focus on making the team as efficient and productive as possible.

So the role of the Scrum Master is one of maximising the productivity of the team by removing obstacles, inspiring, motivating, and ensuring the scrum methodology is followed.

The responsibility for what is built (the scope) is then given to the business. Scrum identifies a Product Owner, a business stakeholder who has a list of the requirements for the project prioritised by business value.

Maintaining quality levels can be aided through the use of agile development practices such as automated tested, continuous integration and refactoring. http://www.martinfowler.com/articles/continuousIntegration.html

The project team select the highest priority requirements (as specified by the product owner) they think they can build in 4 weeks. So time is fixed, cost is fixed, the highest priority business needs are defined, and how much is achieved (scope) is based on the team’s productivity level.

So whereas PMs own the Iron triangle and spend their time, directing, planning, mitigating, and monitoring progress, Scrum Masters give the responsibility for the scope of the project to the business, set time and cost as fixed, and focus their efforts on the productivity of the team.

The team is responsible for delivery, the business defines the direction or scope, the scrum master helps the team meet its objective for the 4 weeks.

The role change from PM to Scrum Master is not easy… releasing control and sharing the responsibility with others can be a little disconcerting. However, I’ve seen at first hand that the productivity gains in adopting this approach are impressive.

The business sees its highest priority requirements built and delivered every 4 weeks. The team continually improves and increases its productivity levels, and every 4 weeks everyone knows exactly how far the team has progressed because the software is there for everyone to see, test and review.

About Me & This Blog

2004-11-12T13:45:00Z

Hello,

My work experience includes 9 years in the Royal Navy, 6 years in IT, and an MBA thrown in for good measure.

I’ve been a Tester, Business Analyst and Project Manager, and I’ve used Prince, Summit and Enablers as delivery methodologies. I am currently a Senior Project Manager focussed on delivering application development projects using agile processes, particularly Scrum.

So the blogs I post will focus on the management and business perspectives of Agile and Scrum, with no technical postings at all.

I'm looking forward to some interesting debates.

Steve