More recently, Scott interviewed me separately to discover what it takes to become an IBM Champion. I hope you enjoy the video as much as I did in making it.

Cheers,
Julian

Quicker and cheaper

Whilst it is an admirable objective to achieve quicker and cheaper results for projects, this should not be the primary objective for greater agility. The key objective should be for IT teams to be more predictable in their delivery, increasing stakeholder confidence and satisfaction, and delivering against business objectives. Most executives would be happy to just get what they are promised, for a change. Driving for cheaper and faster can also result in a reduction of focus on quality, which will of course be costly in the long-term.

Governance rules

Most governance rule sets were designed to provide stakeholders added confidence in the delivery of their solutions by the project teams. However, how they are interpreted has often led to the governance of projects by the production of documentation. Delivering Agile projects in this kind of environment can be very tough, and unless you can return to the principles of the governance rules, being allowed to demonstrate real value as opposed to false effort-spent, your agile project is unlikely to prosper.

Application Maintenance

The total cost of ownership for any system has a very large proportion being spent during its operational life, so the ability to run and maintain a system efficiently is a very important outcome for a project. However, there are dangers when supposedly-agile projects don’t produce any documentation or include the needs of the operational stakeholders that the system will not be efficient to maintain and run. By failing to consider the needs of operational stakeholders early in the life of a project, a perceived project success may turn out to be a costly long-term failure.

IKIWISI (I know it when I see it)

A common issue for any project team is that what the customer said they wanted is not necessarily what they later want or indeed need. IKIWISI (I Know It When I See It) is a factor that unless addressed and utilised throughout a project will put any project at risk. Agile projects should provide continuous insight into progress and regular demonstrations to the customer. If this visibility is lost or the customer is not engaged with the project to “see it”, then the opportunity to know if the right solution is being developed will have been lost.

Prioritisation

To achieve an early ROI for an agile project, the customer needs to be engaged continually in determining the priorities of the project to ensure that this meets the prioritised needs of the business. Without this prioritisation effort, the project will have to start guessing, and make investments to develop solutions that potentially don’t add significant value to the business.

Value versus Risk and Strategy

Whilst agile projects should always remain focussed on the delivery of maximum value to their customers, there has to be a balance maintained against the need for an overall project strategy and the management of project risk. An agile project that maintains a sole focus on value as the customer sees it, may discover that they have overlooked technical risk and a strategic alignment to the customer’s enterprise environment.

Independent Test

There is a growing market for outsourced test services where rigorous testing practices are applied post-development, but whilst it may seem like a cheaper and more rigorous approach to determining quality, the separation of test activity from the development process will have a more costly effect over time. The agile team needs to have a test element to its activity within every iteration of delivery, maintaining quality, and removing the likelihood of major issue discovery late in the project lifecycle.

Command and Control

The legacy of waterfall and a misguided belief in up-front detailed Gantt charts, may cause some in the project organisation to feel they have lost control of an agile project team. This can be particularly true of the project managers (PMs) who have been used to defining every action of the team to deliver a result. There is a place in the agile organisation for the PMs but it’s not telling people how to do their job, it’s about helping remove obstacles and distractions from the team’s path, and ensuring that the customer remains engaged at all times. The old-school PMs will only create inefficiency, frustration and animosity in an agile project.

Skills and Discipline

A long-held myth is that agile projects are full of “hacker” developers, throwing away all processes of the past and exposing the organisation to great risk. However, the reality is that for an agile project to be successful the team does need skills, experience and discipline to do the “right thing” in a responsible manner. Unfortunately, not all organisations have invested in their people in a way that allows them to work in a successfully agile way.

Constant change

One of the benefits of agile delivery is the ability to react to the changing needs of the customer. However, where this can go wrong is when the project team never has any stability in what it is trying to achieve at any point in time. Within any project iteration, the team must be able to focus on a stable set of requirements that have been previously prioritised by the customer.

If needs do change, then priorities for the next iteration can reflect these changing needs up until the start of the next iteration. Without this discipline of change management the delivery team can suffer from change fatigue and their productivity will certainly suffer.

Summary

In essence a “fragile” project environment is typically when an element of what is done is “agile in name only” and activities are performed without discipline and the appropriate level of rigour. However, when applied correctly an agile approach will deliver results and massively reduce the risk of a poor return on investment.

Julian Holmes
UPMentors

Software development project failures can prove very expensive and operationally detrimental for any organisation, often leaving the finance director at a loss as to why the project has failed to deliver its key business objectives. How often do finance directors invest heavily in a software development project, believing they will have the business solution they need, only to be disappointed with the end result?

