An Agile software development approach could have prevented this – just saying.

An Agile software development approach could have prevented this – just saying.

UPDATE: January 30, 2018 The Washington Post published an article with more details: https://www.washingtonpost.com/news/the-switch/wp/2018/01/30/heres-what-went-wrong-with-that-hawaii-missile-alert-the-fcc-says/?utm_term=.84e766af06c6 It is interesting that one of the suggestions I mentioned to prevent this was actually in place, “They then must click ‘yes’ when the system asks ‘Are you sure that you want to send this Alert?'” the article also stated that the application uses “the same language irrespective of whether the message [is] a test or actual alert.” Hmmm.

I live most of the year in Hawaii on the island of Oahu and was woken by this alert last week. Needless to say it was a distressing event that should not have happened. I don’t claim to have any inside information other than what I have read in the paper, but I have managed enough software development projects to know the root cause of this kind of error. I have been contemplating writing about this for the last week, and first of all I want to say, “Do not fire the person that sent this out!” This was user error but based upon a poorly designed system that is all too common in software development projects. For those of you who aren’t in the industry, let me walk you through how this happens:

“Traditional” Approach to Project Management:

Step 1 Business Requirements: A business person or customer decides what they want an application to do and they create a high-level requirement. e,g. “Create an application to allow a user to send out an alert to the phone and television emergency systems. This application should have a dual purpose for both testing the system and for sending actual alerts.”

Step 2 Analysis and Design: Analysts then create a set of system requirements based the business requirement. A designer designs screens to support the application. An architect designs how each piece will work together. They write everything down and get sign-off from their business stakeholder. They then hand it to a software developer to build. Sounds good so far?

Step 3 Development: (This is where it really break down) The developer builds it exactly the way it was written down!

Step 4 Testing: (Final failure point.) The developer hands-off the application to the tester, who tests it to make sure it meets the original business requirement and technical specifications. Once it passes the tests, it is ready to go live.

Again, for those of you who are not in this industry, the above steps probably seem completely reasonable, and many projects are still run this way. The problem is, this approach is why 50% of projects fail. I worked under this model for about 10 years until I experienced a couple of major project failures. Those project failures probably cost more than the above mentioned failure because they were expensive commercial software development projects that built a product “exactly the way it was written down.”

After those experiences, I became an Agile evangelist. For the last 10+ years I have focused on managing, consulting and training on Agile practices. We still have failures but there are far fewer, and if we fail, we fail fast. Also, Agile software development is a true collaboration between the users and the developers. So, for those of you who do not know much about Agile, let me tell you how we (the Agile community) would manage this project:

Agile Approach to Project Management: 

Step 1 Business Requirements: This step is pretty much the same – a business person creates a high-level requirement. e,g. “Create an application to allow the user to send out an alert to the phone and television emergency systems. This application should have a dual purpose both for testing the system and for actual alerts.” We call this big requirement an Epic.

Step 2 Analysis and Design – Agile Discovery: (This is where everything changes) There is no analyst or middle-man between the developer and the business. Here is what we do:

  • The business person is part of the project and joins the development team.
  • At the start of the project we then have a workshop to break that big requirement into smaller requirements called user stories.
  • Included in the workshop are the people who will be developing and testing the software, business people, potential users and any interested stakeholders.
  • There is a facilitated session where we review the high level requirements and ask the following questions*:

What will the user likely do next?

What mistakes could they make?

What could confuse them?

What additional information might they need?

*Let me be clear, I did not come up with these questions in response that alert failure. It may look like I am using hindsight to fix the problem since asking those questions and addressing them would have obviously prevented the alert from being sent out. The reality is, I took those questions directly from an Agile training I have been delivering for years. I learned that technique from a leading Agile author, Mike Cohn, in his book User Stories Applied: For Agile Software DevelopmentThis is a common technique in Agile to ensure an application is well thought through.

  • The final difference in this step is that in that requirements meeting the developers are listening, asking questions, and writing notes that make up the specification. There is no second hand information, they design and build the application based upon their conversation with their customer.

Step 3 Agile Development: A key difference in Agile is that requirements are presented as a problem to solve not a specification to be built. It is the developers’ job to come up with a solution. The developers understand the business need since they reviewed the requirements with their customer. They are empowered to ask questions and clarify the design while they build it. They have a business owner or customer representative on the team who is available daily to answer questions. They are asking questions in real time, such as, “It seems like the requirement to test the system and execute a real alert are very different activities and should have a very different workflow and authentication model? Technically, there are many ways we can prevent errors from happening. Can I show you a couple of options?” Again, I am not using hindsight. I worked with systems that had a single critical field that if filled in incorrectly required a lot of work to fix. In those cases developers know the technical, and often simple, best practices to ensure quality of data entry. You may have seen these before even on a regular webpage:

  • Please enter your password again (replace the word password with “authorization for an alert”)
  • Please type YES if you want to close this screen without saving (replace the words without saving to “send the alert”)
  • A more advanced technique I have used in the past is called Double Key Data Entry.This a common technique for ensuring quality of high-risk data entry. Two different people have to enter the same information before the workflow can progress. I used it on a project for entering SSNs since an incorrectly typed SSN caused a new customer to be created instead of updating an existing customer. This prevented a lot of rework. Seems like this would be a great approach for this situation.

