In this article, Grant Lloyd, Chief Technology Officer Softline and Sage AAMEA reflects on the impact of managerial style on Agile Software Engineering initiatives.
Grant Lloyd, CTO Softline and Sage AAMEA
Growing application complexities, drastically curtailed project delivery schedules (schedules being halved every 2 to 3 years in practice), a general intolerance by commercial users of software defects, and, greater integration, interface and interoperability requirements are principle drivers of software engineering in the present day.
Simultaneously, functional requirements have amplified and project funding apportionments have declined. Where a project manager was previously able to trade one component of the project triple-constraint: time, cost and quality, against either of the others to reach a reasonable compromise, the more recent challenge has become improving the performance of all triple-constraint aspects simultaneously.
This compounded vigour in user demands and commercial priorities is demonstrated by frequently developing customer requirements which have given rise to agile software engineering models. Principally directed at focussing software engineering on tasks and activities adding direct value to the ultimate deliverable i.e. functional software, the approach eliminates “non-value-adding” activities from the project whilst embedding the principles of constant change, trust, courage and independence at the core of the initiative and team.
A significant differentiator between agile and traditional approaches is that each requires very different management styles. Traditional methodologies require more management and less leadership, whilst the agile approaches require more leadership and less management.
As a process-based approach, the traditional methodologies focus heavily on what is supposed to be done, in what order, with what inputs, processes and outputs, and, with a desired deliverable as overriding goal. On the other hand, the agile approaches are completely outcomes-based. The sole goal of the agile approaches is to deliver software that exceeds customer expectations with little or no concern with interim processes unless these processes add directly to the final outcome of customer satisfaction.
If one considers a highly simplistic continuum of management styles from [controlling to directing to visionary to anarchic] it is apparent from the style of the traditional approaches that a blended management style, somewhere between controlling and directing would be most suited for traditional methodologies.
On the other hand, the optimum leader of an agile approach project would have a very visionary outlook, would be directing at times (when needed) and would most certainly not be uncomfortable with phases of anarchy during the project – even in times of trouble an agile leader needs to avoid operating at the controlling end of the spectrum at all costs, as the basis of agile development leadership is courage, empowerment, trust and a focus on the customer’s needs.
This is clearly not to say that one approach is subjectively “better” than the other – I believe that not only are both approaches applicable under very different circumstances, but they are equally suitable to different leadership styles at different times. Care should be taken when selecting agile versus traditional methodologies to not only match the project with the approach, but also the people with the approach.
Personalities of individuals on the team, specific project requirements and indeed corporate culture as well as the risk profile of each project should be used to determine the optimal type of methodology being deployed on any given project.
Whilst the purists may disagree with this assertion, the real power of software engineering, I believe, lies in a sensibly “blended” approach for optimal results and performance as well as team wellness, motivation, energy and courage in the face of some of the largest challenges this planet has ever seen i.e. engineering modern-day software systems.
Where the agile approaches are of less benefit is where the application being constructed is mission-critical, high-risk and specifically where requirements of the system are clearly specified and unlikely to change rapidly over time. For example: space shuttle mission-control systems, aeronautical embedded systems, healthcare applications and the like…..
When agility, responsiveness and high levels of flexibility and change are present (together with active customer commitment and involvement) in a project, the agile methodologies such as XP and SCRUM can provide empowering alternatives to the more rigid waterfall model regardless of project size and scope.
Whilst I am personally an ardent fan of the agile approaches (particularly SCRUM and XP) in the ERP and line-of-business industry, they do indeed have many detractors one of whom is Steve Yegge who presents a light-hearted yet scathing critique of agile on this link: http://steve-yegge.blogspot.com/2006/09/good-agile-bad-agile_27.html