Bank11 Success Story

In 2016 PLEUS Consulting supported Bank11 in the development of their brand new sales financing system VICTOR 3.0.

Success Story Bank11 is a credit institution that specializes in sales financing. In 2016 the bank decided to replace their existing software with something new. To be able to meet the challenging requirements in terms of quality, customer satisfaction and process efficiency they decided to build their own solution.

The front-ends were developed using modern web technologies such as Javascript, HTML5, CSS and Angular. For the backend Java Enterprise (JEE) and a Sustainable Service Design approach was utilized to design and build a backend with a high degree of reuse and scalability. The service landscape was established using Domain Driven Design principles.

On the technical side, PLEUS Consulting supported the teams as Master Developer and Architecture Owner. In the area of agile techniques, PLEUS Consulting supported the development teams as Scrum Master and Agile Coach. Although not 100% tension free, the combination of those roles worked quite well. With these roles the bank received thorough support in the areas of technology and methodology.

From the beginning we tried to align technology and business as much as possible, creating a people centered architecture. Central to the strategy were BPMN process models, graphical business rules and visual service contracts. In order to create appealing front-ends for the car dealers and the back office of the bank we worked closely with user interface specialists which were members of the cross functional teams. Web stack technologies allowed us to create individual and great looking front-ends. Agile frameworks such as Scrum organized the development teams and created valuable software together with the customer within a short period of time.

The project has shown that with a combination of modern technologies and agile approaches a very short concept to market cycle can be achieved, creating competitive advantages. It also demonstrates that it is possible to establish an agile culture in rather traditional business domains.

You can read more details about the project in the official success story. If you want to find out more come to watch my talks at JAX 2017 in Mainz.

JAX Sessions about Agile and Architecture

Between the 8th and 12th May 2017 JAX will be taking place at Rheingold Halle in Mainz.

On the 8th I am going to give a presentation about Agile trends, myths and best practices. . In this talk I will show why Agile is the way to go and what it actually means to work with Agile rather than just applying Scrum or Kanban rules.

On the 9th I will share insights from a banking projekt in 2016. This technical talk will show how to combine current architectural patterns such as sustainable service orientation, process automation and business rules to create an architecture that evolves around people.

You can see the timeslots on the JAX website. I look forward to seeing you there.

Agile Animals

Agile is successful, efficient and (often) fun. That’s why many companies are trying to be more agile these days. Basically it seems to be easy to apply agile practices and frameworks such as Scrum, Lean Startup or Design Thinking to get started with Agile.

However in reality many, especially larger companies are having problems doing this. From my observations the main reason for this is existing corporate culture. These companies want to be agile but are not willing to significantly change their culture and mindset. They often adhere to bureaucracy, hierarchy and zero mistake policies. This approach has obviously helped them to grow and be successful in the past. When it comes to agile this causes a culture clash which is almost inevitable. These companies can be compared to Elephants. Strong and powerful but inflexible and slow.

There is another kind of animal out there. Squirrels. Squirrels are fast, flexible and full of energy. In other words they are agile. You’ll find these companies in the startup scene, but not only there. Some larger firms spin-off smaller companies in order to gain flexibility. The new companies are free to act autonomously and independently from the originating company. In this scenario the Elephant funds the Squirrel and acts as a sponsor.

Elephants mainly come from the Classic Economy whereas Squirrels can primarly be found in the Creative Economy.

There may be some exceptions, but from what I have seen especially in Germany for many Elephants it is difficult to become really agile. They often try a little bit of Scrum-but and wonder why the agile silver bullet does not fly properly for them. It is not the size that hinders them (amongst others Microsoft and Ericsson are examples of successful or ongoing transitions). For Elephants it is very hard to shift their mindset in ths way it is required to be truly agile.

This is great news for the Squirrels as the inflexibility of the Elephants opens up opportunities for them.

To make this topic more tangible, I created a little illustration which shows the difference between the agile animals (the roller skates represent agile and lean techniques ­čśë ).

agileanimals

