The technology arena is saturated with agile – particularly in software development with the maturity of Scrum and the lean method of Kanban. The momentum created by the successes of collaboration, transparency, and adaption in a technology group naturally seeps into the rest of the organization. It’s not uncommon to see leadership decide to take those same frameworks and apply them outside of technology to other divisions such as Business Intelligence, Marketing, and Creative Services. There are often some early successes, particularly in the beginning. But many non-technology teams experience challenges that are not answered through the application of the same frameworks that created the successes in technology.
I am a proponent of the popular frameworks and models. They provide safety in an agile transformation so we have a playbook to guide us through the labyrinth of change management. So why not just pick a framework and start with where you are at? Because to fully harvest the benefits of agile at a team level, it is best to start with fertile ground – create an agile environment.
In this blog, I take a practical look at six steps that help nurture and grow agile at a personal level (what you might describe as the agile mindset); a team level (including those pesky managers who don’t know what self-organizing teams will mean to their job); and an organizational level (how do we do more and how do we do it better.) Continue reading “6 steps to agile outside of IT”
[Disclaimer #1: Warning: strong Scrum language ahead. If you don’t speak Scrum, you can make it through this blog, but you might need to review the Scrum Guide. For example, I use the Scrum term Product Backlog Item (PBI) which can indicate any requirement in the backlog. The PBI might be in the form of a User Story, but a PBI can be non-functional requirements, technical debt, or anything the Product Owner wants in the backlog.]
You are <anyone on the Scrum Team.> You are half-way through Sprint Planning and tasking stuff out but realize there is a major dependency that cannot be mitigated. Everything is blocked. Sprint Planning starts over with a new Goal.
You are the Product Owner (PO). You bring your beautifully written PBIs to Sprint Planning and start planning but you can’t come to a consensus on a Sprint Goal because the Development Team keeps interrupting with things they need to do before they can build what you want.
You are a member of the Development Team. You are ready to dig in and task stuff out, but the PO hasn’t had time to prepare. The whole team spends the day writing PBIs.
You are the Scrum Master. You are texting all your buddies asking for a diversion phone call because this train wreck is just too painful to watch.
It needs to be said: Poor Sprint Planning leads to a heavy, bloated, wandering Sprint. A Development Team that just can’t take flight. Work gets blocked for days because the team is waiting on another team or resource to do something important – but they have their own important stuff to do. PBIs blow up, they don’t get finished, everyone is frustrated, and then there is the great rationalization to let stuff slide into the next sprint because it is “almost done.”
From David Anderson, the founder of the Kanban movement: “with Kanban we’re using visualization, a working progress limit (WIP), and a quantitative measurement to stimulate Kaizen (Japanese for “improvements.”)
Me: In Kanban, we show all of the work in the system on one board, control how much we work on at any one time, and use data to improve the flow of the work through the system.
My friend: And they pay you to do this?
When I was first introduced to Kanban in 2009, it was this funny sounding thing, (which I didn’t really know how to pronounce) and while I understood the whole “controlling WIP” concept, I have to admit, I felt like it was just lazy Scrum. But, as I get to know Kanban more, I’m realizing all I didn’t know. Continue reading “Kanban – it’s not just lazy Scrum”
I’m working with a colleague on a client’s organizational design issues. So I started to refresh my thinking with industry resources and reading. I call it “spring training” (even though as I write this, we are in the dog days of summer in the Sunshine State right now, with a hurricane or two thrown in for fun.) I think of it as the same thing that a pro baseball team does in the spring – making the investment to hone my craft. It’s the third part of my coaching kata: practice the principles, uphold the values, continually improve. (Don’t have a coaching kata? Here’s how to get yours.)
My spring training has validated a core belief. To borrow from Oprah, there is one thing I know for sure:
Low Trust = High Process
Process kills Innovation
Innovation is the life blood of any organization that wants to exist more than 15 years, the average age of a company today. And for innovation to be in the bloodstream of a company competing in our global business world, we can think of cultural agility as the heartbeat, the regular cadence of responding and delivering, responding and delivering. Cultural agility sounds sexy, and for a start-up, it’s as natural and necessary as breathing oxygen into that bloodstream. But for those of us working with mature organizations to move the cultural needle, it’s darn hard.
My spring training also taught me something new. I came across this quote on the agile insights blog:
“Agile is a subset of Lean principles and practices which are in turn a subset of Systems Thinking.”
As an agile consultant, I help organizations understand the different frameworks such as Scrum, Extreme Programming, or Kanban all share agile tenets, and which one to use for their problem. However, I often thought of Agile and Lean as friendly cousins, if you will, borrowing favorite outfits from each other on their way to delight the customer. I’m taking my thinking one step further, and I really want your feedback. Do you find the below to resonate?
I recently passed Scrum.org’s PSM III* with the 95 required to continue in the trainer process. It was challenging – and it took more than one try. Here’s 500 words on what worked, and why it was worth it.
Coaching can be lonely. It’s hard. It’s complex. It’s subjective. We take it personally. There’s a 1,000 books and blogs on how to do it right, and yet, no one way to do it right.
Nearly ten years ago, my coach, Jesse Fewell called me a ‘Truth Sayer.’
“If you are not on the verge of getting fired, you are not doing enough. The trick is, don’t get fired.”
Unfortunately, it appears I was born without the fear of being unemployed. I have never shrunk away from the hard conversations. On the counter side, my performance evaluation every year starts with a management session on ‘your delivery.’ (I have also never shied away from self-improvement.) But I keep going, and I keep growing. Perhaps it is my Libra optimism, or perhaps it is the Western culture I grew up with, born of the East: “Fall down seven, get up eight.”
This does not make me unique, in fact, I have found most coaches to have similar makeups.
To be an agile coach, to live in our world, means to grow resilient, to embrace connections, to thrive on experimentation.
Jesse also taught me: “Divorce yourself from the outcome.” However, even us tough guys and gals can have our world shattered. Perhaps we are in the game too long without validation. Perhaps someone hit on our deepest insecurities and wounded us mightily. Perhaps the organization was not ready – or perhaps they were not ready for me.
It’s been 15 years since the Agile Manifesto and there is no refuting the consistent evidence that agile works. The Standish Group’s 2011 Chaos Report states that “Agile projects are three times more successful than non-agile projects.” Nearly every technology shop is working within some kind of agile framework, mostly Scrum. However, if you are working in the field, you might have recently used the term “Scrum-but.” For the uninitiated, this term refers to the myriad of ways that teams, trying to deliver in an agile fashion, conflict with traditional requirements, supervision, reporting, and bottlenecks.
Scaling agile for delivery efforts versus an enterprise culture.
If we are talking about multiple teams working on one product, program or value stream, we are talking about scaling Agile. There is no one-size fits all model, although four of the five best known scaling models are based on Scrum. Every one provides a framework for organizations to deliver big, complex features with multiple moving parts.
They don’t offer solutions for hiring the right talent; for determining compensation in a team-based world; for structuring contracts with vendors that complement agile deliverables rather than handicap them. They don’t describe how to partner with clients on delivery projects with a focus on value and quality instead of scope. They don’t focus on how to grow the agile mindset.
Once we are talking about anything outside of delivering the work, we are talking about enterprise agility. Enterprise agility encompasses all aspects of an organization. It requires a baseline of a learning culture, a shallow organizational structure, and the embedded value of experimentation. It goes beyond development teams: HR in hiring for passion, retaining the agile mindset, and developing new career paths; Legal and Accounting to adjust their vendor and client contracts; Marketing and Sales to collaborate with customer relationships in frequent feedback and planning sessions. In fact, perhaps the proof of an agile organization is shown through the crucial handshake between business and technology.
I’m going to leave this right here: I think being a Product Owner is the most difficult roles in Scrum, and one of the least supported, which adds to the difficulty. I see so many new Product Owners struggling with the role, I started the Tampa Bay Product Owner Meetup – and if you are in the area, we’d love to have you come!
I wanted to write about a great tool I’ve borrowed from a product master, Roman Pichler. It helps with the following scenarios I often see in engagements.
The Product Owner has an exciting new idea they want to implement, they bring it to the development team, they deliver a passionate description. The team launches right into development – but several sprints deep it feels like a struggle, and someone asks: “So – whatexactly are we building – and… why? Another common question when things go awry: “Did anyone think about… (fill in the workaround, risk, issue, here…)”
Conversely, we have experienced Product Owners who make the mistake of going too deep, designing the solution before they have clarified the ‘what’ and ‘why.’ This reduces the discovery process with the development team who could help innovate and eliminate waste long before they start writing code.
Hopefully we have all experienced the success stories too. Success comes when execution of a new product starts with the foundation of shared understanding within the whole Scrum Team. The product takes flight, development seems to fall into place, morale and creativity flow as easily as the banter in the Scrum events.
We all know these anti-patterns but how do we avoid them?
Words matter! Check out the latest addition of Scrumguides.org to freshen up your coaching language. Why? Because as coaches, trainers, evangelists and enthusiasts of Scrum, it’s up to us promote crisp Scrum practices and precise language. And “because Ken Schwaber and Jeff Sutherland developed the framework, the Scrum Guide is written by them, and they stand behind it.” [ScrumGuides.org]
It’s not a ‘standup’ –> it’s a ‘Daily Scrum.’ Standup is actually a term from XP, it’s not part of the Scrum framework. Like writing User Stories, it’s a common practice because it helps us keep those daily Scrums short and to the point.
It’s not a ‘ceremony’ or a ‘meeting’ –> it’s an ‘event’ and we want our Scrum Teams to honor them.
Forgo ‘commitment’ –> emphasize ‘forecast.’ Check out this great article about why the word ‘forecast’ fits our world of collaboration and change better than ‘commitment.’
‘Done-Done’ is done –> ‘Done’ will do it!
‘Grooming’ has a very different and very negative connotation in some countries than it does in the United States –> the Scrum Guide supports using the word ‘refinement.’
‘Prioritize’ has given way to –> ‘Order.’ A Product Owner must make decisions to order the backlog. James Coplien’s article delves into this topic further.
‘User Story’ is not in the Scrum Guide –> Call anything in a backlog a Product Backlog Item (PBI.) Like refining, it’s a generally accepted Scrum practice to write PBIs in the form of a user story, but it’s not an official part of the framework.
Define ‘Team’ –> clarify if you mean it’s the ‘Scrum Team’ or the ‘Development Team’ and help your business owners know the difference. The Development Team owns the Sprint!
‘QAs, BAs’ –> they are all included as ‘Developers’ The Scrum framework makes no differentiation between specialized roles on a Scrum team.
Live your truth; hone your craft; show your thanks