Agile Office Space Followup

Thanks to Skip Angel (@skipangel) for facilitating an excellent session at the Seattle Scrum Gathering on Collaboration Workspaces.  For those that are interested in more information, my deck on Agile Office Space is available here. I also have some supporting images available here.

Also see Agile Office Space and Agile Office Space – Isolation versus Distraction for my previous blog entries on this topic.

I will be presenting on Agile Office Spaces at the the July NOVA/DC Scrum User Group meeting and at Agile 2011 conference in August.  Those sessions will be a highly re-factored workshop based on my original presentation.

On a side note, I am way overdue on my Agile Coaching Part 2 blog entry.  Coming soon (hopefully).

What is an Agile coach, really? (Part 1)

This past Thursday night Lyssa Adkins spoke on the topic of being an Agile coach at the APLN DC chapter meeting. Lyssa is widely known as a coach of coaches and is the author of the popular Agile coaching book, Coaching Agile Teams. Having heard her speak several times, I really like the energy she brings to her sessions, her positive vibes, her experience, and the coaching expertise that she applies to her talks.

Lyssa explaining the path to being an Agile Coach (picture courtesy of Manoj Vadakkan)

The session presented clarity on what an Agile Coach is and does and how that differs from that of a consultant or even a ScrumMaster.

Below are some of my notes and takeaways from the session.


Agile Coaches are detached from the outcome
An Agile coach has a certain amount of detachment from the outcome.  I believe Lyssa's point is whatever happens is what was meant to happen.  As a consultant coming into client as a Agile Coach, there can be a certain amount of healthy detachment that allows for clarity in perspective and approach. One issue I raised is that as an employee to a company and working as an internal Agile coach or ScrumMaster, it becomes harder to detach yourself from the outcome.

Agile Coaches take it to the team
Many times as "experts" and consultants, we feel we have the right answers.  However, as an Agile Coach we are there to guide the team towards their own answers. Questions were raised throughout the night on specific client issues and it was interesting to hear Lyssa answer with, "As a consultant, I would tell the client to do the following....".
Overall, I definitely agree with Lyssa here, if a team comes up with their own solutions and own that solution, they are more vested in its outcome and this ultimately helps the the learn and grow (which brings us to the next point).


Agile Coaches work to help the team learn
The goal of the Agile Coach is not to solve a problem for the team (or client), but it is to help the team learn and grow.

Agile Coaches holds up mirror on accountability
Agile Coaches help the clients understand themselves and how they are related to what is going on around them. Self awareness and realization helps the client create the answers that are right for them.


Agile Coaches master their face
This one is interesting.  As an Agile Coach, we need to be aware of our body language, such as our facial expressions. When clients come up with something that visibly makes the coach happy (or sad), this can affect the client's decisions. What the coach wants is the client to do what they feel is right, not what they feel will make the coach happy.


Let there be silence
I like this one. When there is awkward silence during meetings and discussions,often the expert/coach is tempted to break the silence with the thought of keeping the meeting moving or to generate ideas. However, it's that awkward silence where the team thinks about the hard questions and often step up with incredible solutions.

This ends the first half of my notes, more tomorrow on Part 2 of my notes where we talk about:

• Being outrageous
• Letting the team fail
• Doing and being
• and more .....

Local DC Agilists enjoying Lyssa's session (photo courtesy of Manoj Vadakkan)

DoD Agile Conference - A Summary By Dr. David Rico

Five years ago if someone had told me there was going to be an Agile conference centered around the Department of Defense, I would have thought not likely.  However Agile is striking a chord in the Federal government and there are those in the DoD looking to leverage Agile to bring success to their programs.  The DoD, through AFEI, recently sponsored a one day Agile Development Conference.  Excella Consulting had the honor of being a Platinum Sponsor and I had fun fielding Agile questions as part of the Expert Panel.

A friend of mine, Dr. David Rico, sent me his summary of the event and he has graciously allowed me to share it via my blog.  David is a keen Agilist who also works in the Federal sector.  More information on David and his work can be found on his website, http://www.davidfrico.com/.

Click for event program

-----------------------------------

AFEI DoD Agile Development Conference

