Agile in the DOD By Roland Cuellar

I recently went to a presentation by Don Johnson, Advisor to the Defense Sciences Task Force on Acquisition of Information Technology within the DOD. This group has been investigating how to speed up and lean out the acquisition process within the DOD for some time now and they have a new report out with their recommendations. The task force is recommending that the DOD take an Agile approach and furthermore, they have asked for and have received congressional approval to begin piloting the use of Agile in the procurement of large DOD systems! Some of the reasons for this move towards agile are:

1. The current technology acquisition process was designed decades ago and is no longer suitable for the rapid pace of change that is required to design, develop, and deploy latest technology solutions to the field.
2. The current process is designed for and better suited towards large platforms such as ships and planes than for software intensive systems.
3. The USA has a declining software development pipeline. The number of American citizen college graduates in the technology fields is shrinking. Finding clearable employees is getting more and more difficult. Therefore, we need processes that make us significantly more productive. It is likely that we will need to produce far more software with fewer resources.
4. In 1970, IT accounted for only about 20% of weapon system functionality. Today, it sometimes accounts for as much as 90% of weapon system functionality.
5. The current acquisition and development process has an average delivery time of 91 months!

For these and other reasons, congress has granted the DOD the authority to modify the current acquisition and development process for up to 10 large systems annually to utilize an Agile approach and the DOD will update congress annually on the results of the new process. The new process will feature Scrum-like iterations, early and frequent delivery of working software,and some degree of requirements flexibility.

This is an exciting time for us in the Agile community as the DOD recognizes the success that Agile has had in the commercial marketplace. But the DOD's adoption of Agile will also bring extraordinary challenges. The scale and complexity of modern defense systems will certainly tax our existing methods. However, I am sure that working together, we can improve significantly on the current process.

Write to us here at LitheSpeed using the 'comments' link below if you would like to get a copy of the DOD slides on this topic.

Don't Forget the Storming

Our good friend and agile champion, Sean Buck, recently wrote an outstanding article on the 'storming' phase of team maturation. He has kindly allowed us to share it with you.

Building Teams - Don't skip the "Storming"

By Sean Buck, 2009

A lot of you may be familiar with the Forming - Storming - Norming -Performing stages of a team. It has been around quite awhile, almost 45 years actually. It's also referred to as Tuckman's Stages, since it was first brought to us by a psychologist named Bruce Tuckman. Something I have observed and found interesting is that there are a lot of people that don't embrace the Storming so much. Maybe because there are many personalities that would rather avoid conflict. I have even observed instances within the organization where some members would rather take things "off-line" or may possibly exhibit a passive aggresive behavior by agreeing with something in a meeting, yet disagreeing and not supporting it outside of that meeting. In my humble opinion the Storming stage of building a team is one of the most important steps that does need to happen to becoming a Performing team, and needs to be properly facilitated and supported by leaders. It's needed to build trust and comraderie, which are crucial traits of a high performing team. I would like to share a brief story on how the United States Marine Corps embraces storming, and some tips on supporting a positive environment for Storming within the organization and just the corporate environment in general.

Storming in the USMC - What I learned in 3 days that will last me a lifetime

As a Sergeant in the USMC, I understood the importance of teamwork. The teamwork concept is so crucial to how we operate and execute. So much so, that teamwork is a focus from day 1. When you arrive at bootcamp the first thing they do is shave your head, and throw you into a camoflauge uniform. This is symbolic of stripping away your individuality. Not that individuality is not valued in the USMC, but it's overvalued in the civilian world. You even don't have a name and can no longer say "I" or "me" You are required to refer to your self in the third person. When addressing a Drill Instructor, you can't say "I have a question" It's "Sir, this recruit has a question, sir" From day one everything we do is done as a team. And throughout training storming will occur. The USMC forces Storming in a final event leading up to graduation called the crucible.

The Crucible

Back in the 90's I had the luxury of being in one of the first platoons through a newly created event called the crucible. Although it has probably changed over the years, for me it was 3 days and nights of one of the most challenging experiences I have faced. Throughout the course of the 3 days, our platoon had marched over 60 miles in full combat gear (about 75 lbs on your back), we had about an hour of sleep per night, and less than one meal per day. In the middle of all that, there were obstacle courses of over 60 different missions that required our 6 person team to be working as a team to complete. Things like scaling a 15 foot high wall as a team with no rope, trying to get to the other side of a bridge damaged by an explosion, getting down from a series of platforms simulating a four story building blown in half (there are no stairs on your half.) All things we could possibly experience in combat. The crucible was our last event, or challenge if you will. It was the pinnacle of our training that ended in our transormation into Marines. After this event we were called Marines instead of recruits.

