I have been using methods similar to "Agile" for more than 30 years, and even built the principles of “Agile” into my ERP / FMIS product, "Crusader".
I had found it necessary to use “Agile” methods because I found that many clients regularly changed both the scope and priority of work being done as their perceived "pressure points" changed focus with changing circumstances. I very quickly learned to empathise with their point of view, recognise the implications of their request, then negotiate for a compromise that would be satisfactory to them without jeopardising progress. The objective was always to see their needs met as soon as possible without excessive cost, whilst allowing the developers to be able to remain focussed and to successfully complete their current section of work.
Some years ago I came across the following quotation, which I think summarises how I best like to work;
“They will be mentored but not managed; encouraged but not controlled”
When working with developers, I have been determined to enable them to reach their full potential of creativity and productivity by receiving requests from clients' and balancing the priorities so that the developers could stay focussed on the work at hand. This was not truly "Agile", as has been formally defined, but the problems I encountered and my overall approach to resolve these have strong similarities.
In the early days of Crusader, I was both project leader and developer, but once we started to create sub-systems outside of the core Crusader code, based on Pick / D3, I was increasingly focussed on guiding and facilitating development work done by others using Visual Studio.
I have now used this experience in the context of existing methodologies by writing a paper on "Agile" that is designed to be both readable and relevant to management level people. You can read the introduction here. I'm not going to repeat what I have written in that paper, but want to draw attention to a couple of key factors that I believe contributed to the success that I experienced over an extended period.
1. The first and most important factor for success with "Agile" is to have the trust, respect and co-operation of stake-holders - the business owners, management and users of the system under development. Throughout my experience with Crusader and the various add-on technologies we developed, the critical factor in our success was having the almost unconditional support of the business owners and management.
2. The second factor which very much supported the first, was that whenever possible I have taken opportunities to provide new deliverables so the business owners received a return on their investment to that point. The only reason I referred to "almost" unconditional support was that it appeared to be unconditional, but I believe it was actually a result of providing consistent benefits project after project, incremental improvement after incremental improvement over a lengthy period.
The "Agile" Team
Looking at the diagram above, the business is shown on the left. The Project Owner and Systems Architect relate directly to the business, have the responsibility of communicating with the business stakeholders and interpreting their requirements. This responsibility extends to creating and maintaining an open and trustworthy relationship with both the business and the Development Team, who have their own "representative" in the person of the Project Manager. (The "Scrum Master" when using the "Scrum" methodology.)
My role for much of the time in the past was to be Project Owner, Systems Architect and Project Manager all at the same time. There is something to be said for combining Project Owner and Systems Architect roles into one, but ideally the Project Manager will be separate. This person needs to focus on the Development Team, monitor progress and make adjustments as necessary. They also need to create an environment in which the developers can be most creative and productive, encouraging a true sense of a supportive community within which to work. It needs to be a place where they feel "safe" to share their ideas and to challenge themselves and their team mates to excel.
Because I am very familiar with doing so, and have strengths in communicating with business stakeholders and in systems architecture, I most enjoy taking the Project Owner and Systems Architect roles. Contact meif you know of an opportunity!
Download a summary of the benefits of Agile development methodologies in PDF format here. 245 Kb.
Download the benefits of Agile methodologies plus a brief description of a methodology similar to "Scrum", in PDF format. 704 Kb.