You only have to look at the recent UK Government reports into their current relationships with IT suppliers, to realise the damaging effect of ploughing money into an IT project which fails to deliver the required business value. Of course, not all software projects result in expensive lawsuits or public outcry, but many can end up causing huge headaches for both IT managers and finance directors which could be prevented by building a greater level of collaboration, the ability to react to business change, and continual demonstrations of “real” progress, to develop a layer of trust between the IT supplier and the business.

This is most typically achieved by contracting with suppliers in a way that both encourages and supports them to deliver using incremental, iterative and agile software development practices.

Failing to build trust with the IT supplier

Building trust between the business and their supplier is vital for any software development project. FDs aren’t expected to have knowledge, expertise or experience in delivering IT projects, and rely on their IT department to manage the relationship to their IT suppliers. However, more often than not the supplier is forced into a fixed-price contract for a project that promises to deliver everything, if not more than, the business needs.

Suppliers also know they only have one shot at obtaining a contract to deliver, and the IT department typically has one opportunity to secure a budget for a system. This typically results in the IT department defining everything that they think a system might ever need to do, asking the supplier for the fixed-price quotation, resulting in a large budget allocated, a contract being secured with one of the cheapest bidders, to deliver a system at some point in the distant future.

As a simple approach it seems to provide a level of control and financial certainty to the business. Unfortunately it typically results in dissatisfaction for the business, a breakdown of trust with the supplier, and a solution that does not reflect the business’s future needs, or worse still, no solution at all.

So how can this happen? This failure tends to stem from a lack of trust, a flawed governance model, a false measure of progress, and a misunderstanding of risk. It’s fair to say that the IT industry does not have the best reputation for successfully delivering projects, whether success is defined as on-time, within budget, or delivering the business value expected of the system. This poor history has led to much of the distrust that exists today.

With such a lack of trust the business adopts a governance approach to oversee the project and keep the supplier honest, typically introducing “gateways” that want to see a measure of progress against governance objectives. Whilst sound in principle, these gateways are often misinterpreted and misused by those performing the governance, leading to measures that adversely encourage poor supplier behaviour, such as a focus on endless documentation, as opposed to demonstrating working solutions. This also results in some very poor risk identification and management, from a mistaken belief that the defined governance approach will ensure success.

Whilst a one-shot procurement model can seem like an attractive option for the FD, providing a defined budget request need with no expected increases, the risks that this can bring to successful delivery are extremely high.

Little consideration is made for how the project will manage the inevitable change of business priorities that the organisation will have during the lifetime of the project. Most likely the strategy of a business and its plans will have moved on and changed during this time, making some parts of any project obsolete.

Plus, by using a fixed price, scope and delivery method, it is impossible for an FD to envisage a return on investment before the end of the project. FDs are often led to think that the project is progressing well from measures of effort against plan. This lack of visible real progress would be highlighted very quickly by asking just one important question – what level of business value return on investment would I get on a project if I had to trim the budget and stop it half-way through?

Relieve pressure on cash flow during project lifecycle

FDs can stop this vicious circle of project failure by encouraging a more progressive funding style relationship with their IT suppliers. Before the project is contractually agreed, FDs should expect to see an agreement from suppliers where they plan to demonstrate a return on investment on a regular basis, or at least for certain stages during the project delivery. If a supplier can show the financial controller of the project some tangible benefits throughout the project, layers of trust gradually build between the two parties and the FD’s confidence in the supplier’s ability will grow as the project develops.

This method also puts FDs in control of the project’s budget and relieves the pressure on cash flow as their finance department shouldn’t need to commit to a large investment, before any of the results have been delivered. Even though there are strong signs that we are coming out of recession, FDs need to remain cautious and ensure that they receive a real value on any investment they make. Taking an agile, iterative approach to their software projects will help them maintain control on their budgets and deliver the objectives set out at the start of the project.

However, there have been instances when people just don’t seem to want to engage or can’t quite understand the significance of what we are discussing. When I dig beneath the surface of their previous experiences and why they feel they are attending the course, I typically discover that there is a common reason for their disengagement; they simply aren’t ready to learn.

For an individual to want to make changes in how they perform, take on challenges or operate their daily activities there needs to be a compelling reason for them to learn how to make the change and to then apply that learning. Traditional thinking tends to be that we provide people with ‘just in time’ education so that they are prepared with the new skills required of the change. However, this tends to fail in ensuring that the skills are learned in a way that allows them to be applied effectively when the time for change arises.

I much prefer to find ways of applying a ‘just too late’ learning approach. This can be achieved in a number of ways and here I will share with you just a few…..

New opportunities – “Things are changing, you have the opportunity to be part of it and reap the benefits.”