The Storming Part

Anyone ever been cranky after skipping breakfast, or getting an hour less sleep at night? Imagine what we were going through from a stress perspective with basically no sleep and no food, physically exhausted from marching, and then being asked to complete these missions as a team. When we first started on day 1, we were accomplishing missions ok. We were divided into newly formed teams of people we probably hadn't worked with before. After all the exhaustion, crankiness, and stress started to settle in, things got ugly. We were yelling, arguing, fighting (physically), and pretty much hated each others guts, and obviously failing at all of our missions. The Drill Instructor assigned to our team just watched, sometimes laughing at us, but let us carry on. After awhile he then explained to us that what we were going through is absolutely normal. That teams normally go through a period of storming, however due to our lack of sleep, lack of food, and exhaustion that everything was amplified.

Now The Norming and Performing

It didn't take long after he put things in perspective for us, that we started to see what was going on. We even started joking about some of the stupid things we were doing and started to bond. Funny thing happened is that as time went on, we had less food, less sleep, and more exhaustion but yet were accomplishing our missions with greater ease and we were seeing the difference. Our productivity and performance was night and day after experiencing our storming. That's not to say that we didn't have our arguments throughout the rest of the crucible. But they were more constructive and actually lead to greater results. Because we learned how to properly storm, when not to cross the line, and how to control our emotions by recognizing stress was changing our rational thought. I still remember that event to this day. Not from all the blisters and pain. Not from the ceremony in front of an Iwo Jima monument - where our platoon of beaten down recruits were handed an Eagle, Globe, an Anchor (USMC logo) and called Marines by our Drill Instructors. But I remember that event because I think I finally learned and figured out what a team was. That it was more than a group of people. In 3 days I saw with my own eyes and was part of a transormation that lead me to believe that the saying that "the whole of a team is greater than the sum of it's parts" was not just a bunch of BS. And I truly believe and see how the storming was necessary step for us to understand how to work with each other to perform.

I wanted to share that story as an extreme example of Storming, but to drive the point that it is necessary. It can't be skipped over. Well, it can, but your team will not reach it's full potential, and in my eyes won't be a team unless they go through that stage. Passive aggresive behavior is detrimental to a healthy team.

How I Embrace Storming Today - Tips:

It doesn't always happen, but the first thing I try to do when forming a team is talk about storming and "constructive arguments" with my team. And that I feel it is a necessary component and completely normal thing for us to go through. I also let my team know that I expect them to challenge me and my thoughts and ideas. That they should feel comfortable engaging in a "lively discussion" with me and not just always agree with what I say. I do outline rules of maintaining professionalism but encourage lively discussion. No insulting anyones thoughts or ideas. Challenging is ok. Absolutely no personal attacks or insults are tolerated. Another rule is that the storming phase of a team does stay within a team, and people should feel comfortable to solve their problems and talk them through with team members. As a leader you are a facilitator, but when it comes to 2 people not getting along, they are the only ones that can resolve that. In the USMC we used to make 2 people having difficulties with each other go dig ditches together for hours. They might be upset at first, but eventually figure out they need to work together, find some common ground and start talking. I've experienced this myself, and even observed some people becoming best of friends after such an event. When a lively discussion is taking place sometimes I joke about us storming to ease tension but also recognize that we are exhibiting healthy team behavior. When I see someone biting their tongue, I encourage them to talk and voice their opinion. Otherwise, they will go voice their opinion to someone outside of the team and start anti-team behavior. Always keep an eye on things, when you get passionate people together with strong convictions, chances are sometimes lines will be crossed. Call timeout on such events and follow up with the individuals to address problems and concerns. Never reprimand someone in front of the team. Know your own limits. It's innevitiable if you are a strong, passionate leader that you will sometimes not just facilitate but will get involved. In many cases, I have found myself needing to take a step back from a discussion. Others thoughts or feedback? Feel free to storm with me if you disagree.

Sean Buck