Step 4 Agile Testing: Testing is done very differently as well. We test as soon as we build a single functioning piece of software. We don’t wait until we build the entire application. That prevents the high cost of fixing errors. Also, another difference, and probably more critical in this situation, is we write all of our test cases, called acceptance criteria, before we develop anything. That ensures that the developer knows how the product is going to be tested and then used in the real world.

Again, don’t blame the end-user. This happens all the time our industry it’s just that the failures aren’t so public. This is why implementing Agile has become mission critical for many organizations. Implementing Agile to prevent these problems rather than assigning blame is the real lesson learned from this experience.

About the Author, Dan Tousignant

Dan is the president of Cape Project Management, Inc. and is a lifelong project manager. He has embraced Agile as the most effective way to manage software development projects. He has been managing mission critical projects and developing training for over twenty-years and is passionate about improving project team performance.

https://agile.us.com/

Dan@CapeProjectManagement.com

The Practical Agile Blog

The Practical Agile Blog

The Practical Agile Blog

Finding ways to be Agile in an un-Agile world.

Are you ready for Agile?

Has your Agency or organization started moving to Agile? Do you hear the word Scrum, and wonder where the Rugby game is at?
Well, you may be part of the growing trend in IT organizations throughout the Federal Government.

read more

Agile 2.0 – It’s about People and Connections! It’s not about Scaling.

Agile 2.0 – It’s about People and Connections! It’s not about Scaling.

Andrew Carnegie once said,

Teamwork is the ability to work together toward a common vision. The ability to direct individual accomplishments toward organizational objectives. It is the fuel that allows common people to attain uncommon results.

His observation is spot on, and yet, when discussing Agile Software Development, we find ourselves focused on frameworks instead of people and connections.

Over the past 15 years, Dan Tousignant and Todd Kamens, two Agile thought leaders, have collaborated on numerous projects.  Leveraging Traditional Project Management, Scrum, Lean and Kanban techniques to manage software projects they have now joined to share their thoughts.

Working together on and off over the years, Dan and Todd have discussed many issues with clients’ different implementations of Agile, and with each conversation, a pattern started to emerge.  It wasn’t clear at first, but they started to see how Agile’s success was more about the people and values than the prescribed process and framework.  Dan and Todd started to see how Agile was becoming a practice that was unique to each company and involved people and connections in making it succeed.

Interestingly, when Dan and Todd saw these connections in the workplace, they had both started to practice Mindfulness.  Mindfulness seems to be the new buzzword these days for the stressed out corporate executive, those going through a midlife crisis or those that are just searching for more meaning out of their day.  Though it is a new term, it is not a new concept and has existed for thousands of years.

We are not attempting to teach Mindfulness in this article, however, it is important to understand it at it’s core as defined by Jon Kabat-Zin as follows,

Mindfulness is paying attention, on purpose, in the present, and non-judgmentally, to the unfolding of the experience moment by moment.

In their conversations about Agile and Mindfulness, the patterns became clear as they started to see how Mindfulness aligned with the core values of Agile.  

Agile Mindfulness
Individuals and Interactions over processes and tools Mindfulness teaches us to be open to novelty, sensitive to different contexts and to be aware of multiple perspectives.
Working software over comprehensive documentation Mindfulness teaches us to accept change, to appreciate other viewpoints and to be able to focus on the present.
Customer collaboration over contract negotiation Mindfulness teaches us an awareness of multiple perspectives and listening to hear versus listening to reply.
Responding to change over following a plan Mindfulness teaches us to cherish trust, expertise and direct communication.

In summary, Agile 2.0 moves us beyond Frameworks and instead, focuses on people and connections.  We observe how the individual, the team and the organization work together to achieve amazing results.  We pay attention to one another, non-judgmentally, and work together to achieve great value for our customers.

Over the course of several collaborative articles, Dan and Todd will convey their vision of Agile 2.0 and explain how leveraging Mindfulness practices with your Agile software development adoption can create better people, teams and companies capable of achieving greatness.

 

Dan Tousignant, President, Cape Project Management, Inc.

Todd Kamens, President, Guidance Technology, Inc.

 

BE AGILE.®

Certifications, Integrity, Values: Where do you stand?

Certifications, Integrity, Values: Where do you stand?

