Category: Agile

Agility through Business Process Automation?

Sometimes business process automation (BPA) is described as the silver bullet to improve agility and time to market. Especially large vendors spend huge amounts of marketing budget to promote their BPM tool suites, “360 Degree”- and “Zero Code”-approaches.

But why does BPM increasy agility? Is it really easier to adapt processes to business changes if a process has been automated using a BPM suite?

Sometimes yes, in the narrow range of allowed options. Often no, cause IT-coded processes are not as flexible as people in an organisation. But that does not mean that business process automation is a bad idea at all. There are areas in which process automation makes perfect sense.

Especially processes for which the following factors apply:

  • clearly structured and predictable
  • repetetive
  • frequently executed

Interestingly, often agility does not come from automated processes itself, but rather from the people who have their hands free for other more sophisticated ad hoc processes. We have experienced that in a large project for an international organisation from the public sector. Provided people have the right skills, BPA can help turning people from “routine workers” to “knowledge workers” (see It is All Taylor’s Fault). BPA allowed them to automate their repetetive tasks. It was a great improvement and productivity gain for the people and the organisation. The key was to give them a tooling that they were able to control, even without much help from IT guys.

Knowledge workers do not need their processes automated. They need other tools mostly to get the right structured information at the right time. IT can help in this regard, but not via BPA. I would call this Business Process Facilitation (BPF) rather than automation.

BPF means giving the people tools to do their job in a efficient manner without imposing predefined processes on them. In other words, it leaves the process and decision power with the people not the machines. User centered dashboards, search engines and adaptive case management tools are examples for BPF. We have experienced this in another project in which we evaluated the value of process automation using a BPM-Suite. In this highly dynamic environment the decision was to not implement BPM as it would have hindered agilty. Instead we implemented BPF to support the knowledge workers. The system mainly focused on efficient data management and decision making.

All in all it is not black and white, not Taylorism against knowledge work. Success comes from a combination of both. The key is focusing on things that are beneficial for the people and organisation. Sometimes it is automation, sometimes not. Process automation is cleary no silver bullet, but if applied wisely and with the right focus it can help organisations to improve efficiency.

Scrum Planning with Enterprise Architect

Although keeping a Scrum team together 100% on-site is the ideal situation, sometimes it is not possible and the team works distributed. In such situations it might be handy to have a tool that can be used instead the whiteboard. A kind of virtual whiteboard that is accessible from everwhere. A popular modeling tool in IT projects is Sparx Enterprise Architect due to its rich modeling capabilities and fair pricing. In order to use it for Scrum planning, I created a UML-Profile which can be used to easily create and maintain Scrum user stories. The profile contains stereotypes for epics, user stories and tasks together with tagged values to track business value, story points and team responsibilities. In order to use it, download the profile and import it using the resource view in Enterprise Architect as show below.

To use the Scrum model elements, open the toolbox and add them to the palette using the More tools … action at the top of the toolbox dialog.

Now create a new diagram for your Sprint planning. You can use swimlanes (Diagram- Swimlanes and Matrix in the menu) to add stage regions to the diagram. Right click on the diagram pane and click properties in context menu. On the elements tab select Tags and Notes. This gives the Scrum elements a card like appearance on the diagram. That’s it. Now you should have something like this:

You can quickly change story points, etc. and the notes using the tagged values and notes view. By dragging the elements between the swimlanes you can change the status of the respective user stories. The package browser (right click on a package in the project browser) can be used to show all stories and tasks in a table view.

A nice gimmick since Enterprise Archtect 9 is the ability to visualize diagrams in whiteboard mode. Just tick the options Whiteboard Mode and Hand Drawn in the diagram options and you will see something like this:

Because the whole model is stored in a repository, you can create story dependencies by connecting the elements, automatically determine backlog sizes and print story cards based on custom templates.

In my opinion using the whiteboard is still the most efficient way for Scrum planning. But especially in cases where teams are distributed, such an approach is hardly possible. As shown in this post, Enterprise Archictect can easily be turned into an effective Scrum planning tool that can be used in those situations.

You can download the Scrum profile here: Scrum.xml
If you want to change the team members, make sure to edit them in the profile before importing it into Enterprise Architect.

Core Values of Great Software

Over the last decade I have seen many software solutions. Some excellent and some really bad ones. But most solutions were somewhere in the middle. They just did what they were supposed to do.

