Introducing our agile dashboard

The Accelerated Delivery Platform’s (ADP) Agile Dashboard is a pragmatic and publicly available tool (free) for managing project progress online. The Agile Dashboard was originally intended to manage progress for our agile projects, but these day it is used in a much broader perspective.

As the ADP Core Team receives a lot of questions about it, it’s time to present a small introduction here, including future directions.

Administrating projects
The Agile Dashboard simply administrates projects, project teams, work packages and work items. Furthermore, the Agile Dashboard allows you to define statusses your work items go through. In a typical Scrum project you will likely have ToDo, Working and Done. In a typical Smart project this will likely be New, InIteration, Working, Testing, Rework, Done, Dropped.

Managing work items
Work items such as user storie or features can either be added manually, or via a straightforward import feature that allows UML models to be imported in the Dashboard (from XMI). As Smart projects evolve around implemeting smart use cases, use cases can be marked as work items automatically. For each work item the complexity of the item needs to be established. Whem importing a UML model using smart use case stereotypes, establishing complexity is automatically handled.

The actual Dashboard
The main page in the Dashboard shows the progress of your project’s work items, or a the work items in a single work package, as shown below. This page will give you an immediate overview of the project.

When a work item changes status, e.g. when development is done, the user can drag-and-drop the work item to te next status, in this case for instance Testing. This pop-ups a next page where the user can add comments, and give an estimate for the amount of work still needed on the work item. Note that this is typically an action that is done during stand-up meetings.

Real-time burn-down
This information is used by the Agile Dashboard to recalculate the burn-down chart for the project real-time.

The freely available Agile Dashboard offers very basic functionality and does not excel in abundant charting and progress reporting. This is done to make managing progress in projects as easy as possible – albeit the Dashboard could do with some minor useability improvements.

Using the Agile Dashboard thus presents real-time project progress. It’s online availibility makes it suitable for distributed scenarios, e.g. in offshore – we e.g. manage projects with it that are executed on several locations simultaneuously in the Netherlands and India.

Sander Hoogendoorn
Principal Technology Officer Capgemini
www.sanderhoogendoorn.com

P.S. There's an additional part to this post on my personal blog, that elaborates on the new features of the dashboard, to be implemented as soon as possible. Check it out at: Introducing our agile dashboard.

Posted by Sander Hoogendoorn on January 23, 2010

Beyond agile testing. Or: how to become a pro-active tester

Agile – in all it’s variations – becomes an increasingly popular process for realizing software. The roles testers and testing plays in these projects is challenging and new. Testers are no longer considered code-killers, but can play – and are expected to play – a very pro-active role in agile projects.

Although all agile process agree on the importance of testing, unfortunately many of these agile processes do not elaborate much on the specific role testers have. Testing is often referred to in unit testing, which is really a developer technique. Much less attention is given to true functional testing, performance testing, integration testing and acceptance.

Tester and developer closely collaborating

To investigate where testing and testers can play this vital new role you will need to see what it means for projects to be agile – beyond the scope of the processes available, such as XP, Scrum, Lean, Kanban and Smart. It’s about close collaboration of all different roles, finding the right unit of work (that also needs to be testable), defining short iterations, celebrating feedback and delivering fast and early.
Testing from day one

When introducting agile and testing to each orter, in short a number of questions pop up:

• What is this agile stuff anyway? To traditionally organized projects and organizations it is not self-explinatory that testing and testers will be in the project from day one.
• How does an (a)typical agile team look like? Many agile processs do not include the roles of testers, but rather stick to the traditional agile Bermuda triangle of coach-customer-developer.
• What can be the role of testers in agile projects? In my personal experience, that comes from doing projects in all kinds of processes, testers do play a vital role in almost all activities in a project. Testers can influence projects positively during software estimation (test effort is always underestimated), requirements gathering (what scenarios apply to a use case?), (test) design, and even development in agile projects. There are very good reasons for have an explicit test role in agile projects, as the somewhat more structured agile process such as Smart and DSDM emphasize.
• What’s a good unit of work in agile project when it comes to functional testing? Do we apply user stories, features or smart use cases? In my opinion, adding some structure is not too bad, especially when it comes to larger, more complicated projects such as service oriented or cloud oriented projects. User stories will be a to adhoc techniques to deal with in such projects. Features, but especially smart use cases add this little bit of structure and reuse that make life easier.