If you like it you can download this poster in A3 format.

If you want to be more agile and work for an Elephant company I would recommend the following options:

1. Change the Elephant’s mindset

Apply agile techniques straight away and start learning. Make sure the Elephant is able and willing to change the culture and mindset thoroughly. This might take a long time and a great deal of energy.

2. Work in partnership with Squirrels

Fund existing Squirrels or create spin-offs (also known as Corporate Startups) which act in full autonomy. This leaves the Elephant unchanged. Over time the market share might be moved from the Elephant to the Squirrel. Once the Elephant sees the Squirrell’s success, changing the Elephant’s mindset will be easier. ­čÖé

What do you think? If you have any other options, please send me a message …

 

 

 

 

Product Owner CRACK

When staffing your next agile project make sure you have the right Product Owner on board.
In their book Balancing Agility and Discipline: A Guide for the Perplexed Barry Boehm and Richard Turner coined the acronym CRACK which describes the properties of a good Product Owner.

Collaborative: Works well with development team and stakeholders. Is present within the team.
Representative: Has a good understanding of the product vision and is able to represent the stakeholder.
Authorized: Is empowered to make decision.
Committed: Shares the development team and stakeholder goals.
Knowledgeable: Understands and is experienced in the specific domain to guide the project to success

Keeping those rules in mind can help you to find the right person for the Product Owner role.

Turn contracts into documentation

In part one I’ve shown how to turn contracts into code. In this part I am going to show how to turn contracts into documentation.

Using the contract as a model for both code generation and documentation can save a lot of time. That is because the contract represents a single source of truth, which can be used by developers and business people alike. Just like you would probably do when you design BPMN models together with people from business you can design service contracts in the same way. Designing service contracts together with business people fosters the notion of services as business assets rather than just technical artefacts. Beside the time savings this creates mutual understanding amongst developers and business people. It facilitates collaboration and aligns business and IT. It work especially well in agile contexts in which business and IT work closely together.

But in order to be able to generate proper documentation from XML schema it is necessary to document the schema very thoroughly. Luckily there is a standardized way to do that using <xs:annotation> and <xs:documentation>. The following listing shows how to do it right.


<xs:element name="PerformSimpleCalculationRequest">
  <xs:annotation><xs:documentation>Performs a simple calculation</xs:documentation></xs:annotation>
  <xs:complexType>
    <xs:sequence>
      <xs:element name="operation" type="tns:Operation" minOccurs="1" maxOccurs="1">
        <xs:annotation>
          <xs:documentation xml:lang="EN">Operation to perform</xs:documentation>
          <xs:documentation xml:lang="DE">Operation zur Ausf├╝hrung</xs:documentation>
        </xs:annotation>
      </xs:element>
      ...
    </xs:sequence>
  </xs:complexType>
</xs:element>

You can see the full listing in the previous blog post.
It is best practice to document every aspect in the schema in a way that can be understood by humans. Ideally not only by technicans but by business people as well. To achive that it is essential to use the right language from the respective business domain. As shown in the listing it is even possible to add documentation in multiple languages.

As XML schema itself is XML we can easily validate and transform it to HTML using XSD and XSLT. A template can be found as part of the example project.

The stylesheet can be linked to the XSD using the directive <?xml-stylesheet type=”text/xsl” href=”contract.xsl”?> within the XSD. If you open the XSD in a web browser it will be transformed right away and show the HTML output.

Alternatively you can transform the XSD on the commandline using msxsl.exe. Just type the following to generate the HTML documentation.

msxsl calculator.xsd contract.xsl -o calculator.html

Another option is to automate the transformation process using the Maven plugin org.codehaus.mojo:xml-maven-plugin as you can see in the following excerpt from the POM file.

