Thursday, 12 December 2013

An Agile Christmas Story

Today was the first day of the last iteration for 2013! To celebrate the EDW Release Train had a Christmas theme for Unity Day.
Gingerbread Reindeer 

It all started after our Movember "Ginger-Mo" fund raising event, when one of the team showed me how to turn an upside down gingerbread man into a gingerbread reindeer. The next thing I know we are planning Christmas pudding chocolate crackles, mistletoe cup cakes and meringue Christmas trees. The end result being a Christmas themed Unity Hour with just one condition from from Development Manger, +Wayne Palmer: "As long as I don't have to dress up as an elf!"

My boss dressed as Santa
Wayne would live to regret planting that idea in my head. While Christmas shopping on the weekend I came across an Christmas Elf t-shirt and couldn't resist purchasing it for Wayne to wear. Luckily he is a good sport. He even offered to wear green tights, but there was universal consensus that this was unnecessary! Not wanting to leave behind the rest of my team I also purchased Christmas t-shirts and Santa hats for my other direct reports. Before I managed to escape the shopping centre I came across $12 Santa suits, now this was really too good to resist, would my boss be willing to dress up as Santa? As it turns out he is also a good sport and immediately responded "Sure. No Problem." to my Saturday afternoon text message.

With my boss in a Santa suit, my team in their various Christmas t-shirts and plenty of Christmas treats to eat we were ready to end the year on a high. For me the end of the year is always an excellent time to reflect. We decided to use Dickens' "A Christmas Carol" as the base for the agenda - Christmas Past, Christmas Present and Christmas Future.

Tuesday, 26 November 2013

Switch in Action: Business Change Management Applied to Software Engineering

As regular readers of this blog would know, I recently read Chip & Dan Heath's Switch (which I blogged about here). One Saturday evening in July, whilst only a short way though the book, I found myself thinking of the challenges we had rolling out "Trails", our automated deployment tool. Even though Trails was built by our System Team, using agile methods, including fortnightly demonstrations of working software, the roll out was far from smooth. Would we have been more successful if we had used the Switch Framework? Switch argues that for change to be effective you have to Direct the Rider (our rational side), Motivate the Elephant (our emotional side) and Shape the Path (clear the way).

A few months later, the System Team had another change ready for implementation. This time we would be changing the EDW source control repository from SVN to Git. Given the experience with Trails, the System Team made a huge effort to get buy in from the impacted teams. They spent countless hours at the whiteboard talking with teams about why version control is important and how version control will enable better data in development environments. There was some resistance, strangely enough because some engineers thought the proposal was to replace SVN with a bespoke in house application called "GIT"! The conversation improved significantly once everyone got on the same page. To use the metaphor from Switch we had started by appealing to the developers rational side, the Rider, by Pointing to the Destination: Change is easier when you know where you’re going and why it’s worth it. 

As the cut over grew closer, the System Team, using their new found "Jean Tabaka" skills, scheduled a workshop to plan the change. They had learnt from the Trails roll out that no amount of PowerPoint or documentation would make a difference. What had worked last time was sitting with the engineers while they tried to execute the new process and helping them. If Switch was to be believed, we should:  "Follow the Bright Spots. Investigate what’s working and clone it."

Replicating this approach was not as easy as it would seem at face value. With Trails the change was less invasive, only impacting the engineers executing a given deployment. A member of the System Team could sit with the engineer each time they needed to use the new deployment tool until they were comfortable. With Git, we needed all six teams to make the change at once. After coming to the realisation the System Team were not Gremlins and could not be multiplied by adding water, a different approach was required.

In the days leading up to the planning meeting, EDW Development Manger, +Wayne Palmer had been giving a lot of thought to the roll out approach. His original instinct was to include all the things that "we just had to do" in the scope of the change. The theory being that the engineers were going to have to use a new tool anyway, so they wouldn't know the difference. Thankfully his train of thought eventually lead him to refer back to Switch. He knew his instincts were wrong, we needed to: Shrink the Change. Break down the change until it no longer spooks the Elephant.  He talked to the System Team Product Owner about the magnitude of the change. They discussed their hopes and fears for the upcoming deployment and decided to defer the major change to the current branching strategy, continuing with branch by project rather than moving to branch by feature.

Even with a smaller change we were still going to need more support than the three System Team developers could provide, if we were going to be successful. Again using the advice from Switch, Wayne suggested we look to increase our pool of subject matter experts by growing our people: Cultivate a sense of identity and instil the growth mindset. Each team was asked to nominate a Git Champion that was passionate about the change and respected by their peers. The System Team then partnered with the "volunteers" to define the process that would be used to migrate the non-production code from SVN to Git.

The change was deployed one Sunday a few weeks back and to quote the System Team Lead Developer "It went scarily well". That is not to say we have not had some hiccups since.  Last week someone accidentally deleted the master branch in order to overcome a merge conflict, by using an SVN technique as opposed to a Git technique. Thankfully these types of errors are easy to back out with Git!

All things considered, the concepts we used from Switch lived up to their promise. I do think we missed a trick when it came the third component of the Switch Framework - Shape the Path. While the hiccups we experienced have not been catastrophic, with more focus on ideas like building habits they might have been avoided completely. So next time you are looking to change the behaviour of your software engineering team don't forget:
For things to change, somebody somewhere has to start acting differently. Maybe it’s you, maybe it’s your team. Each has an emotional Elephant side and a rational Rider side.  You’ve got to reach both. And you’ve also got to clear the way for them to succeed.            Chip & Dan Heath 
To hear the full story of our journey towards DevOps watch the video of my keynote at the DevOps Enterprise Summit 2014.



Tuesday, 12 November 2013

Measuring Team Happiness

When I accepted the role leading the EDW delivery team, I knew my biggest challenge was going to be customer engagement. I had been a customer of the team for a number of years and I am sad to say I would not have recommended their services to anyone. Now the tables had turned, I was the head of the organisation and I had to change the business perception of our ability to deliver if we were going to survive.