Is it Groundhog Day? Thoughts on Self Organization, Self-Discipline & Light Touch LeadershipBy Sanjiv Augustine

In the movie, Groundhog Day, the central theme revolves around the protagonist reliving February 2 over and over again. In doing so, he uses the knowledge to improve himself, and of course, to move the film towards a happy Hollywood ending.

A couple of years ago, Jim Highsmith's Cutter Advisory on self organization, No More Self Organizing Teams, resulted in a passionate response from Tobias Mayer (and others). I responded via this Blog post.

In the time since, I've encountered this debate regularly on various user groups. Do agile teams need project managers or ScrumMasters; or can they simply self-organize? I've come to realize that it is one of those groundhog day type questions that keeps getting asked over and over again. I think the question is repeated because someone in one camp or the other doesn't really like the answer they've been given. And so they ask the question again in hopes of getting and an answer closer to one they like.

In the hopes of improving myself, and moving towards a happy ending to this story, I'm reposting my response below. I've taken the liberty to update it slightly for readability:

This is a discussion that gets to the essence of Agile methods. Both Jim’s and Tobias’ posts are impassioned and display remarkable shared concern for preserving the hard-won value wrought by Agile methods in tough environments. But there’s also a difference, that though barely perceptible, reveals a divide to those familiar with the territory. The dividing line becomes clearer when one reads the follow up messages — the line faults along manager and non-manager.

To managers, this is about something very, very fundamental. Managers are interested in understanding how to add value on Agile teams and discover the best value-adding role for them on Agile projects. So, to my mind this is really about the role of the manager on the Agile team. See my Blog post on this topic here:http://lithespeed.blogspot.com/2007/09/agile-project-management-role-of.html

Agile methods have been great about defining how developers can add value. With the product owner role becoming more solidly defined in Scrum, business analysts can jump on board as well as product owners or product owner proxies. But what about managers, and testers (anyone remember those guys who used to show up with reams full of defect listings?). And how about user interface designers (users do like those cool interfaces and design is an increasingly sought-after specialization), production specialists (maintaining production environments that are reliable and secure is an expert skill), etc.

The truth is that, as Agile methods are successfully making the transition into the mainstream, they are being quietly adapted to fit into large, complex organizations. Very few adoptions of Agile in these organization go exactly "by the book." Work in large, complex organizations tends to flow across organizational silos. Significant strides have been made in creating integrated teams that collapse some organizational silos. On these teams, costly hand-offs have been eliminated or at least reduced. But, the prevailing reality is that, in most organizations organizational silos with division of labor exist in some shape or form. And in most large organizations, those silos are also represented on Agile projects. Therein, I think, lies the core issue. Can division of labor be completely eliminated from Agile projects and teams?

Most managers, I believe, will take the pragmatic view, press for an integrated team, and then manage work across said silos. Others will hold that the organizational structure itself is flawed, and therefore needs to be completely replaced. Rid organizations of the scourge of division of labor, move to completely integrated teams, adopt a craft model, and everything will be solved, they hold. Managers — at least those not appointed by the team — will then not be necessary, they believe. Perhaps. But, as long as organizational silos exist, some division of labor is necessary for effective functioning, and these discussions will continue.

As for leadership, it’s like mom-and-apple-pie. Everyone seems to agree that leadership is a good thing, don’t they? Though how that leadership is appointed, sanctioned or manifested is the subject of debate, I think we all agree that leadership is a good thing on Agile teams.

My own position is that, if we can find ways to reduce non-value added management work caused by the reality of organizational silos (via Lean Kanban systems, etc), we can then all — managers and non-managers alike — get down to the important business of figuring how to lead our Agile teams. Until then, having a role that addresses the management work is simply a necessity.

To that end, Light Touch Leadership, as Jim articulates, is a great way for managers to lead Agile teams in a way that is completely congruent with the Agile value system, but that also acknowledges the reality of organizational silos and division of labor in most organizations.

I think there is definitely a place for a value-adding Light Touch role on agile teams. Light Touch is about managing agile teams with a style that allows team autonomy and flexibility, and a customer value focus without sacrificing control.To learn more about what I deem Light Touch management, go here: http://www.informit.com/articles/article.aspx?p=390811.

What do you think? Do we need project managers and/or ScrumMasters on agile teams? Please chime in!