Category Archives: Agile

Don’t Be A Jerk

Posted on by
7

I’ve been threatening for years to put together a presentation titled “Everything I needed to know about Leadership I learned while running a guild in World of Warcraft.” I still might someday, but I’m annoyed with myself for continually talking about it and not doing it, and one of the points I want to make is top of mind today so I’m just going to write it down in a post and consider it pre-work for my epic future Agile Alliance presentation.

I started playing World of Warcraft shortly after it was released in 2004. I had a small group of friends who had been playing City of Heroes together and we all decided to try it at the same time. When enough of us had gotten the game and decided to stick around to do so, we started a small guild (a guild, for those of you are unfamiliar, is a means to communicate and share resources in the game with a specific group of people). Eventually we met another guild that was populated by people who we thought were neat, and we decided to merge the two guilds together.

For some reason I agreed to lead this new guild.

I won’t go into a lot of detail as to why a guild needs leadership, because it’s not really relevant to this post, but the very short version is that there is a lot of content in the game that requires large groups to complete, and part of running a guild is to help schedule teams to take on that content and establish agreements around how any rewards won from beating it would be distributed among the group. Guild leaders also establish the culture of the guild (ours was considered a “casual” guild, with mostly older players who had responsibilities that prevented them from devoting excessive amount of time to the game) and will also set up rules around acceptable behavior by guild members.

When we formed our guild, we had one rule: Don’t be a Jerk.*

For a while, that worked just fine. Everyone understood what being a jerk meant, and we were all pretty good about not being one.

But then the guild grew. We kept adding people who we didn’t know as well as the original members. As our numbers expanded, the line on what everyone accepted as “jerkish” behavior began to get fuzzy. Common sense, it turns out, is not so common. Especially when you’re dealing with a diverse group of individuals who are paying for the privilege of playing a game. People with different backgrounds, who come from different regions of the world, and have a variety of socioeconomic situations, genders, ages, and sexual orientations (not to mention skill levels). Heck, one of our prominent members was a retired grandmother who used to send me cookies every Christmas.

Mardi, if you’re still out there my address hasn’t changed.

Eventually something happened that I, and the folks who helped me run the guild, couldn’t ignore. I don’t remember what it was, specifically. All I remember is that our response to the thing that happened was to create a new rule, so now we had two of them. It wasn’t too long before another incident got our attention, so we created a third rule. Then a fourth. A fifth. You get the point.

When I finally stopped playing the game in early 2009, I believe our rule book was three pages long.

We would make broad announcements about how we have “noticed certain behaviors” and how those behaviors “violate the spirit of our core value of not being a Jerk.” If the person in question continued doing the “thing” we had created the rule for, we could point at the (newly expanded) rules list and accuse them of violating it, thereby justifying our decision to remove the person from the guild.

You know what we never did in any of these situations (before it was too late)?

Talk to the person in question.

Instead of having an open, honest discussion about whatever the infraction was that caused us concern we avoided confrontation entirely and hid behind bureaucracy.

Our reward? More headaches. The bureaucracy that was protecting us from being the “bad guys” continued to grow and become more complex, and eventually got to the point where we spent more time managing rules and people than, you know, playing the damn game.

Eventually it got to be too much for me and I quit playing. All the enjoyment had been sucked out of the game for me, and I walked away. I still have friends who I met playing WoW, and some of them are still playing and in the guild I helped create, but I canceled my account almost 14 years ago and haven’t looked back.

So what does any of this have to do with Leadership in the professional world?

The first, and most important, lesson I took from this was that creating rules to deal with people problems is a no-win scenario. I’m not saying you shouldn’t have rules, codes of conduct, etc…but if you’ve got someone on your team who isn’t working well with others in some capacity, creating some kind of rule, procedure, or process to deal with that person is not being a Leader. It’s managing (and managing poorly, at that).

