Tag Archive for: Rethinking the Agile Manifesto

Tag Archive for: Rethinking the Agile Manifesto

This is the final post in a series examining the changes that have occurred since the Agile Manifesto was published and the implications they have on how we might consider the Manifesto today. Read the first post here and download the full ebook, “A Modern Take on the Agile Manifesto.”

In my earlier posts in this series, I discussed the need to review the Agile Manifesto in light of how the world (and how we work) has changed. I’d like to suggest some recommendations to ensure that product development is optimized to give organizations the best chance of success and customer satisfaction:

Pause and Rethink

  • Decouple the manifesto from Agile – take a moment to consider the manifesto through the lens of your own surroundings and look your own processes.
  • Continue to shift the understanding of failure – Look at how you’re releasing information and reacting to the release of that information. If you’re providing some kind of working software, it’s important to understand how you’re reacting to that. What are you doing as an organization to react to that information?
  • Evaluate your current communication modes – Are you an organization that loves to have meetings? Do you love to talk on IM or email? It may be worth actually recording some data on this and do some research and looking at the results – number of emails and reply-alls. You may find that decisions are being made in those vacuums and people are being left out because they weren’t even aware of a conversation that was happening.
  • Track metrics – If you do not have metrics, then it’s an emotional game deciding which direction to go in. One risk you run with metrics is misinterpreting the data so be sure to debate then negotiate what the metrics mean.
  • Think of Agile from an organization perspective – The more we can spread the idea the more it will mature.

Communicate

  • Find ways to constantly provide visibility – Into what you’re working on – even if it’s in its early draft stages. Sharing early and often is a good thing.
  • Find ways to allow communication and opinions to flow freely – There can be a fear that the noise level will hinder progress but I have not found that to be the case. I think there are ways to allow information to flow, and if it is found to be overwhelming, you can always work backward and filter it down to the relevancy of it. Having the wealth of information is a wonderful starting point. Your customers could be interacting with you through hundreds of mediums. It’s not valid to say you wish they would not interact with you but more valid to distill the information down to its relevancy.
  • Identify where decisions are made and captured – Decisions are happening everywhere and they are what cause your product or project to drift – going away from the initial path to the objective for a number of reasons. This will continue to become increasingly important.
  • Constantly ask if people understand what they are doing and why – There is an opportunity from a company perspective to empower and motivate by enabling people at every level to understand what they are doing and why. It drives creativity, innovation and success.

Evolve

  • Open up the dialog about culture – If you think this is not your role than think again. If you’re involved in the development and delivery of products you have a perspective and a voice.
  • Embrace process – Focus on making the process more efficient and understandable. Process gives us guidelines to collaborate more creatively and effectively.
  • Continue to communicate – Content and data is incredibly valuable if it’s made available in the right place. Having a ton of information is a great starting point, the next thing is figuring out how to utilize it.
  • Start with too much information then work your way back – Find the balance. In early stages of a product this can be especially true. Having more information will help you eventually develop parameters.

This is the seventh post in a series examining the changes that have occurred since the Agile Manifesto was published and the implications they have on how we might consider the Manifesto today. Find the first post here.

In 2001 the notion was that documentation should be replaced by working software. Of course, back then ‘software’ was a simpler concept. Certainly some was very complex, but overall, software products have grown greatly in complexity. The mindset at the time often was to document everything upfront, then go build, the result was that teams built the wrong thing.

Alistair Cockburn, signer of the Manifesto, has spoken about the word “comprehensive” and the decision to use it. According to Cockburn, this software term was highly debated. The creators didn’t want people to think that documentation in and of itself was unnecessary because they did believe it was important. The intent was to call out exhaustive documentation as overkill.

Today we have more complex software. We also have realities of Minimum Viable Product (MVP) and continuous delivery. The idea of working software is much more of a reality. This does not change the importance of documentation. What does change is the idea of the word ‘document.’ A white board, sticky notes, wiki, or collaboration software, these are all documentation. This is a critical and necessary aspect of the process. The ability to respond to change, to interact, in fact everything the Agile Manifesto believes in relates to communication and collaboration around something – the ideas, stories, epics, and decisions written and made everyday.