Last week I passed the Product Owner Assessment (PSPO 1) from Scrum.org (you can check out my new PSPO 1 mock exam here).  As an Agile Coach and Trainer, I try to stay current with certifications. I don’t believe that these certifications necessarily make someone more effective, but for me, they are a structured way of staying current with industry best practices. As part of my long-term professional development plan, I have been thinking , “What’s next?” I had already achieved what I considered to be the core certifications for a project management consultant; PMP, PMI-ACP, PSM 1, PSPO 1, CSPO, CSP, so I wasn’t sure in which direction should I go? Should I go “big”, like SaFE or DAD (heaven forbid). Should I get certified as an Agile or PMI Trainer and pay thousands in licensing and application fees? As an independent consultant, these types of certifications become cost prohibitive.

The value provided by consultants like me is that we offer services based upon real world experience at a reasonable cost. Not that long ago, I sat in a meeting with an external project management auditor from one of the Big Four. His rate was $475/hour. He was hired to audit my Scrum project to see if it was adhering to project management best practices. He started his initial findings meeting with, “I was reading about this Agile thing last night, and I think I have some recommendations.” Once my blood pressure dropped to reasonable levels, I realized that this interaction only reiterated that I needed to stay committed to my values:

  • Always provide value to my customer.
  • Stay current on best practices.
  • Keep my expenses low so I can offer reasonable rates.
  • Never sacrifice integrity for profitability.

I considered these same values when reviewing the available certifications. Can I meet those values with my current certifications? At this point, my answer is yes. What about you?

If you are interested, at my last count, there are 64 different Agile certifications! (I am sure I missed some). Can you imagine the signature line on my emails?

Agile Certification Institute

  • Accredited Agile Practitioner (AAP)
  • Accredited Scrum Master (ASM)
  • Accredited Product Owner (APO)
  • Accredited Scaled Agile Practitioner (ASAP)
  • Accredited Kanban Practitioner (AKP)
  • Accredited Lean Software Development Practitioner (ALSP)
  • Certified Agile Associate (CAA)
  • Certified Scrum Associate (CSA)

Scrum Alliance

  • Certified Scrum Coach (CSC)
  • Certified Scrum Trainer (CST)
  • Certified Scrum Developer (CSD)
  • Certified Scrum Master (CSM)
  • Certified Scrum Product Owner (CSPO)
  • Certified Scrum Professional (CSP)

Disciplined Agile Consortium

  • Disciplined Agilist-White Belt
  • Disciplined Agilist-Yellow Belt
  • Disciplined Agilist-Green Belt
  • Disciplined Agilist-Black Belt

DSDM Consortium

  • AgilePM certification
  • DSDM Atern Foundation Certificate
  • DSDM Advanced Practitioner Certificate
  • DSDM Foundation Certification
  • DSDM Consultant
  • DSDM Coach
  • DSDM Trainer
  • DSDM Advanced Practitioner

The International Consortium for Agile

  • ICAgile Certified Professional (ICP)
  • ICAgile Certified Professional in Business Value Analysis (ICP-BVA)
  • ICAgile Certified Professional in Agile Portfolio Management (ICP-PFM)
  • ICAgile Certified Professional in Agile Project Management (ICP-APM)
  • ICAgile Certified Professional in Adaptive Management (ICP-ADM)
  • ICAgile Certified Professional in Agile Team Facilitation (ICP-ATF)
  • ICAgile Certified Professional in Agile Coaching (ICP-ACC)
  • ICAgile Certified Professional in Agile Programming (ICP-PRG)
  • ICAgile Certified Professional in Agile Software Design (ICP-ASD)
  • ICAgile Certified Professional in Agile Testing (ICP-TST)
  • ICAgile Certified Professional in Agile Test Automation (ICP-ATA)
  • ICAgile Certified Professional in Enterprise Agile Coaching
  • ICAgile Certified Professional in Agile Leadership

International Scrum Institute

  • Scrum Master Accredited Certification (SMAC)
  • Scrum Product Owner Accredited Certification (SPOAC)
  • Scrum Team Member Accredited Certification (STMAC)
  • Scrum Certification for Java Developer (SC4JD)
  • Scrum Certification for Web Developer (SC4WD)
  • Scrum Certification for Mobile App Developer (SC4MD)

The LeSS Company

  • Certified LeSS Practitioner
  • Certified LeSS for Executives

Project Management Institute

  • PMI Agile Certified Practitioner (PMI-ACP)

Scaled Agile Inc.

  • SAFe Agilist (SA)
  • SAFe Practitioner (SP)
  • SAFe Program Consultant (SPC)
  • SAFe Program Consultant Trainer (SPCT)
  • SAFe Product Manager/Product Owner (SPMPO)

Scrum.org

  • Professional Scrum Developer (PSD)
  • Professional Scrum Master I (PSM I)
  • Professional Scrum Master II (PSM II)
  • Professional Scrum Product Owner I(PSPO I)
  • Professional Scrum Product Owner II(PSPO II)
  • Scaled Professional Scrum (SPS)