The other big lesson I learned is that by creating a rule that applies to all members of a team when only one person is responsible for doing the “thing” that caused the rule to be made, you create a situation where the unintended consequence of your action is to cause people who have nothing at all to do with the situation to suddenly worry that THEY were the reason the rule was created. For example, say you have a person in your organization who has some kind of issue with body odor that is disturbing others and instead of having a conversation with that person you send out an all-users e-mail reminding the entire company that “we all have to work together in small spaces” and to “please be mindful of how our personal hygiene might impact those around us.” The person who inspired the e-mail might not think it is about them, or they might realize it is and get horribly embarrassed and/or resentful. Even worse, people who had nothing to do with the original announcement may start wondering if they are the reason the email was sent in the first place.

This lesson shows up in the Agile Manifesto, of course. “Customer Collaboration over contract negotiation” is one of the four values found in the manifesto. Talking with people and working out situations directly is much more effective than hiding behind contracts (and what is a list of rules in an organization but a contract that one agrees to abide by to continue working there?), and how can we argue with the fact that most effective means of communicating information being face-to-face communication?

If I knew then what I know now, I’d have spent a lot more time talking to people and a lot less time managing a list of complex rules. The short term discomfort of having a difficult conversation pales in comparison to the drudgery and annoyance of dealing with the red tape of a ridiculously long rule book.

*In the interest of full disclosure, the word wasn’t jerk. I think you get the drift, though.

Estimates are dead. Long live estimates.

Posted on by
Reply

The act of estimating work brings no value to your customers.

This is not to say that there is no value in estimating work. There certainly can be. But in terms of benefiting the customer the amount of time and effort spent in coming up with estimates is worthless. A customer does not care whether you hit your deadlines, unless missing a deadline adversely impacts them. Conversely, a customer does not care whether you made a deadline or finished a project early, and for the same reasons. This is also not to say that there is no value in delivering a project within a certain time frame. There can be tremendous value in that, from being the first to market on a new offering or just putting something into production that begins generating revenue or cost savings.

But the act of estimating in and of itself, and the act of basing project milestones on those estimations, has little to no value. Human beings are notoriously bad at estimating, and no matter how much effort is put into attempting to define processes that can help in that effort the fact remains that the larger and more complex the work is the less accurate your estimates about how long it will take to complete will be, so time spent trying to come up with estimates is wasteful.

So why do we estimate at all? Why do I, as an Agile Coach, teach teams about things like story points or relative sizing? What that’s the point?

Being able to predict when you’ll deliver value to your customers.

That’s it. That’s the only reason to estimate work. The methods of estimation that I teach are tools that a team can use to predict what value they will generate during their next iteration, and the more mature a team is the less time they will spend coming up with those estimates. The goal is to eliminate the need to use estimating tools entirely. A high performing, mature team should be able to accurately plan the value they will generate in the next iteration (sprint) without needing to put a numeric value on that work.

There is a lot that must happen for that goal to be met. A key component of that is for external forces (i.e. managers, supervisors, executives) to trust that the team wants to, and will be, as productive as possible without constant scrutiny. That’s a big ask, but without it the whole house of cards collapses.

So when I see leadership teams fret about an organization needing to get better at setting realistic timelines for project completion I worry, because when I see that I see delivery teams spending extra time trying to come up with “accurate” deadlines that are, ultimately, going to be wrong. What’s more, that the time spent coming up with those bad estimates could have been spent doing things that generate value for the customers. The only true value generated by asking a team to estimate is that it gives someone removed from the work the ability to absolve themselves from blame when the work is not completed on time (which is, of course, one of the many factors that lead to teams inflating their estimates).

This is always the point when someone looks at me and asks if I’m advocating some sort of system in which there are no deadlines or expectations and teams just churn out whatever they want in their own time without any kind of external influence.

No, of course not.

What I’m advocating is that dates and deadlines should be focused around value.

I’m going to turn to Star Trek to explain my point because that is, as the saying goes, how I roll.

In the original Star Trek series, Chief Engineer Montgomery “Scotty” Scott is often referred to as being a “miracle worker” because he always seems to provide his Captain, James T. Kirk, with what is needed to save the day despite Captain Kirk giving him unrealistic deadlines. In a typical exchange, Captain Kirk will explain to Scotty what the problem is and ask how long it will take to solve it. Scotty will quickly give him an answer (say, for example, “three hours”) and Kirk will respond that he has 10 minutes. Somehow, Scotty always manages to deliver in those 10 minutes. Scotty eventually revealed that he always inflated his estimates to Captain Kirk because “Starfleet captains are like children. They want everything right now and they want it their way. But the secret is to give them only what they need, not what they want.”