This could be seen as the leader’s strategic motivational speech but it doesn’t have to be like that. Being honest within the organisation about what is coming in the industry, how this will mean change, but also new opportunities for people who want to come on the journey, is a great way to help people discover the need to learn. Of course they also need to be given the chance to participate, but those who want to be part of it will really understand why they need to participate in learning too.

Known unknowns – “Find out what you can, answer these questions, tell me what you discovered and question what you don’t understand.”

The above approach to encouraging learning is not for everyone. Instead, some organisations realise a need to develop new skills and their employees find that they are sent on training courses without really knowing why they are there. When that happens, it’s mainly to the extent that they aren’t aware of what it is they don’t know, or how it could add value to them. In this and many other scenarios a ‘research first’ approach to education works well. Don’t make the class sit through your interpretation of what they need to know, let them discover this for themselves. Give them a topic, ask them to find out what it means, why they should care, and have some questions to ask if they don’t quite get it. It makes for a great discussion, with experiences shared and all the learning is driven by the participants.

New challenges – “Welcome to the project, this is what we are expected to deliver and this is how we will deliver it. Any questions?”

As project teams form they can often feel a sense of not knowing how to get started. Sure, someone tells them that they will follow a certain approach using specific techniques, but if that’s even a little new to them it will be tough to get started with confidence. However, if the project can start with a whole team approach to learning using the project as the example to work on, people will see the value of the activity and be left with some progress on the project and a way of working to continue.

Retrospectives – “So, we did well in the last month, but could we have done better?”

This is the most common ‘just too late’ learning moment for iterative and agile teams, but what is most important is that the lessons are also applied to the future of the project. These actions may be a change of working practices for the project which may require additional education, but in this instance there will be a strong appetite to learn from the team who now realise where they need improve.

Summary

In each of the four examples above we are building an awareness of the need to learn. However, to establish the use of the techniques may require an organisational culture change which is rarely easy to achieve. This is because even though an individual chooses to learn because they know they need to change, the organisation around them may not have learned the same lessons and may not be ready or willing to change. To enable this ‘just too late’ learning at an organisational level requires a regular measurement, and a continuous improvement mindset. But that’s another story…

Julian Holmes
UPMentors.com

Scene 1 – The Stakeholder
Establishing that there is a need for the business to invest in a project is just the start of working with the stakeholder. They may think they know what they need, they probably think they know what the solution looks like, but whatever they think they know, they have to work with the project team to make the project a success.
This is where so many projects come unstuck. They assume they can define and clearly communicate their needs to the project team via a document of their perceived notions of what the system shall do: “a bucket of shalls”! This rarely succeeds.
However establishing a Vision and a close working relationship with the stakeholder and their business users will allow the project to start quickly, collaborate with the stakeholders to identify critical needs, and work to quickly deliver a rapid return on investment for the business.
Without this collaboration, wants will quickly turn to assumptions, spec’s into speculations, and a high probability that any invested effort will not deliver what the stakeholder really needed.

Scene 2 – Procurement
Establishing a business need and having stakeholders willing to commit to the project is a good start, but this typically leads to the need to complete funding procedures, whether they be external procurement teams, on internal programme offices.
Those teams want to know what it is they are funding and what they will get for their money. Unfortunately, they typically operate to simplistic assumptions that the business knows the details of what they really need up-front, and that business needs will not change during the life of the project.
Changing their mindset to one of committing only small investments and observing ROI prior to investing further sounds easy. But, when organisations have never had prior opportunity for early ROI before, they expect every project to be protracted and deliver disappointing results late.
The procurement people need to be brave and ask some tough questions of the delivery projects: What if we have to cut funding half-way through the project? Can we look to establish early business revenue help fund the remainder of the project? Can we incrementally fund your project based upon demonstrated results?
Our Agile project manager would be happy to answer these questions.

Scene 3 – Governance and compliance
There are good reasons why organisations set up these governance and compliance teams. Industry regulatory compliance rules need to be adhered to and organisations have been “burnt” so many times by failing, typically waterfall, projects that safety nets were required to protect the business from rogue and dangerous delivery projects.
However, these governance rules can also prevent successful project practices from being used and enforce some of the practices that the governance rules are trying to avoid!
Incremental improvements in delivery success can be achieved by enforcing draconian measures on projects, but to make distinct step-changes in delivery success requires a more significant change: incremental and agile delivery.
Don’t get us wrong, there is nothing wrong with asking a project questions such as: “Can you prove you understand our needs?”, “Can you demonstrate you have a sound solution that will meet those needs?”, “Do you understand the risks involved, and can you demonstrate how you will overcome them?”, “Can you demonstrate that your solution meets the expectations of the stakeholders?”, etc.
However, most typically the governance team have asked for documentation to support the answers to these questions as opposed to concrete evidence that the team is actively delivering results.
Getting back to the objective of any “control point” will typically allow an agile team to establish what measures of valuable progress they are looking for, and provide better measures of real progress than the typical documentary evidence has ever provided.

