ATMAN’s paper accepted to ICSE 2009 SDG workshop

March 4th, 2009 by Ilkka Lehto

Our paper was accepted to Software Development Governance workshop at ICSE 2009. The workshop is now arranged for the second time and we are happy to participate again. Link to full paper.

Software Development Governance Challenges of a Middle-Sized Company in Agile Transition

Ilkka Lehto & Kristian Rautiainen 

Abstract

We studied how a middle-sized Finnish company
employing agile methods governs its software product
development. Through observations and interviews we
followed the trace from strategic plans in the form of
roadmaps to various backlogs and all the way to daily
work. The governance roles, responsibilities and deliverables
seemed to be in place on different organizational
levels. However, closer inspection revealed
challenges in the practical implementation. There were
too many roles and hierarchy levels with information
consistency problems in between. Prioritization of the
high-level goals was unclear and made it difficult to
plan and organize development work based on business
value. The trace from high-level goals to more
detailed plans was easily corrupted due to poor planning
practices. Progress monitoring of daily work was
poorly done and not linked to high-level plans. Consequently,
the required feedback loops were inadequate,
making it impossible for management to take corrective
actions in time.

 

Ville Heikkilä’s Master’s Thesis has been published

December 3rd, 2008 by Ville Heikkilä

A new ATMAN related deliverable has been published.

The deliverable is the Master’s Thesis of Ville Heikkilä on the topic of “Tool Support for Development Management in Agile Methods”.

In addition, the Master’s presentation slides and audio recording can be downloaded. The files can be found here.

The first paragraph of the thesis abstract:

The goal of this research was to find out what requirements the most prominent agile methods and the case company have for a development management tool and to determine if an existing tool that sufficiently fills the requirements can be found. Many tools have been developed to facilitate the management of work and requirements in agile software development projects since the mainstream breakthrough of agile software development methods following Agile Manifesto in 2001. However, it is not known whether the tools that are publicly available actually meet the requirements that the agile methods have for managing work and requirements. Pre-existing research on the topic has concentrated on generating a set of requirements and building a new tool which is based on those requirements.

The Leffingwell Framework

November 30th, 2008 by Jarno Vähäniitty

(also known as “Enterprise Agility – The Big Picture”)

Dean Leffingwell’s Scaling Software Agility blog contains an interesting article series on the Big picture of enterprise agility. Dean’s “world model” is shown below.

So far, Dean has posted in more detail about various aspects of this big picture, such as the teams, iterations, the role of the product owners, product managers and estimating epics. Just recently, he has started dissecting  portfolio management. I was so enthused to read the entries I am currently reciting the entire series as podcasts…stay tuned for these.

In the meanwhile, check out the entire series (and subscribe to Dean’s blog)!

“Rescuing Scrum teams keeps me in business”

November 19th, 2008 by Jarno Vähäniitty

James Shore on the “decline and fall of agile development“; read and enjoy.

“I’ve seen a shift in my business over the last few years. In the beginning, people would call me to help them introduce Agile, and I would sell them a complete package that included agile planning, cross-functional teams, and agile engineering practices.

Now many people who call me already have Agile in place (they say), but they’re struggling. They’re having trouble meeting their iteration commitments, they’re experiencing a lot of technical debt, and testing takes too long. So they hire me to help them with one of these things. When I go visit, I see a team that is nominally agile, but is suffering huge numbers of problems and is anything but the joyful, settled, smooth-running workplace I expect from an agile organization. …”

What’s wrong with these user stories?

November 18th, 2008 by Jarno Vähäniitty

Now, a question for you guys. What - if anything - is wrong with the user stories below? Check out the context from a previous blog post.

  1. [Add parent] As a product owner (PO), I want to be able to add one or more URL-pointers (*) to a backlog item in the Edit tab so that I can denote its children.
  2. [Add children] As a PO, I want to be able to add a single URL-pointer to a backlog item or a sprint goal in the Edit tab so that I can denote its parent item.
  3. [Add reciprocal relationships] As an Agilefant user, I want that when parent or child relationships are added, the respective reciprocal relationship(s) are created as well so that I don’t have to go and add them separately.
  4. [Create child] As an Agilefant user, I want to be able to create a new child for a backlog item (that inherits all the relevant properties of the parent, such as themes) directly from the parent item’s edit tab so that I don’t have to go copy-pasting the parent’s URL pointer and remembering its various properties. For the same reasons, I want to be able to transform a ‘todo’ to a child item from the Progress tab.
  5. [Show child progress] As a PO, I want that the status of child items shown in parent items like todos are so that I can evaluate the progress of the parent item (it is possible for an item to have both todos and children; progress of grandchildren or child’s todos do not have to be shown in any way)
  6. [Navigate hierarchy from list] As an Agilefant user, I want to be able to navigate to an item’s parent or children directly from backlog item listings (such as daily work, product, project, iteration) without opening the item in question so that it is feasible for me to study the hierarchy.
  7. [View relatives from list] As an Agilefant user, I want to be able to see the names of the parent and child items of a backlog item directly from backlog item listings (such as daily work, product, project, iteration) so that it is feasible for me to study the hierarchy.
  8. [Create sibling] As an Agilefant user, I want to be able to create a sibling for a backlog item (that inherits all the relevant properties, such as parent, themes, iteration goal, etc.) from the backlog item’s edit tab. Likewise, I want to be able to transform ‘todo’s into siblings from the Progress tab
  9. [Navigate hierarchy from edit tab] As an Agilefant user, I want to be able to navigate to an object’s parent or children from the Edit tab so that it is feasible for me to study the hierarchy.
  10. [Mass change parent] As an Agilefant user, I want to be able to denote the parent item for several backlog items in a single operation (”mass change parent”) to ease the transition to hierarchical backlog items

