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

Questions on smart use cases. Part III - Stereotypes and minimal use case specifications

Smart use cases have become a fairly straightforward requirements technique that we have introduced in many different types of projects, such as Java, .NET, BI, SOA, SAP projects. Often I receive questions on how to apply smart use cases in projects, this time from Ron Kersic (Capgemini).

Ron: If you apply smart use cases and the associated stereotypes, do smart use case specifications become unnecessary? If so, this is a massive unique selling point, and should get much more attention.

Smart use cases have a low and equal granularity. This low granularity (sub-function level) guarantees that use case specifications are never very long, and in general will not consist of more than pages of text, including alternative flows.

Example smart use case specification (in this case 2 pages)

Applying smart use case stereotypes
Additionally we standardize further by adding smart use case stereotypes. There is a growing list of smart use case stereotypes available. We occasionally add new ones, for instance I would like to add a Register stereotype soon.

Using these stereotypes, the scenario’s smart use cases run become very much standardized. Think of one of the most used stereotypes Manage, that is meant to maintain (add, update, delete) single instances of a particular domain object. It is more or less the same for any application, for any domain object in any domain. Why bother writing long use case descriptions for that? So we have templated it, both for documentation purposes, and also for code generation.

During analysis workshops, where we model out smart use cases together with our customers, we tend to model as many of the use cases we can towards using the well-known stereotypes. This saves an enormous amount of time and effort in projects – which yes is also a very good thing for our customers. They too will have less work on the project, and it gets delivered sooner, and better.

Model driven estimation
Moreover, as we apply the stereotypes during these workshops, and use code generation, we simply generate out an estimate (in an Excel spread sheet) for the project at the end of a workshop, using Tobago MDA and a simple template that runs over the use cases in the model. “Dear customer, this project consists of 298 smart use case points. It will take us 14 weeks to build it.”

So, to answer the question, yes smart use cases have some BIG unique selling points, and yes, we should give them more attention.

Sander Hoogendoorn
Principal Technology Officer Capgemini
www.sanderhoogendoorn.com

Posted by Sander Hoogendoorn on December 22, 2009

Questions on smart use cases. Part II - The smart use case life cycle

As you might have heard from me before (endlessly), smart use cases are a fairly straightforward reqirements technique that we have introduced in many different types of projects, such as Java, .NET, BI projects apply smart use cases, but also in service oriented projects, where smart use cases where used to model the front end and also the services and workflow.

At times I receive question on smart use cases in projects, this time from Belgium, by Erwin Bauwens. See Erwin’s original Dutch version below.

Erwin: In the smart use case life cycle all smart use cases go through the same stages (“New”, “In iteration”, “Working”, “Testing”, “Rework”, “Accepted”) from left to right. But, I take it, from “Rework” use cases go back to “Testing”?

And, additionally: it’s only the sub-function level use cases (or the user-goal level use cases without sub-function level use cases) that go through the cycle.

The smart use case life cycle identifies a number of stages smart use cases CAN go through. The stages proposed in Smart (the agile methodology the life cycle comes from) are not mandatory, but represent the most used stages. Some projects add stages such as “Design”, or split “Testing” into “Testing Team” and “Testing Customer”.

Having this simple staged smart use case life cycle allows projects to put up an nice dashboard – either on the wall or white board, or online using a dashboarding tool such as our Agile Dashboard, Mingle or VersionOne.

Example smart use case dashboard

In fact, ALL smart use cases go through this life cycle, not just the sub-function level ones or the user-goal level ones without additional sub-function level use cases. And indeed, coming from “Rework”, it is likely that the use case needs to go through “Testing” again.

Sander Hoogendoorn
Principal Technology Officer Capgemini
www.sanderhoogendoorn.com

Posted by Sander Hoogendoorn on December 17, 2009

Questions on smart use cases. Part I - Estimating user-goal and sub-function level use cases

As you might have heard from me before (endlessly), smart use cases are a fairly straightforward reqirements technique that we have introduced in many different types of projects.

Of course, Java, .NET, BI projects apply smart use cases, but this year I have also been involved in service oriented projects, where smart use cases where used to model not only the front end but also the services and the workflow. Works smoothly. The developed system has been in production since December 1 and is running fine.

At times I receive questions around the use of smart use cases in projects, this time from Belgium, by Erwin Bauwens. I’ll try to translate. See Erwin’s original Dutch version of the questions below.

Erwin: Now there’s an opportunity to apply smart use cases in a project. This brings forward some questions.

When estimating the complexity of smart use cases, is an estimate only produced based on the sub-function level use cases (at lower granularity), and is the complexity of the user-goal level use case merely the aggregate of these points?

Extracting sub-function level use cases from a user-goal level use case is NOT a functional decomposition. The single user-goal level use case always performs some part of the works. At least it’s responsible for co-ordinating the whole process it implements, but in most cases it also will own part of the user interface, like in the example below where user-goal level use case Site Overview show all information on the managed site.

Thus, it has the same level of granularity as the underlying sub-function level use cases. And it is also estimated using the same scale (1..5, 8, 10) as the sub-function level use cases. The total complexity of the diagram then is the aggregate of the weights of ALL use cases in it.