It is a little known fact that I used to work in Market Research. My portfolio included Brand Research, Customer Satisfaction Research and the occasional Employee Satisfaction survey. Given my background in Customer Research, naturally my curiosity was peaked when my employer moved from measuring customer satisfaction to implementing the Net Promoter System (NPS).

For those of you not familiar with NPS, it is a customer loyalty metric, developed by +Fred Reichheld and Bain & Co. NPS is measured by "the ultimate question": "On a Scale from 0 to 10, where 0 is not at all likely and 10 is extremely likely, how likely are you to recommend [Company Name] to a friend or colleague?'. Responses are categorised into Promoters (scores of 9 and 10), Passives (scores of 7 and 8) and Detractors (scores of 6 or less).  The percentage of promoters minus the percentage of detractors is the Net Promoter Score.

Source: http://netpromotersystem.com/about/measuring-your-net-promoter-score.aspx

I was not aware there was a whole book on the topic until +Mark Richards mentioned he had been reading the book behind the Net Promoter System, +Fred Reichheld's The Ultimate Question 2.0. So of course I followed suit. While the book gave me quite an extensive list of ideas to follow up the one message that spoke to me the loudest was that "You can't create loyal customers without first creating loyal employees." or as I like to phrase it "happy teams lead to happy customers". The Ultimate Question 2.0 uses Apple Retail as a case study, citing a correlation between stores with high customer NPS scores and employee engagement scores and vice versa.

Tuesday, 22 October 2013

Advice for Agile Coaches on "Dealing With" Middle Management

Over the past few months I have been fortunate to attend a number of Agile Conferences. A theme I observed, particularly in open spaces and social conversations, related to the role of middle management in an Agile Transformation. Questions like: what to do about Middle Management, how to deal with the "frozen middle" and what is the role of an Agile Manager kept coming up.  To be honest the answers given often surprised me. The most common view I heard advocated is "get rid of them".

Strangely, I have also found I tend to be the only middle manager in the vicinity, or least the only one willing to own up to being a middle manager, when the topic comes up. Hence, I  have been known to inject a different perspective into the conversation. What if middle management weren't a blocker to change, but actually the key to unlocking change? I have a theory that middle management lead change is often the most successful. As my boss always says, its the middle managers who actually make things happen across the company.

When working with development teams, the buy in of middle management is critical. Middle Management can be either a force for good or kryptonite to an agile transformation effort. If teams perceive that management does not support agile, how will they ever feel safe to experiment and risk failure? I have seen agile adoption attempted in organisations where management still holds a traditional mindset. It can be devastating for teams that have invested in agile values like transparency, to be reprimanded by management for exposing the truth.

Sunday, 13 October 2013

Book Clubs at Work - Are You Serious?

As mentioned in a prior post, the idea for the EDW Agile Release Train came from reading +Dean Leffingwell's Scaling Software Agility. A couple of months after reading the book, there was a restructure and I found myself leading the technology team that I has previously been a customer of.  I was eager to pitch the idea of forming an Agile Release Train to my new team, so I arranged a series of workshops with the key leaders across the group.

From these workshops I hoped to achieve shared understanding and agreement on the shape of our future organisation. We kicked off with +Mark Richards sharing what he had learnt about Agile Release Trains from Dean's Lean Agile Enterprise Leadership Workshop. We also provided everyone with the details of Dean's more recent book, Agile Software Requirements. Over the remaining workshops we debated various organisational models, operating principles and approaches to getting started until we landed on a majority consensus on the way forward. With our vision agreed it was all hands on deck to get ready for our first release planning (PSI) workshop tentatively scheduled to happen in about 6 weeks.

As the day of our first release planning event grew closer, I noticed that there were some blank faces among my extended leadership team when I referred to various aspects of what we needed to do. My heart sank as I asked the team, "Who has read the book?". A couple of hands were raised. "Who has finished the book?". Only one hand (and yes he still works with me!). "Who doesn't own the book?". At least four or five hands were sheepishly raised. "OK" I said "Change of plan. We are all going to buy the book. If you cannot afford the book, let me know and I will arrange a book for you. Then we are going to read the book together. We are going to form a book club!" As Deming said, "without theory there is no learning".


Sunday, 29 September 2013

What Happens to Project Managers When You Implement SAFe?

What happens to Project Managers when you implement SAFe? I see this question come up time and again and while I am sure there is more than one answer, in my experience, the role of the Project Manager changes and there are less of them. In the specific case of the EDW Agile Release Train, pre-SAFe there were 18 Project Managers supporting up to 5 projects each. Today there are 4 Portfolio Managers each overseeing around 20 projects. Portfolio Managers are generally aligned to a specific line of business or program of work. They own the relationship with this stakeholder group on behalf of the Release Train.

Our Portfolio Managers are servants to our development teams, they help protect the teams from bureaucracy and support the teams by removing blockers beyond the teams control. When new projects arrive, they work to smooth the transition of the work into the development teams. They do this by understanding the end to end project and the role EDW needs to play, establishing the priority of the work and securing funding.  They confirm the stakeholders and induct them into our delivery approach, and where possible help break the projects down into pieces more easily consumed by the development teams.

Most of our epics, start with an analysis spike, which we call discovery. This is where our feature teams establish the high level design, estimate the effort involved in delivering the epic and work out an indicative release plan based on their current backlog. The Portfolio Managers support the teams by overlaying the financial profile and packaging up the findings for inclusion in the various enterprise gating processes.



During the delivery of the epic the Portfolio Managers participate in the daily Feature Wall stand up with the development teams, escalate and resolve blockers, manage the project financial and co-ordinate epic showcases with stakeholders. Where necessary, Portfolio Managers, will also negotiate changes in release windows and commercial coverage for additional features. Post deployment, the Portfolio Manager arranges for the formal project closure, facilitates a retrospective on the epic's delivery and obtains a Net Promoter Score from the epic owner.