SCRUMStudy.com

  • Scrum Master Certified (SMC)
  • Scrum Developer Certified (SDC)
  • Scrum Product Owner Certified SPOC)
  • Agile Expert Certified (AEC)
  • Scrum Fundamentals Certified (SFC)

People have different reasons for certification. Some do it to advance their careers, others to learn new skills. Yes, there are also those that use certifications to artificially represent their expertise. I don’t worry about them because the job will weed out those people. Ultimately, you need to decide, based upon your professional values. Will these certifications allow me to provide more value to my employer or my customer? Once you have that answer, the decision is easy.

Dan Tousignant, PMP, CSP, PMI-ACP, etc., etc., etc.

President, Cape Project Management, Inc.

Using Kanban to run your start-up aka Stephen Covey was the first Agile Coach

Using Kanban to run your start-up aka Stephen Covey was the first Agile Coach

Honolulu has a thriving startup community. I decided to present on this topic after attending the kickoff of the extremely popular start-up event, Honolulu Startup Weekend. While listening to the pitches, I realized that these potential new companies were ripe for some Agile basics. Many of them were already very familiar with Lean Startup and customer driven business development, but very few were familiar with the Agile techniques designed to manage day-to-day projects or business.

I like to consider Stephen Covey as the first true Agile coach. His 7  Habits of Highly Effective People addressed key  effectiveness techniques that align nicely with Agile. My favorite one is First things First,  “To live a more balanced existence, you have to recognize that not doing everything that comes along is okay. There’s no need to overextend yourself. All it takes is realizing that it’s all right to say no when necessary and then focus on your highest priorities.” This is perfectly aligned with the Agile Manifesto principle, “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”

One of the techniques he uses for First Things First is to get people to understand  the difference between urgent versus important work. He wasn’t the first to make this distinction, Dwight D. Eisenhower is credited with this quote: “What is important is seldom urgent, and what is urgent is seldom important.”  What Covey is responsible for is the creation of the following time management matrix to help people distinguish where they are spending their time:

  • Quadrant 1 is for important activities you could not have foreseen, and others that you left until it was almost too late. Plan for these.
  • Quadrant 2 is for important activities that help you achieve your personal and professional goals, and complete important work. Focus here.
  • Quadrant 3 is for time-sensitive distractions. They are not really important, but someone wants it now. Learn to say no.
  • Quadrant 4 is for activities that are just a distraction. Avoid them if possible.

The intent of this matrix is to get people to focus on daily activities and plan their time within Quadrant 2. At the time of publication (1989), the most common technique for managing your time spent on important activities was to capture them in your calendar book. This was before phone apps or even the use of Outlook calendars. They were documented in those heavy DayTimers calendars that people carried everywhere. Covey’s training courses suggested that you block time in your calendar to focus on important tasks and limit the time you spend on urgent tasks.

This fits nicely with Agile prioritization approaches and managing WIP. For the purpose of the audience last night, small business owners, I compared this approach of managing your important work in your calendar to the Kanban concept of prioritization using of classes of service and managing work in progress (WIP). I personally use this approach to manage my business every day. I have an online Kanban board (LeanKit) with swim lanes of important activities and I have WIP limit of a minimum of 6 hours of important work each day. I assume that at least 2 hours of my day will be taken up with unplanned urgent activities. I also use the Kanban Board to capture a backlog of ideas that may eventually become actual work. Here is an example of my business-oriented Kanban board:

Kanban

For those of you familiar with Agile techniques, it is easy to see how these techniques can be applied to many different situations other than software project management. I also believe that there are very few new ideas in Agile since these effective management techniques have been around for many decades and are just now being embraced within traditional project management. If Stephen Covey was a software developer, he would have made a great Agile coach.

For more information Kanban, check out my blog post or listen to my Introduction to Kanban self-study training.

References:

About the author, Dan Tousignant

Dan is a lifelong project manager and trainer with extensive experience in managing Agile software development projects. Though the role of the professional project manager is changing dramatically through these approaches, Dan coaches organizations on how to transition teams and organizations to Agile.

Dan has over 20 years of experience providing world class project management for strategic projects, direct P& L experience managing up to 50 million dollar software development project budgets, experience managing multi-million dollar outsourced software development efforts and strong, demonstrated, results-driven leadership skills including ability to communicate a clear vision, build strong teams, and drive necessary change within organizations.

Dan holds a Bachelor of Science majoring in Industrial Engineering from the University of Massachusetts, Amherst and is a Certified Project Management Professional, Professional Scrum Master, PMI Agile Certified Practitioner and Certified Scrum Professional.

Dan Tousignant, President

Cape Project Management, Inc.

http://CapeProjectManagement.com

https://capeprojectmanagement.learnupon.com/store