Agile on the Beach 2013
The Cornish countryside is an ideal and relaxing setting for any conference. With wide green pastures, grazing livestock, occasional wildlife sightings and a rugged coastline, it was a most welcome backdrop to the annual Agile on the Beach 2013 which took place at Falmouth University, in Cornwall, UK, during September 2013.
Agile on the Beach is a two-day business and technology conference and I was asked to partake in the event and share my perspectives on product management with over two hundred delegates from the UK and Europe. Most of the attendees were software developers and Agile practitioners but there were also people with roles in software testing, product marketing, product management and executive management. It was evident from the outset that the conference was very well organized with all logistics running smoothly.
Allan Kelly, who had invited me to the conference, said that the speaker selection was designed to expose the attendees to a variety of opinions and thought streams on business and development issues. On the first day of the conference, Dan North presented a keynote speech on software mastery. This was followed, for the rest of the first day, by presentations by different speakers on (mostly) various Agile related matters.
My keynote speech on Market-driven Product Management opened the second day, lasted an hour, and presented the fundamentals of product management and several poignant and entertaining case studies.
My expertise is in product management and my focus is on the problem space. With the Blackblot Product Manager's Toolkit® (PMTK) methodology it is relatively simple to put forward rational and cogent arguments on virtually any topic in product management.
Yet, following many conversations with Agile practitioners at the conference, it became rather obvious that the clarity that exists for me in the product management domain is lacking in the development world with respect to Agile. Quite frankly, I learned that many of the people who practice Agile development are somewhat confused or are in disagreement among themselves about what a Product Owner should do and how Agile should be implemented.
I do not know much about Agile or other product development methods which reside in the solution space and are practiced by engineers. I do not have any career or professional investment or interest whatsoever in Agile or any other product development method. Therefore, I believe that I am in a position where I can objectively identify some far-reaching problems that are emerging from the lack of subject matter consolidation in Agile and which could have lasting implications.
Concept – My position is that Agile at its core is an incremental/iterative product development technique that is confined to the solution space. Agile was meant to allow the delivery of a product in stages, providing additional validation or fine-tuning of the product's feature set with each delivery stage. The problems begin when these fundamentals are breached.
Identity – Several people at the conference tried to characterize Agile for me. Phrases such as Agile Project Management, Agile Product Management, and Agile Product Development were the most common. New term variations such as Scalable Agile and Lean Agile were confusingly interjected into the conversation. I feel that Agile Software Development is the correct identity and all the other phrases are incorrect or meaningless.
Roles – The proper way to define roles is to first understand the high methodology, its principles, main processes and key deliverables. Once all these fundamentals are clear and consistent, it is mere technique to formulate the roles that adhere to the fundamentals. It seems that in Agile, people first define the roles and then try from the role's title to extrapolate the inner workings of Agile.
The most inconsistent and ill-defined role in Agile is likely the Product Owner. People at the conference were conflicted and contradictory on how to define the Product Owner role and the associated responsibilities and tasks. I knew something was thoroughly misunderstood when someone told me that Product Owner is synonymous with Agile Product Manager. There is no such thing as an Agile Product Manager.
In my keynote speech I presented a popular illustration of the Agile Product Owner role and its exceedingly expansive host of responsibilities which I labeled as "unrealistic" and the "stuff of legends" – the audience was in full agreement.
Because of the current diffusive state of the Agile concept, it is not surprising that people struggle to properly define the Product Owner role. Many seem frustrated by the ambiguity and lack of guidance in this matter but some seem to desire that ambiguity so that they can shape their personal Product Owner role according to their comfort zones.
Another lurking motivation drives some people to assume as many responsibilities as possible as Product Owners to increase the company's dependency on them. This is quite erroneous because professionals are more valuable to a company when they are utter experts in one thing and not when they assume a multitude of diverse responsibilities. Spreading out to cover more tasks does not make one more valuable or critical to a company.
By extending the roles described in the Blackblot PMTK Methodology™, I submit that the Product Owner in Agile should be responsible only for scoping for sprints and managing a release. The Product Architect role will transition from writing Product Requirements Documents (PRD) and Uses Cases to maintaining the Product Backlog and generating User Stories.
Encroachment – Agile is not, and was not meant to be, an experimental discovery or research-driven development technique. Also, Agile is not meant to validate product concepts or generate market requirements. Product concepts are validated by the Product Architect, not the product developers, and market requirements are generated by the Product Planner. By extending their reach into the problem space, the developers are attempting to take control of responsibilities that belong to product management and program management. One person even told me that under Agile the developers should "guide" product marketing activities.
By allowing the development team full control of the product delivery program (activities in both the problem and solution spaces) the whole matter of selective competencies, enhancing expertise, career focus, and procedural checks and balances is drastically and negatively disrupted.
Scalability – In his keynote presentation, Dan North eloquently argued that "Agile does not scale." This had the audience grumbling and it is only natural for many Agile practitioners to wish that Agile could be the answer to any development project of any size. However, this is not the case and Agile is not suited for large and complex projects because of its lack of systematic market research and overarching central planning and management that are needed for big projects.
Some people at the conference that I spoke with during the breaks offered salesforce.com as an example of a complex product that was developed via Agile, but this is a misconception as the salesforce.com platform was created in 1999 with waterfall-like processes. In 2006, Salesforce switched to a very efficient way of doing Agile to add new features which are driven by a vast customer feedback and suggestions mechanism that is constantly being gathered electronically.
My position is that Agile is great and applicable but fundamentally only to small products or known specific features.
MVP – The term MVP (Minimum Viable Product) is a concept associated with the Lean Startup approach, which I consider a largely unproven theory that advocates that companies should use iterative development (e.g. Agile) and frequent incremental product releases. There is nothing new or special about MVP – it has been called for a very long time Version 1.0 of the product. Product validation was traditionally done via a beta program or some form of a pilot program. So MVP is just a repackaging of well-known concepts that are marketed as new ideas, and is loosely related to Agile.
In conclusion, the Agile Software Development method is still in flux, and consequently so are all derived aspects such as the role definitions, deliverables and interfaces to other disciplines. Agile still needs to undergo a period of maturity and subject matter consolidation to achieve the same consistency, practicality and holism that has been achieved with PMTK in the product management domain.
In other news, following my keynote presentation on the second day of the conference, I was approached by several individuals who were keen on learning Blackblot's position on the matter of User Experience (UX). As it seems, UX is yet another domain seeking clarification and placement. Opinions among the conference's delegates positioned UX as an autonomous entity within the company's organizational structure, while others claimed it is a task that belongs to a rather amorphous role in the Agile team or the Product Management team. Again, in a perplexing déjà vu moment, I knew something was thoroughly misunderstood when someone mentioned that UX Expert is akin to UX Product Manager. Blackblot's position on UX, its roles and interfaces to other organizational units, will be presented in a separate and dedicated article.
With regard to good old product management, well, although Europe is very advanced, modern and arguably the center of the cultured world, it is drastically lacking in its understanding and application of sound product management methodologies at product companies. This is very surprising given how many capable and educated people work at European product companies. My conversations with people at the conference showed that there is a great desire to learn and improve.
It seems that many European companies are technology-driven with the developers in control. While by no means a negative proposition, being technology-driven is just the very first step in the evolutionary track of a product organization on the road to becoming market-driven (to be able to capitalize on the lucrative mainstream markets). In comparison to the USA, India, Israel and some other Asian countries, product management is woefully underdeveloped in Europe.
Overall, I was privileged to attend the Agile on the Beach 2013 conference. The keynote speech went well, the discussions were most challenging, the people smart and friendly, and the scenery beautiful. It was an enjoyable and enlightening experience which hopefully I was able to share with you in this post with regard to my insights and recommendations on Agile and other topics.
