A Look Back at Agile 2014

TomThe Agile 2014 Conference was like a symphony, made up of many individual movements that form a whole, like the Agile movement in general. All five days of the conference included 16 planned tracks, with at least four presentations per track (Friday had a much smaller number of presentations). The variety of presentations and topics reflected the range of related, but different, movements classified as Agile.

Topics ranged from the social sciences of psychology and sociology, targeted at coaching teams and facilitating organizational change, to highly technically topics, such as pair programming and DevOps.

The conference attracted 3,000+ attendees and speakers. For anyone interested in Agile this is a conference that not just allows, but almost insists, on an immersive Agile experience.

Several attendees that have attended in years past suggested that this year’s attendees reflect a subtle shift. Exhibitors noted that there were more decision-makers than developers/practitioners in attendance. Other attendees noted that the themes of scaled Agile and DevOps were also more prevalent than in past years.

Many of the early Agile thinkers were in attendance and involved, not only in presenting, but in shaping the conference. None of the early thinkers have lost their particular fire. For example, one speaker from this cohort publicly lamented that sponsors were monetizing the conference. Ken Schwaber even suggested turning the branded lanyards over to hide the branding. From my perspective, picking on the vendors is an easy target that could have negative consequences. The vibrant vendor/exhibitor community present was positive and provided the sponsorship needed to hold great, special sessions that made the conference more than just a fire hose of information.

Agile 2014 was also a social experience. If continual presentations and interactive workshops were not to your liking, there were plenty of less structured events. The conference had constant hallway talks, lean coffees every morning, open jams, coaching clinics and space provided for one-on-one conversations. There was no shortage of ideas, nor any shortage of space to discuss those ideas outside of the formal agenda.

This conference was large enough to hit some important topics one day, then explore topics outside of your comfort zone the next, and then have time to switch back and forth on the third, fourth or fifth days. I overhead folks discussing an interesting strategy: spending a day attending sessions that were exactly opposite of those you would typically attend to make sure you were exposed to new ideas.

Conversations within the hall suggested that attendees that have been part of the Agile movement for more than a few years feel that innovation experimentation by Agile practitioners is slowing and that the cycle of inspecting how Agile practices are performed by organizations and teams are being codified, and in some cases they are being practiced as cannon and orthodoxy. Hallway conversations suggested that the hardening of the rules that some groups are exhibiting is being noticed. Leading voices are beginning to reemphasize learning and experimentation. One of the reflections of the slowing in evolution of Agile is a suggestion from a few people that I chatted with that unless you are new or in the business of Agile consulting, attending the conference every two years and reading blogs is enough to keep current. I am not convinced that this suggestion is 100% accurate yet, but it may be soon unless innovation accelerates again.

There were very few negatives to the conference. One downside worth mentioning was that many speakers that I went to see ran out of time. It seemed almost like a badge of honor for speakers to announce they were out of time even though they were not done with the material they intended to cover; this included one of the two keynote speakers. Many of the offending parties I would consider professional speakers and know better. Not the end of the world; if I really want to know the rest of the story, I will track down and interview on my podcast.

As Ernest Hemingway said, “It is good to have an end to journey toward; but it is the journey that matters, in the end.” Agile 2014 wass part of my journey of enlightenment.


Tom Cagley
VP of Consulting & Agile Practice Lead

Written by Tom Cagley at 05:00
Categories :

What's the Best Software Development Strategy to Choose Today? Five Years On!

MikeJust about five years ago, I wrote a blog post describing a conversation I had with a friend who had taken on the challenge of integrating 50 separate pieces of IT capability into one cohesive unit. Our conversation touched on the best software development strategy for his circumstance – a circumstance surely shared by others.

I never imagined that this simple post would become one of our most visited pages on the website.  Five years on, it seemed appropriate to revisit the original post to see if I would change anything today.

Several of the themes outlined in the previous post readily stand the test of time and would still be my recommendations today:

  • Leadership: Finding the right leader for the group is key in successful integration.
  • People: Establishing a new culture – aside from just new leadership – including new processes and training.
  • IT Governance: Defining what decisions need to be made, who should make them and how they will be made.

However, a number of my recommendations have changed over time.

Five years ago, for an ill-disciplined group such as my friend had assembled, I hesitated to recommend more than an Agile trial. If we had the original conversation today, I would expect over half of the 50 teams to be using or to have had exposure to Agile. From this more substantial knowledge base, I would push harder for him to deploy lean-Agile across the board. I would, perhaps, recommend a greater focus on the use of Kanban to manage task flow than some of the team might have experienced from basic scrum implementations, which would be an adjustment. Overall, the scale of the operation would lead me to recommend SAFe™ for implementing Agile across the enterprise. 

In the previous post, I also talked about the importance of integration in the context of the applications being managed and extended by the 50 teams. The rise of lean-Agile has made continuous integration a necessity, and I would expect the volume of interaction between the various groups to have grown from occasional design meetings to frequent, if not daily, discussions about integrations and dependencies.

