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.

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!"

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.

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.

For the Christmas Past section, we asked everyone to take an index card and a Sharpie and spend a few moments reflecting on the year that was. What is their largest regret, the one thing they wish they could change?  With each person having written down one thing. We asked them to "let go" of the past by tearing up the card and giving the remnants to our resident skeleton "Meh" to "take to the gates of hell". There is something so cathartic about writing something down, tearing it up and letting it go. We did have to reassure some team members a couple of times that we wouldn't try and reconstruct their cards!

Christmas Present was a time to celebrate. We asked everyone to think about who had been naughty and nice in 2013, while they enjoyed a cup of coffee and a Christmas treat. We then asked the team to share their thoughts with the group. With the exception of calling out a certain Scrum Master that likes to "borrow" Sharpies and not return them, people focused on thanking those they had worked with in 2013.

We closed with Christmas Future. The day before I e-mailed the team:

Santa is coming to Unity Day! Santa would like to know your Christmas wish for the EDW Release Train. One of Santa’s elves will place a wish card on your desk today. Please find a minute to clearly write one or two words with a Sharpie on your wish card  and bring it with you tomorrow morning where each of you will be able to share your wish with Santa and the broader team. Merry Christmas one and all!

Each team member read out their wish and gave it to Santa's helpers to create a word cloud. The wishes ranged from "world peace" to "a new Sharpie" (from the Sharpie stealer of course). There was a theme about Xboxs and PS4s (and even one request for a PS5!) and a really inspiring set of wishes about enablers for continuous delivery. Looks like Santa is going to have his work cut out for him!

While this set of activities obviously doesn't hit the mark in terms of a true retrospective, it was a fun way to reflect on the year that was and prepare for the year ahead.

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 through 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 rollout 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. Using the Switch metaphor, we started by appealing to the developer's 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 cutover grew closer, the System Team, using their newfound "Jean Tabaka" skills, scheduled a workshop to plan the change. They had learnt from the Trails rollout 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, the RTE had been giving a lot of thought to the rollout approach. His original instinct was to include all the things that "we just had to do" in the scope of the change. The theory was 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 led 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, the RTE suggested we look to increase our pool of subject matter experts by growing our people: Cultivate a sense of identity and instil a growth mindset. Each team was asked to nominate a Git Champion who 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 Technical Lead, "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 instead of 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 to 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 Heath & Dan Heath 

To hear the full story of our journey towards DevOps, watch the video of my keynote at the DevOps Enterprise Summit 2014.

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: https://netpromotersystem.com/about/measuring-your-net-promoter-score.aspx

I was not aware there was a whole book on the topic until a colleague 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.

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.

So what should you do with middle management? In my view you need to embrace them. When I reflect on my journey, I am forever grateful to my coach for the time he put in to helping me learn. +Mark quickly established my "office hours", working out that I came in early and left late. He would drop by to chat either first thing or last thing and sometimes both ends of the day. In the beginning, he did more listening than talking as he invested his time in understanding what drove me and the organisation. While these days I am a huge advocate of the "seek first to understand" approach, at the time it would be fair to say that Mark's desired to understand drove me completely batty! (Much to his amusement.)

After what felt like an eternity, our discussions about what was puzzling me evolved to include observations he had made and advice for tackling challenges. Some days there was more laughter than advice and other days there were raised voices as opinions were passionately debated. Don't get me wrong Mark was not always right, and there were times I didn't listen to him and he was, but the time he invested in me as the "middle manager" of the group, allowed me to become an important part of the success of our agile transformation.  (For those who are not familiar with this part of my journey, I shared how Mark used "embarrassing Em" to kick start our cultural transformation in a previous post.)

While my coach was lucky enough to have a willing middle manager to mentor, not everyone will have that good fortune. Some managers are going to find Agile threatening. Implementing agile most likely means change and no one likes having change done to them.  In this scenario, rather than “pitching” Agile to resistant managers, perhaps consider the advice Dennis Stevens and Mike Cottmeyer, gave at Agile 2013 and don’t talk abut Agile. Instead, focus on the objectives of the business and how you can help management achieve their goals or alleviate their pain.