But is this really good enough? I don’t think so. Especially today where time to market is critical and the budgets are limited, functioning software is the bare minimum. On top of that other core values are getting more and more important.

  • Functionality – This is obvious.  The software must do what people expect it to do in a reliable manner.
  • Evolvability – This is also known as sustainability. A value that is important in many areas of our daily life. And also in software development. It means that we don’t want to reinvent the wheel over and over again. We don’t want to produce waste. Software must be flexible so that it can be reassembled even if technologies change. Investements have to be saved. Evolvability can be primarily achieved through proper software design. Especially service-oriented approaches are promising here.
  • Production efficiency – This is the most underestimated value. It means that just work is not enough, rather it must be quick and easy to produce. For a long time IT is has a reputation of being complicated and expensive. As a reaction to that companies are outsourcing to cheaper countries or applying more flexibile development processes auch as Scrum to improve efficiency. Especially the latter has proven to be successful. Choosing the right software is also a good way to come closer to that goal. For example frameworks should not only assessed by its functionality (often done by developers) but also on the ease of use and developing performance.

Although those values are important for every software project, they are especially important in todays SOA/BPM undertakings as they promise to increase agility and time to market. This can only be achieved with software solutions that are flexible and easy to use. Ideally even for business people without a developer background.

Speaking at Agility & User Experience Expert Forum

I am glad to be invited to speak at the Agility & User Experience Expert Forum. The conference organized by Accelsis and the Fraunhofer Institute for Experimental Software Engineering is going to take place on 16.June 2011 in Frankfurt/Germany.

The conference is packed with lots of real world examples showing how innovative approaches in the areas of usability and agility can improve corporate software development.

In my presentations I am going to show how agile techniques can be used in fixed price contexts (Yes, that is possible!) and how to achieve real operational agility beyond just Scrum.

I look forward having inspiring discussions and hope to see you there.
You can register here.

Groupthink and Scrum

People who apply Scrum in their projects are familiar with Tuckman’s stages of group development which describe the phases a team runs through every time it is formed or changed.
The assumption is that the team members have to find their role before they can be productive. They get to know each other and conflicts are resolved during the storming phase.

Then after the norming phase often something interesting happens. When the people feel comfortable with their role they tend to avoid conflicts and discussions. This is natural and not a problem per se, but sometimes it hinders innovation and striving for the better.

In 1952 William H. Whyte already coined the term GroupThink which describes this behavior.

Quotes:

“Groupthink is a type of thought within a deeply cohesive in-group whose members try to minimize conflict and reach consensus without critically testing, analyzing, and evaluating ideas.

During groupthink, members of the group avoid promoting viewpoints outside the comfort zone of consensus thinking.

Groupthink may cause groups to make hasty, irrational decisions, where individual doubts are set aside, for fear of upsetting the group’s balance.”

And indeed if you work with people closely for a longer time (which is common in a Scrum setting), Groupthink is likely to happen. The consequences are underestimated risks, failing sprints and finally not delivering the promised results.

In order to avoid that, a Scrum Master should foster a healthy level of controversy among the team. He or she should encourage the team members to argue for the best solutions.
This must happen in a fair and constructive atmosphere in order not to damage the team. It requires strong interpersonal skills of the team members and the Scrum Master in particular.

Silverlight Receives Technology of the Year Award

InfoWorld rates Silverlight the best rich internet application platform in 2011.

Quote:

“Right now, we favor Silverlight. In the two categories most important to decision makers — developer tools and design integration – Silverlight trumps Flash/AIR/Flex. The toolset in Microsoft Visual Studio 2010 is demonstrably excellent, and Microsoft Expression Blend bridges the design-development gap much better than Adobe Flash Catalyst. For these reasons, companies like Netflix have chosen Silverlight as their RIA technology. We completely agree.”

Of course such a rating always depends on what is important in a certain context, but it shows that Silveright is definitely one of the leading technologies in the RIA space. Beside many other aspects the toolset is very important, as it helps to boost developer productivity.

I can only confirm that. We are currently using Silverlight in an Scrum project applying an incremental design and agile specification approach. Silverlight is ideal in this context as the toolset supports all phases from sketch, specification, design, development and test in a flexible manner. Business analysts, designers, developers and testers are able to work closely together using the same toolset.

Scrum in Practice at Fraunhofer Fokus

Im am going to give a presentation about Scrum at the Fraunhofer Focus in Berlin at 2.November 2010. The event is called Scrum in practice. In addition to the principles of Scrum I am going to show how Scrum is applied in real projects and how to deal with typical challenges.
I would be glad to see you there. You can register here.

