One More Agile Blog

Agile Office Space Followup

2011-05-18T16:58:00.000-04:00

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)

2011-03-06T21:55:00.002-05:00

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

2010-12-21T21:16:00.004-05:00

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

2010-11-28T23:00:00.001-05:00

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….

2010-09-30T00:03:00.040-04:00

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 30^th	Agile Alliance Board Reception 6:30PM to 9:30PM, The Westin Hotel @ Tyson's Corner
October 6^th	PMI Fairview Park Luncheons: Agile Project Management - Truths and Misconceptions Exposed Presented by me :) 11:30AM – 1PM, Falls Church, VA
October 6^th	DC/NOVA Scrum User Group - Enterprise War Stories 6:30PM, Bungalow Billiards in Chantilly, VA
October 7^th	APLN DC Chapter Meeting - The Art of Storytelling Presented by Fadi Stephan 6:30PM – 9PM, Vienna, VA
October 8^th	Agile Influencers DC 5:30PM, Argia's Resturant, Falls Church, VA
October 9^th – 12^th	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 22^nd	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?

2010-09-08T15:42:00.001-04:00

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:

The product backlog – ensuring there is a high level backlog. This usually starts at the project initiation phases and continues throughout the lifecycle.

The sprint backlog – ensuring there is a detailed backlog for the immediate and perhaps upcoming sprints

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.

Stable velocity – once you have a high completion rate, then look towards stabilizing the velocity.

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

2010-08-11T23:24:00.000-04:00

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"

2010-05-24T10:27:00.001-04:00

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

2010-03-08T10:54:00.002-05:00

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.

Agile Office Space – Isolation versus Distraction

2010-03-02T21:20:00.006-05:00