I realize that I run the risk of offending by saying that this applies to business leaders as well as starship captains but, frankly, it does. Estimates and project deadlines are ways that we try to force a scenario in which we get everything we want, not what we need. Without that focus we cannot even begin to have the conversation around delivering with a Minimum Viable Product (MVP) mindset.

So how could this work in the real world?

By setting deadlines tied to customer/business value and cost of delay, we flip the conversation from “when will this be done” to “what can be done in this time frame?” This encourages everyone involved to focus on delivering instead of “moving cards to Done” to meet expectations. In a healthy and trusting environment, it also can provide opportunities for external stakeholders to remove impediments that are preventing value from being delivered in a timely fashion. If, for example, the reason that a team cannot deliver value by a set deadline is because they are still working on other projects those projects could be delayed or, even better, stopped altogether (which also requires the existing projects to be organized in an MVP factor AND for the organization as a whole to resist the trap of the sunken cost fallacy).

Some questions inevitably arise when contemplating this kind of scenario. The answer to most of them ultimately boils down to “you have to trust your teams” but I will address a few in particular.

Doesn’t Parkinson’s Law state that work will expand to fill the time allotted?

It does, but that is a result of the kind of behavior that I’ve talked about here. When someone knows that they are being held to a deadline, and that often the deadlines they are being held to are arbitrary and meaningless, they understandably tend to take advantage of scenarios that develop that allow them to take some breathing room. In a high trust environment if a team becomes idle and literally cannot find things to do that are valuable uses of their time they will let you know.

But we’re not doing the work! How can we possibly tell a team when it should be done by?

By focusing on the value instead of focusing on finishing a “project.” Tell the team what you need. Tell them when you need it by. Let them tell you if they can do it, and if not let them tell you what they can do in that time frame. If that’s not satisfactory, ask them what they need to meet that time frame. If you can give that to them, do it. If not, modify your expectations. Don’t change your dates, change the scope of your request. If you’re being unrealistic your teams will tell you. Listen to them. Trust them.

Does this mean I won’t ever get everything I want out of a project?

Maybe it does. That’s ok. To paraphrase yet another frequently cited business world axiom, “80% of the value comes from 20% of the effort.” If your teams can focus on delivering value often and regularly instead of meeting deadlines, you will likely find that it’s ok to not get everything you want. More importantly, you’ll find that getting everything you want can be incredibly wasteful.

What if we’re wrong?

What if you are? Will the world end? Will you go out of business completely? Chances are the answer to both those questions is “no.” If the work your teams deliver does not generate the value that you expected, focus on getting better at predicting value, not deadlines. Ask your teams to do the same. Learn from each other. Run short experiments. Take risks. Spend less time planning and more time doing.

Be, I don’t know, Agile?

Free Training Friday (May 22nd, 2020)

Posted on by
Reply

It occurred to me while writing my last post that there are potentially a lot of organizations who, like ours, are looking for ways to be Leaner because of the worldwide impacts of the Coronavirus pandemic. Conferences are being canceled, budgets are being slashed, and many of the traditional methods that Agile practitioners use to earn PDU’s or SEU’s are suddenly unavailable or too expensive. I like to think I stay fairly well tied into the Agile community, and I’m a bit of a social media addict, so I tend to see a lot of great stuff come across my feeds throughout the week. I thought, perhaps, there might be some value in me saving and sharing those things out to the world.

So here you go…the first in a weekly series I am going to call Free Training Friday. Because I am original like that.

Events

AgileThought Virtual Forum – Effective Backlog Refinement for Remote Teams

Date: Thursday, May 28th

Time: 12:00 PM – 1:00 PM

Description: Backlog refinement is about adding details to the product backlog. Refinement, on the other hand, is something that the Scrum team does. Unlike the Sprint planning, the Daily Scrum and other events, the Scrum Guide does not prescribe exactly how refinement is to be completed, so the “how” is up to you.