Sander Hoogendoorn
Principal Technology Officer Capgemini
www.sanderhoogendoorn.com

P.S. There's an additional part to this post on my personal blog, that elaborates on a new talk I created to this subject, aimed at introduction agile to testers, and agile testing to (agile) project managers and project teams. Check it out at: Beyond agile testing

Posted by Sander Hoogendoorn on January 8, 2010

Are user stories an alternative to (smart) use cases?

About a week ago, someone (from the UK) send me an email with the following question:

I like your article on Smart Use Cases. Before I throw my hat in the ring on this, could you tell me your feelings on User Stories as an alternative to Use Cases?

To be quite honest, I’m not much in favor of using user stories. In my honest opinion, user stories are too unstructured to serve as a good unit of work in larger projects – although some projects actually benefit from having unstructured requirements. However, in my opinion regular use cases are unsuited to, as they differ too much in both complexity and granularity. For example, I have seen projects where implementing a single use case took several months. Not really handy in projects that are based on two week iterations, such as the agile projects we run.

We have therefore proposed our smart use cases – and have been using them for the last ten years, with ever growing success. Smart use cases are smaller, equally granular and more structured, but do not require much more elaboration than user stories. When it comes to larger projects, including for instance business intelligence and service oriented projects, smart use cases much better reflect the mapping from business processes and workflows to software development.

Furthermore, to work on user stories in iterations in agile projects (or sprints if you prefer), the user stories are broken down into tasks. Unfortunately, since user stories can be very different in nature, so are the tasks. When we use smart use cases, the tasks are always similar, that is, we design, test design, build (and quite often generate), test, rework, accept or drop them. In most projects in an almost daily cycle (the Smart product cycle). The agile dashboard in our projects actually reflect these solid tasks, which makes planning them easier.

Another argument for preferring smart use cases over user stories, is that they can be estimated on an abstract scale rather than in hours. Important is that this estimation process is repeatable, and can be done by anyone (of course with some knowledge).

Over the years we have created a rich vocabulary of smart use case types, including types for maintenance, reporting, services, BI and file exchange. Applying this vocabulary (in stereotypes) allows for fast but structured requirements modeling.

Some links can help you further investigating this material:

• Smart use cases versus regular use cases. http://www.accelerateddeliveryplatform.com/SmartUseCase
• The agile Smart process. http://www.accelerateddeliveryplatform.com/SmartLifecycle
• Estimating smart use cases. http://www.accelerateddeliveryplatform.com/SmartEstimation
• Smart product life cycle. http://www.accelerateddeliveryplatform.com/SmartUseCaseCycle
• Smart use case stereotypes. http://www.accelerateddeliveryplatform.com/stereotypes

Love to hear your feedback and opinions.

Sander Hoogendoorn
Principal Technology Officer NL
twitter.com/aahoogendoorn

Posted by Sander Hoogendoorn on June 28, 2009

Some tips on distributed agile projects

I started using Twitter – no, this is not another post about Twitter – to investigate if it could help me innovate. And guess what, it kind of helps. Since I started writing tweets around the agile SAP SOA project I’m coaching, people started showing interest, and asking questions.

Last week I received to following email:

Hi Sander,
I have been following you work during the last days, and mainly the SCRUM SAP stuff, and the work done is really great.
I am planning to start SCRUM and apply in the company. I will lead a group of 5-7 people but I have a limitation, my developers will be in Argentina, me and 1 domain expert are in Costa Rica, Another one in UK and in future 1 more in Asia.
In the company we have lot of tools for sharing and control so I might try to mitigate those limitations, but time zones might impact and I am concerned.
i have read many discussion talking about Agile is not for remote locations but also people saying it doesn’t apply always. I know daily scrums / stand up. We will lack of face-to-face, but I hope to take advantage of webcams and many other tools.
Hope you can provide input about this situation and provide some tips on how to start and apply.
I really want to make difference and remove the old-style waterfall from managers and peers minds.

