Steve Spencer's Blog

TFS Release Manager and Octopus Deploy, both support the concept of approval steps, but why do you need both pre-release and post-release approval steps. When I first started to look at the automated release tools such as TFS release manager I could understand the reason behind the pre-release approval. This step is your quality gate and adds some controls into your process. When creating your release pipeline you will setup a number of environments (e.g. Test, UAT, Pre production, Production) and at each stage you can make a different set of people responsible for allowing the deployment onto each environment.

When the developers have finished their new piece of code and it has been tested in their own environments, they will want to get it onto the servers so that the testers can test it in a more formal way. Currently this may involve the developer talking to the testers and the developers hanging around whilst the testers finish what they are doing so that they can free up the servers ready for the deploy. The developers will then deploy the software to the test environment, hopefully using some method of automation. With release manager, the developers can kick of an automated build and when it is completed it can then automatically create a release ready for deployment. This release can be configured to automatically deploy to the target environment.

The developer can force the software on to the test environment without the tester being ready. The testers for example may be finishing off testing a previous release and need some time before they are ready to accept the software. They may also have a set of criteria that need to be met before they will accept the software onto their environment.

Adding a pre-release approval step that allows the test team to “Accept” the release gives control to the test team and allows them to accept and indeed reject a release. This “Pause” the process allows the testers to check that all the developer quality gates have been met and therefore allow them push back to the developers if they are not happy. As the deployments can be automated, the testers can use the approval process to also control when the new software is to be deployed into their environment, allowing them to complete their current set of tests first. It also frees up the developer, so that they are not hanging around waiting to deploy. Similarly, moving on to UAT, Pre-Prod or Production, a pre-release approval step can be configured with different approvers who then become the gate keepers for each environment.

A pre-release approval step makes a lot of sense and provides order and control to a process and remove a lot of user error from the process.

So what about a post-release approval step, why would you need one? It wasn’t until I started to use TFS Release manager to automatically deploy my applications to Azure Websites where the need to have pre-release approval process became clear. Once I had released my software onto the test environment, I needed a mechanism to allow the testers to be able to reject a release if it failed testing for whatever reason. The post release approval step allowed them to have this power. By adding both a pre and post release approval step for each environment allowed the environment owner to accept the release into the environment when they are ready for it and when they are satisfied that the developers have done their jobs correctly. They can also control when it is ready to move to the next stage in the process. If after completing testing the software is ready to release to UAT then the tester can approve the release which pushes it to the next environment. If the tester is not happy with the release then they can reject it and the release does not move forwards. The tester can comment on the reason for rejection and the release will show red for failure on the dash board. Adding pre and post approval steps to each environment moves the control of software releases onto each environment to a group of people who are responsible for what happens on each.

Using these approval steps can also act as a sanity check to ensure that software releases do not accidentally get pushed onto an environment if someone kicks of the wrong build for example.

I’ve created a release pipeline for my applications which use pre and post approval steps for releases to Test and UAT, I don’t’ have a pre-production environment, but production utilises the staging slots feature of Azure Websites to allow me to deploy the release to staging prior to actually going live. The production environment only has a pre-release approval step, but as it is only going to staging, there is an additional safe guard to allow the coordinated live release when the business is ready.

Both Pre and Post release approval steps provide a useful feature to put the control of the release with the teams that are responsible for each environment. The outcome of each approval process can be visible, which also highlights if and when there are issues with the quality of the software being released.

Just finished at the Hacking Imagination event in County Durham. My role was to help mentor and encourage the students from Universities and Colleges in the North East of England to help them to develop their ideas for their Imagine Cup entries.

The event was held in a secret location in county Durham and the students were bussed in.

A number of us from Black Marble attended and performed workshops in Migrating to Azure (me), ALM/TFS (Richard), WPF, SilverLight, Phone 7 101 (Leon), Planning Poker (Me, Leon) & Software War Stories/How to Run a Software Business(Robert, Me). The students were all enthusiastic and asked a lot of sensible questions. The students were put into teams if they hadn’t already formed them, which was interesting to watch as an outsider as it was a bit like a recruitment fair with students walking around from team to team where both sides were deciding whether the person or the team were a good fit. This seemed to have worked well with everyone having a team. the age and skill levels range from college students doing their A levels to MSc.