Another approach I have seen work is what Chip and Dan Heath refer to in Switch as "Find the bright spots.". That is find relevant examples of successful agile transformations where middle management has been a key enabler and shine a light on it. For example, one of the services we offer to the broader company and the local IT community is tours of the EDW Agile Release Train. We have a constant stream of agile folk wanting to bring their management to our “Unity Day” event and to “walk the walls”. I think the thank you note I received from a coach who brought his leadership team through last week is a perfect illustration of how shining a light on the bright spots is working for us:

"Thanks for today.  It was great to see how far you and the EDW team have come.  It has really helped to enforce the agile change ideas within my [Department] leadership group and show them what is truly possible if you put your mind to it ☺"

The life of a middle manager isn't easy, they are essentially the “meat in the sandwich” between the organisation's Senior Executives and operational staff. It is not unusual for middle management to have more responsibility than authority.  This can be immensely frustrating and it makes me wonder if the prevalence of command and control style management is a direct consequence of how dis-empowered middle managers feel in large, bureaucratic organisations. Shifting the focus of middle management away from frustration with organisational red tape to improving the lives of the folk who work for them can be rewarding for both the manager and the teams. Don't forget, middle managers are just as prone to the WIFM (what's in to for me) factor as anyone else.  They have to understand how agile will make them successful.

If you are still not convinced middle management has a role to play in an Agile Business, let me share one last story about the fishbowl conversation I joined at RallyON13 with Zach Nies, Jean Tabaka and Jim Benson. Jim spoke about an organisation he worked with where they “killed all the middle managers” and “it was horrible”.  Jim’s emphatic advice was “Don't do that!”. Jim's argument was that in large organisations we need middle management to maintain order. I would add to this, as mentioned at the beginning of this post, middle management driven change can often be the most successful. I certainly like to think that my passion and drive for agility has been one of the secrets behind the success of the EDW Release Train. Whether you agree with my point of view or not, I would like to leave you with Jim's conclusion on middle managers: "they are people too, they are just stuck in the system”.

Share this with your followers on Twitter

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 our coach 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 PI Planning workshop tentatively scheduled to happen in about 6 weeks.

As the day of our first PI 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".

For the next 3 months, I met with my extended leadership team for an hour a week. Each week one member of the team lead a discussion on a chapter or two. We would discuss the concepts covered, how they might apply to our situation and agreed on the ideas we wanted to implement. Book club was compulsory and if one team member had something more important to do then book club was rescheduled. Shared understating and agreement was paramount if we were going to be successful. Visitors to the EDW Release Train are often shocked when they hear that I called a mandatory weekly meeting to read a book. I am always quick to remind them that no one would hesitate to call a "business" meeting, so why wouldn't we want to make time for a meeting focused on learning ways to improve our "business".

While the "Leffingwell Book Club" (as it was fondly referred to) created the shared understanding that I was eager to achieve, there were some unexpected but positive side effects. First, more book clubs spun up. Our Scrum Masters started with Coaching Agile Teams, our Technical Leads read Agile Analytics, the Test Leads read Agile Testing and one of the feature teams chose to read Lean Software Development: An Agile Toolkit. Second, the foundations of what would become our Leadership Continuous Improvement Team emerged as we created a kanban wall to track all the ideas we wanted to implement.

The third and most amazing side effect of the book club was how it enabled the formation of a team. My extended leadership team was made up of various leaders from the 3 groups that had been merged to create my new organisation. Dean's book gave us safe material to debate (no pun intended!). No one needed to be worried about hurting someone else's feelings when offering an opinion on the material.

Today reading is a huge part of our learning culture. Who is reading what is a constant topic of conversation. When people visit us for "tours" we find our book club wall is one of the most photographed and talked about aspects of the EDW Agile Release Train. Some of our visitors have even been inspired to launch their own book clubs - and not just the agile folk! To quote Dr Seuss, "The more you read, the more things you will know. The more you learn, the more places you'll go."For a list of books that have inspired us, check out our virtual book club wall.

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 fewer 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 Project Portfolio Managers, each overseeing around 20 epics. 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 Agile Release Train.