<plugin>
	<groupId>org.codehaus.mojo</groupId>
	<artifactId>xml-maven-plugin</artifactId>
	<version>1.0</version>
  <inherited>false</inherited>
  <executions>
		<execution>
			<id>transform</id>
			<goals>
				<goal>transform</goal>
			</goals>
			<phase>install</phase>
		</execution>
	</executions>
	<configuration>
		<transformationSets>
			<transformationSet>
				<dir>api/src/main/resources/xsd</dir>
				<stylesheet>${project.basedir}/repo/transform/xsl/contract.xsl</stylesheet>
				<outputDir>target/repository</outputDir>
				<fileMappers>
					<fileMapper implementation="org.codehaus.plexus.components.io.filemappers.RegExpFileMapper">
						<pattern>^(.*)\.xsd$</pattern>
						<replacement>contract.html</replacement>
					</fileMapper>
				</fileMappers>
			</transformationSet>
		</transformationSets>
	</configuration>
</plugin>

The result is a HTML contract documentation in the target/repository directory. This documentation can for instance be uploaded to a Wiki which serves as a service repository. It is lightweight, easy to use and highly recommended as it greatly helps to increase the likelyness of service reuse.

It is definitely recommended to develop service contracts in workshops with people from IT and business. The person who moderates such a workshop can be called a BizDev, as he/she needs understanding of the business domain and technology alike. Doing that can greatly reduce misconceptions and create awareness of services as reusable business assets. Give it a try!

Capacity Based Velocity Calculation for Dynamic Agile Teams

Traditionally the velocity (V) of agile teams is calculated as number of story points (SP) delivered per sprint. If our team is static, that means, it consists of the same or at least the same amount of people in each sprint we can get a velocity that really reflects the team performance.
Although highly desireable, from my experience static teams are not very common. In fact most teams have a certain degree of dynamics, especially in long running projects.

Typical reasons are

  • Vacation or sick leave
  • Daily business (especially team members from the business are not 100% commited to the project, as they still have their daily duties)
  • Partial engagement (specialists are only part of the team when their knowledge is required)

How can we calculate the velocity for those dynamic teams? By taking capacity into account and combining it with the team velocity. I can recommend following procedure that I used on several projects with very good results.

  1. Have a sprint planning meeting with all people that might have something to deliver in the next sprint or delivered something in the previous sprint.
  2. Ask every person how much days she plans to commit to the next sprint. This is the planned capacity (PC). Adjust PC if necessary during the sprint planning session based on the selected user stories. Use PC as a basis to plan the next sprint.
  3. Ask every person how much days she really committed to the previous sprint. This is the delivered capacity (DC). The delivered capacity might differ from the planned capacity announced in the previous sprint planning metting. That is normal for the reasons given above.
  4. Calculate the capacity based velocity like this CBV = SP/DC.

The advantages of capacity based velocity are:

  1. It is based on empiric data (delivered capacity instead of planned capacity). It reflects what really happened and not what was supposed to happen.
  2. It grounds story points (virtual) with capacity (real) as it takes capacity into account in addition to the story points. But beware! Once the SP/DC ratio (how many days do we need to implement a story point?) is known after some sprints, it is tempting to perform planning with capacity instead of story points. This is a bad idea as it brings us back to the notion of exact planning which we (hopefully) learned is not possible.
  3. It allows the projection of realistic project release dates as we have a stable measure even if the team structure varies.

 

Understand your Team with SCARF

If you are a Scrum Master or coach you might sometimes wonder why people act and react the way they do.
The SCARF model can help you to understand which factors are driving peoples reactions.
The model lists factors that cause a reaction of either approach or avoid. The factors are:

Status, certainty, autonomy, relatedness and fairness

Here are some ideas what you can do to minimize reactions of avoidance in your Scrum team:

  1. Increase status by praising sprint results as well as team improvements, ideally in public.
  2. Increase certainty by protecting the sprint from outside disturbances. Make sure the expectations are stable and understood.
  3. Increase autonomy by letting the team take decisions.
  4. Increase relationship by colocating the team members. Select team members by personal interests as well as technical expertise.
  5. Increase fairness by treating yourself and the team members equally.

Keeping those factors in mind can help to better understand peoples reactions and adapt your own behavior so that it minimizes reactions of avoidance.