The aim of the two days was to get the teams in a position where they had an idea that is more than just a software app with a good justification for it. This was a difficult task for a lot of teams as they either had a technology solution and tried to find a problem to solve or a really wide problem that they were trying to solve. Most of the discussions were around getting the teams to think about the whole solution including who it is aimed at and how they are going to deliver it rather than just the software side of the solution. It was also about getting some of the teams to focus down on to a specific area rather than being general. Some of the ideas changed each time I spoke to the teams!!

The (long) 2 days ended with each of the teams doing a presentation of their ideas to the whole group. The whole 2 days was enjoyable and the students seemed to gain a lot from the experiences, bringing some out of their shells.

The thing that impressed me most was the amount of young talent that is around and the abilities they have. One group of students were from a 6th form college doing their A Levels/BTEC and the college had around 15 – 20 attendees, all working hard to deliver a good thought through ideas and presenting their ideas to a group of about 50 people. That is something I used to avoid as much as possible when I was at that age. It is this talent that is the future of IT. Credit must go to the teacher/lecturer who has encouraged this amount of A Level/BTEC students to attend an event like this. Its not an easy task to get teenagers to do anything (he says from experience).

Events like the Imagine cup helps these guys (and girls) to gain real world experience and advice from experts in the field. Getting a chance to influence and help this talent has been rewarding for me and I want to try to help some of these young people more. So thanks to all the people who organised and mentored the event and thanks to the students that attended.

There was a lot of information being passed around and to finish off this post, I’ve put together a list of some of the areas that we were talking about in my sessions. I hope they are useful.

Video of wiring the Windows Azure Access Control service into an ASP.NET website. My bit is at the end and its a no code demo to allow users to login to you website using Live, Google or Yahoo accounts.

The Windows Azure Platform training Kit

The Windows Identity training Kit

Windows Azure Pricing& MSDN subscription allowances

Team Foundation Server in the Cloud

Books

Don't Make Me Think!: A Common Sense Approach to Web Usability : Steve Krug (ISBN: 0321344758)

The Art of Unit Testing – Roy Oshrove

Scrum is a process to help with the day to day running of projects. From my experience of running projects using scrum I have written an overview document. This is probably not pure scrum but it works and has practical advise. The overview is written from the team leaders perspective and may be useful to new team leaders or existing team leaders who are new to scrum.

overview - Scrum overview (pdf).

Developing software is complex but breaking the problem down into smaller tasks makes the job easier. It is OK if you are the person who defines the work, splits it down and then completes it yourself as you fully understand what the problem is and when the problem is solved. This is not normally the way it works in the real world. Here the problem is defined by the customer; there is generally someone or a layer or people defining what needs to be done to solve the problem and then a group of developers who are actually implementing the solution. Once the problem and its solution are split between different people the concept of complete starts to become an issue. There are three points of view of completed:  Developers’ perspective, Team Leaders’ perspective, Customers’ perspective.

The customers perspective of completed is when the customer gets what they want. This is not necessarily what is in the requirements. One of the biggest problems with requirements is that the person or people who normally write them understand what they want and often assume that something will be like what they want without actually specifying what it is they actually want. These are hidden or implicit requirements.

The team leaders’ perspective of completeness is when the developers have told the team leader that the task is completed and the software has been built, deployed and is in a fit state to test or demonstrate.

The developers’ perspective dictates that something is complete when the item of work given to the developer is completed as close to the specified design as possible. If you are lucky the developer has let the team leader know which parts of the design have not been implemented for whatever reason.

These three perspectives often are not compatible with each other which lead to disappointment with the customer as things do not appear to be going to plan even though the developers and team leaders think things are going well. If you are not careful this could lead to a de-motivated workforce and an even more disappointed customer.

One of the secrets of a successful development is to align the three perspectives of completion. This generally lies with the team leaders or project managers. This layer of the development process, interfaces with both the customers and the developers and it is their actions that ultimately determine how successful the project is. For simplicity we shall assume that the team leader is handling this issue. It could easily be anyone of the senior members of the development team: the consultant, designer, project manager, team leader etc. It is the team leaders’ responsibility to fully understand what is actually expected to be delivered to the customer. If the team leader does not fully understand what is required then how can anyone expect to get what they want? The team leader must rely on fact and not hearsay or rumours. The team leader must understand the requirements and try to work out what the implicit requirements are and handle the delivery expectations of the customer. If there are features that the customer seems to be talking about that are not explicitly specified in the requirements then the team leader needs to get to grips with what the customer is expecting to be delivered. This will often contradict with what the development team has been contracted to do. This may require that the project manager needs to ensure that the scope of the project is managed and that additional work is charged accordingly (assuming that the customer and developers work for different organisations). It is the team leaders’ responsibility to make sure that the customer is aware of what is being delivered at each stage.