Virtual Scrum Masters Guild – Agile Outside of IT Panel Discussion

Date: Wednesday, June 3rd

Time: 6:00 PM – 8:00 PM

Description: The Agile Manifesto was written by a group of software developers in 2001 and has been heavily rooted in Software and Information Technology from the very beginning. That trend has been shifting, and many companies outside of the software development world (or departments within larger companies that are outside of Information Technology) have embraced Agile values and principles. Join us for a moderated panel discussion on the challenges and opportunities involved in adopting Agile outside of the Information Technology domain.

Practice Does Not Make Perfect: Why Agile Transformations Fail (Gil Broza)

Date: Wednesday, May 27th

Time: 12:00 PM – 1:00 PM

Description: These days, almost every organization is showing interest in Agile. We seem to have all the ingredients for effective transformations: well-known practices, detailed processes, ever-improving tools, extensive literature, myriad certifications, and many consultants. How is it, then, that so few organizations are truly agile? Gil Broza, author of “The Agile Mindset” and “The Human Side of Agile”, thinks that one particular ingredient has been overlooked in the mad rush to adopt Agile. In this session, he leads us on an exploration of that ingredient and its place in an Agile transformation.

Podcasts/Videos

Agile Coaches Corner: Trainer Talk – Why Does Scrum Have So Many Meetings? (With Sam Falco)

Format: Audio

Duration: 4:24

Description: In this episode of Trainer Talk – the supplemental series to the Agile Coaches’ Corner podcast – Sam Falco, a Professional Scrum Trainer, addresses the complaint: “I don’t like Scrum because there are too many meetings.” At first glance, that seems like an odd thing to say because there are only four meetings, so let’s dive into this topic.

Relative Sizing by Clearly Agile’s Fred Mastropasqua

Format: Video

Duration: 9:20

Description: Fred Mastropasqua shares his insights on how to use relative sizing for your Agile and Scrum projects.

Follow Friday

Picard management tip: If you’re on red alert every day, then red alert means nothing.— Picard Tips (@PicardTips) May 21, 2020

I know it seems silly to link to a comedy account, but I get a lot of value out of this feed. This tweet resonated highly with me. I say something similar at work constantly (“If everything is a priority, you have no priorities”).

Getting Started With Agile

Posted on by
1

Before I go into my list of suggestions, I want to take a moment and briefly touch on one of the things I am most passionate about in terms of Agile.

Agile is a set of values and principles that were written by a group of software developers back in 2001. It is not a framework. It is not a process. There are frameworks and processes that people who are interested in increasing business agility can use but following any one particular “path” is not being Agile. It is doing Agile.

If you ever hear that you have to…well, I was going to create a list of things of things here, but basically if anyone tells you that you “have” to do something in order to “be” Agile that is a big red flag and you should be wary. Always go back to the manifesto. It is short and sweet and should be posted up somewhere you can reference it often. This is a great little PDF that I use. While I am talking about the manifesto, there is a version that was created specifically around Marketing teams. You can find it here. There is also something out there called Modern Agile that is a more streamlined and focused version of the original manifesto. What you will find across the board, though, is that all these various documents focus on values and principles. Not “doing stand ups.”

With all that out of the way, here are some things you can do to learn a little more about the “other stuff.”

Agile Values

  • The Age of Agile by Stephen Denning is currently at the top of my recommendation list. It is all about the pursuit of true agility, and hardly mentions any sort of frameworks or specific methodologies at all. In fact, Denning points out that most companies that are well known as being Agile companies made up their own processes and got copied. While I am talking about Denning, the article he wrote for Forbes about “fake” Agile is well worth the read as well. The book is a little slow to start but it gets better as you read.
  • Turn the Ship Around and Leadership is Language by David Marquet. I first saw Marquet speak at the Global Scrum Gathering back in 2016, where he gave a presentation based on his first book. Again, nothing in these books specifically about any sort of framework but a whole lot about what real business agility should look like.
  • Team of Teams, by General Stanley McChrystal. This is one of the first books I was exposed to once I jumped into the overall Agile community, and it is a remarkably interesting and informative read.