by Dr. David F. Rico (author of “Business Value of Agile Software Methods” http://rico.com/agile-book.htm)

The AFEI DoD Agile Development Conference was held on Tuesday, December 14, 2010 in Alexandria, Virginia (http://www.afei.org/events/1A01/Pages/default.aspx). The purpose of the conference was to promote agile acquisition and IT development practices in the U.S. DoD. AFEI is a non-profit organization who helps the U.S. DoD develop contemporary acquisition, systems, and software practices, among other valuable services.

The AFEI DoD Agile Development Conference was rather enlightening. It reinforced the U.S. DoD's commitment to the use of Agile Methods. Furthermore, it was interesting to see that Agile Methods are in widespread use by the U.S. DoD, and that no individual organization, project, group, or person is practicing them in isolation.

Prior to AFEI's DoD Agile Development Conference, both the commercial industry and DoD contractors believed the U.S. DoD was not committed to Agile Methods, which is an enormously incorrect assumption. It's a popular urban legend or urban myth that the U.S. DoD uses traditional methods such as DoD 5000, CMMI, PMBoK, and other waterfall-based paradigms to develop IT-intensive systems (and that no one is using Agile Methods in the U.S. DoD).

The AFEI DoD Agile Development Conference shattered that myth completely. Furthermore, it served as a forum for reinforcing the use of Agile Methods in the U.S. DoD. Psychological reinforcement or affirmation of a desired behavior is a key ingredient to successful organization change (i.e., adoption of Agile Methods and the abandonment of traditional ones).

The OSD/NII(CIO) Office, who is responsible for the acquisition of IT-intensive systems, supports the use of Agile Methods as an alternative to the traditional, waterfall-based acquisition system as characterized by DoD 5000. The DoD's CIO recognizes that IT-intensive systems are not missiles, tanks, airplanes, or ships, and there is a need for Agile Methods as an alternative to DoD 5000.

In response to Congressional Directives, the OSD/NII(CIO), NDIA, AFEI, and a variety of defense contractors and commercial consultants have chartered a number of panels to form the basis of a new U.S. DoD policy requiring the use of Agile Methods for the acquisition of IT-intensive systems. The AFEI DoD Agile Development Conference is a continuation of the process for creating a new U.S. DoD IT-acquisition policy based on Agile Methods.

The AFEI Agile Development Conference was rather unique in that it brought together U.S. DoD Civil Servants who are currently serving as program managers overseeing the acquisition of IT-intensive systems using Agile Methods. The average conference typically arranges for contractors and consultants to share their experiences on the use of Agile Methods. In this case, however, the Agile experience reports were given by U.S. DoD civil servants (i.e., government workers). There were about 150 people in attendance.

The Agenda for the AFEI Agile Development Conference was as follows:

1. DoD Keynote: Beth McGrath, who is the Deputy Chief Management Officer (DCMO), described the necessity of using Agile Methods to acquire IT-intensive systems. She said the DoD acquires over $40 billion worth of IT-intensive systems every year and the average delivery time is seven years (for the few that succeed). She urged the community to stop using DoD 5000 for acquiring IT-intensive systems in order to shorten cycle times and increase the success rate of IT acquisitions. (She cited rapid technological obsolescence as a major reason for using Agile Methods.)

2. Industry Keynote: Scott Ambler, who is IBM's Agile Practice Leader, urged the U.S. DoD to stop using the waterfall-based DoD 5000 acquisition system. He provided a number of statistics showing that Agile Methods are generally superior to traditional ones in terms of cost, quality, schedule, customer satisfaction, overall success rate, and variety of other performance measures.

3. Panel One -- The DoD Environment for Agile:

a. Dave Mihelcic, who is DISA's Chief Technology Officer (CTO), described how DISA has fully adopted Agile Methods for the development of IT-intensive systems. DISA has also developed a variety of automated tools and services to help other U.S. DoD components to migrate towards the use of Agile Methods.

b. Rory Kinney, who is USTRANSCOM's Chief Enterprise Architect, described how his organization has fully transitioned to the use of Agile Methods for the acquisition of IT-intensive systems. He also described how USTRANSCOM has an enterprise architecture and service oriented architecture to integrate their overall end-to-end systems.

c. Dr. Steve Hutchinson, who is DISA's Test and Evaluation Executive, described how they've streamlined the traditional DoD test and evaluation process and reduced it from an average of over six months to only a few weeks. DISA has fully adopted the Agile Methods practice of Continuous Integration (i.e., automated testing) for this purpose.

d. Daniel Risacher, Associate Director for Information Policy and Integration (ODCIO), described his experiences developing, deploying, and institutionalizing the use of Open Source Software Development (OSSD), which is a type of Agile Method. Although he was able to draft the U.S. DoD OSSD policy in a few weeks, it took Pentagon lawyers over a year to approve it. He described the use of open source software as a significant cost reduction measure in the U.S. DoD.

4. Panel Two -- Getting Agile, Lessons from the Field:

a. Kelly Goshorn, AFMC Patriot Excalibur Program Manager, described the U.S. Air Force's Agile Methods journey over the last eight years. Patriot Excalibur, which consists of over 100 developers, is an automated scheduling and workflow system for unit-level aircrew scheduling, training, and evaluation. After adopting Agile Methods in 2002, the AFMC was able to rapidly deliver capabilities to grow their user base by over 10 times.

b. Mike Krzysko, OSD Deputy Director, described the Pentagon's efforts to roll out Agile Methods for developing IT-intensive systems.

c. Pat Benito, MITRE Agile Practice Leader, described MITRE's efforts to help U.S. DoD components adopt Agile Methods. MITRE is tasked with seeking out U.S. DoD IT development offices, promoting the use of Agile Methods, and aiding them in their transition.

d. Maj. Marc Franciszkowicz, DTRA Mobile Field Kit Program Manager, described the DTRA's experiences with Agile Methods. The Mobile Field Kit is a combination of software and services that provide field technicians with on-demand access to information for response planning. Agile Methods have enabled DTRA to scale up and out without the necessity for significantly more resources or loss in acquisition efficiency.

5. Panel Three -- Enterprise Services, Infrastructure and Applications:

a. Wayne Farmer, DISA RACE Program Manager, described DISA's Rapid Application Computing Environment. RACE is a suite of automated tools to support development, operational, and certification testing; certification and accreditation; and other deployment readiness assessment tasks.

b. Robert Viermeyer, DISA Forge.Mil Program Manager, described DISA's Forge.Mil, which is a hosted collaborative environment for developing open source software within the U.S. DoD. Forge.Mil is moving towards a hosted Continuous Integration services for U.S. DoD IT-intensive programs.

6. Panel Four -- Ask the Experts Panel:

This was a panel of five industry experts on Agile Methods, hosted by Chris Gunderson of the Naval Postgraduate School. Chris, an outspoken critic of Agile Methods, challenged the panel of industry experts on a variety of flash points. These included organizational change and adoption issues, scalability to large U.S. DoD programs, and empirical evidence to indicate whether they were any better or worse than traditional, waterfall-based methods. The industry experts challenged the moderator to prove traditional methods were any more scalable or applicable to large programs, citing the 67% failure rate among DoD programs using traditional methods over the last 40 years.

(Chris Gunderson is the primary author of a NDIA report, which is intended to show U.S. DoD executives "how" to implement and apply Agile Methods on U.S. DoD IT-intensive systems, "Industry Perspectives on the Future of DoD IT Acquisition," http://www.afei.org/WorkingGroups/Documents/TF_804_final_pdf.pdf ...)

As a result of the AFEI DoD Agile Development Conference, it now becomes apparent that the use of Agile Methods in the U.S. DoD is in its Golden Age. On the other hand, it is also apparent that the fundamental belief that U.S. DoD IT programs are characterized by the use of traditional methods such as DoD 5000, CMMI, and PMBoK is only an urban legend or an urban myth. That is, Agile Methods are in widespread use by IT and software-intensive programs and projects throughout the U.S. DoD.

The same can also be said of most small to medium-sized IT and software-intensive systems throughout the U.S. DoD.

The more traditional elements of DoD 5000, CMMI, and PMBoK are required for the largest U.S. DoD programs (i.e., fixed-price contracts, immovable governance boards, meticulously-detailed earned value management, iron-clad project plans, voluminous requirements specifications, big upfront architectures and designs, late and ineffective test and evaluation, reams of documentation, etc.). Large U.S. DoD programs are known as Acquisition Category (ACAT) I programs and are characterized by multi-decade, multi-billion dollar budgets that are subject to enormous cost and schedule growth (along with substantially reduced delivery order quantities). (We'll call these Big Acquisition or Big-A projects.)

However, over 95% of all U.S. DoD projects are not ACAT I programs, but are typically small to medium-sized IT and software-intensive programs. (We'll call these Little Acquisition or Little-A projects.) Acquisition managers of IT-intensive systems typically hire very-skilled and highly-qualified IT workers who are well-versed in contemporary development approaches such as Agile Methods. Therefore, practical experience shows that well over 70% of Little-A projects apply Agile Methods, although hardware-intensive Big-A projects seem to get all of the bad press and fool people into viewing the U.S. DoD as a culture characterized by the use of traditional methods.

(This isn't to say that Big-A traditional methods aren't applied to Little-A projects. Traditional methods such as DoD 5000, CMMI, and PMBoK are occasionally applied to IT-intensive projects, which generally causes them to escalate into runaway programs, i.e., a small multi-million dollar projects explode into a $500 million or even multi-billion dollar projects before collapsing under the weight of over burgeoning governance, processes, and documentation ...)

(The "trick" is to break Big-A traditional methods-based projects into smaller ones and apply Agile Methods to them, not vice versa, scale Little-A Agile Methods-based projects into big ones and apply Traditional Methods – This is called "batch-size reduction" or "lower work-in-process," which is a key Lean/Kanban principle ...)

Big-A policy makers were conspicuously absent from the AFEI DoD Agile Development Conference, such as representatives of OSD's Deputy Undersecretary of Defense for Acquisition and Technology (DUSD/A&T) and the Defense Acquisition University (DAU). However, members of organizations that promote traditional methods for IT and software-intensive systems were in attendance, such as the Software Engineering Institute (SEI) and Data and Analysis Center for Software (DACS).

Agile Methods are not just limited to the development of IT and software-intensive systems. The U.S. DoD has been promoting the use of evolutionary and spiral development for more than a decade. The U.S. Air Force pioneered the use of Agile Acquisition and Systems Engineering as early as 2002. The Stevens Institute of Technology offers a graduate certificate in Agile Systems Engineering.

More recently, the International Council on Systems Engineering (INCOSE) formed a working group for developing lean systems engineering practices, which have already been released to the public. The Project Management Institute (PMI) is developing an Agile Project Management (APM) Certification program. Lean and Kanban techniques for acquisition, systems engineering, and even software development are quickly emerging. The U.S. Air Force Rapid Capabilities Office (RCO) has been using Agile Acquisition and Systems Engineering practices to develop advanced air and spacecraft in as little as two years, such as the Liberty, MC-12W Unmanned Aerial Vehicle, and X-37B Operational Test Vehicle (military space shuttle).

(I was even able to distribute over 50 copies of my new DoD AT&L magazine article entitled, "Lean and Agile Acquisition and Systems Engineering: A Paradigm Whose Time Has Come", http://www.dau.mil/pubscats/ATL%20Docs/Nov-Dec10/Reagan.pdf ...)

What's the bottom line? The U.S. DoD needs to finalize its policy on the use of Agile Methods for the acquisition of IT and software-intensive systems (and stop applying Big-A traditional methods to Little-A projects causing them to escalate into runaways). The DAU needs to take a more active role in institutionalizing the use of Agile Methods for Little-A projects. OSD(AT&L) is in dire need of visionary leadership to begin transitioning Big-A projects to the use of Lean and Agile Acquisition and Systems Engineering policies.

(There are other nagging little gaps and issues that need to be resolved, such as the integration of security engineering, user experience design, and Kanban principles and practices into Agile Methods, along with a focus on commercial Web services integration vs. programming every system one line of code a time ...)

Finally, NDIA and AFEI also need to "continue" taking a leadership role in organizing conferences that bring U.S. DoD civil servants together to share their experiences applying Lean and Agile Acquisition and Systems Engineering practices for Big-A programs as a means of psychologically-reinforcing much needed organization and behavior change within the U.S. DoD acquisition community ...

(NDIA and AFEI may be willing to host a Lean and Agile Acquisition and Systems Engineering Conference as early as February 2011 ...)

(Here is a persistent link to this document, http://davidfrico.com/afei-2010.doc ...)

Industry recommends Agile to Federal government

 I recently read an article that referenced a very interesting report.  The article “Federal Information Technology Reform Urged” discussed a report by TechAmerica.  The article states:

The TechAmerica-backed report, "Government Technology Opportunity in the 21st Century," put together by a 31-member commission largely composed of federal IT industry execs and drawn from interviews with and collection of feedback from 105 IT industry execs, government officials and members of academia finds federal IT lagging and in need of reform.

The interesting item is the report itself, which talks about the gap between IT in the Federal space versus industry.  One key message from the report is a push for Agile/Incremental Development.   Section 2.2 - Promote Agile/Incremental Development is an interesting read.  It talks about the need for Agile and implementation ideas for OMB, Agencies, and working with industry (click on image below for a sample).

Section 3 of the report lays out an implementation plan that looks to promote Agile in early 2011 (click on image below).  The report is a pretty quick read and can be found here .

Washington DC, the center of the Agile universe….

Well, maybe not the center of the Agile universe, but there sure is a lot going on this month in and around the DC area (with most of it occurring in the Northern VA area). Take a look:

Summary

September 30th	Agile Alliance Board Reception 6:30PM to 9:30PM, The Westin Hotel @ Tyson's Corner
October 6th	PMI Fairview Park Luncheons: Agile Project Management - Truths and Misconceptions Exposed Presented by me :) 11:30AM – 1PM, Falls Church, VA
October 6th	DC/NOVA Scrum User Group - Enterprise War Stories 6:30PM, Bungalow Billiards in Chantilly, VA
October 7th	APLN DC Chapter Meeting - The Art of Storytelling Presented by Fadi Stephan 6:30PM – 9PM, Vienna, VA
October 8th	Agile Influencers DC 5:30PM, Argia's Resturant, Falls Church, VA
October 9th – 12th	PMI Global Congress All day events from 10/9 through 10/12 My session "Agile at the Office of Personnel Management: A True Story" 10/12 @ 2:15-3:15PM Gaylord National Resort & Convention Center, National Harbor, MD
October 22nd	Agile Tour DC 9AM – 5PM, near Tenleytown Metro, Washington, DC

 
Details 

Agile Alliance Board Reception

This is a great opportunity to meet the new Agile Alliance Board of Directors, now featuring local Agilist Linda Cook. If you plan on attending, please RSVP to Gale Niles at admin@agilealliance.org. For more information, see http://www.agilealliance.org/index.php/events/agile_alliance_board_reception.

Agile Alliance Board Reception

September 30, 2010, 6:30 pm to 9:00 pm

The Westin Tysons Corner

7801 Leesburg Pike

Falls Church, VA 22043

 
PMI Fairview Park Luncheons: Agile Project Management - Truths and Misconceptions Exposed

In this interactive presentation, I will be presenting a series of Agile Truth or Misconception questions to the audience and we will interactively explore this topic. This promises to be an interesting session for those just learning Agile as well as good for those deep in Agile.

There is no fee for this session, but it is a brown bag lunch session. There is a cafeteria in front of the auditorium in the Noblis building where one can purchase lunch and bring to the presentation. More information available at http://www.pmiwdc.org/2010/10/Fairview

Wednesday, October 6, 2010

11:30 am: Networking

12:00 pm – 1:00 pm: Program

 

Noblis

3150 Fairview ParkDrive South

Falls Church, VA 22042

 
DC/NOVA Scrum User Group - Enterprise War Stories

This DC/NOVA Scrum User Group is a relatively new user group formed by the Motley Fool's Max Keeler. The format is a round table discussion kicked off by a general topic. The fun thing is that we meet at a pub, so there are drinks involved. See Max's notes below for more details. More information available at http://groups.google.com/group/dcnova-scrum-user-group and http://groups.google.com/group/dcnova-scrum-user-group/browse_thread/thread/5c5d9a12a02f629b. Unfortunately, I will be out of town for this event, but it promises to be a good session.

From Max:

• Meet-up starts at 6:30 here:  http://www.mapquest.com/mq/3-pZZiy7mckDBB
  
• The topic will be:  "Enterprise Scrum implementation war stories: What has worked, what has failed and everything in between."
  
• Like last time, we'll chat informally until about 7:30 allowing people to filter in.
  
• At 7:30ish we'll start discussing the topic, and break into groups if necessary. 
• We seem to end at around 9.
  
  Wednesday, October 6^th
  6:30PM to 9PM
  Bungalow Billiard & Brew Co
  13891 Metrotech Dr
  Chantilly, VA 20151
  (703) 502-3925

 
APLN DC Chapter Meeting - The Art of Storytelling

The Agile Project Leadership Network (APLN) DC chapter meeting generally occurs on the second Thursday of every month and is in presentation format. I'm very excited about this month presentation and disappointed that I will miss it because I will be out of town. Fadi Stephan will be presenting "The Art of Storytelling". The summary reads as follows:

"Agilists use user stories as a way to capture user requirements and drive the planning process for iterative and incremental delivery of software. In this presentation we'll see the benefits of using user stories over other types of requirements gathering approaches. After mastering the basic concepts and attributes of user stories, we will progress quickly and discuss different techniques for user role modeling, methods for capturing requirements, criteria for splitting or merging stories, and ways to handle dependencies, constraints, assumptions, and non-functional requirements.  We'll wrap up with clear guidelines on writing effective user stories."

I have seen so many teams struggle with writing and using User Stories and I think this session will be great for helping attendees get a deeper understanding of User Stories. Since I work with Fadi and will not be in town for his presentation, I look forward to chatting with Fadi about his presentation. More information available at http://aplndcoctober2010.eventbrite.com/

Thursday, October 7^th

6:30 to 9PM

AT & T Facility

1900 Gallows Rd.

Vienna, VA 22182

Agile Influencers DC

After the recent Agile Coach Camp in North Carolina, Paul Boos noted that there were quite a few attendees from the Northern Virginia Area. Thus he started the Agile Influencers of DC group. This group meets on the second Friday of every month. The meeting generally start with lightening round presentation/discussion around specific topics followed by group discussions. The fun thing is that the meeting occurs a Argia's Restaurant, which is a great Italian place in Falls Church. For more information, see http://www.coactivate.org/projects/agile-influencers-of-dc/summary


 

Friday, October 8^th

Argia's Restaurant‎

124 North Washington Street

Falls Church, VA 22046-4514

Tel: (703) 534-1033

Web: www.argias.com‎

Google Map: http://bit.ly/cVixWL

 
PMI Global Congress

Now this is interesting, at this year's PMI Global Congress, there are at least 14 separate talks on the subject of Agile. I'm not sure what the numbers were in the past, but I have to believe this is a record. As I was filling out my registration program (unlike the Agile conference, PMI makes you pre-select all your sessions) I realized that there was at least one Agile presentation during every time slot of this 4 day conference. That is amazing!



I, along with David Neumann, will be presenting on the topic of Agile at the Office of Personnel Management (http://congresses.pmi.org/NorthAmerica2010/TheCongress/AOF/Event.cfm?EventID=196). For more information, see http://congresses.pmi.org/NorthAmerica2010/TheCongress/

October 9^th through 12^th

Gaylord National Resort & Convention Center

201 Waterfront Street

National Harbor, MD 20745

 
Agile Tour DC

This one is also very exciting. The Agile Tour DC is a one day event in DC that will feature 3 tracks:

• Agile Essentials – Get the skills you need to get started.
  
• Enterprise and Government Agility – See how it works in the large and hear from a Panel of practitioners working in government.
  
• Open Talks Track – Create the conference you want in this Open Space (like) track.  Don't see a talk on one of the other two tracks propose one or attend one of the 4 concurrent Open Talks.
  

Note that I will be running a panel session on Agile in the Government. This will be the third time I have participated in such as session. The first time was at an APLN event last year that was went very well. However, at the recent Agile 2010 session, I was a panelist for an Agile in the Federal Government session and it did not go well at all. There were quite a few Federal employees in the room and they hated me. I don't think they liked the fact that the panelists were all consultants and I don't think they cared much for me in general. However, I have quite a few lessons learned and I am excited (and nervous) about re-doing this session. This time I am bringing in the big guns by having Paul Boo (EPA) and Don Johnson (DOD) as panelists. Both are Federal employees with deep expertise in Agile. Additionally, I have a new re-factored introduction that I think will either win over the crowd quickly or they'll just hate me again. We'll see, looking forward to it!



For more information, see http://agiledc.org/. Use the code "AgileDC" for $10 off registration.

October 22^nd

9AM – 5PM

Conference Center

4000 Wisconsin Ave, NW

Washington, DC 20016

How do I know if my resources are being fully utilized?

One question I hear from managers just starting an Agile process is how does the process ensure developers are hard at work and that there is not a lot of lull time.


This is the wrong way to think about the project. What I would have the managers look at, in prioritized order:

1. The product backlog – ensuring there is a high level backlog.  This usually starts at the project initiation phases and continues throughout the lifecycle.
   
2. The sprint backlog – ensuring there is a detailed backlog for the immediate and perhaps upcoming sprints
   
3. High completion percentage – having the team be able to give their commitments and establish a pattern of high completion rate.  The completion rate is (the amount of work of work completed) / (the amount of work to which the team committed) for the sprint.
4. Stable velocity – once you have a high completion rate, then look towards stabilizing the velocity.
   
5. Evolve/Optimize – once the team understands its capabilities and capacity, it is ready to expand its abilities.
   

Steps 1 and 2 are extremely important in not only giving teams direction, but also ensuring that there is product/project vision is in place.  I am not advocating a waterfall/SDLC know-everything-up-front mentality, but I am suggesting that the program (product owners) provide a responsible level or direction for the project.  Often we see a focus on ensuring that the team is fully utilized while the understanding of what is being built is under-served. These initial steps should focus on identifying what is being built, understanding the acceptance criteria for being done, and ensuring the priority is in place.


 
Steps 3 and 4 go hand in hand.  When a team understands its ability (Step 3) and capacity (Step 4), the project has great advantages to success.  Project estimates can now be made with responsible levels of confidence and historical backing, which leads to enhanced capabilities on making strategic decisions.  This is where the bulk of the work is going to take place in maturing the process and team.  


 
Step 5 is where we get back to the original question.  Without Steps 3 and 4 in place, this is pointless. Once we understand ability and capacity, then we can look to improve. I would change the statement "hard at work without lull time", which measures no value.  What we can do is measure the value the team is delivering (usually in the way of business value points combined with story points) and identify how we can further improve those metrics.  Focus not on individuals being fully utilized, but rather on team delivery of value and increasing it.

Mouse hard at work

Agile and the Federal Government Panel Discussion at Agile 2010

For the Agile 2010 Conference, I had submitted a panel session on the topic of Agile and the Federal Government.  Fortunately, my session was picked up by the conference.  Thus, tomorrow (Thursday 8/12) at 3:30PM, we will be presenting "Agile and the Federal Government - A Panel Discussion". 

This session promises to be interesting and will be in a format similar to last year's "Agile and the Federal Government - A Panel Discussion" at APLN DC.

Agile Fed Govt Panel Discussion - APLN DC April 2009

The plans for the Agile 2010 session had myself as a panelist and:

• panelist - Dr. Suzette Johnson, head of Agile Management and Leadership at Northrop Grumman 
• panelist - Dr. David Rico, Boeing, author and speaker, http://davidfrico.com/
• panelist - Jesse Fewell PMP, CST, Ripple Rock, founder PMI Agile Community of Practice,
  http://www.jessefewell.com/
• Moderator - Shannon Ewan, Excella Consulting, former APLN DC leadership board member

For anyone that has the printed Agile 2010 Conference program, it has the people above listed as the panelists.  I expected to lose one or two people to unforseen circumstances and thus we had also recruited Rodney Bodamer (AgileX Consulting, APLN DC chairperson) as another panelist.  The unfortunate news is that due to work conflicts, David, Suzette, and Jesse are unable to attend the conference.

The great news is that we found great new panel members to take their place.  Suzette recommended Andy Pickler.  Andy works with Suzette in leading the Agile Community of Practice at Northrop Grumman. 

On seperate recommendations from Ken Mills of VersionOne (thanks Ken) and from David Rico, we welcome Dottie Acton to our panel.  Dottie is Senior Fellow at Lockheed Martin and has deep experience in Agile and in the Federal sector.

I am excited about the new panel and look forward to the panel session tomorrow!  Below I have the full details to our panel session:


Agile and the Federal Government - A Panel Discussion
The Agile Manifesto states interactions over processes, collaboration over contracts, working software over documentation, and responding to change over following a plan. These base principals seem to be diametrically opposed to the Federal government. Is Agile appropriate for the Federal government and is the government ready for Agile? This panel discussion will look to address this question while taking a deep dive into the value, issues, details, and vision for Agile in the Federal government.

Session Format
The session will be a facilitated 90 minute panel discussion featuring panelists who are not only Agilists, but also deep in expertise and experience in the Federal government space.

The breakdown of topics will be:
- Introductions (~10 minutes)
- Why: What value does Agile bring to the Federal government (~15 minutes)
- Opportunities: Agencies and/or types of projects that are most receptive to agile methods (~15 minutes)
- Obstacles: Biggest challenges or pitfalls (~20 minutes)
- Strategies: What strategies have worked best for selling, introducing, and executing agile? (~20 minutes)
- Closing thoughts (~10 minutes)

Each question will start with a panelist or two presenting their thoughts followed by an opportunity for other panelists and attendees to provide their input and ask questions. We will encourage active participation by the audience with a goal of having a lively and interactive conversation.

Panelists

Dottie Acton
Dottie Acton is currently a Lockheed Martin Senior Fellow, and has served as the chief software engineer and as a process/methodology consultant for several major programs. Over her 30 year career, she has worked the entire program life cycle, from proposal through operations at the customer site. Dottie has a BA in Mathematics from Lycoming College, and an MS in Computer Science from Syracuse University.

She is an avid reader, and is always studying new technologies. Dottie's major area of interest is software development methodologies and techniques. She enjoys teaching, mentoring, and figuring out better ways to develop software and is currently helping programs apply Agile development methodologies. In addition to her knowledge of a wide range of software methodologies, Dottie has expertise with C++, Java and COTS integration. She has also led teams in developing effective metrics programs and preparing for CMMI assessments.

Rodney Bodamer
Rodney provides leadership in helping enterprise level clients adopt the use of both lean and agile methods, techniques, and best practices. Rodney has led numerous agile product development teams as a Certified ScrumMaster and Product Owner and has successfully coached numerous Fortune 100 clients in their transition to Agile. Rodney has trained and coached executive management on approaches and solutions to lean-agile institutionalization and organizational change management adoption challenges. He has over 15 years of project, program, and release management experience leading large, complex, mission-critical IT projects in the financial services, government/defense, insurance, and healthcare industries.

Rodney is an Agile Program Manager at Agilex Technologies. He is the chair of the Agile Project Leadership Network (APLN) DC Chapter and is currently working to bring Agile to the Department of Veteran Affairs.

Richard K Cheng
Richard Cheng is a managing consultant at Excella Consulting, providing consulting services to commercial and Federal clients in the Washington, DC area. Richard has successfully implemented Agile principles in managing web projects, implementing data transactions services, creating an international general ledger application, and implementing enterprise level financial packages. As a management consultant, Richard has coached and mentored clients on the adoption and implementation of Agile and Scrum. Richard also leads Excella’s Agile Center of Excellence. Currently, Richard is working to bring Agile to Federal government and is managing an Agile iterative solution on an Office of Personnel Management (OPM) program.

A graduate of Virginia Tech, Richard has authored several publications on project management, presented at Agile and PMI sponsored industry events, and is a member of Mensa. Richard is a certified Project Management Professional (PMP), a Certified Scrum Master (CSM), and a Certified Scrum Practitioner (CSP). Richard is an active member of the Project Management Institute (PMI), Agile Project Leadership Network (APLN), and Scrum Alliance.

Andy Pickler
Andy Pickler, CSM, is an Agile Expert within Northrop Grumman, currently leading a longstanding program through an agile transition. Andy has served as a Scrum Master, Product Owner, and Release Manager for several agile teams and programs, both within the government and commercial space.

Moderator

Shannon Ewan
Shannon Ewan is a Managing Consultant at Excella Consultant and a member of Excella’s Agile Center of Excellence. Shannon is a former member of the APLN DC leadership committee and is currently working to bring Agile to the Department of Defense. Shannon is a Project Management Professional (PMP) and a Certified Scrum Master (CSM).

"As agile development gains steam, some experts question whether it's right for government"

Several weeks ago I had crafted a presentation for a government agency on Agile training.  During this presentation, a Federal Computer Week article came into the discussion.  The article is titled Does 'early and often' work for software?
As agile development gains steam, some experts question whether it's right for government (http://fcw.com/articles/2009/10/19/feat-agile-development-government.aspx?sc_lang=en). Fortunately, I was familiar with this article from October of 2009 and I was able to speak on the points addressed in the article.

 
 

Overall, the article makes some good points.  It promotes the following benefits of Agile:

Agile Benefits

• "allows for quick reactions to technology innovations and shifting requirements"
  
• "It reduces a lot of risk, and you get capabilities into the users' hands much faster"
  
• "DISA used agile techniques to deliver initial capabilities for Forge.mil in just three months, a third of the time it would have taken using traditional methods … Early testing also helped DISA spot security gaps months before they would have surfaced otherwise."
  

However, it is the arguments against Agile that are a bit misplaced. Certainly there are challenges to Agile in the Federal government, as I noted in my last blog entry (http://www.onemoreagileblog.com/2010/03/challenges-to-agile-in-federal.html), however the points that Agile detractor Michael Daconta call out can easily be argued against. Below are the key points against Agile in the FCW article and my thoughts on these points:

1. Subject Matter Experts (SMEs) don't have the bandwidth to meet with team

On my last program at OPM, the previous efforts were nearly killed due to a stop work order placed on the program. One of the root causes was that the vendor at that time creating a solution that the vendor perceived to be correct. However, SME input into this solution was a bit limited due to a perception on how to use the time with the SMEs. In the end the effort did not go far past the requirement stages because the solutions proposed were not acceptable to the SMEs.

Using a collaborative Agile effort, the program was able to re-gain the interest of the SMEs. The program met with them twice a week for the length of the effort to discuss program needs and display working product. This produced engaged SMEs and quality product that resulted in published retirement data feed standards and working software.

2. Program Managers don't have time to help design an application on the fly

For the vast majority of projects, Program Managers should NOT be in the critical path of application design. On a cross functional team, that role is done by the team. The Program Manager can ensure the team has what it needs to perform the design and that there is sufficient bi-directional transparency between program needs and program design.

3. Pace can result in interdepartmental strain

I believe that this says that Agile allows you to go to fast. I don't see how this is a problem. In many ways the government pace should be challenged and Agile provides a great infrastructure for a responsible implementation of accelerated delivery. If the argument is that the pace is not sustainable, it should be noted that one of the key principles behind Agile is "Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely." (http://agilemanifesto.org/principles.html).

4. Pair anything will produce higher quality, but are you willing to pay double the cost

I believe this is referring to the practice of pair programming. It should be noted that though there are many in the Agile community that believe in the value of pair programming, it actually is an engineering technique and arguable not one of the key implementation points Agile on a program. I have seen many successful operations where pair programming is not mandated. I suggest that the program allow the teams to try pair programming as a team technique and let the team decide on its usefulness. With that said, a simple Google search will provide a vast library of information on the value and advantages of pair programming.

5. Agile development schedules bump into government budget and acquisition processes – DOD requires acquisition programs to meet a host of checklist items

This last point is very interesting. This statement actually calls out a problem that the DOD faces today. From a recent presentation by Don Johnson (OASD(NII)/DoD CIO) stated:

"As defined in the March 2009 Report of the Defense Science Board (DSB) Task Force on Department of Defense (DoD) Policies and Procedures for the Acquisition of Information Technology, the fundamental problem DoD faces is the deliberate processes through which weapon systems and IT are acquired does not match the speed at which new IT capabilities are being introduced in today's information age.  The DSB report highlighted that not only is an agile model more appropriate for IT programs, but it serves as a basis for changes to the larger acquisition model cross-cutting major weapon systems. "

The DSB report highlighted that not only is an agile model more appropriate for IT programs, but it serves as a basis for changes to the larger acquisition model cross-cutting major weapon systems. "

Mr. Johnson and the DOD CIO department are making a strong push for an adaptable Agile model for IT acquisition. To that end, on 10/28/09, the President signed the 2010 National Defense Authorization Act (2010 NDAA) that included a mandate to implement the agile acquisition model for all DoD IT acquisitions. Congratulations and good luck to Mr. Johnson on the presidential sign-off and implementation of this new model!

 

 

 
 

Challenges to Agile in the Federal Government

A short blog for today.  I was recently asked about the challenges of implementing Agile in the government.  My quick response was the following:

 -------------------

There are a number of challenges that one encounters in the government sector and these challenges are even further called out when trying to implement Agile in the government space. 

At its core, Agile is built around delivering results while the government focuses on managing risks.  Let us look at the Agile Manifesto:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

The Agile world focuses on the left over the right.  However, in today’s world the Federal government largely operates on the right side of these statements.

Thus key issues include:

·         Reporting of value.  The government largely uses EVM methods for reporting of value.  While EVM is not necessarily incompatible with an Agile model, most government organizations use EVM in a waterfall type model, which causes problems when mapped to an Agile program.

·         Governance.  Organizations such as GAO and OMB provide oversight to government projects.  There was an old theory that the more paper you provided to these organizations, the better your program looked.  Although it is getting better, there are still issues with resources at these types of governance organizations understanding the Agile model and being able to translate that into what they traditionally have required from projects.

·         Funding and Procurement.  The funding of government programs can have substantial lead time which creates challenges to programs.  In addition, government contracts are generally not written to support Agile methods.  This combined with limited knowledge of Agile by program contracting officers creates challenges for implementing Agile.

·         Misconceptions.  There are many in the government that have been use to running programs in a traditional way.  Often they believe that if a program fails, it is not because the traditional process is flawed, it was that the process was not implemented correctly.  Thus even more process is placed on the program.  Additionally, Agile is still new to many in the Federal government and misconceptions and misunderstandings on what Agile is have slowed acceptance of Agile.

·         Agendas.  In the Federal government there are multiple vendors, contractors, and organizational groups working on any given program.  Since these groups ultimately do not report to the same leaders and do not share the same vision, this can cause conflicts and political issues that can handicap projects.

As a side note, when I first started on my government program, I came to a project that had a nine person PMO overseeing 3 project managers, 4 business analyst, 1 architect and 1 developer.  The team size was probably ok, but I think the makeup of the team may have been a little off.