Confessions of a SPC Cheating on the Scaled Agile Framework

I’ve developed a knot in my stomach. I feel like I’m about to cheat on one of my early Agile loves – SAFe. It’s just exploring, right? Well, maybe… maybe I’ll go back, but then again maybe not. I guess I won’t find out until I try, right?

I am a SPC, a Scaled Agile Framework Program Consultant, and I’m going to a Scrum@Scale class next month. Not just any Scrum@Scale class, but one taught by Jeff Sutherland. [insert giddy giggles…]

Jeff isn’t the only draw.

I’ve been a SPC for almost five years and was on the team that explored how we might be able to implement the Scaled Agile framework at a former employer. In fact, I may have been the very first Product Managers who was certified as a SPC. It was a big deal and I was very excited about it. Who doesn’t love the SAFe Big Picture?


That Big Picture was a huge draw for us to evaluate SAFe in the early days of our Agile transformation. It was a natural extension of what we had recently accomplished by adopting Scrum. There it was; a recipe book for how to build software at scale in our large, complex environment. For that reason, SAFe took hold in the organization.

As Jeff and the team at Scrum, Inc. have aptly pointed out, not all companies, and certainly not all Scrum implementations are the same. I would add that as you mature along your Agile journey, the recipe book that was once comforting might now feel a bit restricting. I’ve heard it from some of our customers, “…we really like parts A and C of SAFe, but D and F feel like overkill and unnecessary.”

Additionally, I have recently been working with Scrum teams that don’t build software, but need to scale beyond the single Scrum team. Although those smarter than me may disagree, SAFe doesn’t quite feel right in these instances either. Scrum has expanded beyond the domain of software, and we need to find ways to scale that fit.

And this is when I started to explore...

Let’s inspect and adapt not just how we apply Scrum and other Agile methods, but how and why we should scale. My interest in branching out as a consultant and coach, and even as a SPC, is to explore how we might help those that don’t quite feel that popular scaling frameworks like SAFe “fit.” The lighter weight, modular, fractal structure that we see in Scrum@Scale may be just the right approach to scale an organization.

Stay tuned. In about a month I’ll let you how it goes. Meanwhile, anyone want to cheat with me?  Scrum@Scale with Jeff Sutherland, November 8-9, Durham, NC

Registration Link
 

SatSSAFe.png

A CEO’S PERSPECTIVE ON AGILE

DBS Bank CEO Piyush Gupta

DBS Bank CEO Piyush Gupta

I recently attended and spoke at the inaugural internal Agile conference by DBS Bank in Singapore, which to my surprise opened with comments by the CEO Piyush Gupta. The term “comments’’ fails to describe Piyush’s exceptional articulation of how Agile connects to the bank’s strategy. He covered three major topics - agility, Agile and the way forward for DBS.

“Agile with a little a”

DBS wins awards and justifiably claims the titles “Asian bank of choice“ and “best bank in Asia.” Interestingly, the five year journey to the industry leading position started with the executive team focusing on values, then the “plumbing” of the bank or how work gets done. The end of the journey is a nimble, “Goldilocks-sized” bank - not too big and not too small, that is agile with a little a. Decisions happen quickly, service groups resolve issues fast and DBS measures innovations in days or weeks. As a result, the bank has a foundation to tackle future challenges such as a wider set of competitors, extremely high customer expectations for performance and great experiences, and customers that “need banking, not a bank.” He sees an existing product delivery framework incapable of delivering at a competitive speed to create “moments of joy” for customers.

IMG_2792.JPG

“Agile with a big a”

Piyush started this segment of his talk briefly describing the problem with traditional software development. People create written specifications, which are often wrong or captured incorrectly. Then other people design and develop a solution. Then a new group of people test the solution and find problems that have to be fixed by the developers. Then the product goes live and is often not what the customer needs or no longer viable in the market. 

Interestingly, Piyush identified “limitations of the human brain” as the problem. He channeled Jeff Patton’s comments in User Story Mapping by stating that we are incapable of sufficiently capturing the sum total of the requirements for a new product on paper. The person recording the requirements probably misses 30% of the information and the person stating the requirements probably hasn’t even realized another 30% of what they need.

Agile gets out of this conundrum through small teams working daily with the business in short cycles to see the outcomes along the way. The teams rely on conversation instead of paper. As a result, customers see new products quicker. DBS tests and learns faster from more frequent customer interaction. To get there, the bank needs to “fix the kitchen to get the right meal to the right customer at the right time.”

Agile in a large bank raises concerns of chaos. How do 20 teams “own the thing?” How can we ensure security? How will we manage defects while developing new products? What is the change management process? Then Piyush got a laugh from the audience. “Agile doesn’t mean a Bohemian, hippie-like attitude to managing core banking systems.” He set goals for rigor in DevOps, test automation, daily regression tests and disciplined, parallel processes - Agile to build new solutions and DevOps to deploy them.

The Way Forward

While DBS is well positioned in Asia, Piyush sees a long way to go compared to Silicon Valley and other Asian companies like Alibaba. Apple Pay threatens all big banks. Apple builds faster and better than the banks. DBS must “operate like those guys” at Google, Apple, Facebook and Amazon.