Scrum

  • Read the Scrum guide. No, seriously. It is free and should take you ten or fifteen minutes at most. This is the most important thing you can do in terms of learning Scrum, and anything else you consume that is related to Scrum should be compared back to the guide and scrutinized accordingly. There is a whole bunch of “stuff” out there that people think is part of Scrum that is not (user stories, for example, are not mentioned in the Scrum guide. Nor is sizing or the Fibonacci sequence).
  • If you are a visual person, this is a great video I use when introducing teams to Scrum and unless you are filling the role of Scrum Master or Product Owner it is really all you need to know to be part of a Scrum team. Keep in mind what I said in the bullet point above, though. There are things in this video that are not part of Scrum and not “required” practices.
  • Scrum: The Art of Doing Twice the Work in Half the Time is a book by one of the co-creators of Scrum and a remarkably interesting study into the framework. Sutherland gets a lot of criticism over his ego in this book, and he does very much put forward that Scrum can be applied anywhere, and you are dumb if you do not use it. I think it can be used much more broadly than people think, but I am not entirely convinced it is a solution for every problem. The book has many interesting case studies with teams using Scrum outside of software development, though, and it also talks about ways to “sell” the framework from the perspective of ROI.
  • Essential Scrum is a book by Kenneth S. Rubin that we read as an organization early on in our transformation and has a lot of good “deep” value for those who want to learn more beyond the basics that are presented in the Scrum guide. I must repeat the same caveat that I did earlier, though. This is not a bible. This is not the Scrum guide. There are processes and tools listed in this book that are not “required” parts of Scrum that subsequently can, and should, be tossed out if they are not working for a team or organization. I harp on this point because one of my constant frustrations over the years as an Agile coach is running up against individuals who insist that certain practices must be followed that are 100% not part of the Scrum guide (I also happen to believe that any team that has been using Scrum, and doing it well, will eventually evolve to a point when certain practices found in the Scrum guide are no longer necessary either. Bottom line is that if you are following the same practices that worked two years ago and literally nothing has changed I question whether or not you are actually learning or trying to get better at what you do).

Kanban

  • This book by David J. Anderson is dry as hell and boring but It is pretty much “the” book about Kanban. I really cannot say much more about it. It is included here because it is a good source, but you will never hear me say I enjoyed reading it.
  • A book I did enjoy, however, that really talks about some of the reasons why flow is important, is The Phoenix Project. This book is basically a modern version of The Goal, which was a fable about flow and the theory of constraints in the manufacturing world. The Phoenix Project translates those lessons over to the DevOps world. For a book about management principles it is not only very educational, but an entertaining read as well.

Agile at Scale

So this is kind of touchy subject, because if you think people try to put constraints around Agility on teams, wait until you run across an organization that has had success and now they want it to spread across the enterprise. This is where things tend to get very “command and control” and quick. If you were to ask me where an organization should start, I would suggest Scrum@Scale. Like Scrum, the Scrum@Scale guide is simple, short, and free. You can read it quickly and if you are familiar with Scrum the concepts are not radically different from what you already know. Another major player in the field is SAFe. I loathe SAFe. Just looking at the SAFe diagram gives me a headache. There are some good things buried in the overly complicated mess that is the framework, though, and if you are talking about scaled agile you should at least be familiar with it.

I mean look at this hot mess. Seriously.

Certifications

Certifications seem to be a necessary evil if you are looking for a job in the Agile world, but there are a whole bunch of people out there who hold certifications that are no more Agile than the ninety year old tortoise that I wished lived in my back yard. If you are looking to be as economical as possible the certifications offered through Scrum.org can be taken without having to attend an expensive class and are generally acceptable for most jobs descriptions. If you want to take a class to prepare for any of their certifications, AgileThought has some great folks on their staff. I have not taken any of their official classes, but I am confident enough in the team there to assume they would be great. The other big name in the certification world is the Scrum Alliance, but all of their certifications require expensive classroom work unless you are working with an organization that has a Certified Team Coach on staff. If you decide to go that route, I am a huge fan of the team over at Braintrust. All but one of my certification classes were taught by the team there, and I have learned a lot from (and enjoyed) every one of them.

