Women of Silicone Roundabout Roundup

After insisting that it was a good idea, the business agreed that it was beneficial to send a group of us off to a Women in Technology conferenced at the American Square Conference Centre. We were definitely right.

The morning started with a mix of women at varying stages in their career and differing levels of experience and background; from retail to consulting and development. Many of the speakers were drawn to technology from a young age and shared their stories regarding the hurdles and challenges they faced as young girls interested in science and engineering. This theme of challenges and hurdles appeared to stay with them as they progressed through the years and followed their passions into the careers that they have now. When the same statistics are run in by a number of different presenters you can clearly see where the issue is stemming from. There are 7 times as many men studying tech and engineering as women. Only 7% of the people studying ICT at A Level were women. 14.4% of people Working in the industry are women. These statistics are terrifying. As a result it was refreshing to hear the suggestions and see the high number of talented people trying to work to solve the issue and increase representation in the industry.

There was a variety of different delivery styles; panels, presentations workshops. Out of the panels came some interesting ideas. In particular part of the leadership team from Sky hosted a panel entitled ‘Closing the Gender Gap – What can Employers do?’. They highlighted the importance for buy in coming from the top when starting initiatives for women. They have two schemes running at Sky; a ‘Women in Leadership’ scheme and a scheme dedicated to junior members of staff just coming into the business. After networking with some other staff from Sky it became apparent that they also offer networking events catered specifically to women in technology at their offices, software engineering academies to provide graduates with practical training to develop and support software in order to be more attractive to all manner of individuals not just those with computer science degrees. I have approached Sky to try and gain further understanding of the details surrounding these schemes and more importantly the key steps that they took to introduce them in the hopes of replication elsewhere. However one thing rang through clearly at the conference that it was persistence and commitment to the scheme that helped make it successful.

Value of Agile Methodology

I attended a lecture organised by the BCS West London branch about the Value of Agile. There were two speakers the first of whom, Professor Tracy Hall discussed Agile Software development from an Academic Perspective. Her academic profile is impressive; she has conducted many empirical software engineering studies with a variety of industrial collaborators; she is currently leading a major research collaboration with Sky Plc. Her current research activities focus on software fault prediction and analysis, as well as the human aspects of software engineering. She has published over 100 international peer reviewed journal and conference papers and has won significant funding from the UK’s Research Council (EPSRC) for many research projects.

 

She discussed many papers that provided use cases and theories surrounding the adoption of agile software methodology her recommended reads were works by Tore Dybå, Kieran Conboy, and Torgeir Dingsøyr. Much of their cited work on Google Scholar is almost a decade old in some cases however there is some more recent work. She also recommended the IEEE software publication, there is a vast library of agile reading on their site http://www.ieee.org. As well as the age of some of these publications my only other criticism would be that the limited practitioner experience in the academic examples. Her involvement with the external companies was of benefit academically but without input from industry there will always be hesitation when trying to answer questions such as ‘how scalable is agile’, ‘Examples of failure and what to do in theses instances’. Although clear that the case studies that Tracy referenced had a positive outcome, in my personal experience it is rare that that is often the real world case. The limitation in confirming this however is that very few practitioners who are failing to use agile efficiently would not be prepared to be involved in a case study as they are busy trying to rectify their own issues first.

 

The key point that I took from her talk was the gap that is present between what is being discovered in agile research and what is being practiced and adopted in industry. In order to bridge the gap she believed, and I agree that more business need to be prepared to participate in case studies that in turn allow the world of Academia to be able to answer the tough questions with definitive evidence supporting them and providing suggestions for implementation. I personally was quite taken by the idea having Betfair involved in one of these studies. Comments from yourselves on how to go about this and if you also feel it would be viable are greatly appreciated. 

 

Non Functional requirements are not functional

I attended a lecture lead by Tom Gilb http://www.gilb.com an American systems engineer and acclaimed author about Value Project Management Methodology EVO (Evolutionary Project Management) at BCS London. He alluded briefly to his attitudes towards Non Functional Requirements in a less than positive light this encouraged me to delve further into his works. Given that we are in the middle of a discussion and working through pieces of work that outline some core NFRs that will be used to guide and advise the future processes that other teams need to be aligned alongside the standards proposed. I thought it would be worth writing up a very brief high level view of his theories along side my own personal thoughts.

Consider for a moment that even the term ‘Non Functional Requirements’ is riddled with negativity and ambiguity. In order for any task, project or user story to succeed it needs to be clear and unambiguous, grounded in design and hold a stakeholder focus, we should all be nodding in furious agreement at this point. Non functional requirements fail at the first stage, dictionary antonyms for functional include; worthless, impractical, broken as such are we really willing to suggest that the additional standards we are advising be followed are flawed from the start. That is certainly not the expectation that we want to set when looking through these guidelines.

In his paper Rich Requirement Specs: The use of Planguage to clarify requirements and included in his Planguage (planning Language) book http://www.gilb.com/dl44 Gilb heavily pushes for clarity, quantification, quality and value in all requirement specifications. He also suggests the below alternatives for renaming the different requirements.

                                                                  

Not an NFR in sight. Interest in the above and for this purpose would extend to the Performance requirements specifically the naming conventions that are applied here. The definition of a function is straight forward; an action, what the system does.  Product qualities are harder to define, Gilb explains it as how well a product interacts with people, other products, or internally within the product itself. Product qualities in turn create value for the stakeholders of the project.

The principle is simple in design, if there is a security requirement specify it as such if there is a requirement that differentiates that product to another product call it a quality requirement. Are there resource requirements? Say so. Is it an Operational requirement e.g transactions failing, then assign the term Operational Requirement and so on. This encourages the shift away from fluffy buzz work terms like ‘Optimal exposure of app status’ or ‘Logging to be relevant, configurable’ (real examples from confluence) and towards quantitative instructions that can be measured.

There is a lot of documentation out there around NFR both for and against the terminology, we have the scope to change our current approach and adopt an alternative naming convention going forward. Ask yourself can we hand over highly polluted requirements with ambiguity and obscurity to the next stage and expect that the final result will meet all the specificity that is needed when dealing with tools such as Chef, Ansible, Thoughtworks Go and processes such as logshipping or monitoring. Whether you agree with the above is open to interpretation however the take away should be to move away from negative and ambiguous terms such as Non Functional Requirements and towards alternative naming conventions suggested here.

Tyler