Team Complexity – The Underestimated Factor

Most people would agree to say that an IT project is complex if it has to cope with difficult technology and a challenging business context.
But it is not just technical complexity that threatens the success of a project. Team complexity is an important and often underestimated factor that highly affects the likelyness of success and failure of IT projects.
Even if you have a simple technical problem to solve, it can get much more complicated if you do it with a complex team.
The main problem is that effective communication is very hard to achieve with complex teams. But effective communication amongst the stakeholders, developers, business and operations is one of the key success factors for IT projects. Thus having a team with low complexity reduces risk and increases efficiency. But why is this often not recognized? I think the reason is that dynamic effects are hard to measure and invisible most of the time.
Inspired by the article Projects fail due to dynamic complexity (German) written by Prof. Dr. des. oec. HSG Stefan Gr├Âsser I thought about common factors that affect team complexity and therefore dynamic complexity.
To create more awareness in terms of those factors and make the subject more tangible I’ve created the Team Complexity Calculator. Its a fun tool that can be used to get a better idea of how those typical factors affect team complexity. It does not produce absolute results, so please don’t take it too serious. ­čśë
If you know additional factors that affect team complexity, please let me know.

Those factors are based on experience I’ve made in projects ranging from small to very large sizes.

Agile Games Released

Today my Windows 8 app Agile Games passed the Microsoft certification process. It is now available in the Windows Store.

Planning

The app acts a a host of typical games that are utilized in agile projects. The first game is planning poker which can be now played by distributed teams over the internet. Other games will be added to upcoming versions. I implemented the app using HTML5/CSS/JavaScript and jQuery. The backend is based on HTML Web Sockets and hosted on Windows Azure cloud infrastructure. Although in my personal opinion XAML/C# is more productive than HTML/JS, I must admit that app development with HTML/JS is great fun. Existing techniques and frameworks such as jQuery or Knockout can be used and the JavaScript code has a high potential of reuse in different environments and across platforms. The WinJS APIs allow a smooth integration to use Windows functionality such as search and sharing. And last but not least the touch interface lifts the user experience to the next level.
If you want to know to develop how those apps, please attend the Windows Store App Development Workshop. I think Windows Apps have a great potential. They are well suited to reach users in a modern way. Most business workstations today are equipped with Windows so the market is huge. Let’s start coding!

Integrated Process Management with Open Source

If you ever tried to create an execution environment to automate business- or integration processes based on Open Source products, you know that this is not an easy task. Although Open Source products like Activiti or Apache Camel are of high quality, they do not run with production grade quality out-of-the-box. For serious usage scenarios typically a lot of work is required to integrate those products into a sound platform. This fact hinders companies to use those great products and turn to closed source alternatives from Oracle, Appian or Inubit, just to name a few.

Now there is an interesting alternative called oparo. oparo is an integrated process automation platform based on rock solid Open Source products. oparo is not limited to BPMN processes only. It rather focuses on the entire process spanning business, workflow, mediation and integration.

The platform does all the plumbing required to turn single products such as Activiti, Apache Camel, Apache ActiveMQ, Lucene/Solr, etc. into a platform that can be used out-of-the box. Even better, oparo is entirely ASF2.0 licensed (today and tomorrow) which offers broad usage options and does not involve any hidden costs for enterprise features.
oparo shields the process engineer (the guy who analyses and automates processes) as much as possible from low level technical tasks such as connecting and transforming Camel and Activiti message payloads. It offers a unified development approach for the process engineer to focus on business functionality instead of technical plumbing. Moreover it comprises additional valuable services such as process flow tracking, humantask integration or a registry. Due to oparos service binding approach, those services can be easily integrated in existing IT landscapes using almost any technology (e.g. .NET, JEE, HTML5/JS/CSS). The runtime is scalable (in terms of technology and licenses), the set up is automated and the whole platform is based on proven standards.

If that sounds promising, you can give it a try. You can find more information and a downloadable jumpstart distribution at oparo – the efficient process platform (German only)