“Agile is not about software.  It’s about change.” 

All of the founders and legends and most of the good people I have met, who truly believed and understood what Agile was about, can be found lurking as signatories.  Although that’s not to say all signatories are everything to all men, it does generally show they have their heart in it – not just their wallet.  I remember the moment I signed and the commitment I felt at the time – like joining a secret club.

For those of you interested or confused here is the Agile Manifesto once more..

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Openness comes into play again in relation to being honest and leaving our biases behind, being ready to explore new ideas, whether your own or others.   This flavour of openness is particularly useful to remember in games, planning and reviews.  Honesty is infectious, when a person is open about failures it encourages everyone around them to be comfortable sharing their knowledge and mistakes too.  Just a little openness offered to others can, and often will, spark innovation and creativity in others, leading to better software, higher quality and high performing teams.

More on Respect and Courage to come…

Coaching can be effective for short and long term purposes.  Short term coaching is usually focused on specific activities, for example coaching a team’s planning meeting or helping groom a complex legacy backlog, and is achieved using a combination of facilitation, training, listening, observing and providing feedback.

A typical example of a formal, long term Agile coaching engagement starts with a facilitated planning session with the client and potential coachees.  The aim of this is to agree a set of key aims or goals that depict the desired outcome of coaching.

The coach will then become immersed in the team’s activities so that they are available and aware of the challenges the team face.  For example coaches may initially facilitate planning sessions or retrospectives to provide a working example of Agile in action.  Or a coach may provide the team with some additional training in different techniques to get more honest retrospectives or better, meaningful reviews and demo’s.  The Agile Coach works informally with individuals too, in a neutral and advisory capacity, to support team members in fulfilling their new roles and to help them become more self-empowered and aware.

Agile coaches use inspect and adapt techniques to help you fine-tune your goals on a regular basis, throughout a coaching engagement.  This is also an opportunity to model and publicise your chosen Agile method, for example when coaching Scrum teams it is ideal to use sprints as a way of planning those regular opportunities to inspect and adapt.

Importantly, an Agile coach is an expert at helping to pace new Agile teams – we often refer to this as the heartbeat, or rhythm. Often when people try something new we run towards, or away from, it.  New teams often try to change everything at once and this can result in even more chaos and uncertainty. Coaches will help your people to prioritise and then embed critical, high-value adjustments to your ways of working, geared towards meeting the goals agreed.  For those teams which resist change, coaches are adept at guiding people to discover their own reasons for change, often finding new goals as a result – this often requires substantial one-on-one coaching with leaders and influential team members.

As I tried to focus on when and where and how to improve I began to correlate with Scrum values.  Over the last several years these ideals became so embedded in my way of working that I simply forgot about them..and recent exploration has confirmed my fears – that most people who are actively pursuing or practicing Scrum are also lacking in conscious knowledge of these core ideals.    I only recall ever seeing these in black and white in the very first Scrum book I read by Ken Schwaber and I can’t think of reading anything relating these directly to the Scrum practices.  If you have, please let me know!

So, what are Scrum Values?

These are simply the traits that guide good Scrum.

WARNING: these values will probably lead to a great life too…

Commitment…. to commit is to pledge or engage in, interestingly the prefix -com- means together and completely.  We human beings make commitments every day simply by being.  We commit to be at work when we’re supposed to, we engage in picking up milk on the way home (just as we pledged in the morning), we make ..and meet… a lot of small commitments as a matter of habit. I often think this value is more about conscious commitment – making a promise together and doing everything we can to keep it (remember that sustainable pace!).  We need to be equally aware as a team of our commitments to each other in order to deliver what we initially promised.

Commitment is the driver for sprint planning, and it’s required from everyone involved in that sprint – be they scrum team members or temporarily assigned or needed by the scrum team.  And it continues to drive daily stand-ups when we pledge to our team what we will take on next so that they can plan their work better.

Focus is about concentration and direct attention.  For Scrum teams this can be portrayed in a simple picture showing who focuses on what.