One quick tip about certifications and classes – Most of these classes have rarely, if ever, been offered virtually prior to this year. There has always been a belief that, as stated in the manifesto, the most value for classes like this came from face-to-face interaction. Many of these companies have had to pivot quickly to try and keep their training income flowing. I mention this primarily because I feel like it is a great time to negotiate training costs. Now do not get me wrong, I suggested the companies above because I think they are solid folks and I want to see them get paid, but certifications are not cheap. I think this is a great time for them to fill some seats for folks who might have smaller budgets or be paying for classes on their own, so ask for it. The worst they can say is no, right?

Networking

Florida has a huge and highly active Agile community, and there are so many free events happening every month that those of us involved in putting them on must coordinate to make sure we are not stepping on each other. Join the Tampa Bay Agile Meetup Group and start attending some of the local meetups. Obviously right now they are all virtual, but we have more events happening now than we were when we were face-to-face. It has been a little quiet lately, but there is also a great Florida Agile community accessible through Slack. Twitter and LinkedIn are also great places to learn more about Agile, but as I write that I realize I have no easy way to share the folks I get value out of in either place. I suppose it is time for me to create some lists.

Other Resources

  • Coaching Agile Journeys is a Florida based community of Agile practitioners who put on several virtual events a month, mostly during daytime hours.
  • AgileThought has been hosting weekly free virtual events. You can keep an eye out for upcoming ones on their event page.
  • Their events are listed though the Tampa Bay Agile meetup group, but I want to specifically point out the Tampa Bay Women in Agile group. This is the local chapter of a worldwide organization that is part of the Agile Alliance, and I am a huge supporter of their cause.

In Conclusion

The more I look at this document, the more I want to add to it. Which is, at its core, directly counter to trying to deliver the Most Viable Product to my customers. Ultimately, I hope you find at least one thing in here that you can walk away with that helps you move further along your Agile journey. I am currently working on becoming an IC Agile Coaching Expert, so if you found value here and would be interested in some one-on-one professional coaching so I can practice on people who I do not work with let me know.

I would like to thank Kari Goetz and Michelle Peatee for being the inspirations behind this post. They both reached out to me at the same time, so I initially started putting it together for them. What you just read is the finished product.

Is it SAFe?

Posted on by
Reply

When I look at the diagram above, I get an absolute headache. Yes, I’m one of those agilists who sees the Scaled Agile Framework diagram and wants to absolutely claw his eyes out. Nothing in the above screams “Individuals and Interactions over processes and tools” to me, and when I think about the level of bureaucracy needed to support something as bulky as what is seen in this picture I want to run screaming.

So, it might come as a bit of shock to know that I arranged at Leading SAFe 4.0 certification class at our organization last week. I recognize the fact that the structures around SAFe are very comforting to people who are trying to transition from a command and control mindset, and I have been challenged by my mentors to learn more about things that are counter to what I believe. You know, that whole “seek first to understand, then be understood” practice that is part of the 7 Habits of Highly Effective People mindset. I’ve previously taken Scrum@Scale training, and (like Scrum) itself it really resounded with me, but several of the members of our transformation team really like the SAFe model. With all of that in mind, I set about to get a better understanding of how SAFe works, and as a result I am, as of yesterday, a certified SAFe Agilist.

That, coupled with all my other certifications and $5.00, gets me the proverbial cup of coffee at Starbucks, and not even a venti one.

While I’m still skeptical about how something this complex would work in our relatively small organization (our back-office staff is somewhere around 150-200 people), I must admit that the framework isn’t all that bad. It’s clear that the creators really did design it with the Agile Manifesto in mind, and throughout the course of our two-day training I saw many things that directly referenced back to it. One of which has been top of mind for me lately.

