Agile methods are of clear benefit while our projects are small enough to be delivered by a single small team responsible for the full life-cycle and incorporating all of the various necessary specialisms. As the project size increases we will eventually reach a state where we face a challenge since the team size becomes increasingly difficult to manage and we seek to provide internal structure through sub-teams. At this point we will typically need to establish the axis along which the team is split.

Option 1: Component orientation
In a large systems it is common to find developers who align themselves to components. This presents a simple option of splitting the team along component lines. By doing this we create a need to split user-centric features into component features and subsequently re-combine and verify the end-to-end behaviour.

In this way we have benefited from natural affinity of developers to components at the cost of lead time. The benefits of this approach will depend on the degree of specialisation and the degree to which specialisation aligns with co-location; this ownership of components by location is common in large systems development organisations. A further drawback, however, is the balance of features to components, it is not uncommon to see feature prioritisation determined by availability of component teams in preference to value, increasing the degree of generalisation increases a teams flexibility to build the next most valuable feature independent of the impacted software component.

Option 2: Discipline
By splitting a team by discipline we risk longer lead times and can easily risk further engraining waterfall like thinking such as stove-piping the organisation with a “throw over the wall” attitude.

However, all is not lost. Kanban systems have been shown to offer a model that recognises the existing flow of work while encouraging innovation to reduce lead time of features. Kanban systems have also been used successfully with teams of up to 50 people, considerably larger than the norm for Scrum or XP teams.

Option 3: Location
Co-location is known to be a strong influencer of team effectiveness. With this in mind it would be naive to ignore location in a discussion of team forming. A co-located team would be expected to out-perform a dispersed team where all other aspects are equal. However, dispersed teams can be used to good effect in order to leverage benefits of feature teams. In this situation we should learn the lessons of those who have successfully built effective dispersed and distributed teams.

Option 4: Feature
The preferred model for team structuring in most Agile methods is to orient teams around delivery of customer valued features. This model encourages increasing levels of generalisation according to the profile of the features being delivered by the team. While integration issues can still arise with feature teams the use of continuous integration will mitigate risks while feature selection can help to limit interaction between teams. Where the project size is very large or the problem domain very complex it is possible to orient feature teams around areas of the problem domain. This is what Craig Larman terms Requirement Areas. By allocating teams to requirement areas we support the team in developing their understanding of the problem space investing in specialisation on that axis in preference to specialising in a discipline or component.

Choosing and Blending
In practice we will typically mix these models in a large multi-location team combining the benefits of co-location, feature orientation and component specialisation while trying to manage the limitations of each. By way of a practical example consider an embedded system distributed across the globe. We may choose to recognise the specialisation of the team that develops the low level board support packages; this team delivers low-level facilities to feature teams. We lean towards feature teams for the majority of user-feature development. However, for high volatility or high risk features we might choose to have co-located feature teams in the vicinity of our key customer groups. This focuses the agility of co-located teams where it adds the most value.

I feel enthused to blog about my current project, which is the first project I’ve ran where we have a dedicated UX expert on the team. For those of you who are not aware of the term UX, it stands for User eXperience. The UX expert will work closely with the customer and business analysts, defining user journeys throughout the site/system, producing the wireframes that feed into the designs and ultimately the UI development.

Consciously or even sub consciously we all appreciate a website with a good UX and can get really frustrated by poor UX.

While this is the first time I have had a specific UX expert in my delivery team, I have been aware of other Valtech projects delivering UX, over the last couple of years, particularly in the the Agency space for our large retail clients.

Now I wasn’t exactly sceptical, but didn’t fully appreciate just what the UX role entailed and what it could bring to the project. I will be honest and admit to being slightly derogatory about what a UX consultant could offer, and I may have possibly labelled it as ‘colouring in’. My bad

My ignorance was however, strongly influenced by the types of projects I had previously delivered. A lot of my previous experience has been delivering large government systems, where the kudos was always focused on the back-end technologies and not the front-end. Also a good user experience was never a non functional requirement.

The UI design and UX for these large government CMS systems is on the whole quite poor, overly complex and unintuitive. In some instances we may have worked with graphic designers, but most of the time the UI was being designed the customers Business Analysts, where only basic principles of a quickly outdated style guide are to be adhered to. On more than one instance, I was running a dev team which inherited reams of up front, waterfall, external design documents. These had been created using Visio and MSPaint, which led to the designing of near impossible components and cross-field validation. Chaos would generally ensue in System test and UAT when the final screens didn’t look exactly like the signed off Visio and MS Paint designs.