Focus is required throughout sprints, from planning to retrospecting.  Everybody should have only one priority to focus on at any given time, this means each development team member should be giving all of their attention to a single feature or user story! (These folks should be protected from outside noise too by the bigger circles.)  Focus does not necessarily increase productive hours, but it will certainly increase quality and probably morale to boot (less stress!)

More on Openness, Respect and Courage to come…

Take Agile games for example…the purpose of these is for the participants to learn, to have an ah-ha moment and to do it in a pleasant way that affords all types of learners an opportunity to participate.  But people only learn as fast as they are able or willing to…simply playing a game will not teach them. Nor will most learn from a trainer reading them the lessons they should take away from games.

The first step to learning is discovery and to discover people need time.. everyone is different remember.

So the next time you’re running an Agile game like 99 Test Balloons or the Marshmallow Challenge please remember to add in enough time for your attendees to discover for themselves.  If you find yourself telling them what they have learned please STOP and instead ask them ‘What have you learned today?’

This time I was one of the main presenters, alongside Jesse Fewell and Sanjeev Kumar Mishra – who ran a mean marshmallow challenge!

Anyway I digress – it is early Sunday morning  - I decided to present on the Agile Principles and thought I’d share it for posterity.

-I need human conversation, someone to listen to me and occasionally guide. You offer random writings and ask me to put my thoughts in a formatted document.

-I want feedback and collaboration so that we can be ‘together’ on this journey. You simply want my wallet.

-I need to know our relationship is special and meaningful. You sell yourself to anyone who pays.

I really hope you mend your ways some day soon and maybe then we can consider picking up again.

Julie x

PS I feel lighter and freer already – tossing my CSP and CSC paper applications in the bin helped a lot.

In addition I suffer from acute procrastination when faced with documentation.

I picked it up again this year with fresh vigour and spent approximately 40 hours of hair tugging, brain dulling recantations of every Agile and Scrum experience over they years.  I was then forced to distill these into the top three style question that permeates the CSC app.  So far I have managed a grand total of 15/25 questions and the ubiqitous case study.

Still on high with the prospect of what I see as a valuable opportunity to get feedback from my peers I received an email prompting about my CSP renewal..armed with my credit card and a minor nag that I hadn’t managed to finish the CSC app earlier I went to pay my fee.  (Now I had pay another $250 AND my CSC app on top )

It took me a good while to find the renewal link, and then…

Another questionnaire – in fact the same one I filled out two years ago and indeed was assessing others on only a few weeks ago??.  Another piece of documentation that causes most people hours of stress and spell checking.  And no doubt leaves the poor reader somewhat confused and lacking in information (having reviewed several CSP apps myself I know I’ve resorted to google and linkedin for more information on what is written).

I completely understand the need to prove Scrum knowledge – reviewing applications certainly opened my eyes –  however could renewals be more effective and aligned to our wicked Agile ways* if we had real person to person conversations?  I would relish the opportunity to talk openly and honestly with a peer in the Scrum community, it would save time, stress and it would allow reviewers the opportunity to probe a little more

Daydream over…back to my lonely laptop and oodles of documentation…

If you don’t already know these as the Agile Principles you can read more here at Scrum Alliance.

It’s an interesting one to ponder.  Over the years I’ve found when traditional programs fail people tend to blame other people not the process.  In fact I don’t recall a single person blaming waterfall, or any of its constituent parts, for their failure – instead they typically focus on blaming the project manager or the architects or even their customers.

I suspect the reason behind this is because Agile really is about people and not process – aka Mushy Agile.  Agile promotes communication, collaboration, courage and change (when needed).  And it’s much more difficult to blame your colleagues when you’ve been getting to know them as people too.

Really – take look at the Agile Principles and try to find one that you think would directly contribute to failure.  Can you fail because you supported motivated people? Or by delivering working software?  Or how about if you seek to improve your technical excellence?  How about continually making improvements as you learn more?   Can any of these could possibly be deemed the path to failure?

I believe not …