Three challenges of BPMN 2.0

There are three major challenges in using BPMN 2.0 as a holistic (360°) approach to Business Process Management (BPM):

  1. Semantic Alignment
    BPMN like all other high-level process languages is context agnostic. This is good, as it allows a wide adoption throughout the industry. On the other hand it means that it does not explicitly express concepts found in business contexts, such as customer, accounts, discounts etc. As people from business and IT often have a very different view on certain business aspects, it is essential that they share the same semantic context in order to understand each other. If not, a process designed by a business person will not be understandable by an IT person and vice versa. In case BPMN is applied in combination with an outsourcing approach things get even worse.
  2. Level of Details
    BPMN2.0 is designed for automatic execution on a process engine. The goal is to have one process model from analysis to execution. But people from business and IT require different very levels of detail in their process descriptions. This is why a processes created by business people are usually not detailed enough for IT people. IT processes are usually full of technical information required for automation, rendering the process almost useless for business people.
  3. Portability
    The BPMN standard introduces several conformance levels (modeling, execution, BPEL, choreography). This is good as it fosters reusability of BPMN diagrams amongst different tools. At the same time the standard explicitly allows model extensions, “to satisfy a specific need, such as the unique requirements of a vertical domain” (quote from the spec). Thus, to avoid vendor lock-in, one at least has to be very careful in choosing the right model elements.

BPMN 2.0 should not be applied naively. Unfortunately this is often happens, especially when the standards are young. To be successful with BPMN 2.0 one has to find the right mixture of standards, design principles and methods.
For instance the semantic aligment problem can be mitigated by applying Scrum for analysis and process development. A multi-layer process design can help to address the level of detail problem. And choosing the the right product can increase portability.
This is nothing that comes for free by just using BPMN 2.0. It is rather something that needs to be actively managed by experienced engineers.

Definition of Done – Never without

One of the keys to success in agile projects is a proper Definition of Done (DoD). Only if everybody knows what has to be produced in order to complete a sprint, the goal can be achieved. 

The ideal outcome of a sprint is a product increment that is potentially shippable. To achieve that, all necessary actions to create a high quality product, such as writing documentation and thorough testing, have to be carried out within a sprint.  

In order to be really sure whether a an artifact is done, acceptance criteria are needed. Otherwise “done” would not be measurable. The criteria depends on the produced artifact. 

Software-Artifacts 

Software products usually comprise the following: 

  • Database structures (tables, stored procedures, triggers, …)
  • Application (user interfaces, Services, …)
  • Interfaces to external systems
  • Data (probably migrated from older data, …)
  • User documentation (online help, …)
  • Installer

    • Acceptance criteria 

    In order to prove that the above artifacts are really done, they need to be tested. Because the amount of test grows for each sprint, there is no way around automated regression testing. Therefore a continuous build,test and integration system, such as Team Foundation Server or Hudson, is essential for agile projects. The following tasks should be automated (in the brackets you can see an example of acceptance criteria for each task).

    • Unit testing  (error ratio maximum=10%, code coverage minimum=60%)
    • Load + Performance testing (concurrent users=20)
    • User acceptance testing, UI tests (error ratio maximum = 15%)
    • Integration (successful installation and availability)
    • Code quality checks (warnings maximum = 20)

    Some tests, such as UI tests, might be difficult to automate. But if you do it, you team will be rewarded with a highly accepted software product at the end of each sprint. As you can see the acceptance criteria is not 0% errors or 100% coverage, because this would not be realistic.

    Concept-Artifacts 

    Some projects develop their concepts using Scrum as well. Something that I would encourage to do. Although in Scrum the amount of written documents is greatly reduced, concepts are often helpful and required. For instance to refine coarse grained user stories from the product backlog or if the implementation of an idea can not be realised immediately. Concepts can be written in many ways as long as they clearly describe the idea down to a level that is sufficient for the implementation. For instance text documents, wiki pages, prototypes or design sketches. 

    Acceptance criteria 

    How can a concept be defined as done in terms of a DoD? As always! Conduct a review with people from within the team or other stakeholders from within the organization. When a concept is successfully reviewed, it is done.

    Summary

    Having a proper Definition of Done which clearly lists the required artifacts and acceptance critera is essential for successful Scrum projects. It creates a common understanding of what “done” actually means and is a key artifact to deliver high quality software in agile projects.