I recently attended one of those business networking events, which predominate focus was for professionals working within Agile Software Development, the room was full of Agile Coaches, Agile Project Managers, Project leaders and a sprinkling of basement dwelling software developers. Typically what I would call “my people”, or so I thought.
I have spent long enough in Software Development, to realize that when I am in a social situation, and asked what I do for living and respond with “I’m a computer programmer” , that the conversation either quickly turns to sport or a question as to why some computing device is not functioning correctly. It is just merely one of the social hazards or working in what many perceive to be a propeller head industry.
I wasn’t expecting the sound of crickets in the room, when as is customary at business networking groups, that you stand up and briefly introduce yourself and what you do for a living. When it was my turn I dutifully stood up and declared with my customary flair and gusto “I’m Gary Woodfine and I’m aSoftware Life Cycle Integration Solutions Consultant”
It quickly became apparent, that nobody in the room had the slightest idea of what that meant. Even though, they spend large parts of their working days, experiencing some of the issues me and my colleagues at Tasktop Technologies , endeavour to overcome.
During discussions with folks at the interval, it became even clearer that, these people actually really need to know that we exist, and that their organisations are already dealing with the problems that we work hard everyday to solve.
Software Development is not just about Code
There is a mistaken belief that in order to produce great software, an organisation requires:
- requires engineers to write good code
- Staff your team with “Rock Star Coders”
- Keep you Developers stocked with Caffeine
- Your team should consist of sleep deprived code generating humanoids
The truth is that probably none of these really play the pivotal role in your engineering effort, they are merely just distractions. The 4 elements a great software team requires :
Software Development as a Team Sport
Software development is very much a team sport, requiring people with a broad range of people with specialist tools, skills, abilities , aptitudes and disciplines. Their collective effort results in either functional software or just one giant mesh of binary spaghetti.
How functional software teams avoid producing waste primarily comes down to how well they communicate. The art of software development is the effective communication. This communication does not necessarily mean “15 Minute Stand Ups”, although that is a 1 of very many methods teams can choose to communicate, it is not the only method, and in many instances it is not necessarily the most effective.
Over the years many agile coaches and experts have made many proclamations of the virtues of the hallowed 15 minute stand up and it is usually the first component of agile methodology that is introduced to many new teams to scrum or agile. The fact is, it’s also probably the one that is most often misunderstood and implemented incorrectly.
Agile at scale
One of the biggest challenges when it comes to implementing Agile methodologies is, how do you do it effectively at scale ? If we take the humble stand up for instance, this may work great when you’re a small software start up, operating out of a neighbourhood garage in downtown San Jose, but how do you implement it, when you’re a large multi national organisation with team members based across many geographical locations and timezones ? How do you ensure that your Quality Assurance team have the right information they need and more importantly how do they effectively communicate the status of bugs and issues correctly with the development team?
One of the very many approaches teams take to solving the communication challenge is to implement systems. For example the developers may implement an issue tracker systems like atlassian Jira to keep track of all their Epic, User Stories and Tasks, while the quality assurance teams may prefer to opt for HP ALM, to handle all their Defects, Test Cases, Test Runs . The product management team may want to keep track of Features, Epics and Ideas making use of Target Process, while the business analysts are really comfortable writing and managing requirements in IBM Doors.
It doesn’t take long before even the most humble organisation will end up with at least 5 different tools all doing similar jobs, but all with very different processes, workflows and features focused for particular areas of speciality. This approach inevitably results in your Software Architecture Life Cycle Management systems comprising of a potpourri of life cycle management systems.
The challenge for many organisations is how to ensure they can successfully ensure the flow of data between these systems, a process which is commonly known as Software Life Cycle Integration . The reason why this is so important is to overcome the dangers of organisation information silos.
What do Work Silos look like ?
If you find your colleagues primarily communicate in emails, private chat sessions or slack, documents are ensconced in complicated file structures on hard drives, work maybe stored in private cloud accounts and never become of the corporate fabric. Sometimes you can only access some information via being granted formal permission through a centralized IT department or by the “doughnut bribery”.
Then these are sure fire signals that your organisation is suffering the effects of “Work Silos” which typically manifest themselves in top-down communication channels and management review cycles which cripple the free flow of communication.
Data is king
Software development is an industry that is entirely based on accumulation and manipulation of Data. The data that is processed is in many different forms and the trade is aligned to converting that data to actionable information. It stands to reason that the software development process must also generate data, that in turn be converted to actionable information. This data can be used to not only improve the software development process but also it will also provide vital business information that is required outside of the software development process.
The problem is that in most organisations this information often lays trapped within the silos. Often the first indication that an organisation is experiencing an information block manifests itself in what at first appears to be, what is termed as Defect Unification pattern, i.e. How do we ensure that Quality Assurance and Engineering are able to share the same information when it comes to Defect status.