Thursday, August 21, 2014

Governance in Agile Projects

Project governance is a reality in many large software development organizations.  Whether you like it or not, there are many valid reasons for software development needing to comply with governance covering a variety of topics, depending on the context in which the project is executed. Good governance covers and mitigates risks that projects may form for the wider organization without imposing too much of  a cost on the project in terms of speed of delivery and budget. These risks can be related to legal, financial, security, reputational, operational and health and safety risks and this list does not pretend to be complete.

For instance there will be a slew of security and legal requirements that need to be fulfilled if you are developing a personal banking site for a financial institution. A system to manage and consult medical information will be subject to privacy laws. In an industrial setting there will be environmental and safety requirements that may have an impact on IT systems. So how to deal with governance requirements in an Agile project, where you just want to be as productive as you can without being hindered by apparently unnecessary rules that just seem to complicate things and slow you down?

Well, first of all, too much of a good thing is not a good thing, and too much governance, like too much government, tends to have a range of unintended consequences. So when deciding on the specifics of governance that your projects need to comply with, it is important that for each of the rules and standards you intend to implement it is perfectly clear which problem you are trying to solve or which risk you are intending to mitigate. Too often you hear statements like ‘All our projects need to comply with rules so and so because that is just what we decided to do many projects ago based on our experience with these projects and it is since then the way we do things around here’.

Aha, is that so? Well, I’ve got a few questions then:

  • The projects you refer to, what kind of projects were they?
  • Do you still do the same kind of projects technology wise, functionally, organizationally, scale wise, budget wise?
  • Are the risks and issues you identified back then still relevant today?
  • Are the mitigation options still valid?
  • What about new technology since then, does this not allow for addressing some of these risks to be handled differently?
  • Are the people still the same, or have most if not all in the meantime been replaced?
  • For external customer facing projects, are the market expectations still the same, particularly in terms of quality and speed to market?
  • Is your market position still the same
  • Have new regulations come into effect, or existing ones changed or abandoned?

The answers to these questions will likely lead you to revise existing governance frameworks and specific rules. Rules for which the motivation and relevance are clear are much easier complied with.

Once you have a pragmatic and reasonable set of rules for your governance framework, it must be made sure it is in fact adhered to. The best way to do this is to explicitly include it in your definition of done, and if some rules do apply to certain user stories only, then they need to be reflected in the individual acceptance criteria for these user stories. It is of course important that the Product Owner puts sufficient emphasis on this when accepting new functionality as Done. It is an area where it can be very tempting to skip a few rules in order to be quicker in the market, but this is a risky strategy. In the type of organizations where governance becomes necessary, there will be steering committees and program boards and release management and it is up to them to make sure that team members, the Product Owner and Scrum Master are aware of the need for this, while at the same time avoiding to become just an administrative hurdle to take on the way to production. The latter will occur when the motivation for certain rules is unclear, this will lead to rubberstamping of certain aspects of governance compliance.

Monday, May 20, 2013

Agile Metrics

Metrics play an important role in project management. They are the primary way to monitor and communicate the status and progress of a project to senior stakeholders. I already mentioned several metrics in previous blogs, but I’d like to sum them up all together.

The first metric, and one that was defined in Agile and has no counterpart in traditional project management, is the velocity. This is defined as the number of story points per sprint that can be delivered by the Team according to the Definition of Done. The velocity is important because it will tell you when all scope on the backlog will be done, it will tell you when you run out of scope. If the velocity drops from one sprint to the next, there should be an explanation for that. It may be that some team members fell sick. Maybe there where a few national holidays. Maybe the user stories that were put on the sprint backlog where more complicated than thought. There can be a wide variety of reasons why the velocity varies between one sprint and the next or why it deviates from the average so far. If those reasons are one-offs, you need to see if there is a way to make up for the loss to keep the project on track, or have the Product Owner come to accept the drop in scope. If the reasons are structural, you need to make the Product Owner and senior stakeholders aware that there is an issue and that expectations must be adjusted.

Burn Rate
The burn rate is the budgetary counterpart of the velocity. It is defined as the amount of man days that are spend during a single sprint, by everybody who books on the project. If your project has several scrum teams, you may want to split out the burn rate for each of the teams. If there are people booking on the project who support the teams, like business analysts, product owners, anyone who is not part of a scrum team, then these costs should be evenly distributed among the teams as to get a burn rate per team that includes indeed all costs that are made to have that team deliver software. Where the velocity will tell you when you run out of scope, the burn rate will tell you when you will run out of budget. If you have a fixed deadline, then the velocity tells you what will be delivered by that deadline and the burn rate will tell what you will have spent.

Defect Detection Rate 

The defect detection rate is the amount of defects detected per sprint. Assuming that developers produce defects at a more or less constant rate, it is correlated with the velocity; the more story points are delivered, the more defects should be found and fixed as well. Teams tend to be pretty consistent in the quality of the software they deliver, so a drop in velocity combined with a rise in the defect detection rate should trigger the alarm. Something’s cooking and you need to find out what it is. My personal opinion is that a lower defect detection rate isn’t necessarily better than a higher one. A defect more found in one of the development and test environments is a defect less that makes it into production. From that perspective, you could support the statement, the more defects the better.

