Tuesday, December 11, 2012

Project Silver, our journey, an introduction


The first question would have to be "What is Project Silver?".

Project Silver is the realisation of a vision for a new fundraising SaaS offering from Everyday Hero (http://www.everydayhero.com.au).

It has transformed online fundraising from a drab static process to a colourful, engaging almost magical experience.

This evening marks the night before the end of a journey that has taken me, my development team and the rest of the organisation nearly 8 months of blood, sweat and tears. Over the coming weeks (more likely months) I will be documenting this journey not only for myself but also to share our learnings, successes, mistakes, failures, challenges and convey the astonishing results we have realised.

Given the size and effort of documenting such a journey, my friend and respected Product Owner Anthony Frew has kindly offered to cowrite these posts with me to not only give a perspective from an Agile Coach but also from a Product Owner/Management stand point.

I am a believer that it is the journey not the destination that is most important and because we have successfully delivered this project to the world I thought it would be good to show where we have come from.

Here are a couple of screens to show you the before and after:

BEFORE


 AFTER






Stay tuned for Part 1 ...

Sunday, June 3, 2012

Agile Australia 2012

First (though I have already) I would like to thank @slatteryit for an exceptionally run conference, this is the third year that I have been and it has just gotten better every year.

This year I decided to attend the workshop day the day before the conference which was a great decision as there were some very interesting and useful sessions on leadership, process patterns for improving Agile development and a heap more.

I wrote a heap of notes and have collated them below into, things to try, suggested reading, things to look up (ie new concepts) and interesting quotes and questions.

Things to try
  • Develop a definition of Ready (as opposed to "done"), this helps to have a story ready for the development team before they get started on the coding
  • Waste bucket for stories started but not finish
  • Grooming, time 2 mins for each card to estimate
  • Mark stories with a state of where they are at eg Discover, ready for dev etc
  • Investigate Sonar to convert technical debt into terms of $
  • Reduce batch size (ie dont have 13 point stories, only have up to 5 or 8)
  • INVEST Model (http://agilesoftwaredevelopment.com/blog/vaibhav/good-user-story-invest)
  • Have the team change avatar's each iteration and vote on the best one
  • Get metrics on old features to make sure it is worth rebuilding them into a new system
  • Get working software out to the end user as quickly as possible, perhaps use BETA sites to achieve this
  • Walk a mile in her shoes, get people to "experience" other roles (ie dev and tester, marketing and dev)
  • Exercise - "Wouldnt it be great if ...."
Books/Authors
Things to look up
  • Software craftsmanship
  • Systems thinking
  • Complexity theory
  • Minimal viable change
  • Batch and queue size
  • How to effectively measure cycle time for stories
  • Stop starting, start finishing (ie mitigate switching costs)
  • What are some insightful questions?
  • Kaisen board, visualising technical debt, limit technical debt
  • Infinity circles
  • Rule of Three
  • Cognitive walk through (PO signoff)
  • Card sorting (to do with UX)
Quotes
  • "Strategies can be distilled into patterns if you can use them multiple times"
  • "Family trouble in the team is ok"
  • "Just ask for small chunks of money"
  • "Quality is fit for purpose, strive for perfection later"
Questions
  • How do you deliver valuable chunks for an existing feature?

Sunday, February 26, 2012

My first article published ...

As with any success, it should be celebrated, below is one of mine. :)

Below is a link and a screen shot of my first article that has been published.




Wednesday, February 15, 2012

My Existence Statement ....

Whilst continuing my Scrum/Agile journey, I have found that it is very easy to loose ones way and forget the fundamental reason why we as ScrumMasters/Coachs are in the roles that we hold. Many businesses initially (and sometimes never) truly understand the role that the Coach plays.

Im my current coaching role I am also looked upon as the development teams manager, a technical conduit to the team, a technical resource in my own right and a business analysis resource for non product related projects. Certainly not ideal and has proved to be extremely challenging to juggle all of these hats.

Towards the end of last year and the beginning of this year this, multi hat swapping almost proved too much for me and I felt that the core reason why I was there had been muddied or lost at worst.

Working with another Coach I was challenged to develop my own "existence" statement, a saying or mantra if you will that I could have near me at all times to remind me why I was there and what the primary value was I give the teams I am working with.

You might think that this is a trivial exercise but actually proved to be quite difficult.

Here is the framework for process:

  • Visualise what you believe to be your reasons for being in the role
  • Video yourself expressing these reasons, feelings etc for 4-6 mins
  • Once you are in the mind set start working on the statement "I am the ________ that causes ______"
  • When you find a statement that truly resonates then re-record that saying it a few times
What is most important in this process is you focus on what you care most deeply about with regards to your role. Without this the statement is just words.

This process took me 3 or 4 goes before I was able to capture my statement, which is now written up and very visual on my desk.

Here is the statement I came up with:

"I am the passionate, resonating force that causes my team to meet its commitment and helps set the path to truly astounding results"

This statement doesn't need to be set in stone and if what you care about or the focus you are trying to work on changes so too can this statement.

Monday, February 13, 2012

An Agile Team "Reset"

By its very nature Scrum is a constant journey of inspection and adaption but sometimes there comes a time when it is a good idea for an Agile team (mature or not) to take a step back and review/relearn the foundation principles and practices of Scrum, ie a team "Reset".

I am sure the concept is not new but it was introduced to me by a very talented Agile mentor (thanks Ben *grin*) a number years ago.

With a view to helping other Scrum practitioners, I thought to outline my structure and experience with a recent "Reset" I conducted with my current team.

My primary reason for doing it with the team was they had successfully implemented the practices for Scrum but didn't really understand the values or principles behind it and suffered from the very common situation of "Doing" Agile not truly "Being" Agile ie compliant not committed.

"Reset" Agenda
  • Scrum in 10 minutes
  • The Values of Scrum
  • High Performance Tree
  • Our Team Vision
Scrum in 10 minutes
Many may ask "Why would a mature team need to revisit the fundamentals of Scrum?" to which I would reply, purely to see either where their journey began or where they may have gotten lost. Although my team were 12 months into using Scrum it was really interesting to cover off the 4 meetings (Planning, Daily Standup, Sprint Review and Retrospective) and 3 artifacts (Product and Sprint backlogs and the burn down chart) and discuss the usage and value of each.

A really good example of how to deliver this (and the one I used as a reference) is done by my Mentor/Coach Lyssa Adkins (http://www.youtube.com/watch?v=_BWbaZs1M_8).

The Values of Scrum
Until recently I didn't really appreciate the importance and complexity that values had in Scrum. For a team to truly realise the Scrum/Agile dream each member and the team as a whole needs to embrace and live the values outlined in the Scrum frame work. A common problem with Scrum being implemented is the practices and processes are put in place but the underlying values that make it work are either not articulated or forgotten all together.

To deliver this part of the "Reset" I simply went through the values one at a time (Focus, Commitment, Respect, Courage and Openness) then let the team discuss them. The critical part of this is that each member finds a meaning for the values that means something to them.

Example image http://tinyurl.com/7ljnuf9


High Performance Tree
Now this was an exercise that I had never tried before and to be honest I was a little concerned that the team would find it a little woolly or fluffy but was surprised at the level of acceptance and relevance the team got from it.

The concept of the high performance tree is to create a visual metaphor around the foundation values (or roots) of Scrum. It then extends these roots into attributes and characteristics that describe a high performing team and finally articulating the outcomes that can be achieved.

The Roots
If you follow the order in which I layout the "reset" then this part is quite simple. Simply review the core values of Scrum and set the foundation of this metaphor and depict the "roots" of the tree (below). This can be a very powerful coaching tool on a daily basis, asking questions like "where are our roots weak?" can give the team great insight into where issues may be that they didn't see before. With strong roots (and trunk) a team can then start looking to extend itself to the higher reaching aspects of a high performing team.

Example image http://tinyurl.com/6mr68g7


The Leaves
Next discuss what is beyond the roots and trunk of the tree (ie leaves) and what a team may need to look like if it wants to take its next steps on its journey to high performance. Empowerment, self organisation and trust are just a few of the aspects that the team needs to master. Dependent on the maturity of the team you can either use a predefined list (as I did) or make it more of a discussion. As with the Scrum values the team needs to buy in to this concept, if the concepts discussed aren't valuable to the team then it will not be as powerful a message as it should be.

Example image http://tinyurl.com/7h52b2g


The Fruit
Lets be frank, the main reason we all work so hard with our teams and Scrum is to help them (and the greater organisation) realise the truly amazing things that can happen when a team reaches high performance. The "Fruit" of reaching this goal is to see a team produce faster results and get to the right solution more quickly. It fosters an attitude that allows teams and members to grow as professionals and in their Scrum journey, finally reaching a point with astonishing results and ultimately a team that can do anything.

Example image http://tinyurl.com/7fto8er


Our Team Vision
This exercise is the easiest but most interactive of the "Reset". I simply put up a question on the white board "This would be a great team if ...", the team then got up out of their seats and started discussing and adding to the list. This was a productive section of the "Reset" but in hind sight I should have left a little more time as we had to cut it a little short. The outcome of this should be written up so that it can be displayed in the team area for all to see.

Example image that could come out of this session http://tinyurl.com/7c3qujr

In Summary
Some times it is a good idea to revisit the fundamentals of Scrum, most importantly its underlying values. My team are on the second sprint post the "Reset" and are already showing a reviewed focus, commitment and passion for delivering high quality, working software and continuing their journey on the Scrum path and eventually to high performance.

References:
Scrum values, The NetCircle - http://www.thenetcircle.com/2011/10/18/the-five-scrum-values-and-why-they-matter

High Performance Tree, Lyssa Adkins - http://www.youtube.com/watch?v=t3kKechcwYM&feature=related