Once the team leader has aligned the customers’ expectations with the requirements the development team can now work to complete the tasks. To make sure that the team understands what they are expected to deliver the team leader must specify the minimum criteria for completeness. This is effectively a set of tasks which explicitly defines what needs to be done. This will include testing, preparing for a demo (including what features are required to demo) and building and deploying. The goal of the team needs to be specified so that all the development team understands what is expected from them. The team needs to be made responsible for delivering the demonstration and the whole team needs to be involved with its preparation. This means that whilst the demonstration is being prepared and the software is being built and deployed, any problems are resolved as soon as possible by the development team. In addition to this any short fall in specification needs to be identified as early as possible so that the customer can be notified and/or the problem resolved before the item is delivered as complete. It is the team leaders’ responsibility to ensure that all this happens, if the delivery is not successful then is it not acceptable for the team leader to blame any member of the team. They are ultimately responsible for the successful delivery.

Aligning the perspective of completeness of the customer, team leader and developer is one of the key to successful software developments. The team leader is the catalyst for this alignment and needs to be able to communicate effectively with the customer and the developer; to understand what is required and to communicate this to the development team.

In this ever growing connected world of computer automation the user interface is becoming more and more critical to the success of a business and the success of a business computer system. The world is moving towards a service-based architecture with the web being the conduit to link all these services together. Ease of deployment is a factor in the move to web based user interfaces for business applications and this move poses challenges for software developers around the globe.

Whilst the underlying architectures are changing the basic premise for a user interface is still the same: To make the business functionality easy and obvious to use. Vast quantities of Time and money are spent developing the back end systems and relatively little is consumed designing the user interface. Most user interfaces that are developed are functional in behaviour, but they are not always usable or appear “Clunky”. The developer is not to blame for this, as the whole development process does not necessarily make the user interface as important as the back end systems and architecture. No one spends real time analysing the way the data should be presented and the way the screens interact with the user; different teams of developers develop the screens so there is not real consistency to the designs and no time is spent assessing the needs of the user when designing the user interface. Quite often the user interface is too complex and is trying to accommodate all users all of the time and often makes the often-simple task hard to use.

One client termed the phrase “Clicks Cost Money”. In an organisation where the throughput of customers is the main factor in profitability the business needs to get the customer though the system as quick as possible so the more clicks the user has to do with the computer system the longer this process takes and therefore the less money that is received by the company.

The user interface needs to be consistent through out so that when the user is presented with a screen it behaves the same way in all scenarios. The number of actions required to complete an action needs to be as short as possible. A few years back I was reading an article (I can’t remember where) that stated that each user needs to do a maximum of 3 clicks to complete a task and that it should take no longer than 1 second.

The design of the user interface needs to be brought in to the forefront of the development cycle. When I talk about design, I do not mean the bit where you make it look pretty and have the right colours (i.e. styling), I mean the actual functionality and behaviour of the user interface. Thought needs to be given to this and the developers need to be given a style guide to work with so that each of the screens is consistent using the same styles and controls.

Designing the user interface has a lot to do with the way the business is run. Each screen needs to present enough information for the user to be able to make the right decision, ask the right questions or gather the correct information so that the real business benefit of the system can be achieved. The design documentation needs to spend more time on the behaviour of the user interface and the interactions. We should be concentrating upon making the user interface easy to use and responsive

During development it is not just enough to say that the user interface performs the function it was designed to do to be fault free. It needs to adhere to some common sense values as well. It needs to be responsive, it needs to be easy to use, and it needs to behave, as you would expect it. Getting these ideas across to the developers is difficult. Time needs to be spent designing the user interfaces and documenting them in a way that is easy to understand by the developers. Developers will develop user interfaces that are easy to build not necessarily easy to use, so we need to educate them in what makes a good user interface. We need to put guidelines in place so that the user interface can be evaluated which should include response times for actions. We need to have User interface Design guides to specify common actions to make the user interface consistent and we need to understand the business requirements for the user interface so that the information that is needed most is easy and obvious to get to and that the day to day running of the business is as efficient as possible. After all that is the reason for putting the computer systems in place.