“The road ahead is longer than the road behind.” DBS needs to quickly figure out how to effectively develop solutions across multiple Asian countries; how to reimagine jobs, roles and skills; and leverage human-centered design to always keep the customer in mind.

A DBS conference attendee during a session

A DBS conference attendee during a session

Piyush beautifully described how the lines between application development, business people and product managers are and must keep blurring. Silos must go away as DBS integrates digital customer experiences, new technology and new approaches to delivery. “Agile with a big a” is not just about technology, he said. Ultimately, every project must leverage Agile for DBS to compete.

He certainly kicked off the two day event on a high note. I have participated in several, similar conferences and had not seen such a senior executive begin the conference let alone speak about the connection of Agile to strategic challenges with conviction and clarity. Piyush’s words led to a deeper, richer and focused experience for the attendees and the six international speakers. As we closed the conference with an interactive exercise for attendees to reflect on what they discovered and remaining “puzzles” followed by an informal panel session to discuss a few of the puzzles, I felt confident and optimistic about the prospects for the DBS Agile journey. I met great people who want to be Agile and they have an exceptional leader who knows what that means for DBS. 

conference speaker laura richardson

conference speaker laura richardson

from l to r: DBS conference organizer howard lim, dbs conference organizer soh wai zee, speaker russell healy, valtech coordinator elin wai, speaker laura richardson, speaker xavier renaudin, valtech MANAGING DIRECTOR HENRI PETITET, SPEAKER JASON TANNER

from l to r: DBS conference organizer howard lim, dbs conference organizer soh wai zee, speaker russell healy, valtech coordinator elin wai, speaker laura richardson, speaker xavier renaudin, valtech MANAGING DIRECTOR HENRI PETITET, SPEAKER JASON TANNER

MY DBS "speaker buddy" and friend freddie yeo. he did a great job making sure i got everywhere i needed to be on time and shared all sorts of new cuisine!

MY DBS "speaker buddy" and friend freddie yeo. he did a great job making sure i got everywhere i needed to be on time and shared all sorts of new cuisine!

singapore skyline from the top of the marina bay sands resort where we adjourned to celebrate the end of a fabulous event

singapore skyline from the top of the marina bay sands resort where we adjourned to celebrate the end of a fabulous event

What We Believe About Agile

Happy New Year! We hope that 2015 started great for you. To kick off what we expect to be more frequent blogging, this post describes what we believe about Agile. I'm motivated to write this for two reasons - to explicitly state our point of view and to prepare for a Certified ScrumMaster class that I'm teaching this week.

Agile is four values and twelve principles found on the Agile Manifesto home page and on the Principles behind the Agile Manifesto page. That's it. We believe that if an organization of people works together in a way that is aligned to these values and principles that the organization is Agile. We approach all of our teaching, coaching and other consulting from this point of view.

Agile isn't daily meetings, user stories, continuous integration, product owners or other related activities, artifacts or roles. Agile is a mindset of collaboration to create great products incrementally and iteratively, frequently adjusting based on changes in the world around us and what we learn.

A group of people could work in a way that is Agile with a model of interaction that they invent. In other words, you don't need Scrum, Extreme Programming, SAFe, Kanban or any other framework to be Agile. However, frameworks certainly help people execute efficiently and consistently.

We created Applied Frameworks because we believe in fulfilling the needs of people and organizations to be more effective and happier in their work to produce great products that meet and exceed their customers' needs. We believe that an Agile mindset enables us to accomplish WHY we exist.

This year we want to help you and your organization find your most effective and happiest state of execution and hope this is your best year yet. Let's go!


Top Ten Signs That Your Product Manager Isn't Agile

Blog Editor's Note: This post originally appeared in late 2008 when we were Enthiosys. I'm very interested in whether anyone else agrees that the list still resonates. Enjoy.

Originally Published October 20, 2008

Here at Enthiosys [now Applied Frameworks] we spend a lot of time helping Product Managers become Agile. In the process, we often run into developers who are really frustrated with their Product Managers' lack of Agility. Acknowledging their pain, here are our top ten ways to tell if your Product Manager doesn't understand Agile. And yes, it was hard to whittle down from the 40+ items on our initial list.

10. She says "I think" instead of "the market research says" or "during our last review meeting with a customer…".

9. He thinks release planning can be done in 2 hours.

8. She sometimes attends an iteration planning meeting, and rarely (or never) attends an iteration acceptance meeting.

7. He thinks the backlog is just the list of market problems he captured in his MRD.

6. She doesn't have a roadmap beyond the stories in the next release.

5. He thinks MuSCoW works when prioritizing the backlog.*

4. She can't provide acceptance criteria during release or iteration planning.

3. He stops visiting customers so he can attend every daily standup. Even worse, he talks about his tasks during the daily standup.

2. She thinks that year-old market data is good enough for managing the backlog or developing a roadmap.

1. He thinks a product owner is a Product Manager.

*MuSCoW is a way to organize requirements into buckets of "Must, Should, Could, Would".