Our Portfolio Managers act as servant leaders to our development teams; they help protect the teams from bureaucracy and support the teams by removing blockers beyond the team's 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 initiative 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 epics 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 ART Sync with the development teams, escalate and resolve blockers, manage the project finances and coordinate epic stakeholder attendance at the System Demo. 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 huge responsibilities across a portfolio of epics, and some move on to less challenging, more traditional project management roles. I have huge respect for our Portfolio Managers; it's a very challenging role, which requires very advanced juggling skills to keep all the balls in the air.

The EDW Agile Release Train was established as a fixed capacity model of five permanent feature teams. As our ability to deliver has improved over the last year, the demand for our services has increased. This led us to contemplate our options - do nothing, add another team. extend the capacity of the existing teams - and decide 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, and it seemed logical. Worst case, should our experiment fail, we could always go back to teams of eight by launching a sixth team.

Development Manager, Wayne Palmer, discussed the concept with the Scrum Masters, and everyone agreed it seemed like a great idea. So we went about recruiting five new developers. After a few iterations, all the teams had an additional developer, and we watched and waited to see what would happen.

Four iterations (8 weeks) went by, and we were surprised to find that nothing happened! Throughput did not increase, nor did it decline; it essentially remained constant. It appears Brooks was right; nine women can't make a baby in 1 month! Having long been an advocate of Brooks' law, it was fascinating to see it materialise in front of me.

Wayne took the data to the Scrum Masters and asked them what they had observed since adding an extra developer to their teams. Their observations were consistent, team members had become more focused on their areas of specialisation, and the team had started to lose the cross-skilling that had been central to our early agile success. The consensus was we should return to eight-person teams and consider experimenting with even smaller teams in the future!

It was time to execute "Plan B" and move from five teams of nine to six teams of eight.  Again we watched with interest to see what happened, and this time the throughput of the Release Train went up!

While we did not get the result we hoped for, our experiment did provide a solid approach for growing an Agile Release Train. By adding an extra person to each team in the first instance, new developers were immediately immersed in our culture and ways of working, quickly acclimatising. When we finally made the call to create an additional team, we weren't adding a new team from scratch, avoiding much of the teething pain that a brand new team of brand new developers was anticipated to cause us.

The lost opportunity in all this was the opportunity to experiment with team self-selection. We had always said that if we ever went to a sixth team, we would look to the train to self-organise and decide for themselves which team members would form the sixth team. But somewhere in all the shuffling, we lost sight of this. If we ever go to seven teams, I will definitely be considering self-selection as an approach.

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 Hard when 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, then 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 us check out our bookshelf.

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 Practice 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. The intent of the class was to introducing Agile and 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!

Follow a recommendation from some agile coaches I spent my Christmas break reading Scaling Software Agility. I was intrigued by the Agile Release Train concept and it was not long before I was plotting with my team how we might implement one.

While we did leverage many of the ideas from Dean's book, Agile Software Requirements we did not by any stretch of the imagination, implement SAFe "by the book". The message I gave my team was "Dean's book contains a lot of great ideas, but Dean does not work in Data Warehousing and he does not work in this organisation. We need to look at the concepts and principles and work out which of these are applicable to our situation". And that is exactly what we did. Among other concepts, SAFe gave us: cadence, a single program backlog, the system team and a way to be agile inside a largely waterfall organisation.

Today we still leverage SAFe, it a significant component of our Agile toolkit, but it is by no means our only source of inspiration. When I reflect on our world, Dean's words come to mind, "we stand on the shoulders of giants". We use Scrum, XP, Kanban and Lean (in the ways recommended by SAFe), however we have also been heavily influenced others, including: Jean Tabaka's Collaboration Explained, Henrik Kniberg's Lean from the Trenches, Scaling Agile at Spotify, Toyota Kata and Ken Collier's Agile Analytics.

My philosophy, when it comes to the various schools of thought, methodologies and frameworks in the Agile domain, is possibly best articulated by Bruce Lee: "Adapt what is useful, reject what is useless, and add what is specifically your own." 

For a more extensive list of books that have inspired me and my team check out our bookshelf.