Key takeaways
|
Software Engineering Methods and Theory (SEMAT) and its definition of the Essence Kernel identifies the core elements that are considered important in all software engineering processes and methods and by doing so helps to define a common language to drive integration.
SEMAT has been described in more detail in two articles on InfoQ, in SEMAT - Software Engineering Method and Theory and in Using SEMAT in Agile Adoption.
The Essence Kernel identifies seven critical areas that any piece of work needs to focus on to ensure success. These are defined as “Alphas”.
Each Alpha has a number of “Alpha States” that are only reached once certain conditions are met.
For example one of the Alphas is Requirements. This has 6 defined Alpha states which are used to explain when conditions have been met to allow progress in the solution. Each Alpha state has a clear check-list of conditions.
So for the Requirement Alpha to reach a state of “Coherent”, conditions such as “important usage scenarios have to have been explained” must be completed.
Using the Alphas it is possible to "Essencialize" processes and methods, by defining at any given phase what alpha state positions should have been achieved.
Essence at Fujitsu UK
Fujitsu, like many large organisations, is using a large number of processes and methods which have developed over the period of many years. Initially in Fujitsu UK we were looking to do a review of some of our core processes for developing Infrastructure / service and Applications. In the past these methods could be standalone. We started to understand that to deliver a successful project they needed to be linked. If you cannot consider the entirety of the project parts in the whole it’s very likely that important issues will be missed, leading to costly problems. So there was a need to define a common layer to allow them to work seamlessly together. At the same time Agile based development became more widely used in projects. We needed a way of combining agile and traditional methods and be able to track if projects were on track and looking good.
At the start of this piece of work I became aware of SEMAT and the Essence Kernel. While SEMAT is currently focused on Software Development its concepts work just as well when applied to system engineering.
As we were looking for a way to hook together our application, infrastructure and service methods, this seemed a perfect match. With only a minor adjustment (we modified the Alpha “Software System” to “System”) we quickly had a structure with a common language which allows us to look at the whole programme of work across all disciplines and understand and communicate clearly and concisely what gaps and issues need to be focused on.
Making it Happen
When we decided we wanted to go down the SEMAT route the first thing we did was to run a set of workshops with key individuals.
Getting everyone in the same room and talking through the concepts of Essence is critical to bring people on board. We included people from across the business, from project management, sales, architecture and design, governance and assurance, testing and operational support. Missing any of these key roles of the business would have resulted in a lack of buy-in and people believing this was just a “Technical method”.
We also used the workshop to role play some of the SEMAT definitions. We did this by defining a potential real world scenario. We assigned people randomly to roles. These included roles of acting as the customer stakeholder, team manager, engineers, testers, etc. Then we identified a number of critical points in a lifecycle of a project and ran these events as if we were fully engaged using the Essence Kernel and the Alphas to define the real state of the project.
For example we started by running a requirement assessment. In this the people acting as the customer were asked to qualify what they really wanted from the project, while others in the team defined what that would mean for them. Then these were pulled together so that the whole group understood the amount of effort needed to deliver these. We aligned understanding of the Alpha states by asking the whole team if they felt the stakeholders were engaged, and to what level.
The group identified real world incidents that occurred and we saw how we would deal with these with and without the use of the Kernel. As you can imagine this created some very heated debates.
We used the Essence cards to clarify what state each Alpha had achieved, using a low tech solution of tacking the cards onto the walls and physically getting people to move them from one side to the other as each Alpha state was talked through and agreed it’s conditions had been met. This is critical as the tactile nature of doing this helps cement the reasoning behind the states into minds.
Getting people directly involved in discussions using scenarios they understand allows them to fully immerse themselves in what SEMAT does and produces a far better understanding than if you just tell someone the theory behind it. They really invest their time in this and therefore care how it works.
Adapting to a Changing World
The world is very different to what it was just a few years ago. Infrastructure projects always used a tried and trusted waterfall method. With the raise of cloud services this has changed. The ability to provision hardware in agile manners using an Infrastructure as a service (IaaS) it is now possible. PaaS and SaaS are becoming ever more mature, resulting in changing methods for how these are used within solutions.
This means that trying to define a single process that will work in all occasions has become impossible. The Essence Kernel comes to the rescue as it defines common areas to be considered (the alphas) and concentrates on how these are progressing (alpha states). By considering the alphas states of projects you can now assess if the project progresses as expected independently of the method being used. This quickly gives management a real view of emerging issues (e.g. states not progressing as they should) which they need to concentrated on.
For example, if this showed that the stakeholders were not reaching agreement across all programme areas then this potentially could derail getting final sign-off on the work. Senior management can react to this and engage the customer stakeholders and address any issues on commitment. Even in the worst case, when the stakeholders have lost interest in the project, at least this becomes visible and a course of action to re-engage or withdraw can be done early.
The common language also makes project assurance easier. No longer do project teams have to spend time explaining the method being used and what this means in terms of the progress. Instead the Alphas and their states are used. This concentrates minds to assure that the important elements are done.
Using Lenses
In Fujitsu we often talk about lenses. What we mean by a “lens" is to look at something from a given point of view, and focus on key concepts. So you can take a “sector lens" where you look at what you are doing for a business sector, for example manufacturing. In this way you can ensure that everything makes sense for customers in this sector. In the same manner you can apply a lens horizontally when looking for important elements for a project, a programme or enterprises portfolio of work.
When conducting large programmes of work Essence can still be used if lenses are applied at different layers of the work to fully grasp the states. We applied three lenses to the Essence Kernel: Enterprise, Programme and Project.
(1) Enterprise Lens – Takes a view from the Enterprise Architecture of an organisation, including the general vision and strategic goals. This is the very top level of any piece of work where most organisations have business strategies, sometimes linked to an enterprise architecture.
The purpose of business strategies and visions are to guide a company how they get from where they are today to where they want to go to. Therefore it’s important that the SEMAT Lens is applied to understand how well this journey is progressing. For instance, as individual programmes are developed are they achieving the desired strategic affect?
In this lens a lot of focus is given to the Sponsorship Alpha. As total buy-in from CEO and board members are required to truly allow a strategic vision to be driven across the organisation.
To allow an organisation to fully embrace cultural change as defined by the strategy, the “Team” and “Way of Working” alphas are used to show how adoption is being embraced. We often see examples of companies that focus on implementing new IT systems without focusing on the cultural shift needed by its staff. If this is not undertaken, however good the new IT system is, the project will be seen as a failure as the staff will not engage and not use the system as intended.
(2) Programme Lens – This looks at a Programme of works. A programme contains a number of related projects to deliver a common overall goal where each project is distinct from each other in delivery.
Sponsorship at this level involves a different set of Stakeholders compared to the Enterprise level, but it is critical that there is always someone who is sponsoring a piece of work and driving the need for success. The “Team” focuses on who will deliver and by managing the “Way of Working” it ensures that all of the programme elements and principles can be aligned.
(3) Project Lens – This concentrates on an individual bounded project delivery. Delivering against a core set of requirements becomes key at this level. The “Way of Working” also can be adjusted from the programme view, in this context it is how the team members work with each other on a day to day basis rather than a handbook or method definition of how people should work. This is key to allow project teams to take control of their own destiny and align with the principles of agile delivery.
Benefits of using Lenses
Lenses allow each of the Alpha states to be focused in the right way and right granularity. At the same time it allows people to think about the different levels of a delivery without getting confused. For example a programme of work could take a whole year to deliver but could contain many shorter term projects. It's therefore important to allow the projects to flow through the Alpha states to show completeness without being locked down by the slower programme view. In parallel by looking at states at a programme view you can see if the collection of projects within the programme are delivering the outcome needed.
Without focus you can deliver all of the programme projects very successfully but still have a failed programme of work because you have missed some additional projects that were required.
For example let’s think of a programme of work to build a house. You start to build the walls, roof, fit electrics, apply plaster to the walls and even decorate. All of these projects of work are completed successfully and therefore the house build programme is a success? Unfortunately not as the ground the house is being built upon has been found to be unstable!! This situation we all know, as soon as the ground issue is discovered an extra activity is to underpin the foundations for example. This is not always the case in IT programmes as hitting defined project milestones seems to become more important .
Applying a programme lens helps identifying issues earlier and lets you address them.
Expanding out
We have started taking SEMAT to the next level. Global organisations expect companies like Fujitsu to deliver solutions consistently across all territories. Fujitsu has a number of processes that have been developed in each local region (for good reasons). In order to ensure that we can run and delivery projects on a global basis we face two options.
(1) to develop a super process and enforce it across all or
(2) use something like SEMAT and Essence to be able to still use the local processes but have a common language and touch points so we can understand the common position.
Simply, option (1) is not an option as creating such a super process would take too long and resulted in a compromised processes that would have been unwieldy and not fit for purpose, and therefore SEMAT is the right way to go. This needs more work in rolling out the understanding of SEMAT and the kernel but that is worth the benefit.
Advice for Adopting SEMAT
My advice on adopting SEMAT is to take it slowly at first. It’s important that you invest in getting a core set of people trained who really understand how to use it and what it is. Ensure your starting group can be in the same place and use the cards and games as the tactile nature helps cement understanding. From there this core group can reach out and, by using the same approach, bring more people up to speed. Roll out by repeating the strategy of using workshops with the cards.
Conclusion
Fujitsu UK adopted SEMAT as a way to create a common language across all of our delivery methodologies. This provides a simple way to drive understanding across different teams about if substantial progress is being made towards successful delivery. At the same time it highlights key gaps that than can be attacked early to reduce the chance of time and cost overruns of projects.
By adopting SEMAT we have learnt that we don’t need to create a monolithic super process. We can continue to use the processes that people understand from a local level. By aligning them to the Essence Kernel we can link them together and take a big picture view on achieving successful projects.
About the Author
Ste Nadin (@SteNadinFJ) is the Chief Architect for Fujitsu Digital in EMEIA (Europe, Middle East, India and Africa). He has been recognised as a Fujitsu Distinguished Engineer and has over 19 years of experience in the IT industry.
He has a passion for driving good method and design practices into the IT industry as well as helping to identify and develop the next generation of IT professionals.
Ste is also a committee member of Nottingham and Derby branch of the British Computer Society (BCS) and sits on the executive board of SEMAT Inc.