Matt Badgley

My career journey has had me wearing many hats ranging from Systems Analyst to Programmer to IT Manager to Programmer to Director. Today, I work as a coach and instructor to the leadership and team members of organizations on their agility journey. I'm constantly practicing to be a good learner, aspiring to be an inspiring leader, and I'm constantly walking the line between pragmatism and conviction when it comes to the application of lean and agile principles and practices.

Matt’s purpose is simple, “I believe in working with teams to help them get better, learn, and be successful in building stuff while having fun.”

At the end of the day, Matt believes in integrity, hard work, curiosity, people, and faith.

If Your Title Rhymes with “leaf”, “erector”, or “resident” – You Should Learn About Agile and Lean

//

If you are reading this blog, then you are either part of an Agile transformation or you are someone considering an agile transformation. If you are someone that works in a management or simply a position of authority at your organization, if you don’t know much about Agile or Lean except that they are the latest buzzwords that don’t seem to go away — well, you should learn more about them. Because, the words might change a little, but the practices and principles have been around for a while and they are not going to go away anytime soon.

Agile and Lean are a set of ideas and principles that shape principles which guide our behaviors and foster the frameworks by which teams use to get things done. These have come about because there’s a recognition that trying to build things that are a result of complex cognitive thinking cannot be done well and in a timely manner to keep up with the demands of consumers. Couple these demands with an exponentially growing and aggressive competitive marketplace — the concepts of focusing on building the right thing and eliminating the waste that keeps us from delivering things right have naturally emerged. Agile and Lean are not old ideas, there’s been a ton of learning and shaping of these ideas and principles. New frameworks and or practices emerge daily as our products evolve and the people creating them do the same.

Why Should You Learn Agile and Lean?

clone_dolly

Have you ever said, “Dolly is a great leader and worker, I wish we could just clone her and have ten Dolly’s.”

Or, how about, “I wish our team would just make a decision and get it done.”

Well, Agile and Lean values promote:

  • Empowerment
  • Trust
  • Commitment
  • Quality
  • Flow of Value
  • Customer Focus
  • Team Work
  • Transparency

All of these things involve, giving teams information and the vision, and then getting out of the way to let them deliver.

Another thing to note about the values above are that they are generally practiced by all organizations and you’ll find aspects of each word above within the corporate mission statements. By learning more about Agile and Lean, you can learn how to help your teams or leadership leverage the organizations’ values and adapt those advocated throughout Agile and Lean adoptions.

The predominant reason organizations and teams adopt agile is to respond better to change — that is market changes. The other reasons are productivity and quality, all things that help us make products people want to buy, at the price they are willing to pay, and ultimately with the right level of quality that help mitigate long-term cost of supporting. A byproduct of agile adoptions is improved morale.

How You Learning Agile and Lean Can Help

cycle, loop or feedback concept

Agile and Lean advocates shrinking the feedback loops which improve communications amongst departments and ultimately help your employees make better decisions. Well, you understanding when the feedback loops happen, your role in the feedback loops, and the types of information shared at the different levels of the organization can help you keep yourself out of the way from the team. What I mean by this is that when sometimes things are going right, we’ll go back to what we are comfortable with and understand — and generally this means metrics and reports that may be costly to gather and result in anti-patterns for good team work.

The other value of you learning about Agile and Lean is that you can help facilitate the adoption by being a good leader and facilitating change practices. Keeping a level head when things aren’t going right, and providing guidance as to how best support the teams.

What Should You Do to Learn?

There’s a ton of reading materials out there. Just keep in mind that there’s a lot of books, articles, and blogs that focus on the practices and not as much on the strategic and scaling aspects around agile. This spaces is growing as organizations have realized that not only is there the “build better software” value, but the planning and practices around Enterprise Agile give organizations a framework to make better investments and harness the short feedback loops to improve ROI.

To help get you started, here are a few resources that have been recommended to me and I can vouch for their value of learning:

The Agile Executive Whitepaper, Jim Magers, VersionOne. Nice quick read and primer / introduction to agile.

The Concise Executive Guide to Agile, Israel Gat. Nice quick read that provides a deeper dive than the Agile Executive whitepaper.

Scaling Software Agility: Best Practices for Large Enterprises, Dean Leffingwell. Foundations for the Scaled Agile Framework (SAFe) which is being advocated as a framework for leveraging Agile and Lean in the enterprise.

Principles of Product Development Flow, Donald Reinerstsen. Helps explain the way Agile and Lean works in Product Development.

Training – Agile for Executives Workshop, VersionOne. This is a workshop that I’ve performed as well as my colleagues and it’s aimed at being a concise four hour session aimed at ensuring Executives understand the history, underpinnings, and execution models surrounding of Agile and Lean.

How to Make Your Own Bacon – Bdub’s Bacon Guide

It’s an honor and a privilege to make the first bacon post here on Agile Bacon, my good friend’s Brian Watson (a.k.a. Bdub as well as @agilebdub) Guide to making your own bacon. Bdub’s Bacon Guide is a simple 12-step process to making homemade bacon. OK, 13 steps if you include the beer — and you should make sure to include the beer.

