HIGH-QUALITY SOLUTIONS Melbourne | Sydney | Canberra | briSbane | HobarT | adelaide | Singapore

The “Right” Working Software

In The Path to Agile, the second paper in this three-part series, we discussed two cornerstone values in the Agile Manifesto: Responding to Change and Customer Collaboration. In part three, we’ll examine the “right” working software and the importance of individuals in an Agile team.

The “Right” Working SoftwareUltimately, customers expect to receive software that’s fit for purpose; in other words, they expect to use the delivered solution effectively. In part two, The Path to Agile, we saw how responding to change rapidly, and collaborating with clients closely, builds the solution clients expect to receive, through responding to change rapidly, maintaining effective client collaboration and feedback.

Until a few years ago, working software was the sole focus; but, in my opinion, all released software needs to work. We need to shift our focus to the concept of the “right” software. This requires embodying knowledge about the current state of the business practices, and ensures software is delivered that’s not only working, but remains fit for purpose and aligned to organisational goals and practices. In short, it retains context.

As discussed in part one, The Agile Journey, the percentage of software features that are actually used is disturbingly low, see figure one.

www.revolutionit.com.au

Agile Today Is it time for organisations to take the plunge?

By examining utilisation, cost savings can be achieved by limiting over-production, or waste; is a key concept in the Toyota Production System (“TPS”). This is referred to as muda, the art of maximising the amount of work NOT done. It’s a key component in the Lean approach, and in turn, provides opportunities to increase Return on Investment (“ROI”).

Agile projects use a product backlog, a prioritised list of functionality to be developed in a product or service. Although product backlog items can be expressed in a range of ways, User Stories are emerging as the most powerful way to define them.

In simple terms, a product backlog replaces the traditional requirements document. However, it’s important to remember that writing User Stories (“As a user, I want …”) needs to be supported by a collaborative and supportive team.

User Stories are crucial pointers to a project’s real requirements. User Stories can link to workflow diagrams, a spread sheet showing how to perform a calculation, or any other required features or functionality necessary to deliver the requirement.

Value PropositionsOverall, Agile aims to promote three key value propositions (in traditional software delivery, these are referred to as scope, cost and schedule):

Right Product: The customer collaborates on driving the product backlog and helps prioritise exactly what features are to be included in the product

Right Price: The price that the customer believes is fair; the budget is set by collaborating with the customer

Right Time: When the customer wants it; the schedule is set up-front by collaborating with the customer

45%

19%

16%

13%7%

Never

Rarely

Sometimes

Often

Always

Source: Jim Johnson of the Standish Group 2002

Feature UsageFigure One

HIGH-QUALITY SOLUTIONS Melbourne | Sydney | Canberra | briSbane | HobarT | adelaide | Singapore

Individuals and InteractionsTo achieve these value propositions, teams need to empower individuals as equal contributors to the delivery of the solution. In fact, it’s essential to encourage individuals to share ideas and collaborate with people fulfilling different project roles. By collaborating as a cross-functional team, people identify with the overall project and its goals; however, in functional teams, individuals often identify with people fulfilling the same functional role. This polarises teams by function, and may lead to competing or unclear objectives for delivery, see figure two.

Maintaining central pools of staff – who follow matrix management lines and support demarcation between delivery functions – places pressure on budget and the ability to deliver solutions. Building high performance teams becomes reduced to question about economics and skill-sets. However, Agile teams operate with a fundamentally flat structure. Everyone is a team member, regardless of their skill-set, from technical architects and test analysts to UX designers and project managers.

In traditional approaches to project management, team members and stakeholders stay in separate groups. So in effect, there are two main groups: people who do the work, and people who want to see the results.

For example, developers and testers deliver specific features they’re accountable for; whereas project managers report on progress. This leads to the so-called ‘chicken and pig syndrome’. ‘Pigs’ are people who are totally committed to the project and accountable for the project’s outcome. ‘Chickens’ consult on the project and are informed about its progress. In this analogy, pigs provide bacon (a sacrificial offering where the pig must die) versus a chicken that provides eggs (non-sacrificial).

A successful project needs both chickens and pigs. However, since pigs have to make sacrifices, such as forgoing work on other projects, they can be difficult to recruit. Constructing a successful Agile team depends upon ensuring the team has sufficient ‘pigs’; and that they are empowered to drive the project in return for their commitment and accountability.

Figure Two

Stakeholders

Project Manager

Sponsor

Gantt Chart Product

SME BA Architect Developer

SME/UAT Tester Developer

HIGH-QUALITY SOLUTIONS Melbourne | Sydney | Canberra | briSbane | HobarT | adelaide | Singapore

Revolution IT - Delivering high-quality solutions for high-performance enterprise.At Revolution IT, we don’t just make software work, we make it perform superbly. From planning through to operations, we use proven methodologies to reduce IT spend, meet aggressive timelines and deliver outstanding application quality. What’s made our name in the industry is our underlying focus on quality. To find out more about how our Agile services can benefit your business, talk to us today on (03) 96002566 or info@revolutionit.com.au or info@revolutionit.com.sg

Agile AptitudesAgile team members need to possess specific behavioural aptitudes that complement their main skill-set. Team members need to possess a “can do” attitude; and they need to quickly adapt and change course as the value stream demands; they need to be resilient to overcome roadblocks; they need to challenge poor processes; they need to be comfortable opening up dialogue with each other; they need to embrace change and be open-minded about the reasons dialogue needs to take place. It’s particularly important to consider these behavioural aptitudes. All too often organisations assume, mistakenly, that people in a traditional team can easily transition into an Agile team.

The best way to demonstrate this is to use SCRUM approach as an example. The Scrum Master, Product Owner and Team are all committed to the project; while stakeholders and management are involved, but not as committed to the project, see figure three.

Product Owner – The Product Owner works with many stakeholders to prioritise and manage the product backlog; they’re the voice of the customer; and ultimately, they’re responsible for the financial success of the product.

Scrum Master – The Scrum Master facilitates resolving blockages and enforcing best practices.

The Cross-Functional Team – Individuals with all the skills needed to deliver a project.

• There are no titles for team members

• Teams self-organise to get things done

• Optimal number of team members is 5-9

• The team are Pigs

• Everyone else is a Chicken

• Chickens cannot tell Pigs how to do their work

The concept of self-organising teams revolves around the “servant-leader”. This concept states that the leader shares the power, puts other team members first, and assists people to develop and perform as highly as possible.

This is in stark contrast to the conventional “pyramid” style of leadership that requires clearly defined tasks and monitoring of execution and results. Decision-making responsibilities rest solely with the executive. In contrast, a participative leadership style involves the team in decision-making. More extensive tasks are delegated and the team’s influence and responsibility increases.

Servant Leadership is closely associated with the participative leadership style. The authoritarian leadership style does not support to the guiding principles of Agile. The highest priority of a servant leader is to encourage, support and enable subordinates to unfold their full potential and abilities.

1 Plato, & Jowett, B. (1941), Plato’s the Republic. New York: The Modern Library

Figure Three

Stakeholders

Interested Committed

The Team

Product Owner

Scrum Master

Backlog