Considering Agile?

Yesterday I stumbled across a study by Carnegie Mellon University’s Software Engineering Institute that used one of my projects as an example. 

I had done phone interviews with the authors, but didn’t realize any of my ideas were included in the final version until I saw it when I was searching for something else.

The paper is called “Update 2016: Considerations for Using Agile in DoD Acquisition.” 

You can find it either on the CMU SEI site or on the official DoD holding at the Defense Technical Information Center.

From the abstract:

…Continuing with the 2010 report's theme, this report updates the exploration of the questions: Can Agile be used in the DoD environment? If so, how? It includes lessons learned from DoD programs that have employed Agile and information gleaned from myriad articles and books on Agile…. The intended audience is policy makers, program office staff, and software development contractors who are contemplating proposing the use of Agile methods. We hope this report stimulates new discussion about adopting Agile in the DoD world and equips practitioners with the information they need to make informed decisions.

Although Agile is more widely embraced today than it was when the report was published in Dec 2016, the lessons still hold.  I would argue that many of the lessons would apply if "Agile" were replaced with the name of many sound ideas for delivering value that are commonplace in the commercial environment but not widely used in DoD.  Many of the considerations are also useful outside of the DoD.

They called out the Coast Guard Logistics Information Management System (CG-LIMS) as an example Agile project. After sharing part of my August 2012 blog post, they concluded:

This is perhaps the most important lesson from CG-LIMS: Agile methods and practices can be implemented even within large government organizations that rely on the formal structures of a Waterfall process, given sufficient imagination, tailoring, and tenacity. That is, processes do not execute themselves. They require actual human beings to make decisions, use judgment, and take action. When confronted with a Waterfall-oriented process, the standard implementation and interpretation is not the only way to proceed. A dedicated leader who wants to use Agile can do so—and do so publicly—by following the Coast Guard’s compelling precedent.

Processes do not execute themselves. Not my words, but I sure like it. Human judgment—and action—from leaders is a key to success.

Agile project leaders should not expect to receive universal support and buy-in regarding this approach. However, the absence of unanimous support does not constitute an insurmountable barrier. As Captain Taylor wrote on his blog in July 2012:

If it causes you some distress to know that Agile values and the principles of the Agile Manifesto are not embraced within the Acquisition community, know you’re not alone. It saddens me too. But please don’t let it slow you down. I was explaining to one of my fellow PM’s ... that I’ve long since given up on getting everyone’s buy in on our approach. We’ll need to keep moving with just enough approval and just enough support for what we’re doing. As we deliver, we’ll continue to make believers one at a time by showing results in the form of working software.

The whole document is worth reading. Even though it's almost two years now, I think anyone involved in a transformative effort in government IT (whether that means Agile adoption, DevSecOps, or cloud migration) will find something they can put to use.

I'll leave you with two quick thoughts that resonated with me:

I love the focus on Users, Users, Users! From the Executive Summary:

Lack of relevant end-user interaction is one of the failure modes that we have seen that significantly reduces the effectiveness of an Agile approach.

Brooks is still right: There is no silver bullet:

There is no “one size fits all” Agile process. Just like any set of practices, implementation of Agile must be tailored to fit the situation and context. For example, Agile teams responsible for developing high-risk core components of the software architecture might apply less-aggressive release schedules than Agile teams developing less critical pieces of the software system. Some Agile teams might pick a two-week iteration cycle where others might determine their optimum iteration cycle is three weeks. Agile is not a silver bullet but rather another “lead bullet” for the Program Management Office’s (PMO’s) and contractor’s arsenal.

Leaders are Readers

photo credit: binaryape

I wrote a post in 2012 to serve as a reading list for my replacement of an IT Acquisition Project in 2013. I followed that up with highlights from the team’s library that had served well as guideposts for the team.

It’s time for an update. Since those two posts, a few friends have published books that I’ve found myself recommending over and over, and I’ve read (or re-read) others that belong on a short list of books to recommend to any agile practitioner.

Also a confession: I’m lazy; I want to have a few places where I can point folks two who are putting agile principles to work in their lives in IT or non-IT projects.

Here’s my top fifteen list of books for agile practitioners that didn't make the previous posts here and here.

FIRE: How Fast, Inexpensive, Restrained, and Elegant Methods Ignite Innovation by Dan Ward, 2014. Dan’s work has influenced my thinking for many years. This book is an evolution of a framework he called FIST: Fast, Inexpensive, Simple, Tiny. When my team invited industry participation to crowdsource our acquisition strategy, we shamelessly stole his work (and acronym) by calling it the FIST Acquisition Strategy Team, or FAST. We took to heart his premise that “If the implementation is hard to explain, it’s a bad idea. If it’s easy to explain, it might be a good idea.” Anyone using agile values and principles in their work will learn something they can use.

The Simplicity Cycle: A Field Guide to Making Things Better Without Making Them Worse by Dan Ward, 2015. This book captures more great ideas that influenced my team when Dan and I were both on active duty. It describes a simple framework that can help agile teams and leaders at all levels communicate the relationship between simplicity and complexity.