To follow the presented example, use cases Site Overview is probably rated as a 3 – Average on the smart use case scale. I would estimate the total diagram at 22 smart use case points, including the 3 from the Site Overview use case.

Sander Hoogendoorn
Principal Technology Officer Capgemini
www.sanderhoogendoorn.com

Posted by Sander Hoogendoorn on December 16, 2009

Creative plumbing. Or: rethinking the construction metaphor for software development

For as long as I’ve been in this business, I’ve heard a lot of manager, project managers, architects and other non-coders compare software development to construction. In this metaphor the architect creates the design and hands it over to the contractor, who does the work. In this metaphor the creative parts ends with the architect handing over the design to the builders. Now doesn’t that sound like a software development project to you?

City planning and blueprints
There is a lot of terminology in software development originating from this metaphor. Never heard an architect talking about the systems landscape, or that architecture is like city planning? And where did you think the term architecture itself originates from? Or the fact that we are building software? And aren’t we still discussing software construction and layered architectures? Did you know that in SAP projects people still refer to the design as a blueprint.

At first sight this metaphor makes sense. However, what has worried me about this metaphor over the past twenty years is that the creative part ends after the design is delivered by the architect. No pretty sight for developers eyes. In construction, this seems to be true. It’s the main reason construction is done by low educated workers against equally low wages.
Ignoring creativity

Converting this metaphor to software development, as a consequence, when the software architecture and design is done well, coding could be done elsewhere in the world by low educated people much cheaper than we are. This is where I highly dislike the construction metaphor. It considers coding as non-creative and repetitive work. It simply ignores creativity.

Moreover, it also surpasses the fact that, as agile projects prove, the quality of software improves at high pace when there’s regular contact with the customer during development, much like the idea that during construction of your new house you regularly visit the construction site and pass comments to the contractor.

So this is where it all comes down to. The idea that an architect sits at his desk and actually design the software at his desk, after having consulted the customer. This is were creativity is ends, and building the software begins, according to plan.

From this crippled metaphor traditional methodologists have fantasized the living daylights out of us poor developers. We were made to believe that software development is a craft rather than creative work. If the architecture is set out correct and presented nicely, building the software is low skilled, repetitive work. And hence, it can easily be outsourced, offshored and done by low educated third world software developers.

So if all this would be true, and construction is a good metaphor for software development, why is it not all projects are delivered successfully, on-time, and on-budget?

Watching plumbers
I’ll tell you why. Last week my new house was delivered by my contractor. Since then, all of the sudden, I’m surrounded with lots of activity in and around the house. This activity falls in the fore mentioned category of low skilled, non-creative work. The house is crowded with plumbers, carpenters, friends with DIY capacities, gardeners. Some of them build closets, others construct my bathroom, whilst others lay floors or grass. And me? I’m constructing a attic in the garage with a friend.

When I was watching our plumbers reconstruct my bathroom, it occurred to me. After over twenty years in this business, I finally saw the light. Having opposed the house building metaphor for software development for so long, it’s time to see things through. Time for a little re-construction.

The plumbers in my bathroom, both in their early fifties actually quite enjoy their work. As I enjoyed constructing an attic in my garage. They were singing and making (lousy) jokes. Why is it, I wondered, that these middle aged, low educated construction workers whistle and make jokes during this work, that they’ve probably been doing since they left high school. Why?

I’ll tell you. It’s creative work. They try to make the water taps fit in the wall of my bathroom. It’s a puzzle. Drill bits and holes in my wall, fitting the taps again. It’s even fun watching. It’s actually quite like I would address software development. Build it, try it out, test it, and possibly refactor the code. The plumbers actually work quite agile. During the process they ask me where I want the tap, where the shower should be, or they propose suggestions on the tiling plan. Although the bathroom isn’t finished yet, I’m quite sure it will work out fine.

Applying patterns
And moreover, the plumbers work is bound by the bathroom architecture we’ve laid out, and even more by patterns, just like developing software is bound by software architecture and by design patterns. The plumbers know how high the shower regularly sits on the wall, how many centimeters they will have to drill in the wall to make the tap fit, just like I will use some implementation of a model-view-controller to implement the user interface, and domain driven design to construct the domain layer of my application.

And you know what, to round up my argument, they make errors too, just like we software developers do. And yes, they make repairs, like we do. It’s a bit like refactoring. They try to create a solution, but if it doesn’t work, they’ll fix it, and try something else. Just like I would refactor my code, if it doesn’t perform.

But most of all, there’s one simple thing that binds us software developers to gardeners, plumbers, and carpenters. So much for the construction metaphor. No doubt about it. Just like software construction. It’s creative work. Don’t let anybody ever tell you otherwise.

Sander Hoogendoorn
Principal Technology Officer, Capgemini The Netherlands
www.sanderhoogendoorn.com
twitter.com/aahoogendoorn

Posted by Sander Hoogendoorn on July 6, 2009

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

Delivering products in agile (Smart) projects