On my current project, the UX expert has made an instant impact. Working with the lead BA, it was obvious that the business owner was engaged and bought in to this way of working. High quality interactive wireframes, are produced in Photoshop with key animation sequences overlaid in PowerPoint. Great care is taken understanding different personas and minimum marketable features. The customer gets near instant feedback of how they want the site to be used.

I sort of expected the benefits that the UX expert would bring to the analysis and design, what I didn’t predict was how important the UX expert has become to the developers. Collaboration between the UX and devs was really visible from the outset and was recognised as one of the most significant positives at our recent retrospective. Key to this success was the way the UX expert researches the technology options, ensuring the design can be achieved using CSS or identifying the necessary JQuery plugin. Non standard design choices are always reviewed with the development team prior to sprit planning to ensure no near impossible designs are agreed with the customer.

Our Agile processes enable this collaborative way of working. We are all collocated provide our updates at a single, large but efficient daily stand up meeting. The devs and UX expert are seeing each others updates, progress and blockers. The BA / UX team are working one or two sprints ahead of the developers, so no design artefacts are going stale in the backlog. We have also ensured that a UX peer review is part of the definition of done policy for the front end developers.

This way of working culminated in a really positive first demo, with great feedback from the business owner and sales director.

Is software engineering the best approach for developing software? Does it apply for the majority of the software projects or just a very few of them?

Software Engineering was an answer for the perceived “software crisis“, back in 1968, in the First NATO Software Engineering Conference and it was created to solve the problems of extremely large NATO and U.S. Department of Defence projects. In the majority of these projects, the hardware was still being designed and with no hardware to test, there was plenty of time to investigate requirements and write the software specifications. Hardware controlled by the software was generally worth billions of dollars like in the case of space shuttle and the Safeguard Ballistic Missile Defence System. People’s lives and national security were also at stake.

The IEEE Computer Society‘s Software Engineering Body of Knowledge defines “software engineering” as:

Software engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software, and the study of these approaches; that is, the application of engineering to software.

Software Engineering can be very effective when developing safety critical systems like the one for the space shuttle as described on “They Write The Right Stuff” – Fast Company article, from 1996:

The last three versions of the program – each 420,000 lines long – had just one error each. The last 11 versions of this software had a total of 17 errors. Commercial programs of equivalent complexity would have 5,000 errors.

Of course that this looks really impressive but there is more to it:

Money is not the critical constraint: The group’s $35 million per year budget is a trivial slice of the NASA pie, but on a dollars-per-line basis, it makes the group among the nation’s most expensive software organizations.

Another extract from this same article when they were discussing the process:

And the culture is equally intolerant of creativity, the individual coding flourishes and styles that are the signature of the all-night software world. “People ask, doesn’t this process stifle creativity? You have to do exactly what the manual says, and you’ve got someone looking over your shoulder,” says Ted Keller (senior technical manager). “The answer is, yes, the process does stifle creativity.”

Many of the NATO and US Department of Defence projects took years, some over a decade to complete. Many had hundreds of people involved and almost half of the time was spend in requirements and design specifications, with uncountable reviews and approval cycles. Of course, due to their reliability and quality, many are still in use today.

Software Engineering for the Masses

More and more hardware became cheap and business of all sizes needed software in order to survive and be competitive. The difference was that a the big majority of these businesses couldn’t afford to pay $35 million dollars per year and neither wait for too many years to start benefiting from their software. Also, many of those software projects were not manipulating expensive hardware or dealing with life-threatening situations. Edward Yourdon, in his book Rise and Resurrection of the American Programmer, wrote:

I’m going to deliver a system to you in six months that will have 5,000 bugs in it – and you’re going to be very happy!

It was clear that software engineering processes had to be adapted in order to satisfy a more impatient and lower budget legion of businesses.

The “Good Enough Software” Era

Over the decades, many new software engineering processes and methodologies were created in order to make software development faster and cheaper. The most adopted were the ones based on iterative and incremental development that evolved into agile software development.

Agile software development and “good enough software” were an amazing improvement in bringing costs down, mitigating risks with quicker feedback and much faster time to market.

Regardless the methodology or process used, software projects are still failing. Some fail because they go over-budget, others because they are not delivered on time, others fail to satisfy the requirements and business goals, et al.

The main problem is that for decades, software development was seen as a production line. That’s the software engineering perspective of software development. Processes and methodologies are generally much more focused on making this production line more productive, creating different management and organisational styles than actually trying to make the employees more capable. Developers are treated as mere brain-damaged programmers and are at the bottom of the food chain.

Good enough is not always good enough