See, in our organization we’re currently at a state where we have been “doing” Agile for several years now. We’ve got teams outside of IT using it. We have area leaders and executives involved in the process. We’ve got a corporate Agile vision statement, and we’re working closely to align the objectives of the organization with Agile practices. It’s all great stuff, and I’m very proud of the progress we’ve made, but as we bring more and more people into the fold, the question of “how do we know we are successful” keeps cropping up. As the Enterprise Agile Coach, this is a particularly vexing question for me. People look to me to explain to them how we know Agile is “right” for us, and they want objective evidence to back up when I say that it is. This frequently results in questions about what metrics we can use to show success, and I loathe metrics. Well, let me quantify that statement. I think metrics are fine as learning tools. I think metrics can give teams data to use to improve. I’m not so anti-metric that I think the practice of collecting data is worthless, but I do believe that metrics can very, very easily be distorted and become useless. I can’t tell you the number of meetings that I have sat in where a person who was presenting a metric did so by opening with “now keep in mind that…” and proceeding to explain why, exactly, the metric they were sharing was completely inaccurate and shouldn’t really be a factor in judging success (“but it will be better next quarter”). When you’re talking about team metrics? Forget it. Measure a team by number of lines of code completed? They add unnecessary code. Tell a team they should increase their velocity? Suddenly all the user stories that would have been 3’s become 5’s.

This is why, in the manifesto, there is a principle that specifically addresses what “success” looks like in an Agile environment –

Working software is the primary measure of progress.

There it is. Simple. Clean. Straightforward. If your team is consistently putting out quality work, the things you are doing are working.

What does all this have to do with SAFe? One of the things I learned in our class, and one of the things that made me think that maybe SAFe wasn’t quite the monstrosity that I thought it was, is the fact that in the SAFe world the ultimate measure of success is the System Demo.

The one real measure of value, velocity, and progress is the demo of the fully integrated work from all the teams during the prior iteration.

Not velocity.

Not burndowns.

Not ROI, or ROA, or lines of code created, or number of tests passed.

Fully integrated work.

Teams getting things done.

I still take issue with the fact that, in both the SAFe model and Scrum@Scale, there is an insistence that all the teams be doing the work in the same manner (although SAFe did recently concede that some teams could potentially use Kanban instead of Scrum). Frankly, I take issue with a lot of the things that SAFe says you “have” to do to be successful (prescriptive Agile makes me break out in hives), but it gives me hope that they at least acknowledge the fact that no metric in the world shows success better than teams producing quality work.

Agile isn’t a checklist, and your organization will never “be” Agile if all you are focusing on is whether or not you can complete a menu of items and say “yep, we did these things.” Some teams are going to thrive using Scrum. Some will do better with Kanban. Some might just adopt XP practices, or come up with their own way of doing things that works for them. That’s ok. That’s great! The Agile Manifesto doesn’t say anything about following a set of practices. What it says is that, in the end, if the team is delivering value on a regular basis you should get out of their way and let them keep doing it.

Don’t even get me started on how to define “value,” though…

The Past Is The Past

Posted on by
Reply

“Those who cannot remember the past are condemned to repeat it.”

– George Santayana

The first time I heard this quote was in the early 1990’s. Jello Biafra chanted it three times, like a self-affirming mantra of sorts, during a spoken word show at the Ritz Theater in Ybor City. That show was truly life changing for me in many ways. It happened during the first Gulf War, and as a result of what was said there I resolved to myself that I would never be compelled to take another human life unless it was in self-defense (I claimed for years that I had “registered” as a conscientious objector, but that was untrue. I knew what was required to do so, but never actually went through the steps to make it official). I tore up my draft card during that show, and left the scattered pieces on the floor of the venue. I became more interested in politics, and in particular the people who pointing out just how ridiculous some of the things that went on in the world were. After this performance I expanded my reading to include more than just fantasy and science fiction books, and eventually found myself immersed in the words of people like Hunter S. Thompson, Kurt Vonnegut, Ken Kesey, Jack Kerouac, and Henry Rollins.

It was a hell of a night.

Now it’s about 25 years later. Jerry Brown, the vile enemy of the Dead Kennedy’s song California Uber Alles is now a darling of the Democratic Party.  Jello Biafra is still around and trying to change the world, but these days he looks more like someone’s Dad than a dominant figure in the punk music scene. We long for the days when we thought George W. Bush was the Worst. President. Ever. We carry the wealth of human knowledge around in our pockets and we use it to look at pictures of cats. Then there is me. I’ve worked for 15 years with the same company, working my way up through a non-profit corporate chain to a significant advisory position to the leadership group. I have tattoos, and I still have some “crazy” notions like “killing other people is generally a really bad idea”, but I’m definitely not the same person I was when I was so enamored by the words of Mr. Biafra back in the 90’s, and some of the things that stuck with me that night don’t hold up quite so well in my current way of thinking.