I also discussed COTS and outsourcing.  While most large organizations continue to use COTS systems, in the past five years the line has probably blurred between installed systems and cloud-based systems, which have significant advantages if an organization can reconcile its security needs on such systems.  For example, most companies have become accustomed to using salesforce.com or something similar for CRM but not all are ready to put, say, their HR system in the cloud. 

Of course, “the cloud” was not mentioned at all in the article five years ago, while now even DCG uses cloud tools internally! Thus today, my recommendation would probably integrate more of a cloud-based approach.

Software development is an ever-changing industry. I’m sure if I revisit these posts again in five years, I will have new recommendations. This exercise outlines the importance of continuously reviewing a software strategy to ensure that it’s still the right choice for today’s environment – successful strategies are ones that easily adapt and change over time.

There have been many changes in the past five years.  What important ones should I have included?


Mike Harris
DCG President

Written by Michael D. Harris at 05:00
Categories :

Agile and Healthcare.gov

MikeI have read through the newly published GAO report on the failure of healthcare.gov, and I, of course, focused on the mentions of Agile – a few pages in a 40 page report. The report identifies that the real problem related to the use of Agile in the project was not the methodology itself but the department's admitted inexperience with Agile, which introduced additional risk into the project. 

Reading between the lines, I suspect that working with government staff not used to the demands of Agile implementations, led the contractors to struggle to maximize the potential benefits of an Agile implementation. Perhaps the contractors were too busy to provide the training that the government staff needed? The report implies that this “additional” risk was “avoidable.”  I am not intimate with the facts, but, in principal, I disagree – this smacks of 20-20 hindsight.

So, if Agile as a new methodology was only a contributing factor to the overall risk in that department, what were the main causes? The report highlights many causes, but from a purely software development perspective, there simply wasn’t enough time to get the project done in the government environment. 

The report says that the department was at fault for not finalizing the requirements before starting the project, even though that would have made the project duration at least two years instead of the 15 months actually available. To quote from the report,

“Meeting project deadlines was a driving factor in a number of acquisition planning activities. HHS had 15 months between enactment of PPACA and the agency’s request for proposal to develop requirements for the FFM and data hub. In a prior report on acquisition planning at several agencies, including HHS, we found that the time needed to complete some pre-solicitation planning activities—such as establishing the need for a contract, developing key acquisition documents such as the requirements document, the cost estimate, and, if required, the acquisition plan; and obtaining the necessary review and approvals— could be more than 2 years. The time needed depended on factors that were present for this acquisition including complexity of the requirements, political sensitivity, and funding. CMS program officials noted challenges developing requirements for a complex, first-of-its-kind system in these compressed time frames and indicated that more time was needed.”

The report repeats the theme that federal regulations and GAO best practices state that the best software projects happen when the requirements are all known and locked down prior to the start of the actual project. Dang! If only we’d known that. 

Of course, the way healthcare.gov was going to work was not known or locked down when the agency started, but with only 15 months allotted for the project, they had to start anyway. In this scenario, Agile was probably the best choice. I would have made the same choice – but I would have worked harder to resolve the inexperience issue. There are experienced Agile coaches available and they should have been used.

There is no explicit recommendation for executive action on Agile in the report. This is a missed opportunity. We know that Agile is being implemented in many agencies and is under consideration in most, if not all others. I believe that the government should use Agile in some (but not all) of its projects. There is an opportunity to learn from the healthcare.gov experience, and I think most agencies would welcome an update to existing GAO guidance on Agile, focused on how to improve on the healthcare.gov implementation. 

That’s my takeaway from the situation. What’s yours? Please share in the comments!

 

Mike Harris
DCG President

 

Written by Michael D. Harris at 05:00
Categories :

Rescuing a Troubled Project With Agile: Making the Break With Teams

Early in my career I worked for a turnaround specialist. Two lessons have stayed with me from that experience. The first is that there is never a “formula” that will solve every problem. Different Agile techniques will be needed to rescue a troubled or failing project depending on the problems the project is facing. Second, once the turnaround process begins, everyone must understand that change has begun. The turnaround specialist I worked for was known for making everyone in the company he was rescuing physically move their desks, with no exceptions. The intent was to let everyone know life would be different from that point forward. In many troubled projects, the implementation of fixed teams focused on a single project at a time can be a watershed event to send the message that things will be different from now on.

Using Agile as a tool to rescue a project (or program) requires ensuring that stable and properly constituted teams exist. In many troubled projects, it is common to find most of the people involved working on more than one project at a time and reporting to multiple managers. Groups of specialists gather together to address slivers of project work, and then they hand the work off to another specialist or group of specialists. Matrixed teams find Agile techniques, such as self-management and self-organization, to be difficult. A better approach then is the creation of fixed, cross-functional teams that report to a management chain within the organization.

An example of a type of fixed team structure is the Capability Team, described by Karl Scotland (interviewed on SPaMCAST 174).

Capability Team