Scrum: The Art of Doing Twice the Work in Half the Time by Jeff Sutherland and J.J. Sutherland, 2014. No one better than Jeff Sutherland to explain Scrum. Full of reminders about the “Why” behind scrum. This is a great read for beginners or experienced practitioner. One tiny thing I loved was the way he phrases the three questions in the daily stand-up, which subtly puts focus on team :

1. What did you do yesterday to help the team finish the Sprint?

2. What will you do today to help the team finish the Sprint?

3. What obstacles are getting in the team’s way?

This is a great book for Scrum teams and for senior executives who want to understand how those teams could be working.

The Art of Business Value by Mark Schwartz, 2016. This book will make you think. If agile is all about “delivering value quickly,” we ought to have a good definition of what value is. There aren’t a lot of answers in the book, but there are plenty of great questions worth considering and hypotheses worth testing.

A Seat at the Table: IT Leadership in the Age of Agility by Mark Schwartz, 2017. This is a great read for IT leaders in an organization, and anyone who has a role in how the IT organization is resourced.

Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition by Lyssa Adkins, 2010. This is a great resource for folks with experience with agile teams.

Agile Retrospectives: Making Good Teams Great (Pragmatic Programmers) by Esther Derby and Diana Laren, 2006. If you’re going to read one book on retrospectives, this could be it.

The Elements of Scrum by Chris Sims and Hillary Louise Johnson, 2011. One of the client’s I coached chose this book to have the team members read to gain a shared understanding of basic agile principles, practices, and ceremonies. It’s a good place to start.

Little Bets: How Breakthrough Ideas Emerge from Small Discoveries by Peter Sims, 2011.

The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win by Gene Kim, Kevin Behr, and George Spafford, 2013

The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses by Eric Ries, 2011.

Crucial Conversations: Tools for Talking When Stakes are High by Kerry Patterson, Joseph Grenny, Ron McMillan, and Al Switzler, 2011

The Five Dysfunctions of a Team: A Leadership Fable by Patrick Lencioni, 2002.

Team of Teams: New Rules of Engagement for a Complex World by Stanley McChrystal, 2015

The 7 Habits of Highly Effective People by Stephen Covey, 1989. This is one of those timeless books everyone should read. If you read it as I did when it came out, you probably internalized some of it and are putting it to use in your work and life. If you haven’t thumbed through it in ten or fifteen years, it’s worth another read.

Thinking Big

Think Big, Plan Big, Start Small, Deliver Quickly

I heard something this week at the DHS Agile Expo that struck a chord with me. In a talk on Product Ownership, Barry Zukose, DHS's Deputy Chief Data Architect told us about a sign he has in his office:

Think Big and Develop Small

I like that.

It's similar to a sign on my Coast Guard office wall years ago:

Think Big, Plan Big, Start Small, Deliver Quickly.

That was a mantra for the teams I led delivering IT systems.

I consider myself accomplished at stealing ideas from others and putting them to work in my life, but I can't figure out where I got that phrase from. Google searches lead me back to my project blog from Coast Guard days. If anyone reads this and knows the source, please let me know so I can give credit where it's due. I’ve repeated it many times and It has served me well.

This week also marked the end to a non-IT projects I've been working on for five years. My role with the team evolved from full-time PM to part time SME as I took on work with other clients.

While reflecting on the great work of the team, I was reminded of the final blog post I'd shared with the team as their PM. It was a good reminder that "Think Big, Plan Big, Start Small, Deliver Quickly" works for more than just software. It's might apply to anything where value can be delivered in chunks. Here is that post from April 2014 (with portions redacted):

---

Little Things

During our first meeting together after I stepped into a leadership role, I told you my approach to TSCAP would be characterized by a desire to:

• Think Big

• Plan Big

• Start Small

• Deliver Quickly

You should all be proud of the work we did to start small and deliver quickly in the first six months. I had the privilege of speaking on the team’s behalf to [Assistant Administrator] Thursday and Friday last week. Thursday Mike and I briefed him on the results of the [——-] case study. Friday I got to share all that we’d accomplished in the four months since our last PMR.

As I reflect on how far we’ve come since I briefed him in December, I’m just amazed at the progress. In December, we had lots of work that was partially done and lots of concepts that were coming together. In just four short months, the work was made real in our Security System Architecture Framework, or SSAF. Our work isn’t all done, but we’ve made visible progress, and we were able to put it to use to show real results.

As I took a step back to think about the importance of our work, I’m convinced that we’ve taken the first steps in creating something that can fundamentally change the way the TSA does business. We have provided some tools and simple processes that can help decision­makers to be clear about what the important factors and data are in making a decision so they can be transparent about why they are pursuing a course of action. Then we’re using the SSAF to show the impact of alternative courses of actions. That’s pretty powerful stuff. Knowing WHY a decision is made and better understanding the IMPACTS is huge.

What we’re doing is bigger than tools. This isn’t about Decision Lens and Tableau and Access. it’s about how we’re using those tools to help TSA think different. That’s where we’ll see the real payoff down the road.

Granted, our problem domain is just a part of what TSA does... but it’s a pretty important part. Imagine if the way of thinking we’re promoting – structured, repeatable, and transparent – can start to take hold throughout the organization.

Be proud. We started small. And we delivered. We delivered work that is making a difference. You’ve started to deliver a series of little things that will continue to grow into something great.