Decision-making Poster

Agile teams work in a widely self-organized way. This raises the question who actually takes descisions in such a context.
Depending on several factors such as corporate culture the way decisions are taken can differ.
To build trust and support for descisions amongst the team it can be helpful to understand the way a decisions are made.
In order to support that, we created a poster that visualizes the most common models for decision making. It covers the most common decision models single, consultative, consent, consensus and hybrid.
Every model has strengths and weaknesses in terms of speed and sustainability. Every organisation should find the most appropriate model or even a mixture that works best in the respective context.

Visualizing decision models helps to gain insights into the way decisions are made and thus improves fairness and trust amongst the team members.

You can download the poster for free in German and English here.

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.

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 …

 

 

 

 

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.

 

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.

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)

Collocation Is Vital!

What does collocation mean? The concept is very simple. It means bringing together the people who work on a software product in a physical environment. This seems to be natural. But in highly distributed work environments that we have today it is not anymore.

I’ve been working on agile projects for many years and I always hear that collocation is difficult. Especially in larger enterprises it seems that the hurdles are high. There are many reasons stated by different people.

Here are some examples:

  • There are no adequate rooms available (managers).
  • The buisiness guys don’t understand IT. We can’t work in the same office (developers).
  • The IT guys don’t understand our business. We can’t work close to them (business).
  • Our outsourcing partners are from country xyz. It is impossible to work with them in one office (managers).
  • The business people have their work to do. They simply don’t have the time to work closely with IT (business).
  • I have to concentrate. Working close to others would always disrupt my work (developers).
  • We don’t like travelling. (all of them)

All of those are valid arguments, but to me it seems that they are sometimes artificial. In this case reluctancy to change is stronger than the will to increase efficiency.

From my experience collocation is an underestimated factor that can greatly improve effectiveness of teams. The study Collocation Impact on Team Effectiveness goes in the same direction.

Another interesting read is Collocation, Collocation, Collocation. Quote from the blog:
“A big part of the problem is socio-political in nature and would appear to be deeply embedded in the human DNA. We naturally tend to come to trust those that we have regular contact with (our family / village / tribe / region / country / team) and have an equal and opposite tendency to distrust those on the outside of these habitual daily contact networks (all those that the lock on our front door or the defences around the tribal village are designed to keep out).”

If a company is interested in real agility and effectiveness, I think it should try really hard to create collocated work environments and not give up early. It might somtimes be difficult, but the reward will be better results and most likely even better motivated staff.

Scrum and Silverlight in Reinsurance

Today I would like to share a success story of a project I accompanied as Scrum Coach and Solution Architect from analysis to production.

Main success factors were:

  • Scrum (Agile Development)
  • Cross functional Team
  • Service-oriented Design (SOA)
  • Silverlight RIA

You can read more in the case study Modernization of business partner management.

Bug or Change – Cause of Conflict in Agile Projects

According to the second rule of the agile manifesto working software is more important than comprehensive documentation. This is definitely true!
To be clear, this does not mean that software developed by agile teams is not documented. If comprehensive documentation brings value to the organisation, agile teams produce this as well. Specifications are written as well in agile projects. Why? Because it is not (and never was) a good idea to start development without knowing what to implement.
But contrary to waterfall projects in which much of the specification is written upfront, in Scrum the specification is written as part of the sprints. And due to the close collaboration in cross functional teams, the specification can be much more lightweight without loss of quality for the final product. This is all great. But there is a challenge to keep in mind.

When it comes to testing (acceptance, performance, etc.), either as part of the sprint (which is definitely the preferred way), or later when the product moves towards production, the testers have to find and classify bugs. Usually they do this based on the specification. In case a functionality is missing or not working as described in the specification it is a bug.
With a lightweight specification that don’t decribe every little detail it is sometimes hard to tell whether someting is a missing feature or rather a change for a later version of the product. This situation can cause conflicts.

But not necessarily. The important factor is that the testers are part of the agile team context from the beginning, so that they share the knowledge and experience with the rest of the team. In a culture of trust, the team can easily negotiate whether a finding is a bug or a change. If the team is commited to deliver quality (the Scrum Master has the responsibility to educate the team to do so), this model works properly.

This strategy correlates with the conflict resolution scenario Use collaboration to resolve the conflict described in the interesting blog post Know These Five Causes of Conflict written by Karen Ruby.

Quote:
“However, if trust is there, this conflict resolution scenario can be the best way to resolve conflicts once and for all. When both parties come together, communicate, and trust each other a definitive resolution to their conflict can occur.”