Read the next post in this series, “Rethinking the Agile Manifesto: Customer Collaboration and Contract Negotiation.”

This is the fourth post in a series examining the changes that have occurred since the Agile Manifesto was published and the implications they have on how we might consider the Manifesto today. Find the first post here. 

In the previous two posts in this series I discussed that the world has changed and software is now everywhere. The third reason for reviewing the Agile manifesto is simply that complexity has increased, both at the product and company level. Building products used to be simpler as hardware products could only handle so many lines of code, and web applications only had to worry about a couple of browsers and monitor sizes, and there were fewer programing frameworks.

In the modern product delivery survey conducted with Forrester, it was found that 55% of companies had over 100 products and 87% of companies had multiple teams working on projects. 70% of companies stated that they release products quarterly or more frequently. 61% of projects had at least four different teams involved, while only 4% of stakeholders were co-located in close proximity. 23% of products now consist of both hardware and software elements.

Today, products are more complex by their very nature, often performing multiple tasks simultaneously, and generally in a smaller form factor. Hardware contains a lot more software; software products need to consider many more devices and situations; and open source has provided the development community with many more libraries, frameworks and languages from which to choose. The range of products available is wider and product development has become more complex. A greater number of platforms must be supported – in 2001 Firefox and Chrome did not exist yet, now there are many browsers, as well as many different devices and platforms on which to browse. That’s not to say there was no complexity back in 2001, but there have been significant added layers of complexity since then.

Many products now have a much greater ‘ecosystem,’ in that they operate in conjunction with other products to enhance functionality. For example, the success of Apple’s iPad was around its ecosystem, that is, the applications that it enables and which enable it with greater functionality. Nest’s vision was not just around home thermostat but more around the broader ecosystem of home control which, bigger picture, was what Google was interested in when they acquired Nest.

When we look at the complexity of companies, technology has progressed so much that we now have the ability to communicate across distributed teams in many ways that were unavailable in 2001, enabling geographically dispersed teams to work together more efficiently, but which can also amplify the organizational challenges of product delivery. There is less a need for everyone to be in the same room, and many organizations have product teams both here in the United States and overseas.

Read the next post in the series here.

This is the third post in a series examining the changes that have occurred since the Agile Manifesto was published and the implications they have on how we might consider the Manifesto today. Find the first post here. 

Today, software is everywhere. It’s in everything we do. We as consumers interact and buy software more than ever, often without even knowing it. In late 2013, Jama partnered with Forrester Research on a ‘modern product delivery’ survey that found that 23% of products now contain software in some form. ‘Disruptive’ technology, that is, innovations that create and markets and value networks, and which over time ‘disrupt’ existing established markets, is increasingly pervasive. For example, Amazon changed the book selling – and everything selling industry – with software. Airbnb is disrupting the Hotel industry. A new generation of tech savvy consumers is helping to drive social adoption and they see disruptive technology as a positive thing.

Established industries are also evolving to adapt software to improve performance. The automotive market, for example, used virtually no software back in 2001. Now we have software working all over our vehicles, from sensors and cameras to navigation to infotainment systems to diagnostics. In 2001, cars had a minimal amount of code in them. A new car now has about 100 million lines of code. What’s more, it is expected that more than 150 million connected cars will be on America’s highways and byways by 2020. We have already seen examples of software being used ‘on the fly’ in remote product recalls. In March 2014, automotive manufacturer Tesla addressed a known fire risk in its cars in part by providing a software update to existing vehicles. This helped mitigate the risk without owners needing to visit dealerships or service centers. Cars are also beginning to connect to each other. The U.S. Department of Transportation is working on a system that has the potential to reduce accidents as a result of an intelligent connected car network.

In the financial industry, it’s becoming less and less important for consumers to have face to face interactions at their bank because of mobile banking, deposits using your camera phone, apps that allow you to budget and transfer money. This has banks deeply concerned. They were not prepared to become a software company. Now they have no choice.