Scene 4 – Enterprise Architecture
There is a lot of value that any project can gain from working with Enterprise Architecture (EA): understanding the strategic technologies of the organisation; establishing the non-functional and technical requirements of the project; aligning to the other systems of the enterprise; providing feedback on the technical vision of the project; to name just a few.
However, EA should not be looking to define the detail of the solution that the team needs to determine and deliver. They should be like the stakeholder; helping to define needs, validating business value, and collaborating regularly with the team.
In this way, they provide a valuable source of strategic technical governance and alignment to business strategy.
Delivering a big design up-front only leads to speculation and proof by documentation that a technical solution will work. It’s much better to demonstrate an executable architecture, and the EA teams will agree when they start to realise that it’s possible to work that way.

Scene 5 – Development team
Not everything on the project will be technically easy. Many of the things asked of the project team will be new to them. The developers will have different experiences, and the best way to overcome the challenges for the team will be to encourage them to collaborate.
Unfortunately many members of development teams have had careers where they have been encouraged to act as heroes. They have been measured by their individual performance and not by the success of their project team.
When the regular delivery of demonstrable success becomes important, the team needs to recognise this and whenever technical challenges arise, work collaboratively to find a solution. This will be both more efficient and help build a sense of team.
Pairing is one approach to achieving this, but it’s not required all the time, only when anyone on the team finds a challenge and asks for help. Then a member of the team will volunteer their help, for as long as the challenge still remains.

Scene 6 – Deployment
It’s no wonder that deployment teams view development teams with caution. So often they have been on the receiving end of executable solutions that have been rushed into deployment, poorly tested, and not designed to support a production environment effectively. However, if treated as another stakeholder of the project, their needs can easily be catered for, and their fears allayed.
They are also expected to protect the business, and when projects have rarely delivered to expectations, they are very wary of new solutions that are regularly delivered and expect regular deployment.
Engaging the deployment team regularly in the project, allowing them to see successful pre-deployment testing, and demonstrating a successful deployment plan, will help the team to gain the confidence to schedule the Agile team’s regular deployments.

Scene 7 – Stakeholder Acceptance
By the time the Agile project team is ready to deploy a solution that adds value to the business, there should be no surprises for the business about what it is going to get. Their continued involvement as members of the project team or through attending regular demonstrations, should provide them with ample opportunity to ensure that the project is delivering what they need, even if their need change, or they were unsure what they wanted until they saw it for the first time.
However, even in the worst-case scenario of the stakeholders only seeing the solution at thei first point where a basic solution could be deployed, they are still able to change the course of the project far earlier than would be possible in a more traditional lifecycle.

Epilogue
Our brave Project Manager, Luke, did manage to force his Agile project through the organisation, but whilst it was a tough journey, it was worth it. The customer did receive early value and Luke established precedents with many of the other organisational functions.
Over time he will find that the rest of the organisation starts to recognise the value of the Agile delivery approach and barriers will removed or refined to accommodate the delivery of early value.
However, this process will take time, and it will take more than just Luke’s endeavours to make that change.

So, where did this phenomenon come from, why is this such an instinctive reaction, and does it help them?

Waterfall, or the linear software development lifecycle, has been present in the industry for a long time despite software leaders in the past trying many times to discredit the approach, it still remains commonplace for software delivery projects, even if they say they are doing otherwise. The use of iterative and agile practices, which are widely recognised as superior to a waterfall approach, are rarely adopted well. There are a number of reasons for this, so here I will explore a few key examples.

Academic introductions

Unfortunately, the world of academia, the first place so many of our software colleagues learn about how to organise and manage a software project, is still very slow to catch up with iterative and agile practices. So many graduates are arriving in the workplace having been primarily educated using the waterfall model as their primary lifecycle, with only side reference made to these more modern approaches, if they are lucky.

This may be because it is easier to learn and to teach waterfall as opposed to iterative practices. Waterfall can be learnt as a step by step set of instructions, which is how most things are taught. Iterative is much harder to explain if you’re used to explaining or follow a step by step process. However, all hope should not be lost, as some academic subjects do naturally use iterative principles; art for example, setting a context and prototyping with pencil sketches, prior to investing cost and effort with canvas, paints and hours of detail.