In reading, Bdub provides guidance to ensure the best flavors are achieved. He does this through the right mix of humor and pragmatic experience that shows he cares about your outcomes. The guide is well illustrated, and by simply looking through it — you should be inspired to go off and make your own bacon (or at lest hungry enough to go buy some).

You can download the guide here.

[su_button url=”http://agilebacon.com/resources/BdubsBaconGuide.pdf” target=”blank” style=”flat” background=”#efb22d” color=”#00000″ size=”4″ icon=”icon: download” icon_color=”#00000″]Start Makin’ Bacon[/su_button]

Please comment below on your experience making bacon. Not only is it rewarding to do something yourself, it’s just flat out good!

Words Mean Things – Maniac or Bacon

/

Well, it has been almost three years with the maniac and now it’s time for a change.  Actually, what has occurred is that some nice person told me, Matt, to Google the definition of maniac.  So I did, and here’s what I found:

maniac (plural maniacs)

  1. An insane person, especially one who suffers from a mania.
  2. A fanatic, a person with an obsession.

At first glance, I thought — well, that works. But I quickly realized, maybe I am crazy, maybe I am a fanatic. Ok, I’m really not — at least I don’t have that perception of myself. In any case, I realized that maybe I should change this because, really I don’t prescribe to the heavily prescriptive approach to anything. I believe in visioning, informing, building, and realizing — I don’t care how I get there, I just happen to feel that Agile Development Methodologies or Agile Project Management is a great way to get there.

That brings us to bacon. Why bacon? Why not? I for one am a big fan of bacon, you can add it to anything and have it enhance the experience. Not to mention, I like to keep things simple and there’s not anything more simple than bacon. Not to mention, to steal from the Chicken & Pig metaphor — I think we are all pigs and we are all committed.

So without further ado, I introduce agilebacon.com. This blog is roughly the same as the old agilemaniac.com, except it is new and improved! I’ve already added some cool features including a Link Library, an embedded Glossary that will provide definitions in-line, and, of course, we have a new look and feel that provides much better readability than ever before.

Please let me know what you think! Comments are open below, my new Twitter handle is online – @agilebaconbeer, and I even broke down by creating a Facebook Agile Bacon page. Thanks again for coming by and giving me a read, and please visit often.

Words Mean Things – Waterfall

/

If you are someone who is passionate about Agile, the word “Waterfall” is usually used in a derogatory manner or, at least, when you use it — you are making the stink eye. On the converse, if you are someone who practices what is popularly known as “Waterfall” Project Management you generally get offended or defensive when the phrase “Waterfall” is used.

Here’s how the conversation plays out:

Agile Practitioner – There’s no way I’ll ever work on a Waterfall project.

Waterfall Practitioner – There’s no way I’ll ever work on that Agile project.

Agile Practitioner – Waterfall projects are never successful and I hate being told what to do.

Waterfall Practitioner – Well at least we do work and don’t practice that Agile witchcraft and all that kumbaya mumbo-jumbo.

Agile Practitioner – Well, your mama said Waterfall is for losers.

Waterfall Practitioner – Don’t be talking about my mama …

[chaos ensues]

Winston and Murphy

The sad part about this dialog is that although it’s somewhat fictitious — I’ve heard similar arguments at organizations and with colleagues that work across all spectrums of the project management continuum. The funny part about the dialog above and, in particular, the word Waterfall — no one is really clear who started calling it Waterfall. It’s obvious that when diagramming out a sequential process, it looks like a waterfall.

waterfalldiag

Often, people credit Dr. Winston Royce with waterfall, especially with respects to software engineering when, in 1970, he wrote a part in a white paper that describes this project management approach (read it here). The funny thing is that he goes on in that same white paper that is credited for starting the waterfall practices to describing how risky it is and that in order to mitigate the risks, each stage of the process should do things iteratively and incrementally.

Waterfall Project Management is really Sequential Project Management. Meaning we perform a sequence of activities and there are generally stages, maybe with sign-offs, and usually hand-offs to another group of people that are charged with performing the next sequence and consuming the output of the previous sequence. Some refer to this as Traditional Project Management, but in most environments its called Waterfall.

I’m not going to discuss the differences between the two and which approach I think is better — it should be clear since you are reading an agile blog. I will say that I think that the merits of each approach are obvious and each approach has challenges. The usage of one approach over the other really depends on the project and possibly the people engaged. What I am going to say is that the world we all live in today, it is very likely that we’ll have a mix of projects using a more Agile approach and one using a more Sequential approach. Sometimes, we’ll have to join forces and combine the output of these approaches into one. Of course, we are learning and adapting ways to do this, but that too is another discussion altogether.

Let’s face it, when words start dividing people, we probably shouldn’t use them any more. Instead call the project management approaches what they are – iterative and incremental, or sequential, or continuous, or simply ad-hoc. Also, be aware that moniker we place on people isn’t really on the people, it’s on the processes by which they may operate in and they may be really comfortable in that process. Generally, they’ve put in a lot of blood and sweat to make it work. Sometimes we need to put the monikers aside and focus on “individuals and interactions over process and tools” (crazy how I got the Agile Manifesto into this blog, isn’t it?).

For now on, be aware and instead of calling it Waterfall, try Sequential Project Management or even Traditional Project Management — unless you want to get in an argument about “your mama.”

1 3 4 5 6 7 14