Using agile, lean or any methodology is not enough. It is all about the people involved in the project and their willingness to succeed and be proud of what they produce. If developers are seen as the least important and cheapest members of a software project, the maximum that this team is going to produce is mediocre software, regardless of methodology.

A software project would have much better chances to succeed with “good people with a bad process” than “mediocre people with a good process”. Good people would always find a way to improve the process, be productive and produce something that they are proud of. Mediocre people accepts whatever is established, even when it is not good enough, and will produce just what they were asked for.

In a software project, if a company wants a good software, they will need good and empowered software developers. Instead of 10 mediocre people with a good process, it would be better to have 3 or 4 good people and empower them to deliver the project.

A process, imposed by managers and people that have no clue how to write software, will just guarantee that mediocre software is predictably delivered (if lucky). On the other hand, a team of self-organised and great developers would have a better shot at creating a more efficient way to produce great software, constantly trying to improve they way they work.

A process should never be more important than the people. Managers should facilitate the work of great software developers and not tell them what to do. It should always be harder to replace a good software developer than a manager since they are the ones that know the system inside-out. Managing a few well motivated, well paid and good professionals is always easier than managing many mediocre people.

Software development is a creative and highly skilled profession that takes years to master. While software development is treated like a production line, projects will continue to fail.

Software Craftsmanship: The New Imperative – ISBN 0-201-73386-2, 2002
http://en.wikipedia.org/wiki/Software_engineering
http://en.wikipedia.org/wiki/Software_crisis
IEEE Standard Computer Dictionary, ISBN 1-55937-079-3, IEEE 1990
“They Write The Right Stuff”, Fast Company, http://www.fastcompany.com/magazine/06/writestuff.html
Safeguard Program: http://en.wikipedia.org/wiki/Safeguard_Program
Stephenson, W. E. “An analysis of the resources used in the SAFEGUARD system software development”
Edward Yourdon  – http://yourdon.com/about/
http://en.wikipedia.org/wiki/Iterative_and_incremental_development
http://en.wikipedia.org/wiki/Agile_software_development

Agile practice irrespective of flavour (Scrum Kanban XP …)can often be reduced to:

• Work in small batches
• Deliver often
• Build the most valuable chunk first

And it’s the “value” bit that can get us in trouble.

How do we determine which is the most valuable bit? Particularly early on in a project we need to be careful about how we prioritise. Do we just get a bunch of business folk to fight for their favourite features or do we have some hard won lessons to apply from many years of technology project management?

One of the first projects I was responsible for was fixed scope and fixed price. The customer was documenting requirements to be handed into the “agile” development team who built and tested software prior to a traditional system test cycle. Not very agile!

However, we benefitted greatly from the rhythm or scrum, the rigour of agile engineering practice and the predictability the the planning and tracking approach provided.

Most significantly, by taking the Product Owner role I was able to prioritise according to my own definition of value. Put yourself in my seat, you work for a software consultancy, it’s your first project and it is fixed everything, what makes one feature more valuable than another? The answer is risk. When everything is fixed value is in the reduction of risk. In fact I combined prioritisation according to risk with other engineering considerations such as profile of the work to bring the project to a successful conclusion.

So what about other interpretations of value? I’ve been helping a client with a project initiation over the past couple of weeks and found myself using the word uncertainty a great deal. It seems that driving out uncertainty held a great deal of value in that context. In fact, when kicking of a project we look for information generation first, then seek to identify key risk areas and mitigation strategies such as finding new stakeholders or driving out technical risk with proof of concept work.

Uncertainty isn’t new; I often use the “cone of uncertainty” model to express the value of reducing uncertainty. As wikipedia will tell you, this model is primarily concerned with project estimation. At the beginning of a project, skilled estimators may have a factor of 4 error in either direction. Over time error should rapidly reduce as information arrives and the project progresses. This dynamic is known as the Cone of Uncertainty and is the inner line on the graph.

The outer line is the cloud of uncertainty. This is what could happen if uncertainty is not driven out of the project. Right to near the end of the project there is significant error in estimating the size due to missing information.

When we execute agile projects lets not forget the value of driving out uncertainty. This isn’t an excuse to analyse everything to death. Our goal is to recognise where the uncertainty that matters is hiding. Those innocuous features that come along and prove the architecture is flawed are a prime example. We must do enough to understand the risk we are carrying while being sensitive to the cost of gathering detailed information pertaining to speculative requirements.

Technorati Tags: cone of uncertainty

I walked past two teams doing their daily SCRUM standup today. Both teams claim to be agile. I didn’t join in (even as a chicken) but just observed for a minute or so.

