If you ask 10 people why Digital Transformations fail, you’ll get 10 different answers, often with phrases like “buy-in” and “culture” thrown around. Although there isn’t a simple answer to this question, I’d like to talk about one that often gets ignored. Dependencies.
You have a dependency if something is contingent on another, here are some examples:
“Getting this work complete is contingent on the tests passing.”
“We need the platform team to spin up a test environment before we can run the tests.”
“We need to have sign-off before we can allocate time to create the instance.”
This Agile game is based on The Penny Game. I’ve seen it in various incarnations, but this is based on the original concept. Instead of simply showing how batch size affects throughput, this game has been heavily modified to give several additional lessons. Attendees can expect to learn about Agile’s roots in Lean manufacturing, batch size theory, single piece flow, being adaptive to change, quick feedback and communication.
Each round after the first is essentially optional, you can choose exactly which lessons you wish to deliver. This may be all of them for more experienced teams, or fewer for those new to Agile.
Please note that this no longer represents my view on this subject, but is maintained for posterity.
Risk Management is a part of everyday life, crossing the street or even walking downstairs in the morning carries with it some risk factor. A project is no different. When projects were managed by default by using high overhead techniques such as PRINCE2, risk was an integral part of running a project; they were cataloged, monitored and actively mitigated through the use of logs and registers. Many of us have since abandoned these heavy methods in favour of lighter approaches, such as Scrum or Kanban. However, amid all of the confusion in the revolution, we appear to have thrown the baby out with the bath water. Even now, risk is rarely included as an active element in our practice, and rarely done well. I would propose a new method of managing risk, something lightweight that fits with our de facto practices, but with the rigour of the old guard.
What is Risk?
First, let’s define risk. The ISO31000 standard defined risk as an uncertain event, which should it occur, will have an effect on the project meeting it’s objectives. Notice the lack of connotation here, risk isn’t some inherently bad thing, it’s simply a degree of uncertainty. The message is clear, we should be looking for, and actively managing, all forms of uncertainty.
Risk sits in the middle of cause and effect, some cause may trigger an effect, although we don’t know.
Tracking Agile Projects is about monitoring the project health, and checking adherence to the schedule is a relatively simple exercise. The amount of work actually completed in an iteration is compared with the amount of work expected to be completed. Differentials are feed back into the amount of work expected to be completed in the future iterations, which has a self corrected effect on the project schedule.
Note that this no longer represents my thinking, but is maintained for posterity and ridicule.
Agile Planning and Estimating covers the activities involved in actually planning how the software being developed is going to be built, splitting up the development into manageable pieces and deciding a schedule for the release. This part of my Agile development guide is based on the excellent book by Mike Cohn, Agile Estimating and Planning.
All relevant stakeholders should be present at this meeting, including owner, Scrum master, clients and developers. For a Scrum overview, please see Agile Overview. This guide is heavily influenced by Mike Cohn’s Agile Planning and Estimation.
Choosing Themes
At project initiation, the team will meet in order to determine the themes and goals of the project. In determining these themes, many factors will need to be considered. These themes will also need to be estimated and prioritised so that the development team knows what to build. These initial themes will form the general functional requirements for the project and will be expanded upon later on, when more knowledge is gathered about exactly what needs to be done. The owner will determine the themes, but the developers will aid in this choice. Developers can help this decision by indicating the risk level or dependencies of each theme. These themes are often written on Index cards and should be considered at a high level of abstraction, such as:
As a user, I require the ability to add new cars so that I can manage my growing stock.
As a user, I should be able to buy items using a credit card so that I can process my order quickly and securely.
As a user, I want the software to record my high scores so that I can try and beat other scores.
Note that there is no technical specifics here, these are simply general, high level features that the user requires for the product.
Contrary to traditional management methods, an Agile approach considers the team to be a single cooperative unit. Individuals are not scored on the amount of work completed, but the team is monitored as a whole. This serves to improve team cohesiveness and ensure that anyone working on a project is dedicated to the success of a project through collaboration. You are all in this together.
Product Owner
The product owner is the individual responsible for establishing a common vision. This person is often the sponsor or customer of the project. The owner must be the lead in identifying features (Stories) and prioritising the workload such that the highest value is being delivered.
When somebody wants to backup either the JIRA or Confluence onDemand databases.
Context
Atlassian onDemand does not currently have any features for automating a backup of either JIRA or Confluence. To get around this we can trigger a backup from Atlassian and then automatically download the resulting file to a location of our choosing. We can take this a step further by automating this processes with a cron job on Mac or Unix, or by using Windows Task Scheduler.
Disclaimer
These scripts were based on one given for Jira by Marlon Aguiar of Atlassian, the original can be found here. Some minor modifications were made and a separate script for Confluence was created from the resulting code.
The following is an adaptation of content I wrote to help a new agile team. It was meant to be a brief skim over the surface of estimation, rather than an exhaustive document. It generally sticks to the classical agile approach, but has some additional techniques that I have found useful. The information on which this is based is largely attributable to Mike Cohn, of Mountain Goat Software, perhaps my favourite technical author of all time and, for me, certainly one of the most readable. I would love to hear peoples opinions on estimation, feel free to drop me a line with any tools and techniques that you use.
Story Points
It is very difficult to provide an off the cuff estimate for something unknown. We may hazard a guess or try and compare it to something else of similar or relative size. If asked to estimate the size of a mountain, it would be much easier to estimate it as double the size of another mountain than to specify a weight in kilograms. There is also significant scientific evidence to support the hypothesis than humans are much better at estimating relatively than absolutely.
Story points are way of estimating effort to complete a feature that decouples that tie to specific units of measurement, such as time. By estimating effort in relation to other estimates, we can derive a value for time. Because we have estimated relatively, our final value for time is likely to be more accurate.
A story point is a unit independent measurement of effort required to complete something. Features are measured in a number of story points.
I was rummaging around in some old directories and found an implementation of the Sieve of Eratosthenes that I’d thought I’d share. I thought I’d share it because of the simplicity of the algorithm, it represented a very enjoyable programming exercise and one that I now use as a standard kata when learning a new language. The Sieve of Eratosthenes is an algorithm used to identify prime numbers.
In it’s simplest form, the algorithm states:
set Array to array of size N
set Array to all true
for i from 2 to N
for each j where i divides j, j from i + 1 to N
set Array(j) to false
Basically, it trawls an array of “on” bits and “turns off” any index that is cleanly divisible by any number less than the square root of it’s size.