In most cases where a form of agile software development is applied, projects are challenged with difficult issues, such as a swaggering scope, unclear and incomplete requirements, unstable software architecture, are quickly approaching dead lines. Within these strict boundaries projects try to deliver high quality software at high productivity - or velocity. This is not an easy challenge.

Delivering just what is needed
Therefore, during agile projects there is high pressure on delivering just that what is needed. The emphasis of an agile project team is on creating just the right (amount of) software, and minimizing the amount of work spent on other products, such as documentation and work in the peripherals of the project. Although many project teams seem to call on this principle to actually not deliver any documentation, the fine art of being agile is delivering just-enough, just-right documentation.

In our experience, a lot of time is spent in agile projects on deciding what's enough, and moreover, what's right. Especially when projects are executed in complex organizations, and applying complex (service or cloud oriented) technology, finding the right level of documentation is actually a quite intriguing task, and goes beyond writing (structured or not) user stories.

Delivering products
In the vision of the agile process Smart (and other agile processes, including Scrum and feature driven development) projects should focus on delivering products, not just on performing activities. Please note that working software is not the only product a project delivers.

The agile process Smart suggests to deliver a number of products that will guide projects through these just-enough, just-right in a more standardized fashion. In essence, Smart projects are product driven, as are other agile processes such as Scrum, FDD and OpenUP. During each of the iterations in a Smart project, the team delivers a number of working products. These products fall into a few categories:

• Project deliverables. In each of the different types of iterations Smart suggests to deliver additional products that will help drive your project to success. These products might include well know deliverables such as a project proposal and non-functional requirements. Although none of these product are actually mandatory in a Smart project, they are considered good practice, and over the years have been produced in numerous Smart projects. Using these standard suggested products, organizations get an even better grip on the projects at hand. Note that emphasizing the existence of other project deliverables besides working software (in smart use cases) does not mean projects become less agile.
• Smart use cases. The body of products delivered in a project is formed by smart use cases, small discrete pieces of functionality that drive development. Smart use cases is a technique to rapidly model your functional requirements at a equal-granular level. Smart use case supply a small and very useful unit of work, and furthermore serve as the main unit of estimation, planning, but also drive realization, testing and even delivery.

All products, both project deliverables and smart use cases run through (a subset of) the product life cycle.

Project deliverables
All products that need to be delivered to run your projects and do not deal with implementing functionality directly (which moreover is partitioned in smart use cases) are referred to as project deliverables. Most of these project deliverables are one-off, although they might be maintained and updated during the project, such as the project's software architecture and the domain model. Any Smart project needs to decide which of the suggested project deliverables will be produced, and in which iterations.

An easy way to achieve the optimal set of project deliverables is to add the products suggested by Smart to the project's backlog during the different iterations defined in the Smart process. Or alternatively, add them to the backlog at the start of the project. This allows project teams to add them to the list of products to deliver in any of the iterations.

For example, during the first Propose iteration the smart use case model, a project estimate and a project proposal can be added to the iteration backlog. At the start of the Scope iteration, the software architecture and reusable services might be added. At the start of each of the iterations, the customer and the project team decide which of these products will be picked up and produced.

Examples of project deliverables
Some examples of project deliverables are:

• Project proposal. A first proposal covering the primary scope of the project and a first cut estimate is produced as a the final project deliverable for Propose iterations.
• Project plan. The project plan describes the project approach, the stakeholders and goals, business case, risks, resources, timelines and project estimate. The project plan is mostly delivered at the end of Scope iterations.
• Iteration plan. For each iteration a very brief iteration plan might be documented, sometimes not longer than a single page. This iteration plan describes the list of products (mostly smart use cases) to be implemented and resources needed. In most projects, iteration plans result from the planning session at the start of each iteration.
• Software architecture. Document describing the architecture for the project. Ideally, your software architecture is an instance of a reusable reference architecture that might be in place at a organization. Having a reference architecture will allow a project team to focus only on deviations. This saves valuable time and effort.
• Business process model. Most projects implement one or more business processes, and a number of additional functions that support these processes. Smart use cases can be derived from these business processes, independent of how these processes are modeled. The business process model is either obtained from the organization, or created during the project.
• Smart use case model. The smart use case model is leading in Smart project. It delivers software estimates, and presents an overview of the scope of the project.
• Domain model. Most custom software development projects will have a model describing the business domain and business services. Sometimes this model stems from previous version of the software, for instance modeled in a data model. In service oriented projects, the domain model in most cases overlays the services called in different back end systems, as forms the basis for a service consuming front end.

Again, in most cases these deliverables are one-off. They are created once during a project, but quite often maintained or updated later on, think of the domain model and a reusable services model.

Smart use cases
Most of the work in delivering working software in iterations that are of type Realize or 'Finalize'' relates to the realization of smart use cases. The smart use case has become our main unit of work. They are implemented following the product life cycle. The work on each individual smart use case includes analysis, design, test design, build, test and acceptance. This work is always visualized using an agile dashboard, either using post-its on a wall, or using an (online) automated dashboard.

Sander Hoogendoorn
Agile evangelist

Read more
You will find more information on these subjects at: www.accelerateddeliveryplatform and www.sanderhoogendoorn.com

Posted by Sander Hoogendoorn on May 11, 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