The first team was sitting down in a breakout area. Their body language spoke volumes. There was not one single participant maintaining eye contact with anybody else. Two people were playing on their phones. One developer had his head in his hands. Most had bored expressions. The team leader who is also the SCRUM master was the only person who spoke for the entire time I watched.

The second team was stood in a space near their desks. They were gathered round a task board which appeared to be up to date and the focus of several of the individual’s updates. One person spoke at a time. Almost everybody appeared to be paying attention to whomever was speaking. Most updates were short and concise. A couple rambled on.

Other than both teams calling their meeting a SCRUM I could see no similarities.

As our agile adoption has spread beyond the original teams I suppose it is inevitable that as the experience gets spread a little thinner that people will simply label their existing activities with agile sounding names. Often we have no clear remit in those teams to supply a mentor and to try offer advice would result in rebuttal as team leaders guard their territory. Does this matter? Is there a risk that these teams who are not practicing agile correctly will diminish and discredit agile in the eyes of our programme managers? This is sounding a bit like an excuse for an Agile Inquisition going round checking that no team is using Agile’s name in vain. This cannot be a good thing either.

Jira from Atlassian is a very popular issue tracking software and can be quite effectively used for Agile Project Management. Jira has a plugin (Green Hopper) that allows for creation of a backlog, iterations and tasks. However, with help from the free Mylyn plugin for Eclipse I was able to setup a Product Backlog and Iteration Backlogs.

For the User Stories in the product backlog I created two issue types (Epic & User Story). Story hierarchies can be represented using Jira Links.

For Iteration Backlog I created a version for each iteration and assigned the stories to that version/iteration. Each leaf story can then have Jira Sub-tasks to represent the tasks in a particular iteration. The Resolved state of the story is used to mark it complete and Colsed state is used to mark it as “accepted”. You can use Mylyn to see story hierarchies, also I found Mylyn to be a much more intuitive interface when working on Product and Iteration backlogs.

By Mashooq Badar.

Neal Ford’s presentation on emerging architecture contained a reference to the controversial Intel practice in the 1990s regarding the 386-SX math co-pro. Intel were producing two variants of the 386 chip at the time:

• The 386-DX which featured a math co-processor on board which allowed faster execution of floating point maths required in financial applications, graphics packages etc..
• The 386-SX which was cheaper but did not feature the math co-processor and therefore was less ‘powerful’. It had enough to differentiate itself from the previous generation of 286 chips but was regarded as distinctly inferior to its more expensive sibling.

This all sounded fair enough until it became public that the 386-DX and 386-SX shared the same manufacturing process including the construction of the maths co-processor. Where the process differed was that at some point the math copro in the SX chip was destroyed via some mechanical process. Suddenly the perception of the SX went from a lower spec product to a broken product. In Neal Ford’s presentation he described the whole process as Intel selling customers their trash, like the SX was a defective unit being offloaded to unsuspecting users as a working chip.

At a very low technical level Neal’s statement is true but not at a commercial or practical level. Intel engineers were given a change in requirements by their marketing department: Produce a chip that is going to enter the budget market to complement but not fully compete against the 386-DX. They looked at their system and determined the most efficient way to achieve this end was to ‘re-configure’ existing 386-DX chips. This was likely much much cheaper than setting up a whole new production line and testing the brand new chip it produced. To do otherwise would be against the pragmatic engineering ideals that Agile is supposed to champion. If you flip the argument around and say: Should we redesign from scratch the entire process to achieve the same end result but at much higher cost just so that we claim that the chip contains no parts that it doesn’t need. Maybe we find this so objectionable because a chip is a tangible entity and we are used to associating (rightly or wrongly) the cost of raw materials and manufacturing with the value of such items. Maybe we don’t factor in the cost of design and marketing, which I suspect are massive for a complex, consumer electronic product like a cutting edge CPU.

This pattern raised its head again, but with less fuss, a couple of years ago when HP shipped high end servers with multiple CPUs. Some of the CPUs were disabled upon delivery. If the customer’s processing requirements increased over time (which they always do) then they could pay HP who could then remotely enable the additional processors without the customer incurring the cost of an engineer on site, downtime for installation etc. etc.. Again, this early step towards todays processing on demand cloud computing concept raised some eyebrows. Why should customer’s pay for something that was going to cost the supplier nothing? Again, this is a preoccupation with the physical entity of the manufactured component. If the additional CPUs had been sitting idle in a HP server farm rather than at the customer’s site and purchasing them involved work being sent across the network my suspicion is that nobody would have had any objections.