Commercial Alignment

I have often heard it said that an iterative or agile approach isn’t feasible because of the constraints imposed upon a project by delivery contracts. It’s true that this is a common issue for software delivery organisations, but these constraints have typically come about from a breakdown of trust between the delivery team and its customer, typically resulting in a scenario such as:

The customer has little confidence in the delivery team and demands that they provide a fixed-price for the delivery of the solution.

In reaction to this fixed-price constraint, the delivery team requests that the customer defines everything they need in detail before a price will be given.

The customer, knowing that this is their one chance to specify what they want or risk severe change control later on, provides the details of everything they might ever want.

The delivery team ties the customer to this specification, unless they pay extra to change it, resulting in a solution that provides functions that are either never used or no-longer need.

This classic waterfall scenario is typically driven by an old-school procurement mindset that wants to know exactly what they are going to get for their money, even if the business can’t say what it is that they will actually need.

Governance Rules

There are many project governance frameworks being used in industry, with most of them seemingly advocating a waterfall approach where the early phases (or service gates) are go/no-go checkpoints when it’s possible to stop a project if problems are discovered. Of course, stopping a doomed project early is good as it saves money. However, the early phases of a waterfall project are usually more paper-based exercises, and not until the latter phases are show-stopping problems discovered, by which point it’s very hard to stop a project because of the investment that’s already been made. This means the ability to stop a project before any code is written is rarely more than theory.

However, many of these governance frameworks are only interpreted as being waterfall-aligned, when in reality they are trying to achieve the same objectives as a more iterative or agile approach. This mistake typically occurs because those people asked to “police” the governance rules don’t understand software development and interpret the objectives as a list of documents that need to be completed and signed-off. This mistake typically forces even well-meaning projects down a high-bureaucracy waterfall approach.

Industrialisation

A common misconception when an organisation tries to maximise efficiency and minimise waste is that turning software delivery into the equivalent of a manufacturing environment will improve the situation. e.g. They see it as analogous to a car plant:  Start with a load of bits, assemble components, assemble bodywork, paint body, assemble car, test car, finished.
However, the mistake is that they see this process as a series of functional steps, a waterfall, forgetting that iterations are time markers. So if we revisit the production line at snapshots in time, one car is having its components assembled, another is having its bodywork painted, another is being tested, etc. At the end of an iteration, a car rolls off the production line and the start is fed with a load of bits. i.e. the production line doesn’t build all the engines at once, paint all the bodywork, test all the cars at the same time…

For software delivery too, the deliverable at the end of each iteration needs to be incrementally different. We are not typically building what has been built before. It’s unique and has to be to justify the investment for the stakeholders. So the activity of a software project has to been seen as more akin to research and development. This takes time, experimentation and repeated iterations to achieve progress over time. A waterfall process assumes everything is known up-front.

Capability Silos

Another unfortunate side-effect of the “industrialisation” mindset is the creation of capability silos. This is where people with similar skill-sets are grouped together to perform specfic roles for project teams. However, this leads to a number of disadvantages for software delivery. The people in each silo become highly specialised in their skills and experiences, unable to perform the generalising specialist role that is capable of stepping to help others whilst knowing how to support the overall team to their best ability. It can also lead to the physical  separation of roles within the project team, resulting in formal document handovers, a non-collaborative work environment, and the tendency to “throw work over the wall” to the next role in the process chain. A perfect breeding ground for a waterfall mindset.

Supporting Tools

It’s not just the organisation that sows waterfall seeds into the fertile minds of software practitioners. Many tools vendors and their training courses, when providing a context to their solutions, often do so by referring to the value added during the “testing phase” for example. They may do so to highlight to the value of their tools to a certain aspect of delivery, but this can result in a mindset that considers the tools to be the solution for a poorly performing project team. Test tools are a classic example, focussing the organisation or project teams on the reactive use of testing tools to identify defects just prior to deployment, as opposed to encouraging project teams to use iterative and agile practices to discover mistakes early and have them fixed at a time when it costs the least.
A focus on power tools supporting only one activity or role, as opposed to collaborative tools encouraging a whole team approach, can certainly cause problems.

Fear of mistakes

And finally, what’s the biggest reason why the waterfall comfort blanket is so common-place? I believe it is fear. Fear of making mistakes, of not having thought of everything before trying to share that knowledge with others, of having to change their minds.

Too often team members are measured by the “completion” of documentation, encouraged to “gold-plate” their work product or knowledge prior to sharing it or having it reviewed. They may achieve beautiful examples of the perfect document or code, but they passed the point of diminishing returns for their efforts far earlier on, a point at which most of the consumers of that information would have had either enough to help them or the ability to provide valuable feedback to the author. This is a principle that applies to every member of team, but when measured by “completion”, waterfall remains in charge.

