Cutting features or processes

The other week, I was participating in a process modeling workshop. We’ve been struggling a bit with project scope and objective, but now I think we’re getting there by focusing on cutting processes rather than cutting features.

In most projects I’ve been involved in, we’ve cut features. I’ve actually been part of two projects in which we added features, but this is as you all know not the normal scenario. When it comes near the project end, the ax is produced and we start cutting trees.

Or in some cases, we take out the lawn mover instead, making everything smaller.

But what is often the case is that the cut feature has some perhaps unexpected consequences. By cutting feature A, feature B and C becomes pretty useless, since they depend on feature A. Or if you use the mover, slimming everything down makes a lot of things useless since they don’t take the reality’s complexity into consideration.

But if you instead clarify the processes, you can see these dependencies and  cut processes instead. This in many cases means that you instead of cutting one feature, cut more. This is more like closing off a road.

It also becomes easier to communicate to stakeholders: what processes we should support and which processes are not supported. This does not make it easier. People never like their stuff being cut.

Creating a mindmap specification

In one of my projects, one of the lead developers asked me for a flow chart, describing the things we’re building. Far from the scrum product backlog, yes, but I decided to give it a try.

I downloaded XMind, a free software with a PRO version with really useful functions, but since I’m just testing the concept as a product owner, I decided to test the free version.

The result, many hours later, is a number of connected flow charts which all looks something like this:

I started with setting up the basic flow chart, and identified the main steps. All these main steps were given their own page in the workflow workbook and then I started drilling down. I looked at all steps and identified which functions I wanted to be available from that step and if there were any special scenarios. To help me out, I have the work from our user interface designer, so all I had to do was translate his work into this flowchart and identify these special scenarios. Well, “all I had to do” is perhaps to simplify the task. I will not hide that it was hard and sometimes gruesome work. For each step I covered, I identified more special cases which I need to find solutions for.

But after a while I got to really like this approach. I focused on one step at the time. Took a good look at that step and tried to think about if I’d really seen all the ways to which one could come to that step and I tried so see which steps were possible from there. The nice little note functionality made it possible to add all those special scenarios and questions.

In a couple of hours I had documented all those discussions we’d had in the project group and I would say that what we have is a number of user stories, but in another format. I can better see the links between stories, and it’s easier to track what the story applies to, without having to write too many X:s under “As a X” if I’d used the user story format.

Also, the diagram does something that user story cards don’t: it puts the story in a context. Yes, a user story does say why we do the story, but it does not show what happens next and what we take for granted has happened before.

So, what about the output? There is a HTML export function which exports not only the image but also the comments and pictures.

WHat about the next step? the next step is to see if the developers like it or not. And if they do, we have to find a way to build using this. But the first step is to see if this is the way to go. What do you think?

Adding complexity

When I this week was trying to understand, analyze and then present a problem, I realized that many assume that all complexity is created equally, in other words it’s like just adding a new field to a table:

But in the case of my problem, the wanted new complexity added a new dimension to the system:

The increase of possible scenarios would rise exponential would we include the required functionality. The stakeholders hadn’t realized this, since they just saw the requirement as just another field in a table. This became clear to the stakeholders when I described the current scenarios and how many there would be after the inclusion of the requested added complexity.

I could also use the 3D model to visualize how this would work and then the stakeholders could evaluate if it simply was worth it.

I’ve realized just how important It is to clarify for stakeholder if added complexity means a completely new dimension or just added complexity in the current dimensions and how I better can visualize this to stakeholders. Without a picture and hard facts this becomes too vague for many to grasp.

News in Team Foundation 2010

From a project manager’s point of view

On 2009-06-25, I and a colleague listened to a seminar concerning news in Team Foundation Server (TFS) 2010. We are currently using TFS 2008 mainly for source code handling and tracking progress (using the work item tracking functionality) during projects. Here are my notes.

Fundamental changes

TFS 2010 include a new client, especially for testers, Test Essentials or Test & Lab Management. This will mean that to be able to work effectively as a test leader or tester, you don’t need a Visual Studio installation. It is today unclear how licensing will work with the new client.

The integration with Microsoft Office require Office 2007.