We use a UML design tool at my current client site called Visual Paradigm. It has a number of editions, each with a different cost. It has a very flexible license purchase system which we have taken advantage of. We have a large number of standard level licenses because the features that this edition gives will support most of our users most of the time. Occasionally we need some of the features from a more expensive edition. Its not that only one or two individuals require these features, we all need them, just very occasionally. The Visual Paradigm license model supports this beautifully. We have a couple of higher edition licenses. On the rare occasion that users need the extra features they just start the program in the higher edition mode. As long as no other users connected to our license are using the higher edition at that time, there is no issue. The similarity with the examples above is that there is only one installation. We don’t need to install a different program binary every time we switch edition. We love this as it makes life easy. I am sure Visual Paradigm like it as well as it simplifies their build and download process.

Two me the two scenarios, software and hardware appear pretty much identical. Everybody appreciates that the cost of creating a copy of piece of software is so close to zero that it is not worth worrying about. Therefore we don’t mind when a supplier gives us a product with bits disabled until we make a payment and get a magic key. It’s harder to think of hardware in the same way, that the build cost doesn’t matter. That there might be no difference in manufacturing costs for two products with very different customer prices. The cost of delivering the product, like delivering software, includes massive costs which have nothing to with creation of the physical artifact.

Maybe this wasn’t the point in the above presentation but I guess the thing that startled me was that my natural inclination was to immediately associate the value with the tangible item. In my head this is all getting mixed up with free (as in speech) software and the idea that it is unproductive and unethical to patent / own / charge for ideas.

There has been some renewed discussion recently on the subject of technical debt, this has been played out on twitter as well as a variety of blog posts including this one.

The technical debt metaphor is one I use often and I believe that there is some clarification required around this subject.

At it’s broadest, technical debt is any trait of the current system that is considered sub optimal from a technical perspective. The debt aspect reflects the cost of ownership of that trait. For example and overly complex and untidy method is sub optimal, it incurs cost each time it needs to be re-visited and re-understood due to either a defect in the logic or a new requirement. This method obviously incurs more cost if it is re-visited more often.

Much of the debate recently has been focused on the times that it might be good to incur technical debt. The debt metaphor reminds us of borrowing money from the bank to get that new toy a little sooner. The question here is two fold, does technical borrowing exists and how can we view the rate of interest or total cost.

Before we can consider technical borrowing we need to split technical debt into two categories. First, the design or implementation decision that was sound the day it was made but now, with new information, is constraining our ability to progress. Second, the quick and dirty approach that we can see on the day of writing is gong to cost us very soon.

The first category of debt is a direct result of doing the simplest thing that could work and resisting the temptation to predict the future. We develop simple software that is easily changed through effective use of tests, the code that is written is written well. We categorise these design traits as debt when new information presents its self and we identify a change that will enable the system to serve us better. We may decide to make the change or not based on the ongoing cost of maintaining an design that no longer reflects our understanding of the problem or technology.

The second category is often the result of a deadline looming. A common chorus of “lets hack this in now and we’ll fix it later” is coupled with the nagging concern that later never arrives. In my mind, this category of debt can give the first category a bad name. But, is this thinking sound? Surely there are times when the wrong technical solution is the right business decision. It is my belief that there are situations where a quick fix is the right decision, imagine a major flaw that brings down a trading system. However, there are too many instances where code bases become un-maintainable through a feeling of time pressure that leads developers to incur debt with little or no benefit. In fact, in most cases, untidy, poorly designed software incurs cost both short and long term. In the short term, defects delay the release of the software and in the long term software is difficult to maintain and rigid in the face of changing business need.

So we arrive at technical borrowing. The decision to borrow must be explicit. As a team, along with appropriate stake-holders consider the decision. For example,

we have selected framework X for the next release, it does not offer the scaling flexibility we would like but we believe that our early entry to the market is a higher priority. We plan to move to framework Y in the next release window to achieve our target scaleability.

There are less extreme examples of refactorings that should be done but won’t fit in this iteration. Again, be explicit. Discuss the need for refactoring with your Product Owner or Project Manager, consider the cost of the refactoring, the cost incurred by not doing so, the risk of refactoring. One approach to maintaining a healthy code base is to keep a backlog of refactoring and allocate time in each iteration.

However, beware the temptation to save time, get it done, do a quick fix or tidy it up later. In almost all cases code that is hurried, poorly designed, overly complex or untidy will incur far more cost both short and long term than the time saved today by not doing it right.

Finally, this can be most difficult in a legacy code base where technical debt abounds. I use a simple motto that has served me well with a few teams:

Do no harm!

Where you cannot fix it all be sure to agree, as a team, that you won’t make it worse. In fact agree to making one small aspect of everything you touch better for the next person.