Particularly the admonitions about remembering the past.

Now, I’m not suggesting we shouldn’t look to the past in order to recognize patterns that recur in human history. Heck, our current administration is pretty much a text book example of why we should always keep an eye out for another totalitarian government. I’m also not suggesting that experiences in our own personal lives shouldn’t shape our decisions today. They shouldn’t dictate them by any means, but one of the whole points in life is learning from our mistakes.

No, I’m talking – probably unsurprisingly – about living in the past when it comes to your current business decisions.

During a recent meeting amongst some of our mid-level managers, the issue of the lack of project documentation came up. “Back before we made this switch to Agile,” the commentator opined, “we knew exactly what we were getting out of a project because it was in the requirements document. We could go back to that document to make sure we got everything we asked for. And all of those documents were stored on the PMO site, so we could go back and look for them years later so that we could refresh ourselves on why we made the decisions we did in the past.”

I did my best not to run screaming from the room like I’m always tempted to do when someone bemoans the “good old days” of Waterfall development. I took a deep breath and talked to the individual about the values present in the Agile Manifesto, particularly the notion of “Customer Collaboration over contract negotiation.” I talked about the fact that those requirements docs were a double-edged sword, and that they could easily be used against the stakeholder (the nefarious “scope creep” accusations). I emphasized how the stakeholder should be in constant contact with their product owner while a delivery team was working on their product, and how they should be working with the team daily. I extolled the benefits of the Sprint Review and how that feedback loop could prevent the delivery team from wasting time by going too far down a path that is dictated by a rigid requirements document. I said all the things a good Agile Coach should say.

What I didn’t do was express my utter and complete horror at the notion of keeping an archive of documents about past projects.

This is one of the areas where I’m really big on the values from the manifesto. “Working Software over comprehensive documentation.” I get that the manifesto isn’t saying that you shouldn’t document, but for me personally documentation is a monumental waste of time – especially if you’re talking about an environment where everyone is working for the same company. Spending effort creating documents that MIGHT be used by a small group of people is really something I personally take issue with, especially in the world of software development where I’m a proponent and practitioner of self-documenting code.

But more importantly, this is an area in which I feel like it’s important to leave the decisions of the past behind you. My mentor frequently states that “an idea that is good enough will come back in time.” He mentions this in regards to regularly cleaning out the backlog by removing items that have sat around for a while with no action. I look at old documents with a similar eye. Do we really need to spend time going over documents that are years old? Do we need to re-hash old arguments? Do we need to try and remember what the market conditions were at the time that led us to our decisions? Do the rules and regulations that led us to past decisions even exist any more? Have they changed? How much time do we waste digging through archives, planning meetings, and generally getting nothing done when we could turn our ideas over to teams who can produce working solutions?

If your organization is trying to promote a culture where teams can “fail fast,” but you’re still overly concerned with trying to prevent the mistakes of the past, you’re destined to, well, fail. Give your teams the safety to run with ideas, try some small experiments, and learn on their own without burdening them with decisions that are, most likely, irrelevant today. Let them learn on their own. More importantly, open yourself to the possibility that they are going to come up with solutions that are completely different than the ones your organization thought of in the past. Considering how quickly the market is changing these days, that’s much more likely than you might think.

 

They Moved My Cheese

Posted on by
1

Kanban board

Sharpies are important

When I decided to start this blog, my plan was to chronicle my experience as a member of middle management and my possible path further up the corporate ladder. I should have remembered that old saying about best-laid plans and what not, because a week after I created this blog and put up my first post my proverbial cheese got moved.

A lot.

Nothing bad, mind you. I didn’t lose my job or anything dramatic like that. I was asked to take on the role of Scrum Master/Agile Coach at my organization.

Continue reading →