So I answered back. Some remarks first:

• You have an extremely distributed project! This makes work very difficult, not only in waterfall style projects, but in agile projects to.
• Be sure that tools will help, but they will not totally solve the problem of distributed communication. Face-to-face as you might except always beats distribution.

• We have similar experiences as you find in the literature. Especially, in applying short iterations face-2-face is always important.
• Still, an agile approach is always preferable over waterfall.

Some tips:

• Create agile awareness. Make sure the whole team is very well aware of the fact that they are in an agile project, meaning being open, share work and responsibilities.
• Organize joint kick-off. A one or two day joint kick off is preferable. Show how and why agile works, what is expected in everybody’s roles, and establish the scope for the project. After the kick-off, people will know each other, and communicate easier afterward.
• Apply standardized and small unit of work. Apply a highly standardized type of functional work item. This will save valuable discussion. (User) stories do not apply, they allow for far too much discussion and do not allow for reuse or repeatable estimates. We use smart use cases in a lot of our projects (also in agile SAP (SOA) projects), which we have standardized on a lot of aspects, such as estimation, testing, code generation. For more information please check Smart use cases.
• Apply online dashboard. In our distributed projects, we love to apply an online agile dashboard. Never forget to use the simplest tool that still does the work. ThoughtWorks’ Mingle will do, but is fairly complex but is not for free. However, there are free-of-charge alternatives. You might even use our Agile Dashboard, which is not perfect, but free-of-charge. See Agile Dashboard and Agile Dashboard 1.3.

Sander Hoogendoorn
www.sanderhoogendoorn.com

Posted by Sander Hoogendoorn on April 10, 2009

Agile software estimation. Should I apply user stories or smart use cases?

The process of creating a sound estimate for your project will take some time in any agile project. You will have to define what work to do in the project. In general this work can be split up into two parts:

• Project related work. There's project related work, such as creating a project proposal or setting up your development environment. The agile process Smart suggests a number of such project related work items to be added to your backlog.
• Functionality. And then there's the functionality related work. In processes such as Scrum and XP this work is specified in (user) stories. In the Smart process we apply smart use cases, whereas in feature driven development (FDD) features are used.

Defining work
To create an estimate for your project, you will have to establish a number, in point, hours, pizza parts or whatever, for both types of work items. For the project related work items, this is fairly simple. How much time do your need to write the project plan? How much effort goes into setting up the development environment? The hard part here is to estimate the amount of functionality the project will realize.

Estimating this requires you to write down the stories, or in Smart to model the smart use cases. This will take some time, especially when you apply user stories as your main unit of work. The problem with estimating user stories is that each new user story is a new case. As user stories are (under normal circumstances) rather unstructured, there is no easy comparison possible with similar (previous described) types of user stories. Hence, the estimate will always be rather inaccurate.

Smart estimation
Using the agile process Smart we apply a specific way of modeling use cases, and apply these as our main unit of work. We model down use cases one level deeper than you would "normally" expect to do. Alistair Cockburn refers to this level of use case as sub-function level use cases. We refer to the collection of user goal level use cases plus sub-function level use cases as "smart use cases". They are equally granular and equally complex. And thus, they can be estimated by different teams in different locations, and in different types of projects in a similar way and on the same scale. Furthermore, we have built up a list of standardized types of smart use cases (stereotypes) from all kinds of projects. Smart estimates appear to be rather reliable (and repeatable).

Estimating agile SAP
For instance, I'm currently coaching an agile SAP project (not exactly the type of project you would expect to turn agile), and we've modeled and estimated the smart use cases in about three days with the team – more or less the time you would spend in writing stories for the project. This initial investment of three days, which in Smart project is normally one of the work items advised to put on your backlog anyway, pays back soon, as the smart use cases also make up the larger part of your product backlog.

www.sanderhoogendoorn.com

Posted by Sander Hoogendoorn on April 1, 2009