Those giving the best answers will be awarded with Agilefant merchandise! :-)

The role of backlog items in iteration planning

November 18th, 2008 by Ville Heikkilä

In my last ATMAN Blog post I wrote that splitting backlog items directly into tasks is not a good idea and that all backlog items selected into an iteration should be taken into account when creating tasks. I was wrong.

After listening Kristian Rautiainen give a lecture on agile project management I came to realize that just considering the backlog items selected to be realized in the iteration is not enough. When tasks are created, everything that affects the implementation of the software source code must be taken into account. In a multi team environment this includes technical dependencies between teams. Although some agilists are against such planning, the backlog items that are very likely to be included in the next few iterations should also be taken into consideration. Emergent architecture simply doesn’t work in any non-trivial software and building the right amount of modularity in the first place will save some refactoring work later.

Mike Cohn on One Piece Flow

November 17th, 2008 by Jarno Vähäniitty

Mike Cohn just blogged on one piece flow.

“…So, while I think swarming in this way is an excellent technique to use sometimes, I don’t think it should be the default way of working for very many teams. Some may benefit from it over the long term, but most will find that it introduces too many opportunities to be in someone else’s way as they try to make progress. I consider it equivalent to a drill that a team may do to improve a skill–good to use for practice but not the way to do something forever.”

Check the entire  entry and the discussion that follows.

A bunch of user stories to kick off Agilefant’s hierarchical backlog items implementation

November 16th, 2008 by Jarno Vähäniitty

Here are a bunch of stories for Testarossa’s upcoming sprints. These already add a lot of value and I’d consider it a success if Testarossa would deliver them.

I’ve put in quite a bit of implementation-related detail to demonstrate how little must be changed in terms of Agilefant’s user interface.

Listed in relative order of importance (subject to change, however):

  1. [Add parent] As a product owner (PO), I want to be able to add one or more URL-pointers (*) to a backlog item in the Edit tab so that I can denote its children.
  2. [Add children] As a PO, I want to be able to add a single URL-pointer to a backlog item or a sprint goal in the Edit tab so that I can denote its parent item.
  3. [Add reciprocal relationships] As an Agilefant user, I want that when parent or child relationships are added, the respective reciprocal relationship(s) are created as well so that I don’t have to go and add them separately.
  4. [Create child] As an Agilefant user, I want to be able to create a new child for a backlog item (that inherits all the relevant properties of the parent, such as themes) directly from the parent item’s edit tab so that I don’t have to go copy-pasting the parent’s URL pointer and remembering its various properties. For the same reasons, I want to be able to transform a ‘todo’ to a child item from the Progress tab.
  5. [Show child progress] As a PO, I want that the status of child items shown in parent items like todos are so that I can evaluate the progress of the parent item (it is possible for an item to have both todos and children; progress of grandchildren or child’s todos do not have to be shown in any way)
  6. [Navigate hierarchy from list] As an Agilefant user, I want to be able to navigate to an item’s parent or children directly from backlog item listings (such as daily work, product, project, iteration) without opening the item in question so that it is feasible for me to study the hierarchy.
  7. [View relatives from list] As an Agilefant user, I want to be able to see the names of the parent and child items of a backlog item directly from backlog item listings (such as daily work, product, project, iteration) so that it is feasible for me to study the hierarchy.
  8. [Create sibling] As an Agilefant user, I want to be able to create a sibling for a backlog item (that inherits all the relevant properties, such as parent, themes, iteration goal, etc.) from the backlog item’s edit tab. Likewise, I want to be able to transform ‘todo’s into siblings from the Progress tab
  9. [Navigate hierarchy from edit tab] As an Agilefant user, I want to be able to navigate to an object’s parent or children from the Edit tab so that it is feasible for me to study the hierarchy.
  10. [Mass change parent] As an Agilefant user, I want to be able to denote the parent item for several backlog items in a single operation (”mass change parent”) to ease the transition to hierarchical backlog items

(*) Pasi has already implemented backlog item/sprint goal/theme -URL-pointers in a branch.

There’s also lots of unresolved issues. For example:

  • How should effort estimates work? For now, let’s leave them untouched.
  • Should moving / prioritising parents move / prioritise children as well? For now, let’s leave that out as well…
  • Should children who reside in the same backlog as their parents be shown as separate items or “be hidden” somehow? For now, no hiding, treat as separate items.

However, I think the steps above are where we should start from. There’s the specs, now start coding! :-)

Agilefant’s Big List of Tools now freely editable

November 16th, 2008 by Jarno Vähäniitty

Our Big List of tools for project, backlog and development portfolio management on Agilefant’s Related work page contains currently over 150 tools, and may just be the most comprehensive listing on the Internet.

It is now also freely editable by anyone who’s interested!

If you have evaluated some of the tools and know of their pricing - as we know you do, please update this info to the list for everyone’s benefit.

If you are a tool vendor or developer yourself, you can also add your own solution and/or update its info!

Project.net

November 15th, 2008 by Jarno Vähäniitty

Today while updating the Related work section and the Big List and  at Agilefant.org, I stumbled across a solution called Project.net.

Seems a quite (typical) ERP-like take on project and portfolio management - complete with servicing & training & stuff - but the surprise was that it was open source!

So, in my eyes, it has potential for greatness - and certainly something I might recommend. We’ll get back to you once we’ve more thoroughly checked it out to tell you what we saw.