The Capability Team is formed around specific groups of organizational capabilities that deliver implementable functionality, things that will enable the business to make an impact. The team focuses on a generating a flow of value based on their capabilities. These teams can stay together for as long as the capability is important, building knowledge about all aspects of what they are building and how they build it. This approach is particularly useful in rescue scenarios, in which specific critical technical knowledge is limited. By drawing all of the individuals with critical technical knowledge together, they can reinforce each other and share nuances of knowledge between each other, strengthening the whole team.

Teams are a central component of any Agile implementation. Implementation of a fixed, cross-functional or capability team in environments where they are not already used will provide notice to everyone involved with the project and organization that change is occurring and that nothing will be the same. Embracing the team concept that is core to most Agile techniques will help provide focus that is needed to start to get back on course.


Tom Cagley
VP of Consulting & Agile Practice Lead

Written by Tom Cagley at 05:00
Categories :

The 500lb Marshmallow!

Never give up and keep swinging!

MarshmallowI often describe challenges that seem to only move an inch at a time despite a ton of effort as, “Swinging at the 500 pound marshmallow!” I have found that over my career in the software industry, many problems in our customers’ environments could also be described as a 500 pound marshmallow. But, as an independent software assurance company, proServices often has both the perspective and objectivity to recognize and assess these challenges more frequently than our customers because they’re too exhausted to see what’s coming. 

These challenges range across the software lifecycle and have been around since the ENIAC (pictured below).

ENIAC Computer

Some notable challenges from the C-Suite of our customers include:

  • “Why are my projects always late?”
  • “Why are my projects always over budget?”
  • “We always find out about our defects too late and from our customers first!”
  • “What process should we be following?”
  • “How do I get more out of our testing efforts?”
  • “We need to do a better job of estimating cost, schedule and functionality upfront.”
  • “I wish we had more proactive visibility into our technical debt.”

Fantastic concerns – and ones you would expect from the C-suite. These challenges have not changed much over the years, but the technology underneath has changed dramatically, from architectures, languages, and hardware to data models, the approaches available to tackle these challenges continue to improve.

So, instead of utilizing the same old series of punches at these marshmallows, why not try something new to see if we can move it a foot instead of an inch? 

Design & Estimation

For starters, you need to put a proper estimation process in place, at the front of the process, as well as a mechanism to measure the result on the backend of the process. This ensures that you’re producing the functionality for the projected cost and schedule. Most of you would probably agree that you design quality into the system, starting at the beginning of the process. I am not an expert in software architectures, but I do understand the importance of having a well thought out strategy that incorporates growth and flexibility to accommodate constant change. Addressing these important items upfront will help mitigate substantial defects later in the lifecycle. One of the biggest benefits of having a solid estimation capability is being able to gauge how well tuned your engine (or process) is for production capacity.  This enables vital information for organizations to continually improve their process by providing constant feedback.  There are companies that offer consultants in both of these areas, as well as a number of products on the market for you to do it yourself, perhaps with some outside expert guidance. Done.        

Build it Right the First Time

How? By implementing an Agile process that includes a continuous integration DEVOPS. Once that’s in place, you should have a system that provides software risk analytic reports profiling quality, security and performance for every build. By providing early and iterative transparency into technical debt, you will be able to significantly mitigate and reduce the rate of defect injections into your software during the execution phase. Leveraging technology platforms to collect important data; correlating it to risks important for your organization to understand and proactively mitigate; and finally, having the collaborative mechanism to socialize this data across the organization from executives to engineers.  There are also companies that offer this as a service and provide platforms that integrate these technologies into the DEVOPS environment. Done.

Testing has a Seat at the Table

Now, your testing team has to be integrated with your development team by driving a test-driven development process from the beginning. Some key metrics, such as functional and performance testing success/failure ratios, should be mapped into your dashboards, as well test coverage metrics to measure the effectiveness of your testing efforts. Then, you should use automation integrated into your DEVOPS and CI environment to streamline the operations. By designing tests upfront and setting aggressive performance targets, you will significantly reduce the defect injection rates at this phase of the lifecycle. Again, there are companies that offer this as a service and technologies to make this happen. Done.

What’s my point? One of the top five complaints we have heard over the years from the C-suite involves finding defects too late in the process. Yet, we continue to swing at the 500 pound marshmallow with the same strategies, expecting different results and finding only frustration. Everything I’ve outlined above can be tackled internally by most companies, but sometimes the solution requires an objective third-party who can analyze the problem and then implement the solution on your behalf. Maybe moving the 500 pound marshmallow requires a new perspective and the help of someone else, but in the end, you need to keep swinging at these challenges to keep moving forward.

Keep Swinging! 

 

Rob Cross
PSC Vice President

 

        

 

 

Written by Rob Cross at 05:00

"It's frustrating that there are so many failed software projects when I know from personal experience that it's possible to do so much better - and we can help." 
- Mike Harris, DCG Owner

Subscribe to Our Newsletter
Join over 30,000 other subscribers. Subscribe to our newsletter today!