So what happens to project managers when you implement SAFe? In our case, some grow, taking on the huge responsibility across a portfolio of epics and some move on, to less challenging, more traditional project management roles. I have a huge respect for our Portfolio Managers, its a very challenging role, which requires very advanced juggling skills to keep all the balls in the air.

Sunday, 22 September 2013

How to Grow an Agile Release Train

The EDW Agile Release Train was established as a fixed capacity model consisting of five permanent feature teams. As our ability to deliver has improved over the last year, the demand for our services has increased. This lead to us to contemplating our options - do nothing, add another team. extend the capacity of the existing teams - and deciding to run an experiment.

The train teams were all 8 person feature teams consisting of 1 Scrum Master, 1 Technical Lead, 1 Quality Lead and 5 Developers. Given, the optimal size of an Agile team is considered to be 7 ± 2, in theory we could add another developer to each team and increase throughput. The idea was appealing, it seemed logical. Worst case, should our experiment fail we could always go back to teams of eight by launching a sixth team.

Sunday, 15 September 2013

Switch: How to Change Things When Change Is Hard by Chip & Dan Heath

Having read and really enjoyed Chip & Dan Heath's first book, Made to Stick: Why Some Ideas Survive and Others Die, I bought Switch: How to Change Things When Change Is Hardwhen it was first released, however it sat on my bookshelf gathering dust until I heard +Jean Tabaka talking about it when she visited Telstra in June. In Switch, the Heath Brothers have done a a great job of making the science of change management simple. The book borrows an analogy from +Jonathan Haidt's The Happiness Hypothesis of the Elephant (our emotional side) and the Rider (our rational side). The premise being if the Elephant doesn't want to go in the direction of the Rider, than the Rider is out matched and the Elephant goes the way it wants.

The book is broken into three sections:
  • Direct the Rider - Find the Bright Spots. Script the Critical Moves & Point to the Destination
  • Motivate the Elephant - Find the Feeling, Shrink the Change, Grow Your People
  • Shape the Path - Tweak the Environment, Build the Habits, Rally the Herd

What I particularly like about this book, was the accessibility of the message. As Agilists, it is often our role to change or transform the teams we work with. Switch provides simple techniques that Agilists can immediately apply. I know this, because I have seen it in action. So no matter what your role, if your work involves changing behaviours this book is for you.

Some of my favourite takeaways from Switch:
"What looks like resistance is often a lack of clarity.
"Find the bright spots.. What's working and how can we do more of it?" 
"In almost all successful change efforts, the sequence is ... SEE-FEEL-CHANGE. You're presented with evidence that makes you feel something." 
"Shrink the change." Not only does this help flow, but "When you engineer early success, what you are really doing is engineering hope".
To read about how we applied Switch when introducing changes to the software development teams that formed part of the EDW Release Train check out: Switch in Action: Business Change Management Applied to Software Engineering

For a more extensive list of books that have inspired me and my team check out our bookshelf: http://www.prettyagile.com/p/bookshelf.html

 

Sunday, 1 September 2013

A Perspective on the Scaled Agile Framework

I have watched with interest and disappointment over the past month or so as Agile thought leaders have taken to publicly passing judgement on the new kid on the block, the Scaled Agile Framework aka SAFe. In the interests of full disclosure, I am a certified SAFe Program Consultant, I use SAFe with my team and my teams approach to implementing SAFe is featured in the case studies section on scaledagileframework.com.

Over two and half years ago, I went on two days of Agile Fundamentals training lead by +Mark Richards. Mark's approach to introducing Agile was to provide us with a tool kit we could use to apply Agile in our work place. I remember talking about aspects of Scrum, XP, Kanban and other methodologies. We talked about various agile values, principles and practises, and we participated in a number of learning activities. After the two days in the classroom and a heap of new ideas to think about, the message I walked away with was - "Agile is a term for a range of methodologies that have in common the principles embodied in the Agile Manifesto. We should embrace the full range of tools available to us and chose which to apply in any given context."

Following the training, we commenced our first agile "pilot" project. The transparency introduced by agile, quickly led to all new projects using agile. It was only a number of months before we had 6 agile teams, across 4 projects, working in parallel with a large outsourced offshore team, on a single code base. As if this was not already a recipe for disaster, we also had no clues as to how to effectively co-ordinate the teams and the work. Agile Fundamentals had not prepared us for this at all!

Monday, 26 August 2013

My Agile 2013 Experience - Day 6 of 6

Friday