SQL 2008, SP1 is required.

You can run a VS 2010 client against TFS 2008 SP1 and using patches, a user can run VS 2008 against TFS 2010. This enables a step by step upgrading of the environment.

The installation of a new server is complicated and takes a lot of time. You can though make the installation first and make all configuration in a second step, This means that the person responsible for installation does not need all configuration variables to complete the installation.

The possibilities for load balancing has been increased which would enable us to runt TFS on multiple servers and also make use of several SQL Server.

Work item tracking

The most important change here is the possibility to not only link work items but actually specify how items are linked. You can for example:

• Specify a hierarchy. This would mean that we can specify which tests are included in a test plan or which tasks belong to a product backlog item.
• Predecessor/successor relationship. This would mean that we could specify that one task is dependant on the for filling of another task.
• Related items of a specific work item type. This would mean that we could specify requirements in the form of tests and we could then specify on a task Definition of Done in the form of which tests are to be passed to see the task as completed.

A smaller change is that you can group different work item types to ease the creation of reports and queries. Using our current development process, we have no need for this.

The reports are as before available in Reporting Services format but there is an increased number of Excel reports, which also use the data warehouse. This would make us less dependant of reporting services for our project management.

There is also a specific report called Agile Workbook. In this, a number of reports, focused on the product owner and scrum master roles has been gathered.

Building environment

The concept of Gated Build is introduced and means that when a developer checks in, he can make a test build before an actual checkin. This would better hinder checkins which breaks the build.

The build scripts use Workflow 4, which enable a more graphical view of builds.

TFS Admin Console

A new client, targeting the administrator wanting control of his TFS and include the functionality which an administrator needs.

Test & Lab Management

This is a Windows client which does not require Visual Studio and target the needs of the tester. Here a tester can set up test manuscripts, run tests and report bugs. What was also really interesting was that while running tests, a tester can choose to record his steps and when filing a bug, he can automatically send a film or pictures of the situation. The recording can then also be used when verifying that a bug is fixed: the macro retakes all steps to the failing step, which makes the validation faster.

What also was interesting was the possibility to set up virtual environments for different test scenarios, for example different cultural settings and configurations. Since a test is run in a specific environment, we can keep better track of the environment in which the tests are run and not run. Also, when filing bugs, a snapshot of the environment at the time of the failure is possible.

Visual Studio for Architects

The seminar did not cover functionality in Visual Studio but notable is the inclusion of modeling in UML using Visual Studio. Use cases and processes can be directly modeled in Visual studio and linked to code and work items. Also, it is possible to automatically derive a model from a current system.

Since this is stored in the source control system, the models would be source controlled, which means that you can track changes of the system and even see which checkins have changed the model.

Query handling

The visualization of a search result has been improved since you can view a tree view or a link of the items and their directly related items. You can also click and drag to move work items in the hierarchy, for example if you want to move tasks between sprints or product backlog items.

Queries can now be collected in folders and you can also make rights settings these folders to hinder users from accidently changing common queries.

Source control

You can in TFS see graphically how branching and merging has occurred and using a graphical tool merge.

Web client

The user interface in the web access has been improved and include a dashboard functionality to enable views which are specific for the different types of users.

Microsoft Project tutorial Part 23 – Making a process diagram

When I’m using the Network diagram function in Microsoft, I always turn of the automatic placing of boxes. Format—>Layout:

Select Allow Manual box positioning and confirm with OK.

To create the first box, click and drag and when you let go of the mouse, a nex box has been created:

You can now click in the different fields, enter text and confirm by pressing TAB. For example:

If you move the cursor to the middle of the box and click and drag to outside of the box, a new linked task is created:

If you instead click and drag outside the boxes, a new unlinked task is created:

Also observe:

• You can use Indent and Outdent and all other commands as usual
• Double clicking a box opens the Task Information dialog box
• Double clicking a link opens the Link details dialog box
• Double clicking outside the boxes opens the Box Styles dialog Box
• If you switch view, for example to Gantt chart, the information in the Gantt chart is based on your changes here.

If you change the duration of a task to 0, the task becomes a milestone task. The form changes by this. Observe that you can using Box Styles specify which format and data all boxes have.