Defect Closure Rate 

This is the amount of defects fixed and closed per sprint. It should be equal to the defect detection rate. If it’s not, the amount of open defects will rise as you move along with the project, leaving the largest part of the bug fixing for the end of the project. This brings me to the last metric.

Gap Between Total and Closed Defects 

This is the difference between the total amount of defects and the amount of closed defects at any one time. This number should be as low as possible. A low number indicates that the quality of the delivered software so far is good. That implies that there will be few if any surprises once UAT and release preparation starts. And that in turn implies that the velocity and burn rate you have measured are indeed reliable indicators to forecast the remainder of your project. I consider this the most important metric of all, for if it’s low, it means I can indeed rely on the other indicators.

A healthy project has a stable velocity and burn rate, combined with a stable and sufficiently high defect detection rate and a low gap between total and closed defects. The velocity and burn rate will ideally indicate that you will run out of scope before you run out of budget, and that you run out of both before the requested delivery date.

It is not possible to give here absolute numbers for any of these metrics that would indicate for a random project whether or not it is in good shape. For instance you can’t say, a project with x number of developers and y days per sprint should produce no more than z number of defects per sprint. Such statements are nonsensical. The actual values of these metrics will depend on the technology you build your systems on, the developers and testers you have, the tools and practices they use, the existing technical debt if there is any, the functional and business context the project is executed in and many, many factors more. What matters is that you determine the actual numbers that result from the execution of your project given its current context and that you know how to interpret them, so you can act accordingly.

Thursday, April 18, 2013

Agile and Prince2

Since Agile doesn’t say much about how to structure a project on a higher level, apart from release planning, it might be interesting to see if and how Agile practices can be combined with for instance a methodology like Prince2. I am going to limit this exercise to Prince2 since I have a certification in and experience with that particular methodology.

Prince2 divides a project in stages. There is the initiation stage, and then you can divide the remainder of the project in as many delivery stages as you see fit, followed by a closing stage.  Prince2 doesn’t say anything about the activities of these stages, except for the initiation stage. In that stage, a project charter, business case, risk register and so on are to be produced. This makes sense in an Agile environment too. You will have a run-up towards the first sprint where you need to define the vision, an initial story map and backlog, provide estimates, establish a fist release planning, do resource allocation, and translate this into a budget that can be included in a business case for approval by senior management. All this qualifies as an initiation stage as defined in Prince2.

During the delivery stages, you can plan whatever you see fit. This means you can take your release planning and consider the various releases of your project as stages in a Prince2 sense. You can create your stage plans as per Prince2 and describe in them the high level scope, risks and a baseline release burn-up or burn-down.  If you need to add teams or change team composition from one release to the next, that too can go in the stage plan. The stage will consist of several Sprints that make up the release. Prince2 mandates that the business case be reviewed after each stage to see if the project still makes sense and that comes very close to Agile practices indeed.

As for the roles, the central figure in Prince2 is the project manager. He has one or more teams working for him each with a team leader. There is no reason why these teams shouldn’t be Scrum teams with a Scrum Master. The project manager then becomes a sort of overall Scrum Master for the project, with all the responsibilities of a project manager in Prince2, as well as supporting the teams and other scrum masters in removing impediments. In Prince2 the users are represented in the Steering Committee by the Senior User. This person could take up the role of the Product Owner, or delegate that to someone in his organization, as long as the delegate has full autonomy and authority to make decisions the correspond to the Product Owner role.

Prince2 is based on a set of principles, that are listed in the table below.

Continued business justificationA PRINCE2 project has continued business justification
Learn from experiencePRINCE2 project teams learn from previous experience (lessons are sought, recorded and acted upon throughout the life of the project)
Defined roles and responsibilitiesA PRINCE2 project has defined and agreed roles and responsibilities with an organizational structure that engages the business, user and supplier stakeholder interests
Manage by stagesA PRINCE2 project is planned, monitored and controlled on a stage-by-stage basis
Manage by exceptionA PRINCE2 project has defined tolerances for each project objective to establish limits of delegated authority
Focus on productsA PRINCE2 project focuses on the definition and delivery of products, in particular their quality requirements
Tailor to suit the project environmentPRINCE2 is tailored to suit the project’s size, environment, complexity, importance, capability and risk

These are compatible with Agile principles and practices like iterative development, the focus on working software, clear definition of roles and empowered teams. As long as the project stays within tolerance for budget and schedule, the teams can proceed in the way that they think is best.

In short, I don’t see any fundamental incompatibilities between Prince2 and Agile. I think the combination of these two can go a long way in addressing senior management concerns on for example development teams doing whatever they want or scope not being fixed up front that you sometimes hear when an organization wants to move to Agile.