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.
Is one more important than the other?
Continue reading “Stop! enterprise agile and Scaled Agile are not the same thing”
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 – what exactly 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?
Continue reading “Product Owners: How to start with ‘Why’”
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
I enjoy hearing from my readers. Got a great tip? A confusing scenario? Heard of a new game or event? Please share it by entering it on the contact page.
If you are excited to hear from me, please subscribe for new content.