The closing keynote for Agile 2013 was "Why Everyone Needs DevOps Now: A Fourteen Year Study Of High Performing IT Organizations " by +Gene Kim, author of The Phoenix Project. (If you haven't read The Phoenix Project you can download a free 170 page excerpt here.)  This is the second time I have heard Gene give this presentation and I must say I was very pleased to discover that on this occasion it had been video taped and posted to the Agile Alliance website. 

Just in case you were considering not watching Gene's keynotes, let me give you a small taster of his findings:
  • High performing organizations deploy code 30 times more frequently, and 8,000 times faster than their peers, deploying multiple times a day, versus an average of once a month. Frequent deployments, coupled with faster change lead times, enable operational agility.
  • High performing organizations have double the change success rate and restore service 12 times faster than their peers. Fewer failures and faster recovery mean less risk to the business when changes are deployed.
The video of Gene's keynote can be found here.



And so my first Agile 20xx conference came to a close. It was sad to say goodbye, but I must confess I was ready to catch up on some sleep. Hopefully this blog series gave those who did not attend a taste of what the conference is like. For me the investment was well worthwhile, I heard lots of great talks, I met lots of great people and I had a great time! Bring on Agile 2014!


Friday, 23 August 2013

My Agile 2013 Experience - Day 5 of 6

Thursday


De-Mystifying Kanban: Understanding Its Many Faces +Al Shalloway

Al provided a very thorough and complete explanation of the various flavours of Kanban. He covered:
  • Kanban as a signal
  • Kanban as a Team Development Process
  • Kanban’s Roots in Lean 
  • Scrum as a Manifestation of Lean
  • Lean Kanban University (LKU) Kanban aka The Kanban Method
  • Kanban Thinking or Lean-Kanban
  • Getting Started with Kanban
Al very kindly chose to record his presentation and make it available on his website. He also posted the slide deck here.


Gaining Support for a Sustainable Agile Transformation +Dennis Stevens and +Mike Cottmeyer 


Dennis and Mike believe Agile is about team and if you can't get to teams you fundamentally cannot get agile to work. When getting started with agile, figure out what is the right thing to form teams around.

When it comes to agile at scale, the challenge is how to coordinate multiple teams delivering output at the same time. You need to determine "what are the things that are shared, and what are the things that consume the shared stuff". At scale the performance of the team isn't as important as the performance of the corporation as a whole. Focus less on team velocity rather focus on cycle time at the program and portfolio level.

Dennis and Mike told us scaling is hard, because books tell us what it looks like but not how we get there safely.  You have to align the team, management and executive perspectives to create the safety for an agile transformation. If you are in a place where you don't have trust in the team it's probably because they haven't delivered because of the system around them. Overloaded teams will find it safer to say 'yes' and fail, than to say 'no' to more work.

When it comes to starting an agile transformation start by understanding the business drivers of the organisation, define the operational framework, introduce change incrementally, measure improvement and tie it back to the business drivers.  Most people in the face of good data won't make irrational decisions. Cultural shift is important but it takes time and requires safety, you have to create the operational model first. "You are not going to kumbaya yourself into an agile enterprise!"


The Language of Change +Esther Derby 


Everything touches everything. If we are trying to change one thing it always impacts another. How does language play into the success of change? How do people talk about change in your organisation?  Do they use words like: change management, drive change, create a burning platform, evangelize, cut the dead wood, clean house, roll out change, overcome resistance. When we use language it's not just the words that are active in our brains.  98% of our thinking happens at an unconscious level.


We are awash in metaphor everyday. It is pervasive, everywhere we go, in every conversation we have. When we use metaphor it kicks off a process in our heads, a frame, with roles and scenarios, therefore we need to be careful and intentional about the language we use. The way we talk about change, for the most part, masks the complexity of what we are doing. When we use metaphor and kick off that script, it makes it more difficult to engage. Every change is different . You have to start where you are and find your own road. Every time we have a gap between our values and actions, cynicism and fear fills the gap.

There is always an emotional element to change. Denying the emotion keeps it in play. You don't need to fix it you just need to acknowledge it. People eventually adjust to change and reach a new status quo. The best time to make a change is when folks have successfully integrated the last change. The worst time is when things are in a state of chaos.

When we change the structure of an organisation we impact identity, status and affiliation creating resistance. When there is resistance we push hard and the resisters push back and don't feel heard.
People resist for a number of reasons, they don't trust the person behind the change  or they might think its a really stupid idea. When people don't feel like they are being heard they hold on harder. The reasons people may resist change are mostly pretty legitimate - to save the things they value.

Changing organisations changes people, impacting identity, status and affiliation. You need to provide support, empathy and time to learn.  If we want to succeed in change it requires trust. Trust must be given (not earned). Trust is not binary, it is always contextual and bounded. Trust is one of the reasons that change fails. People don't resist change they resist coercion. We need to connect. If we don't connect we don't have trust.

Esther recommends the following reading material on this topic:
Metaphors We Live By by George Lakoff & Mark Johnson
Facilitating Organization Change: Lessons from Complexity Science by Edwin E. Olson & Glenda H. Eoyang
Satir Change Model
Slow Ideas by Atul Gawande



Agile Business Intelligence & Data Warehousing Open Jam




Lean Cocktails
Organised by +Lynn Winterboer, the Agile Business Intelligence & Data Warehousing open space was an opportunity to talk with "esteemed authors" +Scott Ambler and +Ken Collier as well as a number of practitioners about the challenges specific to using agile in the data domain. The morning session was so successful it was followed up by "Lean Cocktails" at the end of the day.





Conference Party




Held at Nashville's Wild Horse Saloon the conference party was unlike any conference party I had been to before. Everyone was given a cowboy hat and bandana on the way in and it was not long at all before the line dancing started! While I chose not to line dance myself, +mia horrigan and I enjoyed watching +Matthew Hodgson join in the fun.







Read the next blog post in this series: My Agile 2013 Experience - Day 6 of 6

Thursday, 22 August 2013

My Agile 2013 Experience - Day 4 of 6

Wednesday


When NOT to Have All the Answers: Stop Giving Advice and Start Asking Questions +Judith Mills  and +Christopher Avery 


Judith started by telling us about her addiction to giving advice and her realisation:
"If I was going to be successful I couldn't be the expert I had to change the culture. Changing the culture isn't about imparting knowledge, its finding a way to tap into teams, have them take responsibility" and she immediately had my attention.

Together with Christopher, Judith walked us through the responsibility process and how we respond to problems; moving from blame, to justify, to shame, to obligation. This is how we have been conditioned. If you are not familiar with the responsibility process, which I must admit I wasn't, here is the link to a one hour video overview.

The main premise of Judith's presentation was that questions empower. When you ask questions you are engaging someone, asking them to be creative, and honouring their intellect. When you give advice you take choice away from your teams so they don't feel responsibility.  Technical people are used to being the smartest people in the room, they can be a little socially awkward and not wanting to draw attention to themselves or ask questions. Christopher says,  "We need to create the culture where we are able to be vulnerable". This of course struck a cord with me given my last blog post before Agile 2013 was about "Leading Through Vulnerability". 
"The cool thing about responsibility is you can't make anyone take it, all you can do is offer it and allow it" - Christopher Avery
In closing Christopher recommended reading. "Multipliers: How the Best Leaders Make Everyone Smarter" by Liz Wiseman.

Scketchnotes by +Michele Ide-Smith 


Hiring (or Growing) the Right Agile Coach +Lyssa Adkins and +Michael Spayd 


Lyssa and Michael's session focused on the Agile Coaching Competency Framework and how it can be used as a tool for self development, developing others or even deciding what sort of coach you need and assessing the competencies of potential coaches.

Agile Coaching Competency Framework (http://www.agilecoachinginstitute.com/agile-coaching-resources/)

Lyssa showed a handful of videos of coaches she had worked with talking about how they had used the Agile Coaching Competency Framework which can be found here. I have posted my favourite of these by +Erin Beierwaltes below.

Agile Coaching Framework -- Erin Beierwaltes' Take


Enterprise Agility - A Practical De-Mystification  - Hendrik Esser, +Jean Tabaka and +Esther Derby 


Hendrik, Jean and Esther's presentation was very different to the other sessions I attended. The three of them perched on stools at the front of the room, having a conversation, reminded me of a fishbowl (without the extra chair for someone else to join the conversation). They undertook to provide the audience with three perspectives on achieving Enterprise Agility. Given the presentation used a more conversational style, my notes are reflective of this and hopefully I have attributed the comments to the right speakers!

Jean Tabaka's recommended reading list for Enterprise Agility
The first topic, Flow, was introduced by Jean Tabaka. Jean said, "I don't think agile is sufficient on its own to deliver value to the customer,... I don't think executives should be talking about story points or velocity,... Good executives pay attention to "intraprenuers". "The flow of value Agile" is the best way to learn quickly. We have to take a long view of the flow of value, start earlier than the team and look beyond effective deployment to the hands of the customer. In value stream flow we watch: customer, cadence, capacity, clogs, cost and collaboration.

Collaboration across all different parties is essential. You are not going to be enterprise level agile unless you are collaborating with upstream and downstream process.   Collaboration doesn't happen on its own, you have to help it. For Enterprise Agility we need to move from a language of cross functional to cross departmental.  Hendrik Esser commented that "you need to look at the whole product life cycle" and Esther Derby noted, "The way accounting works and the way people are rewarded is keeping things the way it is".   Esther also mentioned that the Agile Alliance is sponsoring an initiative to look at an agile accounting approach.

Hendrik covered the second topic, Collaboration and Decision Making.  Collaboration is about abandoning contract thinking between different parts of one enterprise. Esther echoed this, commenting that "We need to adjust our plans so we can satisfy our customer rather than "you missed the date you won't get your bonus". We need to visualise uncertainty if we want to embrace change for example provide a range of possibly delivery dates rather than specific milestone date. Jean gave the analogy of Neo choosing between the red pill and the blue pill in The Matrix.  "People willing to embrace a sense of uncertainty are taking the red pill". Enterprise agility requires us to have a new way of measuring success and failure, different metrics other than points and velocity. In Jean's view, the only useful metric is one the team asks for to help itself understand how it's doing.  Esther pointed out that this holds true not only for development teams. Hendrik added at Ericsson "We measure our performance not our people".

The third topic was Eco-system, lead by Esther. If you keep replacing the individuals and get the same results it is a clear indication there is a system problem. Trying to "idiot proof" through policy or procedure almost guarantees you will get "idiotic behaviour". "I find job descriptions often get in the way of people collaborating", said Esther. We have a legacy of thinking of organisations as machines. This is not the type of ecosystem that enables flow, adaptability and responding to change. Trust begets transparency and transparency begets trust. Without this, decision making and flow breaks down. Trust is contextual not binary, and to get trust at an ecosystem level you have to give trust. What people don't know they fill in with their own fears.

The subject of building trust, brought some of +Brene Brown's material from Daring Greatly to mind for Jean: "If you have shame and blame there is no possibility of innovation We are asking individuals to be vulnerable, to enable this the organisation needs to extend its vulnerability". Esther closed out this section with the following messages: "You need to start where you are. Trust grows incrementally. Once you start seeing systems, blame goes away. It's very powerful!"

KEYNOTE: Forty Years of Trying To Play Well With Others - Tim Lister


Tim's keynote was a journey through his 40 year career as told through nine stories. This one of the handful of sessions that were videoed and posted on the Agile Alliance website. So rather than try to summarise it, here is the link.

Music City Concert Tour


I know you are thinking, wow, she made it to Nashville and saw some live music, sorry to disappoint but the Music City Concert Tour was the name of the conference event, held in the exhibit hall, Wednesday evening. While I didn't see or hear any country music stars, I did get a free flashing guitar pin - which made brilliant "gifts" for my leadership team when I got home.

As with all the conference social events, it was another great opportunity to meet people, such as Hendrik Esser, and catch up with people I had met in Boulder earlier this year, including +Ronica Roth+Drew Jemilo and +Jennifer Fawcett

After grabbing some dinner at one of the hotel restaurants, I headed to a gathering hosted by the guys from Leading Agile+Dennis Stevens and +Mike Cottmeyer, where I scored a great (free) t-shirt. Thanks guys!


Read the next blog post in this series: My Agile 2013 Experience - Day 5 of 6

Wednesday, 21 August 2013

My Agile 2013 Experience - Day 3 of 6

Tuesday


Agile Metrics: Velocity is NOT the goal +Michael "Doc" Norton 


Doc opened by explaining that Velocity is a lagging indicator for a complex system and lagging indicators are good for monitoring trends but are poor predictors of the future. He advocated the use of standard deviation in forecasting velocity, noting: "The Business won't like this but it's the closest you can get to the truth with the data you have". Doc also warned against the use of velocity targets, "When you set a target for velocity you unintentionally introduce all sorts of problems into the system".

Next Doc talked to the multiple causes of variable velocity, that cannot be identified by simply looking at velocity numbers. He suggested the use of scatter diagrams to show correlation, at the same time reminding us correlation does not always equal causation. He also illustrated the value of using cumulative flow diagram. In summary, Doc recommends measuring many things, including "Team Joy" (a leading indicator) and remember "Metrics are not for managers, metrics are for teams!"


Agile at Scale at Spotify +Joakim Sundén and +Anders Ivarsson 


For me this was the session of the week. The story of scaling agile at Spotify is inspiring, growing in only three years from 30 developers in one location to 400 developers across four locations and offices all over the world.

For Spotify the single most important principle to maintaining speed at scale is Autonomy. Squads, the term Spotify uses for an agile/scrum team, are autonomous. They consist of  5 to 7 engineers and no more than 10 people in total. The are cross functional, have their own mission, they own a feature across all platforms (including maintenance) and they have their own team workspace. The squad chooses which process to use - Kanban, scrum or whatever else - based on what works best for them. The team is free to select its own work and set its own office hours.

One of the challenges with this model is defining the organisational structure to support the squads without decreasing autonomy. As the organisation grew to 150 engineers they found people didn't know each other anymore, so they created a smaller context, Tribes, made up of squads with a similar mission and of no more than 100 people (based on Dunbar's number).

To help with alignment across Squads within the same Tribes Spotify uses Chapters. Chapters bring together people with similar competencies, for example testing, on a regular basis to share challenges relating to their specific area of expertise. The Chapter Lead is the line manager for the chapter members and looks after the personal development (Spotify's term for career development) of the chapter members. Guilds are used for alignment of Chapters across Tribes.

There is great paper on this by Anders and +Henrik Kniberg, 'Scaling Agile @ Spotify', which provides a much better explanation on Squads, Chapters, Tribes and Guilds.  I also came across the below You Tube video of Anders talking about Agile at Scale @ Spotify at London Lean Kanban Day 2013. 

You Tube video of Anders Ivarsson at LLKD13


Be Agile. Scale Up. Stay Lean … & Have More Fun! +Dean Leffingwell 


Dean provided an overview of the Scaled Agile Framework, its roots in lean thinking, agile development and product development flow and the new material included in v2.5. He went on to talk about the power of 'ba', showing the New Zealand All Blacks Haka video as an example, followed by a very amusing set of video clips of teams he has worked with doing their own haka. The EDW Release Train hakas did not feature in the video montage, but embarrassment was only momentarily spared.

Unbeknown to me, Dean had created a slide from my blog post, The Power of Haka. When he reached this slide in his presentation, I was pleasantly surprised and went to take a photo to send to my team, when Dean asked if "Em" was in the audience. In hindsight, I'm thinking raising my hand was a mistake. I was sitting about 15 rows back, and there is no way he would have spotted me if I had just sat still. The next thing I know, he asks me to stand up, then decides its my story so I should speak to the slide, as he wanders through the room so I can use his lapel microphone.

Everything past that point is a bit of a blur, however I'm pretty sure Dean wrapped up his presentation by talking to a number of case studies (including the EDW Release Train) that have had improvements in employee engagement since the introduction of SAFe.


Continuous delivery? Easy! Just change everything. (Well, maybe it isn't that easy) +Steve Stolt and +Steve Neely  


Steve and Steve told the story of implementing continuous delivery at +Rally Software to a packed room. In May 2010 the engineering team operated in 2 week sprints and eight week releases, today they run Kanban and release features "when they want". They started the process of moving to continuous delivery by understanding their existing processes and removing the manual steps. Along the way, they learned that you need to monitor everything and you must be able to trust your tests i.e. you can no longer ignore tests that regularly fail.

For more detailed information on their story check out the paper by Steve and Steve here.


Tuesday Evening


My Tuesday evening was spent at Rally's Good Old Fashioned Bluegrass Fest held where I got to, very briefly, meet newly published author, +Geoff Watts (check out his book Scrum Mastery: From Good To Great Servant-Leadership). While waiting in the drinks queue, I witnessed long time twitter buddies +Adam Yuret and +Jean Tabaka meet "in real life", which was amusing.

During the evening I ran into +Dean Leffingwell and took the opportunity to ask him to warn me next time he would like me to participate in a presentation. Looking back, I don't think I actually got him to agree, but I did at least get a thank you for helping him out, so I guess that is something! The "Bluegrass Fest" also provided an opportunity for me to catch up with guys from Boost Agile, +Nathan Donaldson and +Jacob Creech, who are doing great things with Agile in Shanghai.


Read the next blog post in this series: My Agile 2013 Experience - Day 4 of 6

Tuesday, 20 August 2013

My Agile 2013 Experience - Day 2 of 6

Monday


I missed Monday morning's keynote to attend the Executive Forum. In hindsight, the Executive Forum was not the best use of my time and hence I decided to spend the remainder of my day checking out sessions from the main conference.

The Keynote, "Coding for America: How Agile and Lean are disrupting government -- and why they need to", was videoed and can be viewed on line here.

The Agile Mindset +Linda Rising 


This session was definitely my highlight from Day 1. Building on a theme touched on by +Mary Poppendieck and +Torbjörn Gyllebring at Agile Australia, Linda explored the fixed versus agile (growth) mindset. This session was a sequel to her Agile 2011 Keynote, 'The Power of an Agile Mindset' which I can also recommend.

Linda's message was clear: mindset is not fixed, we are born agile and research has shown we can develop either a fixed or agile mindset. Stereotyping is dangerous, as those being labelled become believers in the stereotype (as illustrated by the "blue eye/brown eye" exercise). To foster an agile mindset, praise effort not talent eg. You worked hard on that! vs. You're so smart!". Failure is essential to learning.

Linda recommended the following books:

Creating Great Businesses Requires Great Empathy +Jean Tabaka and +Robyn Mourning 

Jean and Robyn's workshop focused on teaching techniques for using empathy practices to shape better solutions. They showed a powerful video of George Kembel from the d.school at Stanford talking about how using design thinking resulted in a more child friendly MRI machine. (While not the video shown by Jean and Robyn, this footage of George Kembel telling the story can be found here - start from 4m45s.). The workshop provided an overview of the design thinking process used at +Rally Software: Empathise, Circumstance, Define, Ideate, Prototype and Test, based on the d.school process. The session left me with no doubt that "Guessing is easy. Empathy requires discipline".

http://dschool.stanford.edu/our-point-of-view/

For those interested in learning more Jean recommends the Virtual Crash Course in Design Thinking by the d.school at Stanford

DevOps isn't Enough for your Dysfunctional Organisation by +mandi walls 


Mandi helps companies implement devops but finds the problems that generally need to be addressed are less about technology and more about people and process dysfunction. She pointed to specialisation, prioritisation and conflicting incentives as the origins of this dysfunction. Tools she recommends to combat this include: goal setting, communication, self awareness and training.

When it comes to implementing devops, Mandi likes to conduct a baseline assessment of the current state and reasons for change by talking to everyone and she has some great questions she uses. My favourites included: "What is the most broken thing about the current process/project?" and  "Who is able to hold your project hostage?"

Mandi was kind enough to post her presentation on slideshare which provide a more details on her approach to implementing devops and some great questions you might want to use in assessing your project's current state.


Ice Breaker Reception


My original plan for Monday evening was to check out The Time Jumpers with +Lynn Winterboer+Erin Beierwaltes and +Ken Collier. Unfortunately, jet-lag got the better of me and I ended up taking an unscheduled nap instead! Waking up around 8pm, I wandered down to the Ice Breaker Reception, only to find myself embroiled in another round of "Six degrees of Jean Tabaka"! In this round I was lucky enough to meet +Gino Marckx+Brian Adkins,  +Jabe Bloom (@cyetain) and +Abby Fichtner  (@hackerchick). I really think there is a future in this game if I could only work out a way to monetise it - perhaps a certification would work! ;-)

Read the next blog post in this series: My Agile 2013 Experience - Day 3 of 6

Monday, 19 August 2013

My Agile 2013 Experience - Day 1 of 6

Having been back home for a week, I have spent a week being asked "How was Agile 2013? What were your key takeaways?" and answering "I haven't digested it all yet. I need to order my thoughts." In an attempt to avoid further embarrassment, I decided to put pen to paper (or fingers to keyboard) and order my thoughts in the best way I know, by writing them down.  And having gone to all the trouble of writing them down, I figured I may as well share my thoughts with the blogsphere...

Sunday


Agile 2013 was my first time at an Agile 20xx conference and I wasn't sure what to expect. Having arrived Saturday afternoon and caught up on some much needed sleep, I was excited to catch up with friends from Colorado on Sunday afternoon. After meeting +Jean Tabaka at registration, I spent what must have been almost two hours in the main lobby of the conference centre being introduced to what felt like the who's who of Agile by Jean. In fact, have now seen how many people Jean knows in the Agile community, I was beginning to think it might be fun to invent a new game called "Six Degrees of Jean Tabaka". It has a nice ring to it don't you think?

After picking up our swag (cool t-shirt!), it was time to weave our way through the maze that is the +Gaylord Opryland Resort & Convention Center to find somewhere for a quiet drink before the Ice Breaker event. On our way through the maze, Jean got stopped by +Lyssa Adkins and +Michael Spayd as we passed each other in one of the corridors. Lyssa says to Jean, "I have just published a blog by Em Campbell-Pretty..." and Jean points to me. It was such a strange serendipitous moment and a great way to kick off my Agile 2013 experience. (Lyssa featured "Leading Through Vulnerability" on her Women in Agile blog in July).



The Welcome Reception (i.e. drinks!) helped me reconnect with my Agile Data Warehousing buddies +Ken Collier and +Lynn Winterboer. I also introduced myself to fellow Aussies +Matthew Hodgson (whom I recognised from his Scrum Australia presentation) and +mia horrigan. The evening was topped off by a lovely dinner with Jean,  +Anders Ivarsson+Joakim Sunden and Jaana Nyfjord,. The conference hadn't even really started and already I felt the investment had been worthwhile!

Read the next blog post in this series: My Agile 2013 Experience - Day 2 of 6

Wednesday, 24 July 2013

Leading Through Vulnerability

When +Jean Tabaka ran her Scaling Collaboration workshop with my team in June, she commented on how open the team was to the experience and asked us how we went about creating an environment where traditionally introverted software engineers, from a diverse range of cultures and backgrounds, were so willing to participate in team activities. From my perspective there were lots of contributing factors eg. the HakasBubble Ups, lean coffee management meetings etc. but it all began with the weekly practise of "walk the walls".

"Walk the walls" came about after I got sick of listening to my coach, +Mark Richards, carry on about what a waste of time my program status meetings were. At this time, I worked in "the business" and as program sponsor  I felt it was my duty to sit down with the program manager once a week to receive an update on the status of the program. Mark, on the other hand, was convinced that there was a deeply embedded culture of fear that was preventing the delivery teams from telling the real story. He was adamant if I spent more time with the teams I would be able to see this for myself.

Wednesday, 10 July 2013

Inspiring Software Engineers to Embrace Facilitation

At the beginning of June, I travelled to Boulder, Colorado to attend and speak at RallyON 2013. This was my first time attending RallyON and I wasn't sure what to expect. I diligently downloaded the Spotme app as suggested by the event organisers and spent a good hour or two trawling through the agenda selecting the sessions to attend. I was travelling with my friend and ex-coach, +Mark Richards, who has always been a huge fan of Rally Agile Fellow, +Jean Tabaka, so I thought I would add Jean and +Laura Burke's breakout session, Scaling Collaboration: Be the Hero Your Agile Teams Need You to Be, to my selections.

On the first afternoon of the conference, Mark and I wandered down to HUB Boulder and found ourselves a couple of seats at a table up the front. Jean and Laura were setting up, writing on flip charts, and directing attendees to sort themselves into tables of 5. It is at this point that I panic, and turn to Mark with what I am sure was a look of sheer terror, and said "You didn't tell me this was going to be a joining in activity type session!". Mark smiles, clearly amused at my discomfort, and says "What did you think was going to happen at a Jean Tabaka session?"

+Bryce Day Scaling Collaboration session - packed room, just finished first collaborative task - nice work! #RallyON13

Tuesday, 25 June 2013

The "Bubble Up" Approach to Scaling Retrospectives

One of the many initiatives I am really passionate about within our EDW Release Train is the commitment of my extended leadership team to continuous improvement. However, we have had some challenges identifying the right targets to improve! Instinctively it didn't seem like something that would be that hard. Surely if the train teams were experiencing pain in their every day work, they would tell us - or so I thought!

I was under the impression we had broken down the communication barriers in our program wide retro a few months into our first attempt at scaling agile. On that occasion, our coach facilitated two hour sessions with each of the agile teams, consolidated the feedback, and worked through it with the program leadership. This retro was a significant turning point in our program. It brought to the surface a number of pain points impacting multiple teams, and started the thought process that lead to the formation of our Agile Release Train and our System Team. As it turned out, while this moment was significant, we had not advanced as far as I thought we had.

Monday, 27 May 2013

The Power of Haka

According to Wikipedia, the Haka “is a traditional ancestral war cry, dance or challenge... performed by a group, with vigorous movements and stamping of the feet with rhythmically shouted accompaniment.” When I attended Dean Leffingwell’s s SAFe Certification course earlier this year, he used a video of the New Zealand All Blacks performing a haka to illustrate “The Power of Ba”. “Ba” being the place teams are in when they become high performing, self organising and energized. If you watch the video I’m sure you will agree that the spine chilling performance is the perfect illustration of what it feels like to be part of a team that has truly reached “ba”, a place where “we, the work and the knowledge are one”.

Recently, there was a reshuffle of people in our scrum teams, predicated on the need to more evenly balance skills and knowledge across the EDW Agile Release Train. This change was unsettling for the teams and I started to think about helping them find their “ba” again.  This lead me to contemplate how I might convince to the teams to invent and perform their own haka.

Monday, 20 May 2013

Can Lean Coffee Replace Management Meetings?

An unexpected takeaway from Scrum Australia was Lean Coffee.

I had the good fortune to travel to Scrum Australia with three of my team members. On day two we decided that a hot breakfast was in order, so we met up at what had become "our place", Strawberry X Cafe. Over breakfast we got talking about our new ideas from the Scrum Australia sessions we had attended, as well as general improvements we would like to make to our ways of working, peppered with random conversations about things to do and see in Sydney!

Three hours later, we were all talked out and one of the guys turned to me and said with a big grin "We just had an impromptu lean coffee!". Having never taken the time to join a lean coffee meetup, I was a big baffled and asked for an explanation.

Tuesday, 14 May 2013

My key takeaways from Scrum Australia

When first invited to Scrum Australia I was dubious, but as I always say, "nothing ventured nothing gained", so I thanked Martin Kearns for the invite and booked my trip to Sydney!

For me Kenny Rubin stole the show. Given I am SAFe Program Consultant, Kenny's views on Economically Sensible Scrum and Strategies for Portfolio Management really resonated with me. Kenny opened with a story about an understaffed restaurant that seated more customers than it could comfortably serve. Customers waited hours for service and everyone who ate in that restaurant that day had a poor experience. He positioned the economically sensible alternative would have been for the restaurant to limit the number of customers it accepts to the number it can comfortably serve. The result, some customers may get turned away, but the customers who do eat at the restaurant that day walk away with a positive customer service experience.

Wednesday, 3 April 2013

In the beginning...

It's been two years since I started my Agile journey in earnest. At the time I was the business sponsor of a significant capital investment being made by Corporate into the delivery of a true enterprise data warehouse. As the business owner of the program, I owned the business requirements, but very little else. Projects in this domain followed a  traditional waterfall style SDLC. The business produced a business requirements document and the IT teams then produced a raft of other documentation (such as a requirements definition document, a system requirements specification etc.) and about 6 months later all this documentation was passed to an off-shore vendor for build and test. Another 6 months would pass and then the business would be asked to acceptance test the deliverables and the endless negoitation about what was and was not in scope would start.

While I had been reading about Agile for a couple of years, the opportunity to put it into practise didn't come until our ongoing dissatisfaction with our existing development processes led to the realisation that to be successful we needed to do something different. This burning platform when coupled with the organisational push towards agile gave us the ideal launching pad to transform how data warehousing projects were delivered in the organisation. This is not to say Agile is a magic bullet, rather it gave us permission to change the focus and tone of the conversation.

While our first agile projects were far from perfect, they showed promise, so we continue to launch new projects and spin up new Agile teams every couple of months. One year into our Agile journey, we had a number of teams across a number of projects but we were struggling to make Agile work at scale. It was around this time that I read Dean Leffingwell's Scaling Software Agility and became convinced establishing an Agile Release Train was the answer to our scaling issues.

As fortune had it, within months of reading Dean's book, I was offered the opportunity to lead the data warehouse software delivery organisation. And so for the last year I have had the great privilege to work with an exceptional team of people and together we have transformed the "laughing stock of IT" into what I believe is a world class Agile Data Warehousing team, or as we know it the EDW Release Train.

This blog will chronicle our adventures...