Summary

So, in summary, whilst it is frustrating to see so many people still clinging tightly to their waterfall comfort blanket, it has to be expected. Many of the messages these people are given, together with the measures of “success” placed upon them, encourage a waterfall mentality.

As an industry, we have a long way to go before we see a thorough decline in waterfall activity. However, if we continue to tackle all of the above challenges, it can be achieved.

Julian Holmes
UPMentors

In a cricket match, “Howzat!” is what the bowling side shouts to the umpire when they believe that the batsman is out.
The article was originally published as “Play Ball!” by Mark Lines in collaboration with Scott W. Ambler and Carson Holmes, and published by the Agile Journal in December 2009.
This cricket interpretation was developed by Julian Holmes over the summer of 2010 for the UK and Commonwealth nations in collaboration with Arun Zachariah.

Overview

We all know that terms such as “iteration”, “project manager”, and “daily stand-up meetings” are extremely difficult for software development professionals to comprehend. To simplify things, we have created a better methodology fashioned after a metaphor from the sport of cricket.

This article explains the fundamental principles of this revolutionary approach, the best methodology ever created because it’s brand-spanking new, named Howzat!.

Some people may refuse to accept Howzat! and take their bat home. They may think that a methodology such as RUP, Scrum, or XP is better, but you need to tell them that their methodology is so 2006.

Team Roles

Here is a list of roles for the project team. We generally don’t need to assign specific roles to individuals, as we don’t want to pressure anyone into having expertise in any particular area. It is more important that we all just get along, or collaborate, and that we have the courage to assume that everything will work out in the long run. Howzat! is a qualisynergistic process, making it far superior to the empirical and prescriptive processes of yesteryear.

Chairman

Every software application must have a majority stakeholder who benefits from the solutions being developed. They are ultimately responsible for the success of the project. In Howzat! we call this role the Chairman. The “Chairman of the board of selectors” controls the funding of the project, approves and may influence the makeup of the Team. The Chairman also is responsible for explaining the suboptimal performance of the team to the other stakeholders or users, known as the Fans. He or she often promises to improve results by spending more money on the project.

Captain

The project team must have a Captain. In Howzat! all team members are contributors, including the Captain. We expect a Captain to be a coder roughly 50% of their time. In the rare situation where a Captain is unable to code to design patterns, they must find another way to be productive, such as monitoring adherence to variable naming standards or ensuring that the code is well commented.

The Captain is not so much a classic project manager, but a “leader”. As such a key function is to keep the team well motivated. An unlimited supply of tea and cucumber sandwiches will be provided. Scones with jam are acceptable alternatives. Occasional hugs and slaps are encouraged, however, check local customs before adopting this approach!

Bowler and Batsman

The Captain relies on key technology experts to assist with decision making. These specialist roles assist the teams in completing their tasks. They provide guidance for every ball bowled in line with a greater team strategy as set by the captain. They also have the freedom to make instant decisions that they feel will be beneficial to the team, however the current score always provides an immediate reflection on the effectiveness of their decisions, which may result in their immediate replacement.

Fielder

Other than the bowler, the remainder of a defending team consists of members known as “Fielders”. All of the Fielders are of equal standing and are self-organised. There is no “I” in “Software Development Team”. However, Fielders are encouraged to sign up for new roles, such as Third Slip and Silly Mid Off. The Captain must never tell the Fielders how to perform their role, as they are in effect free agents in control of their own careers.

Fielders that are also capable as Bowlers and Batsmen, are considered the most valuable members of the team, and are referred to as “All-rounders”. The boldest of Fielders can also apply for the most critical role of continuous integration, the Wicket Keeper.

Umpire

The Umpire’s decision is final, and it’s this decision that determines a team’s real progress. An Umpire is embedded with the team, and provides real-time support and guidance representing the interests of all the Supporters and any competing Chairmen. Without an Umpire the game can descend into chaos as the teams compromise the rules of the game, make decisions in their best interests, and determine progress in accordance with their desire to appear to be winning.

The Match

A project release from initial project inception to termination is known as a Match. Many Matches can be played from the time when the application is initially conceived to when it is eventually retired. The lifetime of the application is known as a Series. In very special circumstances, the lifetime of the application can also be known as “The Ashes” in memory of an application development disaster from the past.

Cricket Scaling Model

A Match can be planned and scheduled in many ways, but is typically defined by the Cricket Scaling Model (CSM).

There are 3 common variants of a Match as defined by the CSM, which in ascending order of size and complexity are:

• Level 1: “Twenty20″ – A short burst of development, normally incremental, providing a significant result at the end of a Series or Tournament.
• Level 2: “1-Day” – A longer development project, that may require a team to perform throughout the day and the night
• Level 3: “Test” – A large and complex development project, requiring greater disciplined, to achieve “Howzat!@Scale”

Inning

The duration of a Match, is split up into a number of periods (the number depends on the CSM) of variable length, each of which called an Innings. The closest concept in RUP is a Phase, but Scrum never really had this concept – with the exception of some forward thinking individuals who insisted that Sprint 0 was different to all other sprints.

Over

Each Inning is broken down into a number of short, identical periods, each called an Over. During each Over, a small number of high-priority requirements are selected to develop (User Fairy Tales). These Fairy Tales are a few lines of text. No more documentation is required as any extra requirements that the users wish to document will be wrong and unrealistic to actually implement. Besides, the details of these requirements are obvious to talented software developers that use the Howzat! methodology.

Use Cases and User Stories are clearly less versatile than User Fairy Tales, as so much more information can be expressed once Magic is involved (a complex requirement easily expressed in Fairy Tales, but completely unbelievable in the land of logic).

At the start of an Over, the relevant team members will congregate and discuss the tactics to be employed. In all cases, this meeting is held standing up in the field of play. Prior to each ball being bowled, the Bowler typically performs some last minute grooming and polishing of the Ball.

The Fans (stakeholders such as end users, senior management, operations staff, and so on) are invited to attend and observe these daily stand-ups. Fans may tend to exhibit unsportsmanlike behavior by expressing their opinions vocally during this meeting. However, under no circumstances must the Team pay attention to the Fans’ comments. The rationale for this is that while the Fans are “involved” in the Team’s performance, they are not “committed” to the outcome.

Team Bonding (Collaboration)

Constant collaboration between the team members maximises productivity and reduces miscommunication. This Team Bonding is also known as co-location. It reduces the need for excess documentation and prevents delays in decision making from using traditional communication mechanisms such as e-mail. Accordingly, the Team will typically socialise in a “work-area” called the Clubhouse, but alternate venues include Bars and Clubs.

Entertainment Value (Scope Management)

Regarding scope, a team should not make promises to the Fans, especially when the Fans rarely make up their own minds about team strategy. More important is to deliver the functionality of high business value prior to the funds running dry. It is also very important that a team sets no expectations for the Fans before The Game, merely telling them to pay the “Ticket Price” (project funding) up front and promising to deliver an entertaining experience.

Game Play

Fairy Tales are decomposed into tasks to be delivered during an Over. Each task or work item is referred to as a Ball. Requirements can be categorized as of good line (functional), good length (non-functional), no-balls (change requests), or wides (defects). When a team led by the Bowler achieves significant success in the delivery of Fairy Tales, he is said to have bowled a Maiden over. However, there is no role for a Prince Charming.

Under no circumstances can the Balls be changed during the Over, even if it is realised that they are incorrect. Focus for the Team is very important. If the wrong balls are deliver in an Over, they will be changed and redelivered in the next Over.

Delivering too many Balls in an Over can result in the burnout of the team. It’s not recommended that the team works too much overtime. This has been referred to in the past as maintaining a “sustainable pace”. In Howzat! it’s called managing the “Extras”.

If it is discovered that the Bowler (often referred to as the Architect) has been delivering a poor performance, for example too many slow-pace balls being hit-for-six, this is clearly unsatisfactory performance and the Fans are justifiably dissatisfied that their system performance requirements are not being met. However, at any time in the Inning, we can send the Bowler to the showers (discussed below) and bring in a new Bowler to find a better way to deliver the Overs. This was previously referred to as major architectural refactoring. The trick is to find a new Bowler to deliver the pace ball that the newly understood architecture requires. Unfortunately restarting The Game at this point is not an option.

Managing the Game (Monitor and Control)

The Umpires make all decisions of to do with the measurement of progress during a game. They make all the decisions as to the success of Balls delivered in an over, especially in the case of when either a Batsman successfully adds a run to the team score (done) or has been deemed to be out (not done).

The team captain will facilitate the team’s overall approach, but each team member also takes responsibility for their performance and techniques.

The end of an Inning is an ideal opportunity to determine if a change to project team is required. Team members that are not good performers may be replaced by those waiting in the clubhouse. Umpires may also suggest the removal of team members from the game for unacceptable behaviour or performance. This typically follows intense discussions face-to-face.

Metrics

A team’s progress is determined by their current score in comparison to their target score (burn-down) and their current run-rate (velocity) provides a strong indication of whether they will achieve their target within the remaining overs.