A colleague of mine recently forwarded an article on InfoQ regarding Agile Team Spaces (http://www.infoq.com/news/2010/02/agile-team-spaces). While I agree with the vast majority of the article, there is a point in this article that suggests minimizing distractions. My concern is the balance between minimizing distraction and isolating the team from everyone else. While teams in their own distraction free space does promote hyper-productivity, the trade off is that the team loses the connection and understanding to the rest of the company. The team's focus and vision narrows to the work in front of them, which is good for the short term, but becomes less clear on the big picture stuff, which ultimately can hurt in the areas such as product development and innovation.

Currently, I have a Scrum team located by themselves in the basement of a government building. The team is talented and has a done a great job thus far. They are left alone with few distractions and can produce work quickly. However, this team has some real struggles. The biggest issue is understanding the business vision and the prioritization of various elements of the program. This is proving to be a real challenge for our program and though we are producing work quickly, we often question if we are producing the right work and in the correct sequence (yes, I know that is the job of the Product Owner, who sits down here with us and has the same problems as the whole team). One of the key goals of this team is to physically move closer to the key stakeholders so that we can have day to day interactions with them to help us think more like our key stakeholders.

When I was working with the Motley Fool, I arguably had one of the best (if not the very best) Scrum teams in the company. It wasn't my awesomeness as a Scrum Master that made my team so effective, it was the team's understanding of the business vision and needs that made them strong. The team's ability to quickly understand the business needs and rapidly turn concepts into deliverables was particularly strong. Eventually the team had such a great understanding of the business and a great relationship with their business stakeholders that they became partners in innovation as opposed to just implementers of ideas. The reason that this team was so strong in this area is that their key business representatives sat right with them and were intimately involved in their day to day work. The team also had frequent access and visit from other people throughout the organization which allowed the team to develop a holistic view of the work and understand the true goals of their projects. Though it is true that the team could have worked faster with less distractions, I do not think they would have been working smarter if completely left alone.

While an Agile team with it's own space that is comfortable and pleasing does promote "hyper-productivity", there should be caution to this thought. In many ways, this is a throwback to the days where developers and development teams were the cellar dwellers and left alone to do their techie stuff while the rest of the company does business. This is a major step back and seems un-agile to me.

Agile Office Space

2010-01-08T15:51:00.003-05:00

I was recently asked what an Agile office space may look like. For an Agile space, let's use the Agile manifesto as a starting point and consider a space that allows for:

individuals and interactions
the creation of working software
customer collaboration
responding to change

Based on that, top goals are:

allowing for collaboration and real time information exchange (1,3,4) and
creating a space where work can get done (2) and where people will want to work (1)

With this is mind, the first thing I would do is get input from the team members. One of my clients recently moved offices. Management consulted with all their Scrum teams (and other teams impacted by the move) and asked them what where their needs for the new space. This was a great exercise on many levels. It allowed the teams to talk about what it really means to be an Agile team and how the space would look like to reflect this. Also, the exercise was a retrospective on our space; what we like and what we would like different in our new space. The feedback was considered and incorporated into the new designs. This is great for teams that are at least familiar with the base ideas of Agile, but if they don't have an understanding of the goals of the team and space, they may fall into bad habits such as setting up space to isolate himself/herself from everyone else.

With all that said, here are some specifics:

Create a open space. This allows for quick lines of communications and for people to get quick visual signs of team progress and issues. Half height cube space is a good way to do this.

Image 1 - Motley Fool Office Space (BTW, back right, where the guys is standing, was one of my old cubes). (http://www.flickr.com/photos/ksmith/152161913/

Image 2 - Motley Fool office space. (http://www.flickr.com/photos/ksmith/152161913/

Have all the team members sit together. If there are business analysts or biz reps on the team, the closer they are physically to the team, the better. This will allow for real time interaction and review.

Have the Scrum Board be someplace that is constantly visible and available. Do not have it in a conference room or someplace where access to it may be limited by others using the space.

Have enough conference rooms or meeting spaces available to the teams. An open space with ad hoc/movable table and seating arrangement works well (see below).

Image 3 - Motley Fool Open Area (http://www.flickr.com/photos/ksmith/152162335/)

Have projectors/electronic outputs (large TVs) available in meeting areas.

Have plenty of whiteboard space available for team usage.

Have space available for visitors or temporary team members.

Have enough room at each person's area for 2 or 3 people to work together.

Have comfortable chairs.

Be open to refactoring the space based upon usage patterns and needs.

For developers (this is not really about space, but I'll throw it in as well)

fast machines
large dual screen monitors
laptops?

One items of note is that when it comes to Agile spaces, you may hear people talk about Agile War Rooms that are setup like the picture below:

Image 4 - Agile War Room (from http://blog.channeladvisor.com/blog/2008/09/30/scrum-is-cooler-than-it-sounds/)

This is great for projects with a start and an end or with consultants, but not so great for people that have their careers with the company. This concept was brought up at a client site and I know some of them were vehemently against it and I can't say that I disagree with them. This is where we balance the where work can get done and where people will want to work equation. I feel in some ways it dehumanizes the employee into a machine line part.

I came across one site that suggested having the Scrum team isolated from others. At the one particular client, our Scrum teams were near their lines of business and other departments and that was great. It gave the team members a perspective into where the software fits into the business and into the company as a whole. This also allowed others to see how software was being built. I do not encourage actively separating the Scrum team from others so that they can be left alone to work.

Some links:

http://www.johnandcailin.com/blog/john/creating-agile-engineering-work-space-digg

http://www.infoq.com/articles/agile-team-room-wishlist

http://judykat.com/ken-judy/our-team-room/

http://www.possibility.com/Cpp/SoftDevOfficeLayout.html

Building a Snowman - A Federal Analogy

2009-12-16T23:18:00.004-05:00

A couple of weeks ago in the DC area, we got quite a bit of snow. Being that there was snow, my three and half year old son and I decide to make a snowman.

We get dressed and go out and start making the snowman. I show him what I’m doing and how to make a snowman. He’s helping out a bit here and there and everything is fine for a little while.

He soon loses attention and decides he wants to play with the shovel, which is fine. He’s playing with a shovel and I’m making a snowman. Once he sees my snowball really take shape, he decides he wants his own snowball. I stop what I’m doing, make a snowball for him and show him what to do with it.

Soon my snowball gets larger and the boy wants me to stop my snowball and make his larger. He then decides he doesn’t like the way I roll my snowball and wants me to only pat the snow into the snowball. He then doesn’t like the way I pat it and wants me to pat it a specific way.

Eventually, he says it’s cold and wants to go back inside. So I wrap up the snowman, take a picture and we’re done.

Our happy snowman!

So what’s the point? As I was going over this in my head, I had a little laugh and realized that there are quite a few similarities between that experience and experiences in the Federal government. Now I wouldn’t be so condescending as to say it’s like working with a 3 year old; I’ve worked with and continue working with many sharp, skilled, and high functioning Feds. The similarities to the snowman exercise lie in the way the projects can get distracted and derailed. It’s the execution of the bureaucracy, governance, and politics that can cause the distractions to the projects. Note I say execution because the questions that the Feds want answered are fine. Things like identifying how much value has been delivered, is this project still viable, are the systems secured are all valid questions, the inefficiencies lie in the way the questions are posed and artifacts or evidence that is required/mandated to answer these questions.

Now back to the snowman, the point of this exercise wasn’t to build the snowman; I could have left the boy inside the house and built a super-snowman in half the time. The point is to enjoy the time with my son.

When working on a Federal project, is the true goal the stated goals of the project/program/organization? It should be, but the nuance is to be able to work with the Feds and help define and direct the implementation of the vision towards actual project success. Along the way, it would be great for us Agile-ists to try to affect true Agile change in these organizations where we can.

An Outline for Scrum

2009-10-29T17:40:00.001-04:00

I recently created a Scrum outline that some may find helpful. Enjoy:

Listed below is an outline for Scrum. This is meant to be used as a guide, the Scrum team is free to adjust and implement based upon team needs. The guiding ideas of the Agile Manifesto and 12 Agile principles should be followed when creating specifics for the Scrum team. Note that you can download the word version of this document here.

Roles
1. Scrum Team
  1. Performs the work
  2. Creates their own tasks
  3. Pulls stories from the Product Backlog
  4. Owns the sprint backlog
  5. Provides estimates and commitments
2. Product Owner
  1. Accountable for the product
  2. Owns the Product Backlog
  3. Prioritizes the Product Backlog
  4. Provides goals and vision
  5. Product Owner determines when to release
3. Scrum Master
  1. Enforces process
  2. Prevents and remove impediments
  3. Tracks metrics
  4. Facilitates Daily Scrum
Scrum Board
1. Sections for:
  1. Work waiting to be picked up
  2. Work in progress
  3. Work ready for review
  4. Work that is DONE
2. Sprint burn down chart
3. Project burn down chart
4. List of impediments
5. High visible in a public area
6. Daily Scrum revolves around Scrum board
7. Team interacts with Scrum board during Daily Scrum
Product
1. Product Backlog
  1. List of all features/PBI/user stories for the product
  2. Can also contain bugs, technical pieces, and spikes
  3. Owned, maintained and prioritized by the product owner, thought team members can add items to the Product Backlog
2. Sprint Backlog
  1. Prioritized list of features the team is developing during the iteration
  2. Sprint Backlog created by the team
    1. Items in Sprint Backlog pulled based on priority from the Product Backlog
    2. Represents the work that the team has committed to complete for the Sprint
3. Roadmap
  1. Mapping of all Product Backlog item to a "timeline". This can be done by month, sprint, release, quarter, etc
  2. Product Owner provides the Roadmap content and prioritization, the Team provides the estimation
4. Release
  1. Product Owner determines release
  2. A regular recurring release cycle is recommended
Meetings
1. Daily Scrum
  1. 15 minutes max
  2. Each team member states:
    1. What I did since last Daily Scrum
    2. What I plan on doing today
    3. My impediments
    4. My work that needs to be reviewed
2. Sprint Backlog Planning
  1. Product owner presents top priority items from the Product Backlog that are candidates for the upcoming Sprint
  2. Team uses planning poker to estimate each user story/item
  3. Stories that cannot be estimated upon can be converted to Spikes
  4. Team commits to a set of user stories/items for the Sprint
  5. Stories are either rank ordered or marked as high, medium, low (and optionally stretch) priority
  6. These items become the Sprint backlog
3. Sprint Task Planning
  1. The team reviews each story and decomposes it into tasks
  2. Hours (Optional)
    1. Team provides estimated hours for tasks (optional)
    2. Team capacity should be # of available hours (should be a number less than 8 per resource, something between 4~6) and number of resources
    3. Take into account holidays, hours, and misc outages
    4. Take into account unplanned work
  3. Generally, work is pulled real time and not assigned during task planning
4. Sprint Closeout / Review
  1. The team along, with the PO and Scrum Master, review the user stories/tasks/spikes
  2. Ensure each is done, a story is either done or not done
  3. Story done-ness is defined by the story acceptance criteria, not all tasks for a story need be completed for the story to be done
  4. Collect total story points completed (optionally actual hours as well)
  5. Note actual velocity and completion percentage
5. Sprint Retrospectives
  1. Team reviews the process and discusses the things that have been working well and potential areas of improvement
  2. The Scrum Master and Scrum Team create and update the process norms for the team
6. Meetings Techniques
  1. Meetings should have a clearly stated goal or desired result
  2. Meetings should be timeboxed
  3. A parking lot can be used to hold ideas that or of note, but not directly related to the meeting goals or desired outcomes
Estimation & Metrics
1. Epics - a high level idea or theme that is comprised of user stories.
2. User Stories
  1. Features that the team can estimated and decomposed into tasks
  2. Ideally in the form of "As a {user}, I want {feature} so that {value}."
  3. Each story has an acceptance criteria so that we know when the story is done
3. Tasks
  1. Team decomposes user stories are decomposed into tasks
  2. Tasks are not assigned, rather they are pulled real time
  3. Team can provide hours estimates at the task level (optional)
4. Spikes
  1. An allocation of time the team uses to investigate unknowns, research potential solutions, or addresses issues that are not stories or bugs
  2. A spike should have a goal
  3. At the end of the timebox, the team should be closer to addressing the goal of the spike
5. Planning Poker
  1. Each team member provides estimates for user stories based upon a modified Fibonacci series
  2. As long as the team members are close in estimates, the team can proceed to the next user story
  3. If there is an inability to provide estimates or estimates differ by several orders of magnitude, then further discussions should occur for the story
6. Story Points
  1. Story points are measure of the complexity of a story relative to previous stories
  2. This factors in both the amount of time it takes for the story and the difficulty of the story
7. Velocity
  1. Planned velocity is the total number of story points that the team has committed for the iteration
  2. Actual velocity is the total number of story points that the team completed for the iteration
  3. Percentage completion is the actual velocity divided by the planned velocity
8. Unplanned work – Unplanned work should be tracked. This can later be referenced in process improvement discussions.
Engineering
1. Continuous Integration - Critical for the rapid pace of Agile development
2. Automated testing – automate testing as much as possible to help build quality into the process

Cross Functional Scrum Teams - A Basketball Analogy

2009-09-17T00:12:00.001-04:00

I was recently involved in a discussion regarding the concept of cross functional Scrum teams. The argument was presented that if you have a team with testers, BAs, and coders, does it make sense for testers to code, BAs to test, and coders to gather requirements? This seems to go against what these individuals do well and ultimately truly want to do. I think those are fair points, but on a Scrum team, the team is really presented a goal, and they must determine how to get there.

Let’s look at the game of basketball. The goals of basketball are very simple, get the ball through a hoop and prevent your opponent from doing the same. You have a team of 5 players on the floor and the team must figure out how to do this. The traditional basketball team is made up of a center, a power forward, a small forward, a shooting guard, and a point guard. These positions all have areas for which they are responsible. The center and forwards play close to the basket and are responsible for rebounding and points near the hoop. The point guard handles the ball and is the floor general. The shooting guard has backcourt responsibilities and looks to create baskets from the outside, either through a jump shot or a drive to the basket. This is an oversimplification, but close enough.

With that being said, there are times when the situation in the game changes and the shooting guard may need to go inside and fight for rebounds. The point guard may get trapped in the backcourt and need to pass to someone else to bring the ball up-court, the center may be left along at the top of the key and be forced to take jump shorts. So essentially, the shooting guard is playing the role of the forward, someone else is taking the role of the point guard, and the center is taking the role of a shooting guard. To accomplish the team goal of scoring and preventing the other team from scoring these real time adjustments and cross functionality must take place.

Similarly, on a Scrum team, the coders should be doing the coding, the BAs should be performing the analysis, and the testers should be testing, in general. However, the team should have a goal and if to accomplish the goal, someone needs to help with the testing, or a developers needs to gather some requirements, or a BA should need to get into the code (gasp!), the team should be ready and willing to step in and fulfill the overall needs of the team.

(LeBron James - Cross functional NBA All Star)

High Value – Low Risk

2009-08-23T21:48:00.002-04:00

I recently had an opportunity to participate as a panelist at a joint APLN PMI panel discussion on Agile project management. It was a good discussion with Jesse Fewell creating an excellent post on this event.

During the course of the discussion, one of my fellow panelists suggested that when first implementing Scrum to tackle high value - high risk areas first. This actually is in line with traditional Agile thinking where it is preferable to fail early rather than fail late. Craig Larman, among others, have written in regards to this and I had supported this Agile line (and in many ways, I still support this line of thought … in theory).

However, in the course of this discussion I did disagree with my fellow panelist. The key here is the context of this point is when first implementing Agile/Scrum. As a consultant, I have seen when first introducing something new to an organization, many times there is very little, if any, room for failure. In these cases, my recommendation is to identify high value - low risk targets and address those first. By creating high value success early, this allows you to build creditability collateral.

For a team (and organization) that is just learning a new process like Scrum, there can be confusion, nervous, and potentially resistance. To ask a newly formed team or a team new to Scrum to implement and deliver on high value and high risk immediately compounds their unease and even further increases the risk. If facing a high value – low risk target, the value can be just as great with a high probability of success, thus allowing the team to create a pattern of success that can help settle some of their initial fears and nerves.

Once this credibility collateral has been established and the team is performing at a high level, then as quickly as possible, shift to addressing high value – high risk work. Hopefully at this point when the team does fail early, there will be enough credibility collateral built, along with organizational understanding of the process, to see these failings not as failings per se, but rather as a step in the process of iteratively delivering a solution.

---------
On a side note, pictures below from this event taken from JesseFewell.com. Jesse is one of my fellow Xperts at Excella’s Agile Center of Excellence and he has been the key driver in creating some of the upcoming Agile PMI partnerships, including the PMI’s Agile Community of Practice.

One More Agile Blog V2.0 or "If you have sent me an email in recent months and I have not replied, here’s why……"

2009-08-23T19:28:00.003-04:00

Welcome to the new (and hopefully improved) version of my blog, One More Agile Blog (now in version 2.0).

There are really two key changes. The first is my blog URL is now http://www.onemoreagileblog.com/. The second change is that I have changed the look of the site (which really just involved me changing the blog template).

Why the URL change? To make a long story short, back in July I found out that my email provider, for some unknown reason, placed my BlogSpot blog URL on their URL blacklist. This meant that any email coming into Excella’s email system with my blog URL in the body was automatically being blocked with us receiving no notification of this happening and being unable to retrieve these blocked emails. This was extremely unfortunate since I have my blog URL in my email signature, so this would have affected anyone replying to one of my emails. I have lost and continue losing emails without knowing how many I have lost and who has been sending me emails.

If you’ve emailed me in the past month or two, there’s a strong chance that I did not get the email. Please contact me at either my richard.cheng@excella.com (just make sure to not include my old blog URL) or richard.k.cheng@verizon.net (which does not have this issue).

With all that said, welcome to the new site. More entries coming soon and this time I’ll strive to not have any month+ gaps in updates.

Common Agile Metrics

2009-07-03T08:00:00.005-04:00

One of the questions that often arise is in regards to Agile metrics. What metrics should we capture for our Agile or Scrum teams? The answer varies based on the goals of the team, project, and organization. With that said, below are some of the most commonly used metrics for Scrum teams.

For teams using an iterative Agile process, like Scrum, the most common metrics revolve around story points. Commonly, Scrum iterations (sprints) are comprised of a set of user stories with each user story given an estimate in story points.

At the iteration level, the team commits to the stories they can complete in the iteration. The sum of the story points for these stories is the projected velocity for the iteration. Once the iteration is completed, the sum of the story points for all of the completed user stories is the team’s actual velocity for the iteration.

Teams may also decompose stories into tasks and these tasks can be assigned estimates as well. These estimates may be hours to complete, due date, or any other applicable unit of measure. This decomposition and task level estimation is optional; I recommend this level of granularity to be based upon the needs of the team and project.

Metrics for the Project

For a project that has a set beginning and end state, the project team can initially spend a bit of time creating all of the high level user stories and providing initial story point estimates. Once this is done, the team has an initial summary total of story points for the project.

Table 1 displays the metrics covered at the project level.

· Baseline Story Point represent the remaining story points at the start of the iteration

· Story Point Updates represent story points that are added or removed to the overall project during the iteration

· Story Points Completed represent the story points completed for the iteration

· Cumulative Story Points Delivered represent total story points delivered to date

· Story Points Remaining represent the remaining story points at the end of the iteration

· Ideal Pace represent the pacing of the project based upon the story points remaining and estimated velocity of the team. In this example, I show it as it was at the start of the project, however, this should be updated often. Updating at the end of each iteration is ideal.

Table 1 - Project Metrics

Iteration	Baseline Story Points	Story Point Updates	Story Points Completed	Cumulative Story Points Delivered	Story Points Remaining	Ideal Pace
0	1200	0	0	0	1200	1200
1	1200	196	60	60	1336	1125
2	1336	210	75	135	1471	1050
3	1471	22	67	202	1426	975
4	1426	-78	75	277	1273	900
5	1273	38	88	365	1223	825
6	1223	30	79	444	1174	750
7	1174	-106	82	526	986	675
8	986	22	90	616	918	600
9	918	-50	100	716	768	525
10	768	-10	92	808	666	450
11	666	25	95	903	596	375
12	596	40	98	1001	538	300
13	538	-30	108	1109	400	225
14	400	-40	119	1228	241	150
15	241	-23	105	1333	113	75
16	113	-15	98	1431	0	0

Figure 1 displays the Project Burn Up and Project Burn Down chart for the same project. The Burn Up line displays the story points completed. The Burn Down line displays story points remaining. For organization that are familiar with EVM type tracking, these Burn Up and Burn Down values can often be translated to EVM measures.

Figure 1 - Project Burn Up and Burn Down Chart

Metrics for the Iteration

The Iteration Burn Up and Iteration Burn Down chart is similar to the Project Burn Up and Project Burn Down charts, but the iteration chart tracks the work at an iteration level. In Figure 2 we are tracking the iteration based on hours completed and hours remaining. We can see that at the end of the iteration, there was 94 hours work of work that was not completed.

Figure 2 - Burn Up / Burn Down Chart in Hours

Metrics for Team Performance

For a Scrum team, some of the key goals include:

1. Achieving a high completion percentage (actual velocity / projected velocity),

2. Stabilizing velocity

3. Eventually increasing velocity (after 1 and 2)

Figure 3, Figure 4, and Table 2 display metrics captured from an actual Scrum team. These metrics are also useful for on-going teams or projects that do not have a set end state.

Figure 3 – Team Completion Percentage

Figure 4 - Measure of Velocity over Time

Table 2 - Team Statistics per Iteration

Measuring Business Initiatives and Value

To measure work on business initiatives, we can summarize story point allocation based on initiative (see Figure 4). This allows the business sponsor to identify where the effort was spent on their project.

Table 3 - Second Quarter Work Breakdown

	Story Points	Percentage
Foundational	78	22%
Maintenance	9	3%
Optimization	168	48%
New Product	98	28%

Additionally, the business teams can also assign business points, similar to story points. Whereas story points measure the complexity of a story to implement, the business points measure the business value of a story once it is implemented. This display of value and effort can help the business determine implementation priority and goals.

Table 4 - Second Quarter Work Breakdown

	Story Points	Business Points	Comment
Feature 1	40	8	High effort, lower value
Feature 2	20	13	High effort, decent value
Feature 3	4	8	Low effort, mid value
Feature 4	13	40	Mid effort, high value
Feature 5	5	20	Low effort, high value

Agile in the Federal Government

2009-06-30T07:26:00.002-04:00

At the April APLN DC meeting, I had the honor of being on a panel for a round table discussion in regards to Agile in the Federal government.
The members of the panel included:

Nate Carpenter of Pyxis Engineering
Myself
Thad Scheer owner of Sphere of Influence
Dr. David Rico of Boeing

(Thanks to Jesse Fewell for the picture. See his blog entry for his thoughts on this session)
Overall, it was a good time. I use to work for Thad’s company (kind of, it’s a bit complicated) and it was great seeing Thad again. It is entirely possible that we may have closed down a bar or two back when we were working together.

Implementing Agile in the government space is tough. Obstacles include the existing oversight, budgeting and funding cycles and processes, general lack of Agile understanding on the Federal side, and conflicts of interest from the various consulting companies, prime and sub contractors, and government agencies. Agile helps you as a company or organization identify your goals and values and execute towards that end. Similarly, Agile does not solve your problems but rather exposes them. In government organizations, identification of clearly stated goals and values combined with exposing problems is something that will generally be met with obstacles.

However, it’s not all gloom and doom for Agile in the Federal government. In an August 2008 interview with CIO magazine, CIA CIO Al Tarasiuk stated “His team has also moved completely to agile project management methodologies…” Additionally, Dr. David Rico stated during our panel discussion that Boeing has standardized on Scrum.

At the team implementation level, Agile has a good chance of success and I am seeing that at my current client site. Since we control the team and with team acceptance of Agile, the Scrum Master / PM can shield the team from much of the organizational issues that may affect the team’s Agile implementation and performance. This will require more work from the Scrum Master. Many of the reports that will be asked to be generated and given may not naturally seem to fall within Agile practices. It will be up to the Scrum Master to identify the key metrics such reports want to capture and translate the Agile team metrics to metrics more familiar to others in the organization. Examples include translating burn up and burn down charts into EVM reports, iteration and product backlog can translate into Gantt charts, and end of iteration reviews and retrospectives and feed into status reports.

At the executive levels, expressing the values of Agile can be quite convincing to a sympathetic executive. The key is identifying and gaining access to an executive who is ready to hear a message about empowered, optimizing, evolving, value based delivery.

The middle tiers is the most difficult. The oversight and middle management levels can be heavy and if leaning an organization, this would most likely be spotlighted as places where leaning can take place. That combined with the conflicts of interest and personal interest that exists at these levels can make these layers quite problematic. Probably the most effective way to deal with this is for organizational support at higher level to effect certain Agile changes to take place at these layers.

For working Agile in the Federal government, I recommend the following:

Choose your battles. There will be a lot that you will want to change and you will not be able to do it all overnight, so start small and pick your battles.
Create creditability collateral. Demonstrate a pattern of success so that when the big battles do come, you will have the pattern of success to strengthen your position.
Identify what is being asked. You may be asked to provide many reports, presentations, briefings, etc that may seem to be a lot of overhead or waste. I recommend identifying that the goals of these requests are and identifying if there is an Agile translation to the nuggets that these requests are trying to achieve.
Lastly, good luck, you’re going to need it!

Shu, Ha, Ri with Alistair Cockburn

2009-06-26T15:09:00.003-04:00

Yesterday, I had the chance to spend the day (actually 12 straight hours) with Alistair Cockburn. Excella’s Agile Center of Excellence held a private breakfast event featuring Alistair and he and I met with several clients later in the day as well. It was a great experience and great fun. Not only is Alistair extremely knowledgeable, but he’s a funny and nice fellow as well.

(Alistair and I after a long 12 hour day)

(Alistair with Excella’s OPM team in front of our Scrum wall. Note we are both pointing at the IMPEDIMENTS sign)

Yesterday provided much blogging material, but I will start with Shu, Ha, Ri.

During one of our client meetings yesterday, the topic of Shu, Ha, Ri came up, which Alistair describes in his book Agile Software Development (now in second edition as Agile Software Development: The Cooperative Game).

When Shu-Ha-Ri came up, Alistair asked me to describe it and I provided something along the lines of the following:

Shu, Ha, Ri, comes from Aikido (think Steven Segal in Above the Law, his only good movie …. other than Executive Decision, which barely counts considering he dies in the first 20 minutes … bonus material for blog, not in original statements). Shu, Ha, Ri roughly translates into learn, detach, transcend.

From the perspective of learning Agile (and really learning in general), Shu represents the first level of learning Agile. At this level, one learns a certain skill/technique and essentially mimics it. In the case of Scrum, one learns Scrum and then starts by implementing a set of Scrum based procedures; daily stand-ups, product and iteration backlog, Scrum Board, etc. At this point the Scrum student is learning and implementing the technique.

The next level of learning is Ha. At the Ha stage, one starts looking beyond their technique. For someone looking at Scrum, they realize that textbook Scrum doesn’t speak to areas such as project initiation, engineering practices, and testing techniques. One looks at other areas to broaden and deepen their skill sets.

The third level of learning is Ri. At the Ri stage, the focus is no longer on technique but more on outcomes. When presented objectives and goals, the practitioner doesn’t say they’re going to use a particular method to solve a problem, but rather the practitioner achieves the desired outcomes by applying the appropriate techniques from their repertoire needed for the specific situation to deliver the desired outcome.

After I gave my interpretation, I asked Alistair if I had it correct. I was happy to hear Alistair state that I had it correct and he said that he really liked my explanation of Ri, which wasn’t quite what he said. He then said he liked what I said about Ri better and is thinking about stealing it. Which makes me happy and will make my lawyer very happy when I put the lawsuit together (kidding!).

Overall, fun day.

To Do List = Personal Backlog

2009-06-11T21:44:00.005-04:00

Wow, I have been very negligent in my blogging in recent weeks. I guess when you have a new baby and a 3 year old running around, it wrecks havoc on your free time. This means that no matter what I do, my to do list keeps growing bigger and bigger.

I've had "update blog" almost every day on my to do list, but like a good product owner, I have been constantly prioritizing and re-prioritizing my to do list. Though "update blog" is a task on my to do list, it seems to keep getting pushed closer to the bottom of the list, after tasks like "buy diapers", "do laundry", and "get some sleep".

When you think about it, this to do list is really a personal backlog. Also, since I am not running personal iterations, it's more like a backlog for an iteration-less process, maybe like Kanban.

And yes, I did say task and not user stories. Zero chance I'm writing full user stories on my personal backlog. Nor do I have owner, or reviewer, acceptance criteria on my backlog (though I'm sure my wife would like this in many of the tasks around the home). Also note that the only status is Done or Not Done.

Hmm, full user stories may be interesting:

As someone who is supposed to write on his blog, I really should write on my blog, so that the guys at work aren't like "Dude, what's up with you not updating your blog"
- Acceptance Criteria: I'm not paying $20 dollars a week for missing all my blog entries (actually, we never did really implement that, which is a good thing)
- Story Points: 13
As a sleep deprived adult about to go insane, I would like to get more sleep at night, so that I don't go postal at work
- Acceptance Criteria: I wake up fresh and alive and ready to take over the world
- Story Points: infinity

Actually, today I put together some notes in regards to an analogy between Agile and the sport of Mixed Martial Arts and so a real user story on my backlog is:

As a reader of my blog, I want a well-written blog entry that creates a compelling analogy between Agile and the sport of Mixed Martial Arts, so that I can be entertained for hours based on a single blog post….
- Acceptance Criteria: Blog is on my blog site
- Story Points: 8
- Priority: Medium
- Due Date: COB 6/15 (I'm taking a 3 day weekend vacation starting tomorrow)

That's it for today. When you next see my blog entry, it may be my mixed martial arts entry, or the blog that I started weeks ago regarding my APLN DC panel discussion and still have not yet finished.

Agile Testing

2009-05-10T21:53:00.001-04:00

A co-worker was recently asked “Who will be doing the system testing” on his project and this brought up the topic of Agile testing. He sent an email asking “When doing a project using Agile and Scrum, how do you develop the system tests? Do you script scenarios based on the stories? The tasks?”

So in my reply, I was able to get a bit of a two for one deal out of it. I was able to reply to his question and create a blog post as well. Here is a paraphrased version of my reply:

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

“When doing a project using Agile and Scrum, how do you develop the system tests? Do you script scenarios based on the stories? The tasks? “

From the stand point of Agile engineering best practices, quality needs to be built into the system. TDD is popular among the XP crowd. Automated testing and continuous integration is key in Agile. With the rapid pace of iterations, it is difficult to go back and manually test previously covered areas, so the automation of testing provides repeatable and repeated verification of correctness.

Using utilities to check for test coverage of code is helpful. Sound testing at the engineering level is the first and best line of defense. If something broken, stop the work until it is fixed. Remember, a user story is not complete until it has been tested. So yes, craft tests around the user stories, but also have the automated tests hit as many areas as possible. Using tools such as nUnit for unit testing, Selenium for UI or interface tests, Fit/FitNess for acceptance tests, and LoadRunner for performance testing are all ideas in the automated test toolbox. There will certainly be a bit of an engineering cost to implementing these tools, but I know there is research out there that does show that these engineering costs are paid back in savings in the quality of the code/project.

Specifically on this project, my thought is :

Ensure the team has a responsible level of code coverage through unit testing

Consider using TDD (though I have not personally had great luck with it, but I’m no expert in it)

For each story, design a responsible set of test scripts for the story. Hopefully these scripts are tests that can be automated.

Work with the tester and the team to identify what responsible set of test scripts mean
Work with the tester and the team to identify how to (and who will) manually test the non-automated tests

“Who will be doing the system testing?”

The question “Who will be doing the system testing?” is a bit confusing. By system test, do we mean a traditional test of the overall system? Does this question ask who will be creating the test scripts and/or who will be performing any of the manual testing? In terms of who should be writing the test scripts, I think that answer varies, but it ultimately should most likely be a team effort. It varies due to the specifics of the project, domain, and available resources.

In this case where there may only be one person devoted to testing, if this is a highly skilled person, they can own the testing strategy and create testing stories and strategies which the team (along with this person) can execute. If the person is not able to fill that role, the team will need to determine the test strategy and work with the testing resources to implement and execute the testing strategy.

The concept of having a person(s) coming in fresh at the end of a project (or even project cycle) to test seems ineffective. In the past I have seen this as just an exercise in helping the tester understand the system being developed and how to use the system. The tester may stumble upon on few defects or issues here and there, but from cost benefits standpoint, the returns seems quite low. Having resources that are integrated with the team and developing tests iteratively with the team seems ultimately more efficient.

I’m back!

2009-05-10T21:40:00.001-04:00

In my last blog, I had mentioned I was going to be taking a little break with the upcoming birth of boy#2 and on April 20th 2009, we were blessed with Lucien Javier Cheng!

Mommy, Boy#1 (Simon Maxwell Cheng, now 3), and baby Lucien are all doing well. Daddy (me) is being driven a bit insane, but also doing well.

I’ve taken a bit of a break from some of my workload (including this blog), but I am now ready (or relatively ready) to jump back into the fire. My next blog coming up shortly!

Taking a Short Break

2009-04-19T14:32:00.002-04:00

Sorry for the gaps in posts, things have been a bit hectic as of late, baby boy #2 is going to be here any day now. Actually, we thought he was coming Wednesday, and then again on Friday, and I'm sure that we are delivering tomorrow.

So, it may be a little bit before my next post. I do have some topics on my mind (aside from freaking out about the new baby almost being here). These include Agile in the Federal Government, which I recently had a chance to discuss as part of an "expert" panel at the April APLN DC meeting. Also, my thoughts with dealing with under-performers on Agile teams.

Anyway, that's it for now, hopefully I'll be posting thoughts again very soon.

You’re either on the team or you’re not…

2009-03-31T12:48:00.001-04:00

Just a little rant today:

Scrum has 3 roles. Scrum Master, Product Owner, and the Team. I believe in a team of doers and performers (probably the same thing).

I, in general, don’t believe in putting a data modeler on a team, or an architect on a team, or any specialized role on a team. It’s not to say I don’t believe in having a data modeler or architect on the team, as long as they can view themselves as a member of the team willing to do work and get work done.

I believe the team needs a team data modeler if the team says, “These data relationships are pretty complex, we really do need a data modeler”, then we start talking about a data modeler (or architect, or whatever). However, in many cases, the team members can really model their own data or architect their own systems.

Often, we use a DBA service, or operations service. They provide a service to the team, but not a part of the team.

There may be some exceptions to the rule. When you want to create an organizational consistency, you may have an enterprise architect or data architect, but they usually work with the team as a guide or provide service. If you’re on the team, you’re on the team, skin in and all.

Anyways, just a bit of a minor rant today, no real coherent thought to it.

Using planning poker to ensure common understanding

2009-03-18T15:16:00.002-04:00

One of the techniques that many Agilists have been embracing is using planning poker to help the team estimate and plan for an iteration. The focus of today’s blog is that one of the nice benefits of planning poker is helping ensure a common understanding of the work (story) at a team level.

Brief Introduction to Planning Poker

Planning poker is generally used during the team iteration planning meeting to help the team create estimates for stories (feature requests). Each team member has as set of cards that are numbered based on a modified Fibonacci sequence (?, 0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100, infinity).

After each story is presented to the team, there may be a few questions regarding the story. The time spent asking and addressing these questions should be kept as brief as possible. At this point, this is not a design discussion, the questions should only relate to helping the team member form a rough order of magnitude estimate.

After the story is presented, all team members display their cards simultaneously. Once all the estimates are shown, the team can determine if there is a general consensus or agreement to the estimate for the story.

Common Understanding

If all of the estimates are roughly in the same neighborhood, then the team is ok. You can optionally ask the highest and lowest estimates on what their thoughts are, but if they are in the same ballpark as the rest of the team, it is usually relatively easy to come to an agreement.

Example, if the ranges are a 3, a couple of 5s and several 8s, not a big deal. Have the 3 explain their thought and you’ll find they’re probably willing to go up on their estimate.

Note when everyone in the same ballpark, do NOT spend a lot of time discussing the story, you’re done estimating the story, go on to estimating the next story (or tasking the story, if your team tasks after each story, which I would NOT recommend).

However, if there is a large gap in estimates, this is where you get the good stuff. Say most of the team is around a 5, but one person has a 20, then something’s going on. Either the 20 does not have a correct understanding of the story (or what it takes to implement the story), or the 20 knows something the others do not. Either way, this requires discussion.

Examples 1 – technical implementation:

The story is “implement role based security model”. Most of the team throws an 8, however one person throws a 40. Discussion is held and the people throwing the 8 believe they can leverage an existing security model the company has. However, the 40 knows that the legacy security model is outdated and does not come close to supporting the needs of this project. The ensuing discussion helps bring this to light and the team re-throws based on this new knowledge.

Example 2 – Story understanding:

The story is “Display Custom Images in System”. Several of the developers throw a 100 and the business analysts throw an 8. Each is surprised at the other’s estimates. During the discussion, turns out the developers thought that the system needed the ability to actually create and save images while the true requirement was that the system only needed to display an image from a specified location.

The key point of this blog is that using this technique should allow the team to quickly breeze through estimating stories where there is a general consensus on the size of the story and ensuring there is a common understanding in situations where there is a large gap in estimates.

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

(Note that the common understanding is just one of the benefits of planning poker. There are also major benefits in terms of velocity and using velocity to help plan team capacity, but more on that in a future blog.)

Scrum Artifacts

2009-03-02T20:39:00.007-05:00

I was recently asked to put together a list of Scrum artifacts, so I figured that this would be a good topic for my latest blog entry. Some of this will just be a Scrum 101 refresher for those familiar with Scrum, but this may be useful for many.

A couple of notes:

· The list below represents a possible/typical implementation of Scrum. One does not have to follow these exact items to implement Scrum.

· Many of the items described below are implementation details of Scrum, but not specific artifacts prescribed by Scrum

In Ken Schwaber’s Agile Project Management with Scrum, the only items he has listed as Scrum Artifacts are the Product Backlog, the Sprint (Iteration) Backlog, and Increments of Potentially Shippable Product Functionality.

· And yes, I know, many items on my list are not really artifacts. To make things easier artifacts presented in black, general concepts in blue, and meetings in red.

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

Epics / User Stories / Tasks

User Stories – A feature that can be estimated.

Epic – A feature that cannot be reasonably estimated due to its complexity, scope or number of unknown issues.

Tasks – The work needed to complete a User Story.

Epics can usually be broken down into User Stories. User Stories can be broken down into Tasks.

Planning

Product Backlog – A list of the Epics and User Stories for the entire Project / Product. This list is prioritized by the Product Owner.

Sprint Backlog – A list of the Epics, User Stories, and Tasks that the team has committed to completing for the current iteration. This is created during the Iteration Planning Meeting.

Story Points – Units of estimation for User Stories. Usually based on a modified Fibonacci sequence.

Planning Poker – A method of estimation used in Iteration Planning. Each team member is given a set of card representing story points. For each user story, team members display a card representing their estimates. The team discusses the results and comes to a consensus on the estimation.

Iteration Planning Meeting – At the beginning of each iteration, the Scrum team meets to plan work for the iteration. The first part of the meeting involves the team working with the Product Owner in reviewing the prioritized Product Backlog and putting Story Points for each User Story. The team then commits to a certain number of User Stories for the iteration. The second portion of the iteration is typically used by the team to create a list of Tasks for each User Story in the iteration.

Tracking

Project Board – This can be a physical board, a virtual board, or both. The board is usually placed in a visible location and presents the status of the iteration (and sometimes the entire project). The board usually contains an area for Work in Waiting, Work In Progress, Completed Work, and Verified Work. Other items that can be shown on the board include (but not limited to) a team calendar, burn down charts, and list of impediments.

Daily Scrum Meeting – A brief (15 minute) daily STAND UP meeting in which each team member gives a brief status up. This typically is limited to:

· What have I done since the last Scrum meeting.

· What I am planning to do today.

· List any blockers/impediments I have

· List any items I have ready for review

This meeting is typically held in front of the Project Board and the team members should update their tasks on the board during the meeting. Only team members should present during the meeting and all team members (barring physical considerations, such as a bad back or being very pregnant) should be standing the entire meeting. Standing meetings tend to not go very long.

Iteration Burn Down Chart – A graph displaying the amount of work completed and amount of work remaining for an iteration.

Project Burn Down Chart – A graph displaying work completed and work remaining in the project.

Team Velocity – The amount of story points a team has completed or can complete in an iteration.

Review

Iteration Review Meeting – Held at the end of an iteration, the Iteration Review allows the Product Owner, and potentially stakeholders and other interested parties, to review the deliverables for the iteration. All deliverables should be fully tested, defect free, ready to ship increments of functionality.

Team Retrospective Meeting – Held at the end of an iteration, the retrospective meeting typically allows the team members to discuss what has been working well, what has not been working well, and discuss any ideas for improvements or changes to the process.

A False Measure of Success …. Revisited

2009-02-25T21:40:00.008-05:00

Today I received an unexpected email:

Hi Richard,

Not sure if you will remember me, but we spoke during the agile 2005 experience report selection process about your experience report. We ended up selecting your submission and you went on to write a paper ... and I am currently using the paper in a masters level course on agile methods at Oxford. The students are expected to analyse the case, and I know some of them might be keen to ask you some additional questions. Would you be open to that? I don't expect it will be too time-consuming, and it might be kind of interesting.

Anyway, I do hope that all is well in your world.

Cheers,

Angela Martin

Lecturer, Department of Computer Science The University of Waikato, New Zealand

I am quite honored to have Angela choose my paper as part of her master’s level course at Oxford (assuming the topic is not “Examples of poorly written articles”). I am also happy to hear that there is a master’s level course on agile methods at Oxford.

The article, titled A False Measure of Success, was something I wrote in 2005 for an experience report and was the basis for a presentation at the Agile 2005 Conference. In re-reading my article, the general message of the article is still pretty good. The heart of the article is really about a disconnect within a company in recognizing business needs and technology goals. Though technology goals were met, it came at a cost to the business needs. Instead of being partners in a solution, technology dictated the solution to business. Interesting stuff.

On the downside, also in re-reading the article, I realized that I might have gone into a bit of a tangent when I started addressing some Agile specific thoughts. I also realize that the longer development timeline does not quite look that bad compared to other projects I have worked since the article was written. But worst of all, who let all those grammatical errors through on a published paper (I blame my two editors .... myself and my wife). ARGHHHHH!!!!!!!

Certified Scrum Master .... the Big Lie!

2009-02-20T13:12:00.005-05:00

At last night's APLN DC meeting, we were fortunate enough to have Scott Ambler present his talk on Scaling Agile Software Development: Reality over Rhetoric. Overall it was a good presentation with some nice takeaways. One thing that was noticeable was Scott's views on Scrum, CSM, Ken Schwaber. I will save most of these topics for future blogs, however I will address Scott's view on the 2 day Certified Scrum Master course.

Scott believes that the 2 day CSM course is a scam, a big lie, complete shenanigans. He believes that any professional should be ashamed if they put CSM in their email tags or business cards. And truth be told, I agree with him.

To take a 2 day course and, with no pre-qualifications, no exam, no peer review, no kind of validation or verification at all, become a Certified Scrum MASTER is deficient. Armed with only this 2 day course, one is most certainly NOT a master and is most likely NOT ready to implement Scrum without additional coaching/mentoring/help. We really should call the class what it is, a 2 day boot camp introducing Scrum.

The course itself is generally an excellent course, but one should understand what it does. The class helps the student understand the meaning of Agile and Scrum. It helps the student shift their mindset from a traditional/PMI/waterfall/EVM (EVM, one of the biggest LIES in he industry, definitely more on that in a future blog) base to an Agile/iterative/value/delivery mindset. It provides an overview of how to do Scrum and a general starting point on Scrum. For those already using Scrum or familiar with Scrum, it helps them walk through some of their thoughts, problems, and ideas. Hopefully by the end of the class, the student will be armed with some knowledge of how to implement Scrum, and more importantly, what it means to implement Scrum.

Scrum provides good process, artifacts, tools, foundation, and framework, but there are quite a few implementation details that need to be worked out and tailored to the environment. The actual implementation is quite tricky. It requires experience, expertise, and intelligence. Most people will need help if they hope to succeed just at the project level. To tackle it at an organizational level becomes an even greater challenge.

So really, understand that not all CSM's are created equal. There are some great ones out there and there are some who just had $1500 in their pockets and 2 free days to kill.

Empowered Optimizing Evolving Value Delivery?!?!?!

2009-02-15T20:11:00.006-05:00

In my last blog, I stated that a Scrum Master that truly understands Scrum attempts to create "...a process /atmosphere of empowered optimizing evolving value delivery". When you say it out loud, it does sound like a bunch of buzzwords strung together, like leveraged synergies or synergized leverages. However, honestly, it does mean something.

Empowered - The process should be empowering. The Scrum process is not one where the team is treated like a bunch of mushrooms (kept in the dark and fed, ummm, dung), but rather it should be an open transparent atmosphere. It's a atmosphere where the team is not ordered and micromanaged, but rather an atmosphere where goals are set forth for the team and the team is empowered to do what they do best in achieving these goals.

Optimizing - The team is constantly look at what they are doing and looking to improve and become more effective. Looking at velocity charts and burns down charts, identifying patterns and cause and effect relationships. These things the Scrum Master works with the team to identify and optimize.

Evolving - Similar to optimizing, but grander. Optimizing is tweaking and improving, evolving is deeper, it is questioning base concepts and accepted process and questioning the value and delivery. It is a team feeling optimized and hitting a plateau, then self reflecting and determining what can be done fundamentally different and better.

Value - Not only having a prioritized product backlog, but ensuring the priority is accurate. It is truly understanding what your company / team / project mission is, identifying where the value lies, and using your resources to work on the value. On my last team, we did something pretty interesting. Once our Scrum team had worked together for awhile and there was a sense of team maturity and safety, we tried having value estimation meetings. Similar to a backlog story points estimation meeting, however instead of effort for points, we started addressing value points. How much value would each feature request deliver relative to each other. Turned out to be a great exercise, but the key was that a sense of safety had to be there for the exercise to truly be of value.

Delivery - This is key. Without delivery, all of the above is just a bunch of co-worker sitting around signing Kumbaya. By delivery, I mean actual working software (assuming your team is ultimately producing software). For example, requirements in themselves have no business value (unless you are in the business of selling/producing requirements, and in that case I have a bone to pick with you as well), rather it is a tool/artifact/side effect of producing software. If that same software can be just as responsibly made without those requirements, then are the requirements truly needed? Now, one common misconception is that Agile states no requirements, which is not true. Often it is more the form and standards in which requirements must be made and applied with which Agile has conflict. Anyway, requirements aren't the point, the point is that delivery is key.

Ok, so I hope I have convinced you that I did not just string together a bunch of non-sense industry words when I said empowered optimizing evolving value delivery. Now, I'm off to synergize my leverages.....

The Key Quality of a ScrumMaster

2009-02-12T21:15:00.009-05:00

I recently met with an executive who is planning to pilot a Scrum team at his company. One of the questions that he asked was what where the qualities one should look for in a ScrumMaster. Most of the answers I gave him where consistent with an article Mike Cohn posted regarding this topic (btw, excellent article).

After giving it some thought, I think the one KEY quality of a good ScrumMaster is that they must get "it". What I mean by that is that they must really know the goals of what Scrum is trying to do and and achieve. Agile and Scrum is not about learning a set of rules and processes and then following some cookie cutter method of implementation, rather it is a set of ideas, principals, and goals that are to be achieved. And by achieved, I don't mean just achieved by the team delivering value, but also by the ScrumMaster working with the team and the company in forging a process /atmosphere of empowered optimizing evolving value delivery. To some people, those last five words may seem to be just a bunch of keywords strung together, but I think a ScrumMaster who gets it understands what I just wrote.

At my last client engagement, the ScrumMasters of the company pretty much got it. There were slight difference in implementation details, but everyone was working towards the same goals and optimizing their teams around a company culture and vision into delivery. They weren't following process for process sake or because some book told them to, but they were trying to identify where the values and efficiencies were and how to properly leverage them.

When a ScrumMaster does not get it, you have issues. Many middle managers tend to micro manage or task and order their teams. New ScrumMasters who came up as developers may have a hard time letting go of the tech side and may get too involved or prescriptive in dealing with their tech teams. ScrumMasters with a PMI/PMBOK background may try to implement Scrum with too much rigidity and process. These are signs that these ScrumMasters may not yet fully get it.

For all ScrumMasters out there, that a step back from your Scrum boards (assuming you are using Scrum boards) and think about this: Are your processes really following the heart of what Scrum and Agile should be bringing to you, your teams, and your company?

As a side note, once you get it, your team gets it, and everyone is firing on all cylinders, the job of the ScrumMaster becomes one of the easiest jobs in the world. Good luck getting to that point!

Can I be a Scrum Master and a Developer.....

2009-02-06T12:49:00.007-05:00

Can I be a Scrum Master and a developer (or business owner or business analyst or whatever)? Sure, um... yes... um... maybe......

Years ago, I had taken a Certified Scrum Master training course that was that was given by Ken Schwaber (who taught the first 2 days and Mike Cohn taught on the third).

As Ken was defining the role of the Scrum Master as one who removes impediments, empowers the team, ensures process, enforces the Scrum rules, etc…, I started thinking “was that all they did?”. Starting out as a developer and at that time being a Project Manager who would still get hands on in the code and architecture, I asked Ken if a Scrum Master could also be an active team member. Ken’s answer was something along the lines of “no”. That did not seem to make sense to me and he and I ultimately disagreed over this point.

Sometime later, I found myself working on a small team (3 ~4 people) developing software. I was the Scrum Master as well as a pseudo architect and a key hands on developer. What I had come to realize is that I spent the vast majority of my time coding and everything I was doing was clouded from that perspective. In my role as Scrum Master, I found myself using the position to drive things from the perspective of a developer. Instead of helping the team focus on delivering value and working with the product owner from that standpoint, I noticed myself addressing the product owner as a developer focusing on meeting development deadlines and telling the product owner what features they could and could not have versus really allowing the product owner to really define the features they needed and valued. Once I started noticing this behavior, I was able to address it …. more or less. There was a constant struggle between the Scrum Master hat and the developer hat and it was at that point that I started really seeing what Ken was saying.

Since then, the vast majority of my engagements have been as a Scrum Master. In most cases, I did wear the Scrum Master hat and often used my experience and expertise in other areas to help the business teams, technical or operations teams in their respective areas. Most of the time it worked out pretty well. The times where it is more difficult is when I become heavily involved in details and implementation and started taking ownership of ideas or deliverables that the lines get a bit blurred. That’s not to say it’s always a bad thing, but in some cases it does have effect on being an effective and fair Scrum Master.

So can someone be a Scrum Master as well as something else? Ken said “no”. I say, in a textbook world it’s not ideal. However, real world situations may dictate differently, so keep an eye on your perspective. Are you being a fair and effective Scrum Master if you are doing something else? If not, what can you do to fix it? Remember, Scrum does not fix your problems but rather it exposes it and if being both a Scrum Master and something else becomes an unmanageable problem that should be listed as an impediment and dealt with.

Why another Agile blog?

2009-01-28T18:39:00.001-05:00

The answer is simple enough, I don't want to lose $20 a week.

As a bit of background, my name is Richard Cheng and a little over 2 years ago I joined Excella Consulting. At the time I joined Excella, I already had my PMP certification and also received my CSM certification as well and had actually managed several Agile'ish and Scrum'ish projects.

During the interviewing process with Excella, I expressed the ideas that I really liked in the Agile space and how I think an iterative, collaborative, empowing approach to developing software was ultimately, the right way to not only run software, but in many ways to approach business. These thoughts and ideas really meshed well with the powers to be at Excella and it's been a beautiful relationship ever since (says the optimist, the pessimist would say thus far).

So what does that have to do with an Agile blog and $20? Ok, I'm getting there. So Excella recently created an Agile Center of Excellence, which I lead, to go along with its current Project Management Center of Excellence (lead by Jesse Fewell) and its Microsoft Center of Excellence (led by Scott Lock). So, the three of us had developed some key areas and goals that each of our CoE's should target. One of the side notes that came out of this was that we really should each have our own blobs. Now, I've been wanting to create an agile blog for years, but ultimately for a variety of reasons (most notably, sloth) I had not. So with this in mind, Jesse and I decided to make this interesting and lay out a friendly wager. Anyone of us who does not post at least 1 blog a week must throw in $20 into the missed blog pot. There you go, that's the story.

Now Jesse Fewell (http://www.jessefewell.com/) and Scott Lock (http://geekswithblogs.net/slock/) already have a head start, but in about 5 minutes, Blog #1 will officially be in the can.

As a side note, one may note that this entry has little to do with Agile, but there's plenty more coming. Next Blog topic will most likely be "Scrum But".