If you click and drag from one box to another, you can create new links:

Observe that you can use the zoom buttons to zoom in and out to view more or less of your diagram:

Microsoft Project tutorial Part 22 – Formatting your process diagram

In Microsoft Project, there is a view called the Network diagram. In earlier versions of Microsoft Project, this view was called the PERT diagram. Independent of which version, the view looks something like this:

If you switch to the Gantt Chart, you would (if you had the same network diagram) find a Gantt chart which looked something like this:

So, if you make a Gantt chart, you get a Network diagram and the opposite is also true. But, we’ll switch back to Network diagram to start decoding the boxes.

These are the heading tasks where the red belong to the critical path (see specific blog post about critical path) and blue does not. By clicking the little box in upper left corner, you can hide and view the subtasks of heading tasks.

On the left, normal tasks and on the right a milestone task (this is explained in blog post covering Duration) and again you can see the difference between critical tasks and non critical tasks. Well, critical according to Microsoft, anyway.

 

As can be expected, the network diagram comes with a bunch of settings. First, you can head to Format—>Box styles. Here you can edit all the different box styles. In the bottom part you can control shape and colors but you can in Data Templates choose which data is shown for that specific task type. If you don’t like the templates as is, you can click More Templates.

Select the template you wish to modify and click Edit. Here you can change the name and by clicking the cells in the middle grid, you can choose which field is shown in that position. On the bottom, you can change fonts and alignment. If you want to change number of cells to work with, click Cell Layout.

Here you can change the grid:

Observe that you can also select a specific box and select Format—>Box. Here you can make the same changes, but only to that specific box.

Another nice place to go is Format—>Layout. Here you can enable manual moving of boxes, how they are arranged automatically, if summery tasks are visible, if critical path is visible and how links are displayed.

 

In the next session, I’ll go into how you create a process diagram from scratch.

Domain modeling – the enterprise problems

On my previous position, I lived and breathed the domain model, the processes and even the information model. Since I was educated in the field, the terms and processes were also near me.

Having moved to a different industry: the leisure travel business, the tables have turned. I have a customer’s concept of the different terms and the domain and my customer’s concept is based on experience from one of the business models used in our business. TUI Travel consists of Fritidsresor in Sweden, Startours in Norway, Startours in Denmark, Finnmatkat in Finland, Tema (Swe, Nor, Den, Fin), Nazar and our flight carrier, TUIFly Nordic. That’s a lot of business models to keep track on. To make things more complex, we’re part of the European TUI group and some of our systems and processes are shared in the whole group. Having worked in a business mainly controlled by Swedish legislation, we now have local legislation in all our countries, and that include destination countries and even the countries we fly over. We also have international legislation on different levels.

Defining processes, domains, enteties and models are seldom easy but in and enterprise environment as mine, the challenge is enormous. How can one possibly set the domain model, information models and processes in such an organisation?

One can easily fall for the temptation that it’s not doable: but this is just not the right answer. Just because you work in the dark doesn’t make it easier. We need to turn on the light even if it’s challenging.

I don’t have any answers here on how we’ll do it. I can just say which methods I use:

1. Force yourself to use the terms that are present in the model. Make sure that you make yourself understood without having to add other words when you talk to business people.
2. Listen to others when they talk about the domain. If they stick to other words, you’ve probably not chosen the right word.
3. Don’t try to turn the big boat around. If people in general is using a word for "the wrong thing" in your model, change your model. People will still think about the old definition all the time. It’s not worth it.
4. Find out the extremes of your domain and test the terms on these problems. Does the models and processes still work when we apply the less than common situation?
5. Test the terms and process description on someone new. People get used to the models and terms so you should try and grab a person who does not meet the model every day. I work with 1500 people at TUI Nordic, so this is the least of my problems.
6. Don’t model everything upfront. Make it a ongoing process.
7. Involve the developers so they use the model in their daily work. Otherwise there will still be other factual models.
8. Make the model an in house model. Someone who is native to the organization has to be the one who owns the model so that it’s owned by the business. Consultants are not bad but they don’t know the business and your model will be clotted by IT terms like Invoice entity, which no business person would ever use.