Additional team-member metrics are also available. The Batsmen have a Strike Rate and Bowlers a Bowling Averages, both of which are similar to a team’s velocity, but provide all the stakeholders and fans with an insight into their team member’s individual performance.

In the spirit of openness and to ensure that everyone involved in the game understands the true measure of progress, all the current scores and metrics are displayed on a score-board. However, depending on the size of the match, and in accordance with the CSM, the available detailed metrics will vary and may be provided through the use of collaborative and knowledge management tools (TV, radio and internet).

Certification

Unless you are a member of the International Process Laureate (IPL) you can’t possibly learn Howzat! on your own. To ensure that you are properly trained and ready for the “Premier League”, we offer Howzat! Certification. Attend one of our “Summer Camp” Seminars, to become a Certified Howzat! Master (CHuM). Beware of imitations. All of our instructors are endorsed by the Howzat! League Commissioner Julian Holmes, and have been trained by the Howzat! Chief Trainer Arun Zachariah.

Certification Seminars are conducted at major centres around the world, in a lecture format. The 2 day seminars are available for £2,000. Seating is limited to 50 Rookies. Cheap Seats are available for £500 whereby we send you a DVD and a certificate. Executive boxes are also available, where unlimited energy drinks are served by ex-OOPSLA booth babes. Additionally Julian will sign books, if bought in quantities of 20 or more (2 signings per order, £100 for each additional).

No actual experience is necessary for certification, nor any testing performed to ensure that you paid attention during the two days of training – the fact that you’re willing to pay for certification is testament enough to your ability. Credit card orders will speed up the printing of your certificate. I am sure that you understand that having our certification instantly increases your batting average on your resume, and increases your chances of being “picked” by the selection committees.

Sign up today so that you too can send a ball into the covers!

For more information, or to sign up for our next Summer Camp session, contact Julian@UPMentors.com

Fine print: Season ticket renewals are required to maintain your certification.

Summary

Seriously though, software development is not a game. As professionals we should not fall for “consultantware” proprietary processes that merely re-state existing ideas. We should be wary of certification scams that designate us as a “Master” with no knowledge testing or experience reviews. The days of revolutionary “brand new” processes are long gone. It does not make sense to turn entire methods upside down in the interest of a few new ideas. No methodology is a silver bullet. A more sensible approach is to incrementally adopt bite-sized chunks of process, known as “practices”. These practices can be swapped in and out of your existing delivery processes as new ideas evolve, according to what is appropriate for your organisation or project.

About the Howzat! Thought Leaders

Julian Holmes is a Co-founder of UPMentors. Like Mark Lines, the original author of “Play Ball!”, he has spent far too much time in the last few years discussing the merits of one methodology versus another. However he has recently been encouraged by efforts within the industry to break down methodology barriers and to find commonality in the sensible adoption of disciplined Agile practices for large-scale and complex software project delivery.

Julian thanks Mark Lines, Scott W Ambler, Carson Holmes, and Arun Zachariah for their input on this article.

It’s really disappointing to see the fall in students opting for a career in IT (A-level results highlight UK’s IT skills gap). High-end IT employers, especially systems integrators, are really struggling to find both graduates with the skills they want, and “experienced” hires who have the education and skills required.

Employers still want graduates, but those with the right IT qualifications are increasingly hard to find, highlighting the current lack of desire and enthusiasm to take those degrees. Demand will eventually help build supply, but whilst IT budgets are being cut and salaries are being held down, the profession will remain low in the aspirations of bright and capable young people searching for a career path via the appropriate degrees.

We have a long way to go for the industry as a whole to get the deserved respect, reward and pull-through required from the student population.

Julian Holmes
UPMentors

Whenever I have heard any manager address a project team and tell them to “Just do it”, I know that it’s unlikely to be a successful endeavour, and it almost certainly won’t be Agile.

When said by the manager, “Just do it” typically means:
- the team is told the scope of what they must deliver and by when
- the manager is not working with, or listening to, the team
- the team is given a detailed and overly-optimistic plan
- the customer is not engaged with the team
- the team members work in isolation to only deliver their tasks
- and the manager measures daily progress by the effort spent

This is obviously going to result in some bad team behaviours and poor results where:
- the team abandons a disciplined approach and starts hacking
- the team no longer takes ownership for the solution
- the team’s morale is lost and productivity drops
- reduced collaboration results in poor communication
- individuals blindly follow a given plan
- and the manager is surprised at the end of the planning period when the “team” fails

So please, don’t encourage your software project teams, or let yourself be told, to “Just do it”.
Get smart and “get” Agile.