Category: Agile

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)

Agile Process Management with Open Source

Are you interested to know how to combine process management, agility and Open Source software? Then the roadshow Agile Process Management with Open Source is for you. It is going to take place in several German cities during autumn 2012. I am going to present ways to achive efficiency in the area of process automation using proven Open Source technologies paired with agile approaches. In times where CIOs have to think twice before they spend IT budget, undoubtely an interesting topic to talk about. It have some interesting ideas to share and hope for inspiring discussions.

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 in Reinsurance

On 5. July 2012 I am going to give a presentation introducing an agile Project in the area of reinsurance which I accompanied as Scrum master and solution architect. The conference is going to take place in the SAP Service Center in St. Leon-Rot near Walldorf.
The presentation is called Scrum in reinsurance – a success story. It covers factors that made the project a success as well as impediments. The aim is to share our lessons learned on the way to successful agile project management. I hope to see you there.

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.

Lightweight Collaboration Tools

When you work with distributed teams it is important to have lightweight tools for efficient communication. Here are some free tools that I would recommend:

Surveymonkey – Online polls
DFN Scheduler – Scheduling
Skype – Video and voice conferencing
Chatzy – Private web based chatrooms (port 80 only, mobile access)
Trello – Scrum and Kanban boards (highly interactive)
Kunagi – Scrum boards (includes tools like planning poker)
Teamviewer – Online meetings and remote control (free for non commercial use only)

Impediment Number One to Agile Adoption

Scrum is in many respects very different from traditional project management approaches, especially waterfall models. It requires a different mindset in which it is ok to say:

“I don’t know yet exactly how long the project is going take, but give me some time to get to know the requirements and the team. After some Sprints we will give you a solid estimation based on empirical knowledge. Trust us, we do the best we can to deliver quality on time”.

For many especially “classic-minded” project managers such a statement is unimaginable. They simply can’t understand the culture of Scrum as it is very different from what they are used to.
After applying Scrum in several projects over the last years and after giving many Scrum workshops I think that the only way of learning Scrum is by doing it, ideally accompanied by a skilled coach. Books and certifications help, but they do not create deep understanding.
And here begins the dilemma. Especially managers in larger organisations never work on projects, they manage. Therefore it is hard for them to leave their classic mindset. This leads to non-supportive behavior which often blocks the way to agile adoption in large enterprises. In a recent interview Scrum in larger organisations Jeff Sutherland describes the challenges to change the management mindset.

He says:
“… major challenges you will have to deal with when you implement Scrum in a large organization is to change the mindset in the organization in general and on management-level in particular …”

For the reasons given above this nut is hard to crack. To me it seems that this is impediment number one on the way to agile adoption in larger enterprises.

Trapped in the Comfort Zone

Many agile techniques such as Kaizen, Sashimi or Kanban correspond to terms and principles found in asian culture. A less known principle is:

“Do not develop an attachment to any one weapon or any one school of fighting”
– Miyamoto Musashi

In the context of agile it means that one should change the process if it helps to achieve the goals. This is something most developers would agree to as processes are often seen as impediments.
The same applies to technology. Translated to the technical world it reads: Do not stick to your favourite technology if there is something better suited to meet the project or customer needs. This is something many developers would not immediately agree to. Developers usually love sticking to their JEE, Spring, .NET, SOAP, REST, [any other technology] with which they grew up. They often argue that learning a new technology is time consuming and therefore hardly possible to change.
I think that is wrong. Provided a developer has a sound background, he or she can become productive in a new technology within a short time. I’ve seen developers switching from JEE to .NET and vice versa without problems. This is possible because technology always evolves. Most new frameworks and programming languages do not reinvent the wheel. The are always based on similar common principles which remain valid and stable over time. It is more a matter of mindset that keeps people trapped in their technology comfort zone.

Is that a problem?

Sometimes yes, especially when paired with Groupthink, it hinders innovation and production efficiency.

How can this prevented?

1. Make sure you have people with long standing experience in different technology domains in your team. People who worked with multiple technologies are usually more willing to reflect technology decisions and align them to the requirements of the business.

2. Don’t start a project with a strong technology committment. Let the team decide which technology is best suited to solve the business problem. Of course in conformance with the corporate standards.

3. Ensure that the team has the freedom to decide which tools they want to use.

Having the option to change weapons (processes, tools, frameworks, etc.) if needed, improves the likeliness of successful project delivery.